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.
don't have enough time right now to continue searching code/printk'ing
and rebooting.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
