Date: Fri, 15 Jan 2016 11:57:49 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160115095749.GC3942@kib.kiev.ua> In-Reply-To: <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160110154518.GU3625@kib.kiev.ua> <1773157955.158922767.1452698181137.JavaMail.zimbra@uoguelph.ca> <1351730674.159022044.1452699617235.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 14, 2016 at 10:14:18PM -0500, Rick Macklem wrote: > Kostik wrote: > > What is the exact value of lblkno ? > > > It was -1 for the crash I looked at. (Since all are the same backtrace and > happen for the same test sequence, I suspect they all are.) > > > There are two kinds of buffers with negative lblk which may exist on > > the UFS vnode queues. One is indirect block, and another is the metadata > > block. Metadata lblks are -1 and -2, indir blocks numbers are calculated > > by formula you can see in calculation of indir_lbn[] in ffs_truncate(). > > > Thanks. I knew indirect blocks were -ve block #s, but I didn't know about > the metadata ones. s/metadata/ext attributes data/ Sorry. > So, if I've understood you correctly, a -1 b_lblkno is an extattr one and > the assert should allow it and not panic? Yes. > > I can change the assert, although it will end up about 6 lines of code;-) > If you think I should do this, I will do so and test it. It is under INVARIANTS anyway. I do see a value in checking that truncation is consistent. We did have many bugs there, which usually caused user data loss. Some caution is worth it, IMO.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160115095749.GC3942>