Tag Info

Hot answers tagged

3

Have a look at this question. I assume that is familiar to your problem. Recreating and even syncing a RAID-1 should not destroy data. Obviously the MD device starts at another offset now. Thus where mount looks for a superblock there is data. This can have happened in at least two ways: You (or rather: the default setting) have created the new array with ...


3

I'm not sure how you can examine any particular superblock, but you can use this command to examine the general contents that all the superblocks share like so, using dumpe2fs. $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Example $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Filesystem volume name: <none> Last mounted on: ...


2

If it's 0.90 superblock format, you should be able to just use a member directly (in read only mode if you please). That gives you access to your data and then you can create a new fresh RAID-1 with just the other disk, copy your data over, then add the original disk to the RAID. If it's something else though (like 1.2 metadata) you'd first have to find the ...


1

The resize_inode feature creates a hidden inode ( number 7, you can view it in debugfs with stat <7> ) to reserve those blocks so that the GDT can be grown. By default it reserves enough space to grow the filesystem to 1024 times its original size. You can disable the feature or adjust the size using options to mke2fs at format time. What does ...


1

If the filesystem is really on that device, running mkfs.ext4 with the same arguments plus a -n will give you a list of superblocks that you can use as alternates. Eg: # mkfs.ext4 -n /dev/vg1/lvol2 ... Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Then you can run e2fsck -b 32768 ...



Only top voted, non community-wiki answers of a minimum length are eligible