[mdlug] e2fsck - What to do?

[Stan Green]

Bob,

Thanks for the extensive write up. I like the idea of working on a copy so 
if/when I mess it up, I can go back and start over. I first need to configure 
things so I have enough free space to make a copy. Once I have that, I can 
get started.

Thanks,
Stan
On Monday 04 August 2008 09:37, Robert Meier wrote:
> Stan,
>
> > The question is am I on the right track [blindly accepting e2fsck
> > recommendations] to recover this drive and if so what
> > should I answer to the last question.
>
> [Read below regarding answers before continuing totally blind.]
>
> I think you are on the right track.
> The bitmap is a cache,
> and the error is reporting a mismatch between the actual inode state,
> and its cached state.
>
> Relocating (duplicating probably deleted data)
> is the safer course of action.
> The risk is that something (e.g. a bad sector) prevented updating an
> actual inode involved in system configuration, and that after relocation
> the bad dupe is used.
> Responding, as you are, to the first report of fsck error,
> the worst I've personally encountered,
> after accepting all of fsck's normal recommendations,
> is to find the actual files (or recently-changed portions) in lost+found/ ,
> and the requirement to reconnect the actual files.
>
> I've seen others continue to use a disk with fsck errors,
> soon find the frequency of errors growing,
> and (by the time I was involved) suffer permanent data loss.
>
> > (I don't want SEVERE DATA LOSS!) I was answering No,
> > but quit after about 40 sets of messages.
>
> If the data is valuable enough, I suggest you get a spare disk drive,
> create a partition of the same size, dd(1) the contents of the
> suspect disk to the copy partition on the spare drive, and recover the
> copy. If the outcome is not desirable, you can repeat the process (with
> answers varied according to why the outcome was not desirable).
>
> > Lastly, is there any way to automate this so I don't have to sit
> > an hit Y 1500 times?
>
> fsck -n > file-on-other-disk.fsck
> e2fsck will report to a file, so that you can examine it more
> systematically.
>
> fsck -y
>
> e2fsck (and fsck in general) nominally separates operations into
> those considered safe, and performed automatically with -y,
> and those considered unsafe, and performed only with approval or -p.
>
> > Inode bitmap for group 0 is not in group.  (block 772925346)
> > Relocate<y>? yes
>
> This indicates that fsck thinks this is a safe operation
> (i.e. the data may end up in /lost+found,
>  but should not be immediately lost.)
>
> > Inode table for group 0 is not in group.  (block 1931314432)
> > WARNING: SEVERE DATA LOSS POSSIBLE.
> > Relocate<y>?
>
> This indicates that fsck thinks this is a risky operation
> (i.e. data may be immediately lost).
> My practice is to always answer n, during the first pass,
> and if it repeats (less than 10%), do further research
> (e.g. find the data referenced by block 1931314432).
>
>
>
> The value of hitting Y 1500 times, is that you can record the inode
> numbers, which usually map linearly to the offset within the data
> image, thereby usually identifying the files at risk and where
> the lost data might be.
>
> Despite the tedium (and need to rediscover the linear map each time)
> I've found it worth recording (esp. if fsck -n was supported)
> the inodes each time.
>
> Hopefully helpful,