On Sun, Feb 14, 2016 at 01:43:05PM -0700, Chris Murphy wrote: > Use all defaults for everything. Anything new by show should do the > right thing including 4096 byte alignment. > > gargamel:~# cryptsetup luksDump /dev/md8 > [snip] > Payload offset: 3072 > > This is a bit weird because the default is 4096. But because the LUKS > offset (header + payload + extra unused space) is 2MiB, so it doesn't > affect alignment. There may be unpatched (fixes not backported) in the > tools of current long term supported distros, that can cause > misalignment. Probably top concern would be parted/libparted, which > would start partition 1 at LBA 63, which is not aligned. The upstream > tools for a long time now have set partition 1 to LBA 2048, but these > crusty old unpatched versions just seem to persist like a booger you > can't flick off. It's really annoying - this idea of "stable bugs" > that go on and on for a decade.
Indeed. Thankfully my partitions now start at 2048 like you say. The only thing I did wrong last time (when using bcache) is md5 - dmcrypt - bcache - btrfs ssd - dmcrypt / This was stupid, I needed to do this: md5 - bcache - dmcrypt - btrfs ssd / So I think at this point, just to be future proof, I'm going to add bcache on top of all block devices I have, before putting dmcrypt on top, even if I don't have a cache device. That way I can later add a cache device without problems. Without doing that, adding bcache later is a full re-install :( Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html