OK so ext4 this time, with new disk images. I notice at mkfs.ext4 that
each virtual disk goes from 2MB to 130MB-150MB each. That's a lot of
fs metadata, and it's fairly evenly distributed across each drive.
Copied 3.5GB to the volume. Unmount. Poweroff. Killed 3rd of 4. Boot.
Mounts fine. No errors. HUH surprising. As soon as I use ls though:
[ 182.461819] EXT4-fs error (device dm-1): __ext4_get_inode_loc:3806:
inode #43384833: block 173539360: comm ls: unable to read itable block
# cp -a usr /mnt/btrfs
cp: cannot stat ‘usr’: Input/output error
[ 214.411859] EXT4-fs error (device dm-1): __ext4_get_inode_loc:3806:
inode #43384833: block 173539360: comm ls: unable to read itable block
[ 221.067689] EXT4-fs error (device dm-1): __ext4_get_inode_loc:3806:
inode #43384833: block 173539360: comm cp: unable to read itable block
I can't get anything off the drive. And what I have here are ideal
conditions because it's a brand new clean file system, no
fragmentation, nothing about the LVM volume has been modified, no fsck
done. So nothing is corrupt. It's just missing a 1/4 hunk of its PE's.
I'd say an older production use fs has zero chance of recovery via
mounting.
So this is now a scraping operation with ext4.
Chris Murphy
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
