DSM-G600, DNS-3xx and NSA-220 Hack Forum

puterboy · 2008-09-22 05:17:15

Unfortunately, I hadn't realized that the standard reboot and do_reboot commands seemingly don't unmount the filesystems resulting in unclean/corrupted filesystems.

So, I found the following errors when running fsck on my unmounted /dev/md0 [/mnt/HD_a2] partition: (note all-caps added by me)

e2fsck -n -v -f /dev/md0
e2fsck 1.32 (09-Nov-2002)
THE FILESYSTEM SIZE (ACCORDING TO THE SUPERBLOCK) IS 243928951 BLOCKS
THE PHYSICAL SIZE OF THE DEVICE IS 243928928 BLOCKS
Either the superblock or the partition table is likely to be corrupt!
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

11119 inodes used (0%)
176 non-contiguous inodes (1.6%)
# of inodes with ind/dind/tind blocks: 6851/690/0
53868207 blocks used (4%)
0 bad blocks
20 large files

9746 regular files
322 directories
0 character device files
0 block device files
0 fifos
1018 links
1042 symbolic links (1042 fast symbolic links)
0 sockets
--------
12128 files

Now running fsck on the naked /dev/sda2 partition (vs the /dev/md0 raid) doesn't give ANY errors.

From googling, it seems that the issue is due to the fact that the RAID array creation add a superblock to the partition thus leaving less room for the the subsequent ext2 filesystem than the full partition size.

Presumably, this is the error that e2fsck -n -v -f /dev/md0 is complaining about.

One source suggested fixing this by running resize2fs /dev/md0 but before I do this I wanted to make sure that it is the right thing and not (too) dangerous.

So my questions are:
1. Am I understanding the problem and cause correctly?
2. Should I be worrying about it?
3. Is resize2fs the answer? or should I ignore it? or should I do something else

Note /ffp/sbin/fdisk /dev/sda gives the following info (and since disk are RAID1, /dev/sdb gives the same answer)

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 66 530113+ 82 Linux swap
/dev/sda2 131 121601 975715807+ 83 Linux
/dev/sda4 67 130 514080 83 Linux

puterboy · 2008-09-22 07:04:38

Now I just tried running fsck again but without the -n flag. I get the following errors but am not sure what to do.
Specifically, I don't know whether they are "real" errors or an artifact of the problem described above.
So, should I let e2fsck correct them or not? Or should I do a resize2fs first or something else?

sudo e2fsck -v -f /dev/md0
e2fsck 1.32 (09-Nov-2002)
The filesystem size (according to the superblock) is 243928951 blocks
The physical size of the device is 243928928 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no

Pass 1: Checking inodes, blocks, and sizes
HTREE directory inode 38289409 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 38289409 has an unsupported hash version (60)
Clear HTree index<y>? no

HTREE directory inode 38289409 uses an incompatible htree root node flag.
Clear HTree index<y>? no

HTREE directory inode 38289409 has a tree depth (48) which is too big
Clear HTree index<y>? no

HTREE directory inode 38666241 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 38666241 has an unsupported hash version (40)
Clear HTree index<y>? no

HTREE directory inode 38666241 uses an incompatible htree root node flag.
Clear HTree index<y>? no

HTREE directory inode 38666241 has a tree depth (27) which is too big
Clear HTree index<y>? no

HTREE directory inode 48414742 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 48578578 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 49184787 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 49283080 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 49135631 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 49135631 has an unsupported hash version (28)
Clear HTree index<y>? no

HTREE directory inode 49135631 uses an incompatible htree root node flag.
Clear HTree index<y>? no

HTREE directory inode 49135631 has a tree depth (16) which is too big
Clear HTree index<y>? no

HTREE directory inode 49364998 has an invalid root node.
Clear HTree index<y>? no

HTREE directory inode 49364998 has an unsupported hash version (32)
Clear HTree index<y>? no

HTREE directory inode 49364998 uses an incompatible htree root node flag.
Clear HTree index<y>? no

HTREE directory inode 49364998 has a tree depth (18) which is too big
Clear HTree index<y>? no

Pass 2: Checking directory structure
Problem in HTREE directory inode 0: root node is invalid
Clear HTree index<y>? no

Problem in HTREE directory inode 38289409: node (0) has bad limit (16387)
Clear HTree index<y>? no

Problem in HTREE directory inode 38289409: node (0) has bad count (584)
Clear HTree index<y>? no

Problem in HTREE directory inode 38289409 (???): bad block number 3145788.
Clear HTree index<y>? no

Segmentation fault

--------------------------------

YIKES! What is going on and what can I do to fix it!

skydreamer · 2008-09-22 11:56:40

I came across this issue before where the partition size does not match the disk size on one of my DNS-323. While you may get away with it, there might be trouble ahead when you start filling up the file system.

There could be an easier way to resolve this but I took no chances and copied all files to a backup, manually repartitioned and formatted the disks on a linux PC and convinced the d-link to start using the new disk RAID1 array. It is in one of my posts approximately 3 month ago.

I do not believe that the size mismatch is due to the unclean shutdown, it was there from the day one but perhaps you have not noticed?
resize2fs - should work although I do not trust the DNS-323 to finish it cleanly. especially that you need to shrink the FS. Plus it is likely to be very slow.

Last edited by skydreamer (2008-09-22 11:57:59)

trepex · 2008-11-17 15:26:51

This problem occurs if you have a single drive in your system, then add another drive to make it RAID-1. Basically the actual file system has to shrink slightly due to the superblock on the first drive, and so things get out of sync. This tutorial will fix things for you:

http://pith.org/notes/2005/07/23/how-i- … ize-error/

Should be able to simply use resize2fs and it'll fix everything

DSM-G600, DNS-3xx and NSA-220 Hack Forum

Announcement

#1 2008-09-22 05:17:15

How to fix e2fsck error: filesystem size != physical size

#2 2008-09-22 07:04:38

Re: How to fix e2fsck error: filesystem size != physical size

#3 2008-09-22 11:56:40

Re: How to fix e2fsck error: filesystem size != physical size

#4 2008-11-17 15:26:51

Re: How to fix e2fsck error: filesystem size != physical size

Board footer