From owner-freebsd-fs@freebsd.org Tue Feb 2 14:48:22 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA82FA99E06 for ; Tue, 2 Feb 2016 14:48:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 656BA1BD8 for ; Tue, 2 Feb 2016 14:48:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u12EmCRA061406 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 16:48:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u12EmCRA061406 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u12EmCOU061405; Tue, 2 Feb 2016 16:48:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Feb 2016 16:48:12 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160202144812.GZ91220@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 14:48:22 -0000 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.