Date: Tue, 2 Feb 2016 16:48:12 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, Kirk McKusick <mckusick@mckusick.com> Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160202144812.GZ91220@kib.kiev.ua> In-Reply-To: <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160202144812.GZ91220>