I had occasion to deal with a system whose hardware RAID-5 had lost a component and operated in degraded mode for some time. Following a power failure, the machine (a DELL PowerEdge 2550, IIRC) refused to boot from the degraded, but operational RAID.
The failed component was replaced and the RAID card's firmware utility was used to reconstruct the logical volume. The machine then proceeded to boot, but the filesystem check revealed very damaged filesystems. Fortunately, the owner of the system had practiced good separation of infrastructure vs application. I ultimately declared the OS filesystems a total loss and installed a fresh 6.1_STABLE from sometime in the middle of 2013 (and recently updated, then updated to i386-6.99.40). The remaining filesystem is where the user's data resides. From my previous attempts at salvaging the OS filesystems, I can expect more orphaned files than can be referenced in a single "lost+found" directory. >From a brief perusal of "fsck_ffs" sourcecode, it appears that if the "linkup()" routine returns 0 (zero) for any reason, the inode being processed is simply cleared. I'd like to give the best possible chance to recover data but I don't really feel like having to approve 65534 reconnections. I'd like to use the "-y" option, but have fsck exit if it can't attach the orphan file. Then I can move the "lost+found" directory out of the way and start over with a new one. That seem reasonable? -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
