Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Feb 2016 18:19:28 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        FreeBSD Filesystems <freebsd-fs@freebsd.org>,  Kirk McKusick <mckusick@mckusick.com>
Subject:   Re: panic ffs_truncate3 (maybe fuse being evil)
Message-ID:  <1548616575.1027329.1454455168829.JavaMail.zimbra@uoguelph.ca>
In-Reply-To: <20160202144812.GZ91220@kib.kiev.ua>
References:  <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> <20160201221710.GR91220@kib.kiev.ua> <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> <20160202144812.GZ91220@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Kostik wrote:
> 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.
> 
I didn't notice the di_extsize > 0 and I see the panic is with di_extsize == 0.
(At a glance I didn't see anything suspicious in vinvalbuf() anyhow.)

> > 
> > 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.
Unfortunately I doubt a simple program will reproduce it.
GlusterFS loves to read extended attributes, so I'd guess it has read at least
100,000 of them by the time it hits the panic in a test run.
(It loves doing system calls, so I don't run ktrace for long, but I recall 10+
 get_link_extattr (or whatever the exact name is, the "get extended attribute without
 following symlinks" one) in a 1second ktrace.)

rick

> 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.
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1548616575.1027329.1454455168829.JavaMail.zimbra>