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
Dennison Williams wrote:
> 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 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.?
Dennison Williams wrote:
> 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
> -
> 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
--
*****************************************************************
* 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. *
*****************************************************************