Handling 'rm -rf' and readdir(..., off_t, ...)

Greetings All,

I have built a network file system that relies on FUSE at
the client.
We use version 2.6.5, but I do not see anything in the
recent change
logs that pertain to my problem.

We implement the newer version of readdir, taking advantage
of the
offset parameter.  We cache object attributes aggressively
in the
user-level file system client implementation.

I have run into a problem supporting 'rm -rf * in the
mounted file
system.  The command fails, reporting "directory not
empty".

For example,
$ cd /tmp/fuse
$ mkdir largedir
$ for i in `seq 1000`; do touch largedir/file_$i; done
$ rm -rf largedir/
--> Error: largedir is not empty

The 'rm -rf' command results in an operation sequence like
this
readdir(offset=0)
getattr(file_0)
unlink(file_0)
getattr(file_1)
unlink(file_1)
...
readdir(offset=128)
getattr(file_256)
unlink(file_256)
...

The first readdir command reads the first 128 children. 
Those 128
children are removed one by one.  Then the FS gets another
readdir
request to read the next batch of children.  But, FUSE sets
the offset
parameter to 128.  The FS, believing that it is being asked
for the
children in the *current* directory starting at offset 128,
returns
those children--file_256-file_384.  This, of course, means
that
file_128-file_255 are not returned by readdir and never
removed.  So
when FUSE attempts to remove largedir/, it finds the
directory is not
empty and fails.

I first thought that we were not invalidating the cached
attributes
for the parent directory (largedir) properly, but that does
not seem
to be the problem.  In fact, FUSE does not seem to re-stat
the
directory after removing the first batch of children.

Is the user-level file system implementation expected to
track how the
removal of a child should affect the interpretation of the
offset
parameter?  I would expect that the FUSE library would
recognize it
modified the directory and reset the readdir offset.

Am I misunderstanding the interface?  Any suggestions or
clarifications would be appreciated...

thanks-
patrick

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

This sounds very familiar!

Look back through the archives for September for
"Problems with rm -Rf".


On Thu, 2008-02-28 at 14:27 -0500, Patrick Eaton wrote:
> Greetings All,
> 
> I have built a network file system that relies on FUSE
at the client.
> We use version 2.6.5, but I do not see anything in the
recent change
> logs that pertain to my problem.
> 
> We implement the newer version of readdir, taking
advantage of the
> offset parameter.  We cache object attributes
aggressively in the
> user-level file system client implementation.
> 
> I have run into a problem supporting 'rm -rf * in the
mounted file
> system.  The command fails, reporting "directory
not empty".
> 
> For example,
> $ cd /tmp/fuse
> $ mkdir largedir
> $ for i in `seq 1000`; do touch largedir/file_$i; done
> $ rm -rf largedir/
> --> Error: largedir is not empty
> 
> The 'rm -rf' command results in an operation sequence
like this
> readdir(offset=0)
> getattr(file_0)
> unlink(file_0)
> getattr(file_1)
> unlink(file_1)
> ...
> readdir(offset=128)
> getattr(file_256)
> unlink(file_256)
> ...
> 
> The first readdir command reads the first 128 children.
 Those 128
> children are removed one by one.  Then the FS gets
another readdir
> request to read the next batch of children.  But, FUSE
sets the offset
> parameter to 128.  The FS, believing that it is being
asked for the
> children in the *current* directory starting at offset
128, returns
> those children--file_256-file_384.  This, of course,
means that
> file_128-file_255 are not returned by readdir and never
removed.  So
> when FUSE attempts to remove largedir/, it finds the
directory is not
> empty and fails.
> 
> I first thought that we were not invalidating the
cached attributes
> for the parent directory (largedir) properly, but that
does not seem
> to be the problem.  In fact, FUSE does not seem to
re-stat the
> directory after removing the first batch of children.
> 
> Is the user-level file system implementation expected
to track how the
> removal of a child should affect the interpretation of
the offset
> parameter?  I would expect that the FUSE library would
recognize it
> modified the directory and reset the readdir offset.
> 
> Am I misunderstanding the interface?  Any suggestions
or
> clarifications would be appreciated...
> 
> thanks-
> patrick
> 
>
------------------------------------------------------------
-------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> fuse-devel mailing list
> fuse-devellists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fuse-devel


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

Ah, yes, thank you.  I searched archives and was surprised I
could not
find a relevant thread.  It turns out I included the token
-rf, which
obediently filtered out all results I would find
interesting. ;)

Anyways, if others cross this thread, here is a link to the
original thread...
http://thread.gmane.org/gmane.comp.fil
e-systems.fuse.devel/5124/focus=5126

cheers-
patrick



On Thu, Feb 28, 2008 at 7:15 PM, Franco Broi <francofugro-fsi.com.au> wrote:
>
>  This sounds very familiar!
>
>  Look back through the archives for September for
"Problems with rm -Rf".
>
>
>
>
>  On Thu, 2008-02-28 at 14:27 -0500, Patrick Eaton
wrote:
>  > Greetings All,
>  >
>  > I have built a network file system that relies on
FUSE at the client.
>  > We use version 2.6.5, but I do not see anything
in the recent change
>  > logs that pertain to my problem.
>  >
>  > We implement the newer version of readdir, taking
advantage of the
>  > offset parameter.  We cache object attributes
aggressively in the
>  > user-level file system client implementation.
>  >
>  > I have run into a problem supporting 'rm -rf * in
the mounted file
>  > system.  The command fails, reporting
"directory not empty".
>  >
>  > For example,
>  > $ cd /tmp/fuse
>  > $ mkdir largedir
>  > $ for i in `seq 1000`; do touch largedir/file_$i;
done
>  > $ rm -rf largedir/
>  > --> Error: largedir is not empty
>  >
>  > The 'rm -rf' command results in an operation
sequence like this
>  > readdir(offset=0)
>  > getattr(file_0)
>  > unlink(file_0)
>  > getattr(file_1)
>  > unlink(file_1)
>  > ...
>  > readdir(offset=128)
>  > getattr(file_256)
>  > unlink(file_256)
>  > ...
>  >
>  > The first readdir command reads the first 128
children.  Those 128
>  > children are removed one by one.  Then the FS
gets another readdir
>  > request to read the next batch of children.  But,
FUSE sets the offset
>  > parameter to 128.  The FS, believing that it is
being asked for the
>  > children in the *current* directory starting at
offset 128, returns
>  > those children--file_256-file_384.  This, of
course, means that
>  > file_128-file_255 are not returned by readdir and
never removed.  So
>  > when FUSE attempts to remove largedir/, it finds
the directory is not
>  > empty and fails.
>  >
>  > I first thought that we were not invalidating the
cached attributes
>  > for the parent directory (largedir) properly, but
that does not seem
>  > to be the problem.  In fact, FUSE does not seem
to re-stat the
>  > directory after removing the first batch of
children.
>  >
>  > Is the user-level file system implementation
expected to track how the
>  > removal of a child should affect the
interpretation of the offset
>  > parameter?  I would expect that the FUSE library
would recognize it
>  > modified the directory and reset the readdir
offset.
>  >
>  > Am I misunderstanding the interface?  Any
suggestions or
>  > clarifications would be appreciated...
>  >
>  > thanks-
>  > patrick
>  >
>  >
------------------------------------------------------------
-------------
>  > This SF.net email is sponsored by: Microsoft
>  > Defy all challenges. Microsoft(R) Visual Studio
2008.
>  > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  > _______________________________________________
>  > fuse-devel mailing list
>  > fuse-devellists.sourceforge.net
>  > https://lists.sourceforge.net/lists/listinfo/fuse-devel
>
>

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel