fsck of large volume with small memory

[Don Lewis]

On 25 Sep, sam wrote:
> sam wrote:
>> Don Lewis wrote:
>>> On 24 Sep, sam wrote:
>>>   Expect major file system lossage ...
>>> I think this patch could be better, but this should get you going ...
>>>
>>>
>>
>>
>> UNEXPECTED SOFT UPDATE INCONSISTENCY
>> LOST 74 DIRECTORIES
>>
>> UNEXPECTED SOFT UPDATE INCONSISTENCY
>> fsck: /dev/aacd0s1f: Segmentation fault: 11

It would be good to know the cause of this segfault so that the code
could be fixed to prevent it.

>> #
>> ======================================================
>>
>> /Vladimir Ermakov
>>
>>
> # cat /etc/rc.conf |grep fsck
> fsck_y_enable="YES"
> background_fsck="NO"
> 
> hm, and after system reboot
> 
> =================================================
> # fsck /dev/aacd0s1f
> ** /dev/aacd0s1f (NO WRITE)
> ** Last Mounted on /usr
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 438959 files, 3567329 used, 69528964 free (94684 frags, 8679285 blocks, 
> 0.1% fragmentation)
> #
> =================================================

That's the fastest way of getting the file system back into a consistent
state (or you could run "fsck -y" in single-user mode), but it increases
the probability of data loss. The problem is that my patch allows fsck
to examine a bunch of uninitialized inodes in the damaged cylinder
group, and there is the possibility that one or more of these inodes
could look reasonably valid and contain block pointers that point to
blocks in valid files.  Fsck will then detect the duplicate block
pointers and clear the inodes for both files. It would be nice if fsck
could be told to put less trust in the inodes that might not actually be
initialized, but this gets complicated ...