Date: Mon, 20 Jan 2003 10:14:47 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: Jan Srzednicki <winfried@student.agh.edu.pl> Cc: current@FreeBSD.ORG Subject: Re: background fsck did not create lost+found Message-ID: <20030120161446.GF49032@dan.emsphone.com> In-Reply-To: <Pine.GSO.4.44.0301201630350.22474-100000@student.uci.agh.edu.pl> References: <Pine.GSO.4.44.0301201630350.22474-100000@student.uci.agh.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jan 20), Jan Srzednicki said: > After building new world and installing new kernel, I rebooted my > machine to launch a new kernel. The system mysteriously failed to > flush 22 disk buffers, and after reboot fsck was launched. [...] > This massive disk mangling occured on /usr, but still, one file in > /home got lost - which happened to be quite important file. > Background fsck logged: > > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065 OWNER=winfried MODE=100644 > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 15:57 2003 (CLEARED) > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: Reclaimed: 0 directories, 8 files, 16439 fragments > Jan 20 16:06:30 stronghold root: /dev/ad1s1d: 33802 files, 13109700 used, 6310697 free (11577 frags, 787390 blocks, 0.1% fragmentation) > > First two entries clearly correspond to the missing file, which > should have been put in /home/lost+found. But, the poroblem is that > no lost+found directory was created, while it should (as fsck_ffs(8) > says). I guess its a bug, probably in the background fsck code. > Still, is there any way to reclaim the file now, besides running > strings(1) on the whole partition? It's not a bug. Softupdates works by guaranteeing that the only things that a background fsck needs to do are reduce link counts, clear inodes, and fix free-space bitmaps. Bgfsck will clear a file's space rather than put it in lost+found. This means that if you delete a file, immediately create a new one with the same name, and then reboot within 30 seconds, both files will be gone. You can minimize the risk by lowering the kern.metadelay, kern.dirdelay, and kern.filedelay sysctl values, but the lower you go, the less benefit you get. String'ing the raw partition is probably your best bet for recovering the data. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030120161446.GF49032>