What if Block Group Descriptors Table are corrupt?

Using TestDisk to repair the filesystem
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Message
Author
amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

What if Block Group Descriptors Table are corrupt?

#1 Post by amarkeyev »

Hi!
A few days ago one of my disks was lost. It was in dns-320 NAS (linux).
I tryed to recover filesystem using testdisk. It hasn't recovered. The filesystem is corrupt despite superblock was fine.
As I'd explored, my disk lost one sector (4096 bytes) in the Descriptors Table. Nothing more, but it was enough to fail the file system and to fool testdisk.
Photorec didn't restore all files too.
However, I restored important files in manual mode (dd, hex-editor, calc, ext4.wiki.kernel.org and patience).
My question is:
Is it possible to recover this kind of bug automaticaly?
May be I missed some section in testdisk documentation?

Thanks for reading!
Double thanks for future answering!

User avatar
cgrenier
Site Admin
Posts: 5432
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: What if Block Group Descriptors Table are corrupt?

#2 Post by cgrenier »

Was it an ext4 Block Group Descriptor ?
fsck.ext4 should have been able to deal with it.

amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

Re: What if Block Group Descriptors Table are corrupt?

#3 Post by amarkeyev »

Yes, it was.
Unfortunately, it didn't help.
Maybe, I should pass additional parameters.
I used fsck with "-nv" parameters with/without additional "-b". I used the value for -b parameter which I got from the testdisk diagnostic message.
Tonight, I will reproduce error message from fsck and write it here.

amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

Re: What if Block Group Descriptors Table are corrupt?

#4 Post by amarkeyev »

device D-Link 320, pair WD 1Tb installed.

message from fsck

Code: Select all

fsck.ext4 -nv -b 32768 -B 4096 /dev/sdb
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

fsck.ext4 -nv -b 8193 -B 4096 /dev/sdb
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
linux ver

Code: Select all

# uname -a
Linux sssssss 2.6.22.18 #23 Wed May 25 15:48:30 CST 2011 armv5tejl GNU/Linux
testdisk analitics screen

Code: Select all

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
 P Linux Swap                  2040       2055         16
 P MS Data                  1062912    2086991    1024080
>P MS Data                  2088960 1951430655 1949341696




Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63

     Partition                  Start        End    Size in sectors

  MS Data                  2088960 1951430655 1949341696 [Linux/Windows data]
superblock 0, blocksize=4096 []
superblock 32768, blocksize=4096 []
superblock 98304, blocksize=4096 []
superblock 163840, blocksize=4096 []
superblock 229376, blocksize=4096 []
superblock 294912, blocksize=4096 []
superblock 819200, blocksize=4096 []
superblock 884736, blocksize=4096 []
superblock 1605632, blocksize=4096 []
superblock 2654208, blocksize=4096 []

To repair the filesystem using alternate superblock, run
fsck.ext4 -nv -b 32768 -B 4096 /dev/sdb
reading descriptor table

Code: Select all

dd if=/dev/sdb of=/mnt/HD/HD_a2/dns/desc-table-b-512-1 bs=512 skip=2088968 count=240
ok!
dd if=/dev/sdb of=/mnt/HD/HD_a2/dns/desc-table-b-512 bs=512 skip=2089208 count=8
error!
dd if=/dev/sdb of=/mnt/HD/HD_a2/dns/desc-table-b-512-2 bs=512 skip=2089216 count=217
ok!

total: 240 + 8 + 217 = 465 blocks or 465*8 = 3720 block group descriptors. farther - zeros.

User avatar
cgrenier
Site Admin
Posts: 5432
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: What if Block Group Descriptors Table are corrupt?

#5 Post by cgrenier »

Can you run fsck on the partition instead of the whole disk ?

amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

Re: What if Block Group Descriptors Table are corrupt?

#6 Post by amarkeyev »

I'm sorry for my misunderstanding.
How can I point this partition in fsck command?

/dev/sdb1 ?

