> The problem is that system service will recognize raid disks and > assemble the array automatically, you might what to disable them. Actualy user is forced to work with MD device from the get go. This is how you would typicaly use mdadm to write metadata to disk: $ truncate -s 1G test.img $ mdadm --create /dev/md0 --level=1 --bitmap=internal --raid-devices=2 test.img missing mdadm: must be super-user to perform this action mdadm: test.img is not a block device. Following is unfit for my usecase: * It requires me to reference /dev/md0 (i don't want to involve kernel at all) * It requires super-user (no need, i just want to write bytes to my own file) * Refuses to work on regular file (once i run it as super-user) > I don't think we need to care. They goal is to not have and use MD > module so mdadm will fail to load personalities. No it is not the goal. Goal is not to rely on kernel. It has to work on any kernel including the ones that have MD module loaded. Possibly even on non-Linux OS. > I agree. The right way is to incorporate it with mdadm. > We should create a volume image (data) without MD internals. In that case i would still need headers with structs to parse the metadata and get offsets where to load actual data (filesystem) into the array images. But to be honest, i am pretty happy with how the genimage code works now, i don't need any help with its functionality. I don't even need those headers to be fixed. I can leave them copypasted. But i think it would be right thing to consolidate them, therefore i've proposed the patch. I just didn't wanted to hardcode definitions that are already in kernel, because i don't like duplicit code that can be included from somewhere else. > If you are looking for challenges this software is full of them! Haha. I feel you. Maybe lets tackle them step by step. Consolidating headers to provide complete ondisk format seems as a good start to me. Especialy if the mdadm could benefit from that as well. Tom
