Memory requirement for fsck_ffs in recovery session

[Lowell Gilbert]

Polytropon <freebsd at edvax.de> writes:

> I have another problem trying to recover my data that has been "destroyed"
> (in fact, it's just inaccessible because the inode at the entry od my
> home directory died).
>
> I'm using a dd image which reproduces the exact error of the defective
> hard disk partition, I run fsck_ffs on a md type vnode.
>
> 	# mount -t ufs /dev/ad2s1h /mnt
> 	# mdconfig -a -t vnode -u 0 -f /mnt/home/poly/rescue/ad0s1f.dd
> 	# fsck_ffs /dev/md0
>
> Up to this point, I tried to use fsck_ffs from FreeBSD version 7, which
> always left me with this:
>
> 	fsck_ffs: bad inode number 306176 to nextinode
>
> Examining fsck_ffs, I found ot that lastvalidinum = 306175, but that's
> a story for another time. :-) I always thought I needed to modify the
> file system so fsck_ffs could do its job, now I think I rather would
> modify fsck_ffs so it would skip these errors I can't see any reason
> for.

I'm not following your logic, but I suspect you're jumping into
dangerous waters here...

> Out of curiosity, I booted my system with a done version 5 installation
> harddisk I had extracted from a system some years ago, and guess what?
> fsck_ffs version 5 seemed to do more than version 7 did! This is what I
> get:
>
> 	fsck_ffs: cannot alloc 1073796864 bytes for inoinfo
>
> My question: My machine has 768 MB RAM (512 + 256 MB SDR-SDRAM) and
> fsck_ffs seems to request 1 GB RAM (1073796864/1024/1024/1024). Is
> it possible to provide this amount of RAM via a harddisk backed RAM
> disk or a swap partition?

Swap should be fine; the allocation is just a regular calloc(3) call.

> I think I'll try ffsck_ffs version 6 from a PC-BSD installation that
> must be somewhere around here...

Not likely to help, but since you aren't working with the original
disk, you don't have much to lose by trying...

-- 
Lowell Gilbert, embedded/networking software engineer, Boston area
		http://be-well.ilk.org/~lowell/