On Fri, Apr 12, 2019 at 04:13:00PM -0700, Kirk McKusick wrote:> > Peter Holm <peter at 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
> Date: Sat, 13 Apr 2019 14:32:45 +0200 > From: Peter Holm <peter at holm.cc> > To: Kirk McKusick <mckusick at mckusick.com> > Cc: Jamie Landeg-Jones <jamie at catflap.org>, jamie at catflap.dyslexicfish.net, > Warner Losh <imp at bsdimp.com>, freebsd-stable at freebsd.org > Subject: Re: Replicable file-system corruption due to fsck/ufs > > On Fri, Apr 12, 2019 at 04:13:00PM -0700, Kirk McKusick wrote: > >> 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. > > -- > PeterGreat, thanks for the quick test. Now committed to head as -r346185. Kirk