Recovering filesystem with large number of orphaned inodes?

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

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