Writes to usb flash drive cached

I know Martin knows this already, but Thue, it seems that we can't win here:

pmount (0.8-2) unstable; urgency=high

  * Urgency high since this fixes an RC bug, the fix should reach Sarge.
  * Added debian/patches/02-async_by_default.patch:
    - Mount devices 'async' by default instead of 'sync'. This will avoid
      physical damage of flash chips due to exaggerated updating of inode/FAT
      structures and greatly speed up the write throughput. On the bad side
      this makes it much less safe to remove devices without proper umounting.
    - Replace option "--async" with option "--sync".
    - Document change in the manpages.
    - Closes: #309591
  * debian/control: Correct package priority to optional, to match the katie
    overrides.

 -- Martin Pitt <email address hidden> Wed, 18 May 2005 15:41:13 +0200

(In reply to comment #0)
>
> This is not very intuitive for new users, who expect to be able to just remove
> the flash RAM when they can see the activity light is not active.

As Colin already mentioned, using "sync" is out of question. When using
removable devices you just have to be a bit careful, there is no other way.

I read through the comments from the debian bug
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309591), and while the problem
is not as trivial as changing a mount option it does seem fixable.

To recab, the problem is described here:
http://readlist.com/lists/vger.kernel.org/linux-kernel/22/111748.html . It seems
that the problem is that the FAT region
(http://en.wikipedia.org/wiki/File_Allocation_Table#Design) is written repeatably.

A possible fix would be to implement a new --flashsync mount option for FAT file
systems, where the FAT table was only written say once every 5 seconds, or when
there had not been any write activity for 1/2 second. (values choosen a bit
arbitrarily, but such that a user would not pull out the device because
inactivity led the user to believe the write had finished, and such that the FAT
region does not get too far out of sync). Any potential for corruption with this
scheme would probably be smaller than the current situation.

What does MS do here? I don't think they would leave this problem unsolved?

"Safely remove device" in system try, same thing as unmounting.

Actually, from testing right here on a Win32 machine, it does appear that
copying to a flash device in Windows is done synchronously. Since I've never
managed to kill a flash card in copying massive amounts of data to one in
Windows, I can only assume they've worked around this in their FAT driver, and
we should be looking to do the same. The sane thing would seem to be "block all
other writes to the filesystem, allocate free blocks, write out file, update
FAT, unblock", lather/rinse/repeat. That would avoid the "copying one file
updates the FAT thousands of times" problem, while keeping multiple file
operations from walking all over each other. It also buys a certain level of
atomicity that FAT isn't generally known to have (if the copy is cut short,
those used blocks will just become free, as if no data was ever copied, because
you never wrote the entry out to the FAT).

Perhaps this should be reassigned to the kernel, and someone should look at the
above hack, or something similar.

Does anybody have any news about synchronously writing to flash disks in Linux like in Win32 since 2005 year? (For abitity to hot remove the USB stick)