On Fri, 2006-01-20 at 14:55 -0500, Shaya Potter wrote:
> On Fri, 2006-01-20 at 14:52 -0500, Josef Sipek wrote:
> > On Fri, Jan 20, 2006 at 02:18:22PM -0500, Shaya Potter wrote:
> > > On Fri, 2006-01-20 at 13:50 -0500, Shaya Potter wrote:
> > > > On Fri, 2006-01-20 at 13:43 -0500, Josef Sipek wrote:
> > > > > On Thu, Jan 19, 2006 at 02:05:44PM -0500, Shaya Potter wrote:
> > > > > > this patch changes the use of the read/write lock to force
> > > > > > serialization
> > > > > > on the branch table.
> > > > > >
> > > > > > basically, any entry point that can change it (ioctl for
> > > > > > adding/changing
> > > > > > mode/inc) is taken with write, while every other fs entry point
> > > > > > (lookup,
> > > > > > read, write....) is taken with read. basically to force the fs not
> > > > > > to
> > > > > > be in use when a branching operation is taking place.
> > > > > >
> > > > > > thoughts?
> > > > >
> > > > > I tried the patch, It failed on the regression tests :)
> > > > >
> > > > > A kernel BUG croped up in super.c:132, which happens with the
> > > > > bug418.sh
> > > > > test.
> > > >
> > > > hmm, ok, thanks for showing me how to reproduce it. It happened to me
> > > > once before, but then I made some other changes and wasn't able to
> > > > reproduce it.
> > >
> > > possibly related, before the BUG, this happens.
> > >
> > > bug418.sh: write: Stale NFS file handle,
> > >
> > > don't know why that would happen on ext3, that's because
> > > unionfs_file_revalidate is returning it. dont know why that would
> > > happen.
> >
> > I have always seen that message, so I assumed that it was "normal." But
> > then again, it could be a bug of some sort. (I saw it on ext{2,3}, xfs,
> > reiserfs, you name it.)
>
> it's being returned because when unionfs_d_revalidate calls
> unionfs_lookup_backend() and gets 0 back as a result. this propegates
> back to file_revalidate (called from write() )and since it's not delete,
> returns ESTALE.
this code may be wrong in unionfs_d_revalidate()
result =
unionfs_lookup_backend(dentry,
positive ? INTERPOSE_REVAL :
INTERPOSE_REVAL_NEG);
if (!result || IS_ERR(result)) {
err = 0;
goto out;
}
as unionfs_lookup_backend() will return 0 on success (perhaps
incorrectly, and this is where the actual bug is)
at the end of unionfs_lookup_backend() it calls
if ((err = unionfs_interpose(sb->s_root, sb, 0)))
goto out_freedpd;
that's the last time it will set err (with 0 if unionfs_interpose()
works), which is what unionfs_lookup_backend() will return to
unionfs_d_revalidate() which is why it will consider it to be an error,
which is why it will tell unionfs_file_revalidate() that the dentry
isn't valid anymore.
if you remove the !result, it works w/o any ESTALE.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
