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>