package: lvm2 version: 2.02.167-1 This bug is opened to document some problems discovered in an IRC conversation on #debian-devel between Sam Hartman and Bastian Blank
The problem seemed to be that often (although not in all the time in Sam's experience) lvcreate --type raid5 -L 128g -n volumename vgname produced a volume with a bogus raid metadata bitmap. In particular, lvchange -an volumename&&lvchange -ay volumename would fail with errno -22 trying to read the bitmap Looking at the _rmeta_0 volumes, the bitmap looked like garbage; among other things the BITM magic number was absent. Doing something like dd if=/dev/zero of=/dev/mapper/vgname-volumename_rmeta_0 (through n for each rmeta volume) would permit the volume to be activated one more time. Thes volumes failed to activate with linux 4.8.0-1-amd64 at all, claiming an unknown feature flag. However, at least in Sam's experience, zeroing all the metadata and activating the volume gets good metadata written out including a good bitmap on 4.8.0-1-amd64 Bastian was unable to produce a raid5 logical volume at all on 4.8.0-1-amd64. Sam's theory was that lvcreate does not properly zero the metadata volume on create, and that since the segment allocation is predictable, Bastian's system was reusing the same metadata extents after an upgrade from 4.7 to 4.8. Sam is able to create raid5 volumes on 45.8.0-1-amd64. However, as part of this process, Sam discovered that even with issue_discards set to 1, lvremove does not issue discards for the data segments of a raid5 volume. To test do something like # create volume dd if=/etc/motd bs=1024k seek=1 dd if=/dev/vgname/volumename bs=1024k skip=1 |less #to confirm motd lvremove vgname/volumename #immediately recreate volume with same params dd if=/dev/vgname/volumename bs=1024k skip=1 |less #to confirm motd the 4.7 issues can probably be ignored since it is an old kernel we never shipped. I think that the failing to zero metadata and failing to discard are important to investigate.