ext3 filesystem is not recognized after losetup -e aes
Here is the setup: MD software RAID 5 on 4 disks (md0), a LVM logical volume (/dev/volume_group/logical_volume) comprised of one physical device (/dev/md0), a encryption layer provided by the cryptoloop driver (losetup -e aes /dev/loop0 /dev/volume_group/logical_volume), then a EXT3 file system (mkfs.ext3 /dev/loop0).
Recently the RAID device kicked out one of the disks during a large file transfer. After re-adding the disk to the array whith "mdadm /dev/mdo -add /dev/sde (smartctl didn't report
anything wrong with it, I am not sure why this happened), authenticating against the cryptographic layer, then trying to mount the drive, I get the following error:
[root@storage redhat]# mount -t ext3 /dev/loop1 /terrorbyte/1/
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
The message in /var/log/message is:
VFS: Can't find ext3 filesystem on dev loop1.
I then tried to e2fsck the /dev/loop1 partition with all of the different blocks that were reported from:
mke2fs -n /dev/loop1
with no luck still.
I don't think that LVM has anything to do with it, because on another volume group, that didn't loose any drives, there is a encrypted logical volume that has the same problem. Actually all of the drives that I have encrypted have this problem now. I am unsure of where the problem actually is, and how to go about debugging it. Any suggestions would be appreciated.
Sincerely,
Dennison Williams
Quoted 13 lines · Dennison Williams
Here is the setup: MD software RAID 5 on 4 disks (md0), a LVM logical volume (
/dev/volume_group/logical_volume) comprised of one physical device (/dev/md0), a encryption layer provided by the cryptoloop driver (losetup -e aes/dev/loop0/dev/volume_group/logical_volume), then a EXT3 file system (mkfs.ext3/dev/loop0).Recently the RAID device kicked out one of the disks during a large file transfer. After re-adding the disk to the array whith "mdadm
/dev/mdo-add/dev/sde(smartctl didn't report
anything wrong with it, I am not sure why this happened), authenticating against the cryptographic layer, then trying to mount the drive, I get the following error:
Quoted 5 lines
[root@storage redhat]# mount -t ext3
/dev/loop1/terrorbyte/1/
mount: wrong fs type, bad option, bad superblock on/dev/loop1,The message in
/var/log/messageis:
VFS: Can't find ext3 filesystem on dev loop1.
I saw in the encryption howto, section 6.1, talks about the effects of blocks occupying different space when the kernel is compiled with the CONFIG_BLK_LOOP_DEV_USE_REL_BLOCK option. Would this effect also be possible by a RAID5 system re-syncing a drive? I don't see this configuration option anywhere in the 2.6.18 kernel (I am using a redhat build of this kernel).
I am pretty confident that this problem is somewhere in the block driver / crypto driver combo and am considering digging through the code. Before I do can anyone point me in the direction pertinent documentation , specific drivers, etc.?
Quoted 37 lines · Dennison Williams
Here is the setup: MD software RAID 5 on 4 disks (md0), a LVM logical volume (
/dev/volume_group/logical_volume) comprised of one physical device (/dev/md0), a encryption layer provided by the cryptoloop driver (losetup -e aes/dev/loop0/dev/volume_group/logical_volume), then a EXT3 file system (mkfs.ext3/dev/loop0).Recently the RAID device kicked out one of the disks during a large file transfer. After re-adding the disk to the array whith "mdadm
/dev/mdo-add/dev/sde(smartctl didn't report
anything wrong with it, I am not sure why this happened), authenticating against the cryptographic layer, then trying to mount the drive, I get the following error:[root@storage redhat]# mount -t ext3
/dev/loop1/terrorbyte/1/
mount: wrong fs type, bad option, bad superblock on/dev/loop1,The message in
/var/log/messageis:
VFS: Can't find ext3 filesystem on dev loop1.I then tried to e2fsck the
/dev/loop1partition with all of the different blocks that were reported from:
mke2fs -n/dev/loop1
with no luck still.I don't think that LVM has anything to do with it, because on another volume group, that didn't loose any drives, there is a encrypted logical volume that has the same problem. Actually all of the drives that I have encrypted have this problem now. I am unsure of where the problem actually is, and how to go about debugging it. Any suggestions would be appreciated.
Sincerely,
Dennison Williams
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 9 lines
***************************************************************** * To communicate with me securely, please email me and I will * * send you my public key. We can then verify each others * * fingerprints in person, or over the phone. * * * * I am open and willing to talk about setting up PGP, the * * security problems inherent with PGP, and alternatives to PGP * * for secure electronic communication. * *****************************************************************