[PVFS2-internal] Re: [PVFS2-CVS] token adjustment?
rross at mcs.anl.gov
Mon Feb 9 17:36:26 EST 2004
On Mon, 9 Feb 2004 neillm at mcs.anl.gov wrote:
> On Mon, Feb 09, 2004 at 04:07:16PM -0600, Rob Ross wrote:
> > Those tokens were supposed to be opaque values, so we should not be doing
> > math on them on the client side!
> Yep, well we have a problem. When a 'rm -rf' is issued, a readdir is
> issued, followed by unlinks of all of those entries returned. This
> readdir/unlink is repeated until all entries in the directory are
> removed, when finally the directory itself is removed.
> We keep state between readdir calls in the VFS to get full listings.
> And that means we store the position and keep bumping it up for the
> next issued readdir. Problem is that in the above scenario, we can't
> do that because 'opaque offset 40' will no longer be valid if there
> are only 2 remaining entries in the directory (which say originally
> had 42 entries).
> > Can someone please explain how things are set up right now, so that we can
> > discuss this some?
> Done. If there's a better solution, I'm interested, as I tried to
> consult Phil earlier to no avail.
I'm worried about the client playing with that value because it's a hack
-- there's really no way to know for sure that the client is getting it
I think that perhaps we should return a code from PVFS_sys_readdir() that
indicates the directory has changed since the token was issued and force a
restart at the beginning of the directory? This should be just fine for
My concern with that plan is that someone creating files like mad in a
directory might make it nearly impossible to read the whole thing.
Maybe the restart is only necessary when something is *removed*?
More information about the PVFS2-CVS