[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: vfat BKL/lock_super regression in v2.6.26-rc3-g8f59342
* Linus Torvalds <> [080819 20:56]:
> So one thing we could perhaps consider is to make FAT in particular
> consider "sync" mounts to be about open/close consistency, not about
> per-write-system-call consistency. So the "close()" wouldn't return until
> the file is on disk, but we wouldn't force a synchronous rewrite the inode
> or the file allocation table thousands of times just because the file was
> big.

I was reading the vfat code, and it turns out that vfat has a "flush"
mount option. Which is documented in the code (not in the manpage) as:

struct fat_mount_options {
flush:1, /* write things quickly */

Since that was very informative I looked at the usage. It's used
in fat_file_release() to do almost what you describe. But it seems to
be a best effort thing. If my data doesn't hit the disk (or flash) in
HZ/10, then all bets are off.



 \ /
  Last update: 2008-08-20 04:29    [W:0.071 / U:3.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site