On Sun, 22 Feb 2015 16:54:12 -0500 Joshua Kinard <kumba@xxxxxxxxxx> wrote: > On 02/22/2015 16:29, Chris Murphy wrote: > > On Sun, Feb 22, 2015 at 11:54 AM, Joshua Kinard <kumba@xxxxxxxxxx> wrote: > >> I'd like to > >> avoid this if possible, as I haven't had to use an initramfs for normal booting > >> in the past, as long as I stay on metadata 0.90. So I thought I'd ask what the > >> official stance is on this. > > > > https://raid.wiki.kernel.org/index.php/Autodetect > > > > Official stance is that it's deprecated, but people still use it. > > Yeah, but it's a pretty useful feature. I can't see why autodetect for simple > setups (several disks or partitions and building a basic array out of them) is > maintained, while userspace autodetect is required for the more complex setups. The in-kernel autodetect is only maintained because tearing it out and throwing it away (my preferred option) would be a user-visible regression, and those are not permitted. The user-space version is more general and more flexible. If the kernel-space version works for you, you can keep using it. But if you want features added to it, you are out of luck. As others have said, creating a simple initrd is really not that hard. Once you spend the time to make it work, you will find that it "just works" and wonder why you ever cared before. There is even a README.initramfs in the mdadm source. It was written 10 years ago so I cannot promise it is 100% correct, but it is a reasonably good and very simple starting point. NeilBrown > > But I suppose this has been discussed before in detail, though I cannot find > said discussion. The RAID Boot page has this one example only: > > "This approach can cause problems in several situations (imagine moving part of > an old array onto another machine before wiping and repurposing it: reboot and > watch in horror as the piece of dead array gets assembled as part of the > running RAID array, ruining it); kernel autodetect is correspondingly deprecated." > > Which I find to be rather unconvincing. The cited example is a fault of the > user not torching the superblock before moving the disks or trying to use > them...and I've done this to myself on several occasions. mdadm --misc > --zero-superblock and 'dd' saved the day in less than ~30s. > > Are there any other discussions that might be more convincing, or offer up > other points of view? Perhaps there's a point I've yet to consider that might > be enlightening. > > Thanks!, >
Attachment:
pgp26lAkXQB6t.pgp
Description: OpenPGP digital signature
