Am 22.06.26 um 09:35 schrieb [email protected]:
On Mon, Jun 22, 2026 at 08:18:45AM +0200, Michel Verdier wrote:
On 2026-06-22, [email protected] wrote:
Your commands are strange : the partitions should be the disk partitions
from /dev and not mapped ones. Or you have another layer ? From where
come /dev/mapper/partition_1 and /dev/mapper/partition_2 ?
If I have been following along, the RAID parts are LUKS encrypted devices,
so to me it does make sense.
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.
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...)
