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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160115095749.GC3942>