Re: [PATCH v2 4/5] fat: eliminate orphaned inode number allocation

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]

On Tue, 4 Sep 2012 15:25:09 -0400 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Wed, Sep 05, 2012 at 04:02:13AM +0900, OGAWA Hirofumi wrote:
> > "J. Bruce Fields" <bfields@fieldses.org> writes:
> > 
> > > On Wed, Sep 05, 2012 at 02:07:40AM +0900, OGAWA Hirofumi wrote:
> > >> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> > >> 
> > >> > Namjae Jeon <linkinjeon@gmail.com> writes:
> > >> >
> > >> >> From: Namjae Jeon <namjae.jeon@samsung.com>
> > >> >>
> > >> >> Maintain a list of inode(i_pos) numbers of orphaned inodes (i.e the
> > >> >> inodes that have been unlinked but still having open file
> > >> >> descriptors).At file/directory creation time, skip using such i_pos
> > >> >> values.Removal of the i_pos from the list is done during inode eviction.
> > >> >
> > >> > What happens if the directory (has busy entries) was completely removed?
> > >> >
> > >> >
> > >> > And Al's point is important for NFS too. If you want stable ino for NFS,
> > >> > you never can't change it.
> > >> 
> > >> s/never can't/never can/
> > >
> > > If vfat exports aren't fixable, maybe we should just remove that
> > > feature?
> > >
> > > I'm afraid that having unfixable half-working vfat exports is just an
> > > attractive nuisance that causes users and developers to waste their
> > > time....
> > 
> > In historically, it was introduced by Neil Brown, when nfs export
> > interface was rewritten (I'm not sure what was intended).
> > 
> > Personally, I'm ok to remove it though, it is really personal
> > opinion. The state would be rather I don't have strong opinion to
> > remove.
> 
> Neil, any opinion?
> 
> If we can document circumstances under which nfs exports of fat
> filesystems are reliable, fine.
> 
> Otherwise I'd rather just be clear that we don't support it.
> 
> --b.


I think that is important to maintain support for NFS export of VFAT on a
best-effort basis.  We can't provide 100% guarantees of all NFS semantics but
that doesn't prevent it from being of real practical benefit to people.

If the usage pattern is "open/read/close" or "open/write/close" while no
other client is accessing the filesystem and while the server is not under
aggressive memory pressure, then it should work quite reliably.

If you rename files while they are open, have lots of file concurrently open,
allow the server to experience high memory pressure (e.g. reading/writing
multiple files that are bigger than memory) etc etc then things can start to
fail.

VFAT is widely used as a file-transfer protocol.  If you use NFS/VFAT in that
way it works fine.  If you try to use it as a general file access protocol,
that is when you hit problems.

The patch series tries to make inode number stable across reboot.  I think
this is not worth the effort as you won't make VFAT access more reliable,
you'll just make it fail differently.

The only real answer to more reliable NFS access to VFAT is the NFSv4 concept
of volatile file handles.  Unfortunately NFSv4 hasn't yet specified these
with sufficient precision to actually use them.

So if anyone wants to improve VFAT/NFS, I suggest that the first step is to
work with the NFSV4-WG to get an implementable specification.  Good luck with
that.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]