[PATCH] Set the DE_UPDATE flag on the directory node on msdosfs
brde at optusnet.com.au
Fri Jun 3 08:25:13 UTC 2011
On Fri, 3 Jun 2011, Kevin Lo wrote:
> Kevin Lo wrote:
>> If you try to NFS export a fat32 formatted external usb devices,
>> you'll notice if a new file is created, you won't see that file
>> on the NFS client. The reason is msdosfs(5) doesn't change the
>> modify time of the directory when an entry is created.
>> Attached is a patch against HEAD that sets DE_UPDATE on the
>> directory node in both createde() and removede().
>> Please test it, thanks.
It breaks compatibility with MSDOS and Windows.
No correct fix is evident. ffs maintains the generation count va_filerev
which should help, but:
- ffs only increments it when a file mtime is updated.
- msdosfs doesn't properly maintain it (it initializes to a non-random
number related to the current time when the vnode is initialized, but
never increments it).
- the old nfs client doesn't use it
- the new nfs client does use it for v4. I don't know if this use is
sufficient (it has to get it from the server to work for this).
I wonder if the problem is larger with negative caching. Negative caching
also uses the ctime, and msdosfs doesn't even have a ctime (it fakes it as
the mtime, but that works especially badly for directories since the mtime
is never changed after birth for directoroes, and negative caching needs
the time[s] to be updated especially for directories).
The only reasonably correct fix seems to be to make the directory timeouts
especially small for nfs mounts of remote msdosfs file systems (or any file
systems that don't update mtimes for directories, or don't have ctimes).
Granularity of times is also a problem. It is 1 second by default for ffs,
and can be reduced, but for msdosfs it is 2 seconds and cannot be reduced.
So it is fairly easy even for ffs to have changes that don't change file
timestamps. Using va_filerev is the correct fix for this.
More information about the freebsd-fs