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