On 2026-06-22, Paul Leiber wrote: >>> RAID is always before LUKS : partition > RAID array > LUKS > filesystem >> "Is always" means for you "should always be" or "has to be"? >> >> As far as I understand OP, their case is the other way around (and I don't >> see why it shouldn't be technically possible: a block device is a block >> device is a block device, after all). > > Tomas' description of my setup is correct, LUKS before RAID. It has > been working in the past, and it is working right now again. Is this > type of setup recommended? I don't know. BTRFS doesn't show any issues > with this setup.
So Tomas found your problem. It is at best useless to have partition > LUKS > RAID array > filesystem I cannot see how it managed to work. It suppose the 2 LUKS are identical which is a nonsense. Also a small change in data gives a bigger change in a LUKS partition thus bigger to sync. I don't know enough about LUKS but I suppose you loose LUKS atomicity during sync. > However, my main suspect for the root cause of the dual-head database is > indeed that the LUKS decryption messes with the md RAID assembly at boot, > e. g. some timing issue or race condition. The database content doesn't change > constantly, there are very few writes per day, so I'll rely on daily backups > and monitor the RAID closely. There was another kernel update today, so I'll > see what happens after a reboot, which probably was what triggered the issue > in the past. If another issue occurs, I'll probably have a chance to find more > information in the logs now that I know what to look for. If my assumption is > confirmed, I'll change the order to RAID before LUKS and restore the data from > backup. (Or I'll do it anyway out of lack of other ideas...) You are right to suspect that. Don't wait and change it even if you can't confirm a bug. The good and safe way is partition > RAID array > LUKS > filesystem And you should also improve performances.
