Hey all... I just got BURNed by this (literally). The hotplug logic for automounting USB flash memory includes the "sync" option. If you are using stock USB flash keys/sticks/cards with FAT/VFAT file systems, this will eventually cause the flash to burn up (possibly sooner than later)! Flash devices don't have indefinite read/write cycles. They can and do eventually wear out. The FAT tables on the FAT/VFAT file systems are particularly vulnerable to this. I've had CF cards burn up in PDAs just from being set to automatically back the PDA up periodically and then there was a FAT rewrite for every file (hundreds) it backed up every night. Good night CF card after a couple of months. So... What does this have to do with USB flash keys and the hotplug logic. By adding the "sync" option, all writes are synced to the drive. That makes the drive REALLY REALLY slow but it also insures that the data is written in case the poor chump pulls out the key before unmounting it. Unfortunately, that also means that the FAT table is constantly being rewritten, as each block is allocated to a new file or directory, during write operations (making the drive even SLOWER). I'm not sure if it's on a block by block or a cluster by cluster basis, but it's still a massive amount of rewriting of that small region of flash. I had noticed that flash keys that were automounted tended to be really slow compared to flash keys that I mounted manually but that they would umount really fast and there was no delay if I typed sync. Manually mounted keys would take a long time (with lots of activity on the key) to umount or to sync after writing data, even though the writes went really really quick. Well, I understood why the manually mounted keys behaved the way they did. The system was flushing the buffer caches. I didn't know why the hotplug mounted keys were acting different and hadn't gotten around to looking into it. Now I REALLY wished I had. I had also noticed that the first time writing a file to an automounted key was slow but subsequent rewrites (even if the key had been unpluged and reinserted) was quiet snappy. Now I know that because of the additional rewriting/overwriting of the FAT tables during allocation of new blocks to a new file. In hindsight, it should have been a clue. I just copied a 700 Meg file to a 1G USB key and didn't realize it was set up with a "sync" mount option. It took forever (more than 30 minutes), even though it was USB 2.0. And then, when it was done, the key was unusable. The lead part of the flash (MBR and FAT tables) was burned out. Hard read errors on insertion. So the first block in the flash was fried. That's when I checked the mount options and realized that the hotplug logic was adding the sync option. BE FOREWARNED! If you are going to write massive amounts of data (lots of little files or even just one great big one) to USB keys with FAT file systems, do NOT use the hotplug automounts! Unmount the key and mount it somewhere else without the sync option. Writing will run much much faster, though unmounting and sync will take longer. Your TOTAL time is better because some sections of the key are overwritten thousands of times if the sync option is enabled but only a few times if it's not. AND! You will extend the life of your USB flash keys immensely! I understand that some intelligent keys may be better than others by rotating the logical blocks to different physical locations in the physical flash to even out wear, but I'm betting nobody here can tell which ones do and which ones don't. I can't except after the fact when it's too late. :-( Now... If I can just find the inDUHvidual who stuck that STUPID option in there so I can beat the crap out of him with a clue-by-four... $70 USB key shot in the ass because of an assinine mount option. Grrr... How do you file a "mount option causes hardware to burn up" in bugzilla? I guess I'm gonna find out... Mike -- Michael H. Warfield | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