I tried to run fdisk. It pointed me, that my disk has GPT partition. Does it mean?

amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

Re: What if Block Group Descriptors Table are corrupt?

#7 Post by amarkeyev »

here it goes

Code: Select all

fdisk -l /dev/sdb2

Disk /dev/sdb2: 998.1 GB, 998062948352 bytes
255 heads, 63 sectors/track, 121340 cylinders, total 1949341696 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb2 doesn't contain a valid partition table
GPT

Code: Select all

gdisk -l /dev/sdb2
GPT fdisk (gdisk) version 0.6.13

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.
Disk /dev/sdb2: 1949341696 sectors, 929.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): F68F34F9-3B77-4549-93E1-44AE8560E306
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1949341662
Partitions will be aligned on 2048-sector boundaries
Total free space is 1949341629 sectors (929.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
and, for whole disk

Code: Select all

 gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.6.13

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 41612D9F-0977-4692-A48D-9EA794381F79
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2099101 sectors (1.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1062271   517.7 MiB   8200  Linux swap
   2         2088960      1951430655   929.5 GiB   0700  Linux/Windows data
   4         1062912         2086991   500.0 MiB   0700  Linux/Windows data
I've read about "mke2fs -S", but it seems little scary...
If descriptor table has unreadable sector, does this command help?

User avatar
cgrenier
Site Admin
Posts: 5432
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: What if Block Group Descriptors Table are corrupt?

#8 Post by cgrenier »

Try fsck /dev/sdb2 and fsck /dev/sdb4

amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

Re: What if Block Group Descriptors Table are corrupt?

#9 Post by amarkeyev »

I'm sorry for delay.
Here is out from fsck
for sdb2:

Code: Select all

# fsck /dev/sdb2 -y
fsck from util-linux 2.20
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext3: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb2
Could this be a zero-length partition?
and for sdb4:

Code: Select all

# fsck /dev/sdb4 -y
fsck from util-linux 2.20
e2fsck 1.41.14 (22-Dec-2010)
Error reading block 246017 (Attempt to read block from filesystem resulted in short read).  Ignore error? yes

Force rewrite? yes

Superblock has an invalid journal (inode 8).
Clear? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Superblock has_journal flag is clear, but a journal inode is present.
Clear? yes

/dev/sdb4 was not cleanly unmounted, check forced.
Error writing block 246017 (Attempt to write block from filesystem resulted in short write).  Ignore error? yes

Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data.  Clear? yes

Error reading block 246016 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

Error writing block 246016 (Attempt to write block from filesystem resulted in short write) while getting next inode from scan.  Ignore error? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create? yes

Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(246017--253952) -(254209--254497)
Fix? yes

Free blocks count wrong for group #30 (0, counted=7936).
Fix? yes

Free blocks count wrong for group #31 (7647, counted=7936).
Fix? yes

Free blocks count wrong (480561, counted=488786).
Fix? yes

Recreate journal? yes

Creating journal (8192 blocks): Error writing block 246017 (Attempt to write block from filesystem resulted in short write).  Ignore error? yes

Error writing block 246018 (Attempt to write block from filesystem resulted in short write).  Ignore error? yes

Error writing block 246019 (Attempt to write block from filesystem resulted in short write).  Ignore error? yes

 Done.

*** journal has been re-created - filesystem is now ext3 again ***

/dev/sdb4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb4: 781/128016 files (0.6% non-contiguous), 31479/512040 blocks
Now '/dev/sb4' is mounted as 'HD_b4' and all its files in place.
But thing is, that I need files from '/dev/sb2'.

amarkeyev
Posts: 8
Joined: 18 Nov 2018, 18:25

Re: What if Block Group Descriptors Table are corrupt?

#10 Post by amarkeyev »

A couple minutes ago I've started fsck with alternate superblock.
Waiting for results...

Code: Select all

# fsck.ext4 /dev/sdb2 -y -f -b 32768
e2fsck 1.41.14 (22-Dec-2010)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdb2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Error reading block 1034 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

Locked