panic ffs_truncate3 (maybe fuse being evil)

Konstantin Belousov kostikbel at gmail.com
Tue Feb 2 14:48:22 UTC 2016


On Mon, Feb 01, 2016 at 08:07:19PM -0500, Rick Macklem wrote:
> Kostik wrote:
> > On Mon, Jan 18, 2016 at 11:25:16PM -0500, Rick Macklem wrote:
> > > Kostik wrote:
> > > > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote:
> > > > > Kostik wrote:
> > > > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the
> > > > > > assert ffs_truncate3 fired ?
> > > > > > 
> > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both
> > > > > IO_EXT | IO_NORMAL.
> > > > 
> > > > Please try this.
> > > > 
> > > Still happens. I put the old panic test in, but with a printf() instead
> > > of panic() and the printf() happens with this patch.
> > > Btw, whenever I've looked, the entry is on the clean list.
> > > No other panics happen and the file system fsck's fine after the test run.
> > 
> > I thought that you posted a stand-alone program which triggered the issue
> > on non-SU mounts, but I cannot find it.  Does such program exist, or this
> > is just me misremembering ?
> > 
> Nope. I do a test run using GlusterFS (a FreeBSD kernel build with the sources
> on GlusterFS) where the bricks are on UFS file systems with SU disabled.
> 
> To be honest, I've been using ZFS for tests lately, so I'm not even sure I
> remember exactly what the test setup was, but I think the above is it.
> (It takes 2-3hrs for an occurrence to happen.)
> 
> I did plan on taking a look at vinvalbuf(..V_ALT..), since that is what I
> think should be getting rid of the extended attribute block, but haven't
> done so.
I doubt that this is vinvalbuf(), more likely it is stray buffer forgotten
by some cleanup code.  Note that ffs_truncate() condition to call
vinvalbuf(V_ALT) is that IO_EXT flag is passed and dinode di_extsize field
value is > 0.

> 
> If you have another patch to try, email it and I'll try and reproduce the
> failure without/with the patch.
I asked about the test program to be able to trace the issue.
I do think that the IO_UNIT patch fixes some situations where the buffer
can be left on the vnode queue.  I did not found any other places so far.


More information about the freebsd-fs mailing list