Date: Sat, 13 Apr 2019 14:32:45 +0200 From: Peter Holm <peter@holm.cc> To: Kirk McKusick <mckusick@mckusick.com> Cc: Jamie Landeg-Jones <jamie@catflap.org>, jamie@catflap.dyslexicfish.net, Warner Losh <imp@bsdimp.com>, freebsd-stable@freebsd.org Subject: Re: Replicable file-system corruption due to fsck/ufs Message-ID: <20190413123245.GA64592@x2.osted.lan> In-Reply-To: <201904122313.x3CND02n069663@chez.mckusick.com> References: <20190411043620.GA87473@x2.osted.lan> <201904122313.x3CND02n069663@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 12, 2019 at 04:13:00PM -0700, Kirk McKusick wrote: > > Peter Holm <peter@holm.cc> wrote: > > > >> I see this even with a single truncate on HEAD. > >> > >> $ ./truncate10.sh > >> 96 -rw-r--r-- 1 root wheel 1073741824 11 apr. 06:33 test > >> ** /dev/md10a > >> ** Last Mounted on /mnt > >> ** Phase 1 - Check Blocks and Sizes > >> INODE 3: FILE SIZE 1073741824 BEYOND END OF ALLOCATED FILE, SIZE SHOULD BE 268435456 > >> ADJUST? yes > > > > Thanks.. I should have tested that myself.. doh! I was trying to > > closer replicate my real file that triggered the problem which > > contained a number of sparse areas. > > > > And thanks for adding Kirk to the discussion. I wanted to first be > > sure it wasn't just me :-) > > > > Cheers, Jamie > > This is indeed a bug in the calculation of the location of the last > block of a file. I believe that the following patch to head will > fix it. > > Peter, can you please test and let me know. > > If Peter confirms that it fixes the bug, I will check it into head > and MFC it to 12-stable and 11-stable after a 2-week settle-in time. > > Kirk McKusick > Yes, this patch works for me. -- Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190413123245.GA64592>