> While the intelligent FAT driver would cache the > directory and file node information on the flash drive, any changes > have to be written as soon as they're made in case the drive is > detached unexpectedly That's exactly why you need to use the ugly "safely remove harddisk" tool (or how is it called). The OS applies write cache on those devices and leaves data unwritten until you click on that icon on taskbar. Maybe there is a timeout when if you do not do anything it will flush all data as once, but anyway, as caching is a dumb way to deal with the device, at this level the OS does not know if the FAT or file had been written therefore the FAT table can be inconsistent if you just remove the disk. And of course FAT is NOT a journaling file system so you can ruin your whole partition like that. I suppose the same would happen with Linux if you forget to unmount the flashdrive first. Tamas On 4/10/07, M. Adam Davis wrote: > > The way flash drives are handled is quite interesting. > > You have these layers: > Computer-->FAT filesystem driver-->scsi driver-->usb host stack-->usb > device stack-->scsi emulation-->buffering-->wear leveling-->NAND flash > > The computer sees the drive as a scsi drive, a generic block device. > > So the first block is the boot block, partition, FAT, etc just as with > a hard drive. While the intelligent FAT driver would cache the > directory and file node information on the flash drive, any changes > have to be written as soon as they're made in case the drive is > detached unexpectedly, so a lot of unnecessary writes take place while > writing a lot of little files, and in some cases one big file. A Fat > driver may instead re-read some of the directory nodes each time a new > file is placed on the drive, which would considerably slow transfer. > > All USB drives have some amount of memory on them to buffer the > incoming data. It could also be that the better drive has more RAM, > or merely a more efficient algorithm to handle the USB transfer to > memory buffering. > > Lastly, due to the flash wear leveling must be used. The cheaper > drive may implement a poor leveling scheme. There are lots of ways > this could slow things down for long transfers. > > -Adam > > On 4/9/07, Dr Skip wrote: > > I just finished some informal testing of several jump drives, and it > > raised some questions. Perhaps someone here can explain this... > > > > I tested 2 drives on opposite ends of the advertised speed spectrum - > > one said 30MB/s read, 20 MB/s write (assuming the PC can do that) and > > was expensive, and the other was a 2 GB unit store brand for $15. No > > speed rating and the absolute cheapest I could find. Available by the > > handful in a barrel! Both were mounted in the same port on the same PC, > > with write caching turned off. > > > > With a read/seek/write test utility, they both showed 8.5MB/s writes for > > 5MB worth of data. This may be a limitation of the speed of the host PC, > > but not bad. > > > > An extended, 2GB write, slowed to 1MB/s on the first drive near the end, > > while the cheap one dropped to 200kB/s toward the end. The fast one took > > about 15-20 minutes to fill, the second took almost 2 hours. The first > > is reasonable to use real time, the second isn't. > > > > Considering there is no physical seek time, what would cause the speeds > > to drop so much over the full transfer? Why can't the speed be > maintained? > > > > BTW, in comparison with a real hard drive, the port itself doesn't seem > > to slow down and the real drive maintains transfer rate, so that should > > rule out any PC buffering problem, at least to this big of a degree. > > > > Any ideas? > > > > -Skip > > > > -- > > http://www.piclist.com PIC/SX FAQ & list archive > > View/change your membership options at > > http://mailman.mit.edu/mailman/listinfo/piclist > > > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - > Moving in southeast Michigan? Buy my house: http://ubasics.com/house/ > > Interested in electronics? Check out the projects at http://ubasics.com > > Building your own house? Check out http://ubasics.com/home/ > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- unPIC -- The PIC Disassembler http://unpic.sourceforge.net -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist