Date: Fri, 15 Jan 2016 21:00:05 -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: <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20160115095749.GC3942@kib.kiev.ua> 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> <20160115095749.GC3942@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_162823116_2090676742.1452909605926 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Kostik wrote: > 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. > No problem. Extended attributes are metadata and I suspect there might be other metadata handled this way someday. > > 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. > > I've attached the patch with the modified test for the panic. I ran a test with the old one (with the panic changed to a printf) just before this one and the printf happened, but no panic. After the test, the file system fsck'd ok, so I think this might be ok. I've added Kirk as a cc. Maybe he can review this? I can't do commits until mid-April, so maybe you can commit it? (I don't think there is any rush, since almost everyone will be using soft updates. To be honest, I have no idea why I turned off soft updates at some point for this filesystem.) Thanks for your help, rick ------=_Part_162823116_2090676742.1452909605926 Content-Type: text/x-patch; name=ffsinode.patch Content-Disposition: attachment; filename=ffsinode.patch Content-Transfer-Encoding: base64 LS0tIHVmcy9mZnMvZmZzX2lub2RlLmMuc2F2CTIwMTYtMDEtMTAgMjA6MTE6NDYuNDA2NjgyMDAw IC0wNTAwCisrKyB1ZnMvZmZzL2Zmc19pbm9kZS5jCTIwMTYtMDEtMTUgMTc6MjI6NTguNDY1OTkx MDAwIC0wNTAwCkBAIC01NDQsNyArNTQ0LDEyIEBAIGRvbmU6CiAJQk9fTE9DSyhibyk7CiAJaWYg KGxlbmd0aCA9PSAwICYmCiAJICAgIChmcy0+ZnNfbWFnaWMgIT0gRlNfVUZTMl9NQUdJQyB8fCBp cC0+aV9kaW4yLT5kaV9leHRzaXplID09IDApICYmCi0JICAgIChiby0+Ym9fZGlydHkuYnZfY250 ID4gMCB8fCBiby0+Ym9fY2xlYW4uYnZfY250ID4gMCkpCisJICAgICgoYm8tPmJvX2RpcnR5LmJ2 X2NudCA+IDAgJiYgKFRBSUxRX0VNUFRZKCZiby0+Ym9fZGlydHkuYnZfaGQpIHx8CisJICAgICBU QUlMUV9GSVJTVCgmYm8tPmJvX2RpcnR5LmJ2X2hkKS0+Yl9sYmxrbm8gPj0gMCB8fAorCSAgICAg VEFJTFFfRklSU1QoJmJvLT5ib19kaXJ0eS5idl9oZCktPmJfbGJsa25vIDwgLTIpKSB8fAorCSAg ICAgKGJvLT5ib19jbGVhbi5idl9jbnQgPiAwICYmIChUQUlMUV9FTVBUWSgmYm8tPmJvX2NsZWFu LmJ2X2hkKSB8fAorCSAgICAgVEFJTFFfRklSU1QoJmJvLT5ib19jbGVhbi5idl9oZCktPmJfbGJs a25vID49IDAgfHwKKwkgICAgIFRBSUxRX0ZJUlNUKCZiby0+Ym9fY2xlYW4uYnZfaGQpLT5iX2xi bGtubyA8IC0yKSkpKQogCQlwYW5pYygiZmZzX3RydW5jYXRlMyIpOwogCUJPX1VOTE9DSyhibyk7 CiAjZW5kaWYgLyogSU5WQVJJQU5UUyAqLwo= ------=_Part_162823116_2090676742.1452909605926--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1817287612.162823118.1452909605928.JavaMail.zimbra>