Am 23.06.26 um 10:22 schrieb [email protected]:
On Tue, Jun 23, 2026 at 08:00:11AM +0200, Michel Verdier wrote:
On 2026-06-22, [email protected] wrote:

RAID is always before LUKS : partition > RAID array > LUKS > filesystem
"Is always" means for you "should always be" or "has to be"?
"has to be". LUKS encrypt a partition in a unique way. So 2 encrypted
partitions are always different and cannot be synced.
I think that is wrong. You don't sync the *encrypted* partitions (how would
you?) but the decrypted block layer, one level up. I don't see a reason it
wouldn't work.

Thomas is correct. The decrypted devices are assembled and synced, not the 
encrypted devices.

And my experience shows that it is not mandatory to have RAID before LUKS. My 
btrfs RAID1 has been running for years in this way without any issue. Right 
now, the md RAID1 is doing what it should be doing. (Yeah, that's right, I am 
watching you, md0!) David has even pointed out in another mail that it is 
mandatory to use LUKS before RAID in special cases:

Am 22.06.26 um 10:42 schrieb David Christensen:
> When you have a layer that combines RAID, volume management, and filesystems, 
such as ZFS and btrfs, the stackable encryption layer must be underneath (e.g. the 
latter of above two I/O layering configurations).

I think this is technically correct, as btrfs is a filesystem and doesn't 
provide a block device that can be encrypted via LUKS, IIUC. Please correct me 
if I am wrong. (Coming to think of it: The btrfs RAID1 was first on the disk, 
the md RAID1 came much later. Most likely I just transferred the way the btrfs 
RAID1 is set up to the md RAID1, without thinking.)

Now, am I saying that LUKS before *md* RAID is a smart setup? No, I am not. 
Probably there are good reasons to do it the other way round. And I still think 
it is likely that my issue comes from some hickup in the way the RAID is 
assembled at boot from the decrypted devices. However, I recommend to not jump 
to conclusions before we have more data on this. And it might be beneficial to 
actually find out what the root cause for my issue is in order to be able to 
fix it. If I have been doing it this way, chances are that somebody else is 
doing it this way as well...

Anyway, thanks, I learned a lot again!

Paul

Reply via email to