[mdlug] e2fsck - What to do?

[Robert Meier]

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,
-- 
Bob

  "Spammers seem to assume that you are heavily in debt,
   under-endowed, impotent, jobless, without a college diploma,
   without insurance, in need of prepaid legal representation,
   and need to investigate those closest to you. In other
   words, they are selling to themselves!"
      -- Raymond Ingles 2002