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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message