Re: [fuse-devel] Avoiding NFS stale file handles

[Miklos S. <mi...@sz...>]

tomm <to...@li...> writes:

> Miklos Szeredi <miklos@...> writes:
>> 
>> tomm <tomm@...> writes:
>> 
>> > Having read probably every post on the subject of fuse/nfs, will this
>> > scenario work to make NFS reliable?
>> >
>> > 1. Mount fuse filesystem with the use_ino option.
>> > 2. Provide a 32-bit unchanging value in the st_ino field that is unique
>> > to every
>> > file and directory and never re-used even if the file or directory is
>> > deleted.
>> 
>> If the filesystem uses the high level API (fuse.h) then you need to use
>> either the 'noforget' or the 'remember=NNN' options.  Providing a stable
>> and unique st_ino value is not enough and is actually not used for the
>> construction of the file handle to be used by NFS.
>> 
>> Alternatively you can provide a unique inode number in the low level
>> API (fuse_lowlevel.h) that will be used for NFS file handles.
>> 
>> Thanks,
>> Miklos
>> 
>
> Thank you Miklos. I've studied the fuse code and I understand now the
> limitations of using NFS with high level API.  Please provide your thoughts on
> the following scenario:
>
> Suppose you have a fuse file system using the high level API and mounted with
> the 'noforget' option, but not the 'use_ino' option (so fuse is assigning
> nodeid's).
>
> In addition, this file system is exported via NFS and mounted by two clients,
> client A and client B.
>
> Now client A starts traversing the file system and fuse starts allocating nodes
> and assigning nodeid's.
>
> Next, the fuse file system is un-mounted and then re-mounted with same options.
>
> Now client B starts traversing the file system and fuse starts allocating nodes
> and assigning nodeid's, but this will be re-using nodeid's from when client A
> traversed the file system because it was re-mounted.
>
> Now if client A starts accessing files, all it's file handles are invalid, but
> client A does not know this.
>
> Question is this: isn't it possible in this scenario for client A to start
> manipulating the wrong files?

Yes, sounds plausible.

>
> I believe this is true, and my solution is patch fuse.c to initialize the
> generation variable in 'struct fuse' with the time-of-day instead of with 0.
> This ensures a different generation value for each file system mount and
> forcing all clients to get stale file handles in this scenario.
>
> Do you see any flaws in my reasoning?

It looks like a good bug fix, certainly.

Can you please send a patch?

Thanks,
Miklos