Linux mdadm superblock question.
in [Kernel]
|
Prev: [patch v3 0/2] updated ptrace/core-dump patches for supporting xstate - v3
Next: [PATCH 3/3] mm: Debugging of new livelock avoidance
From: Bill Davidsen on 16 Feb 2010 12:10 H. Peter Anvin wrote: > On 02/15/2010 04:27 PM, Neil Brown wrote: > >> When mdadm defaults to 1.0 for a RAID1 it prints a warning to the effect that >> the array might not be suitable to store '/boot', and requests confirmation. >> >> So I assume that the people who are having this problem either do not read, >> or are using some partitioning tool that runs mdadm under the hood using >> "--run" to avoid the need for confirmation. It would be nice to confirm if >> that was the case, and find out what tool is being used. >> > > My guess is that they are using the latter. However, some of it is > probably also a matter of not planning ahead, or not understanding the > error message. I'll forward one email privately (don't want to forward > a private email to a list.) > > >> If an array is not being used for /boot (or /) then I still think that 1.1 is >> the better choice as it removes the possibility for confusion over partition >> tables. >> >> I guess I could try defaulting to 1.2 in a partition, and 1.1 on a >> whole-device. That might be a suitable compromise. >> > > In some ways, 1.1 is even more toxic on a whole-device, since that means > that it is physically impossible to boot off of it -- the hardware will > only ever read the first sector (MBR). > > That is either a problem or a solution, depending which bad behavior you are trying hardest to avoid. >> How do people cope with XFS?? >> > > There are three options: > > a) either don't boot from it (separate /boot); > And certainly there are other reasons to do that... > b) use a bootloader which installs in the MBR and > hopefully-unpartitioned disk areas (e.g. Grub); > c) use a nonstandard custom MBR. > > Neither (b) or (c), of course, allow for chainloading from another OS > install and thus are bad for interoperability. > I'm not really sure what you're getting at here, I use grub in MBR and then add chain loader stanzas to grub.conf for many things, usually an alternate Linux release, or to have 32/64 of the same release handy for testing, and always memtest from the boot menu. Even Win98SP2 on one machine, since that works very poorly under KVM. (ask Avi if you care why, something about what it does in real mode). In any case, I don't see the chain loader issue, unless you mean to reboot out of some other OS into Linux. -- Bill Davidsen <davidsen(a)tmr.com> "We can't solve today's problems by using the same thinking we used in creating them." - Einstein -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Volker Armin Hemmann on 16 Feb 2010 09:40 On Dienstag 16 Februar 2010, John Robinson wrote: > On 14/02/2010 19:13, Volker Armin Hemmann wrote: > > On Sonntag 14 Februar 2010, you wrote: > >> On 14/02/2010 18:40, Volker Armin Hemmann wrote: > >>> On Sonntag 14 Februar 2010, you wrote: > >>>> In other words, 'auto-detection' for 1.x format devices is using an > >>>> initrd/initramfs. > >>> > >>> which makes 1.x format useless for everybody who does not want to deal > >>> with initrd/initramfs. > >> > >> True, but afaik every distro uses an initrd/initramfs and bundles tools > >> making it easy to manage and customise them, so what's the problem? > > > > and distros do it because of all the drivers they have to ship. But for > > example I am not bound by such limitations. Why should I deal with that? > > It is hard enough not to forget 'make modules_install'. And now add > > initrd. Autodetecting just works - but if you use an initrd an it > > doesn't. Where do you start? > > > > Initrd's maybe great for distro packagers, but are they really usefull > > for anybody else? > > Not just for distro packagers, they're useful for distro users, which > are presumably 99% of Linux users these days, including the vast > majority of enterprise users who like tested, supported systems. > > But even for people building their own kernels, initrd/initramfs are > useful if you're using LVM, or indeed trying to boot off anything that's > not a simple device. so assume you have an initrd and metadata 1.x without auto assembling. You do some changes to the raid and screw up something else. Next boot nothing works. Mostly because the mdadm.conf in your initrd is not correct. You whip out your trusty usb stick with a resuce system - and you are stuck. If autoassembling would work, you would have working md devices you could mount and edit the files you have to. But you don't and the mdadm.conf in the initrd is outdated. Sounds like 'you are screwed'. Or you have that famous grub boot line to have root autoassembled but the device names changed. Yeah, sounds really great. And that because ...? Is there any good reason not to have autoassmbling in the kernel? Gl�ck Auf Volker -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bill Davidsen on 16 Feb 2010 12:20 Volker Armin Hemmann wrote: > On Sonntag 14 Februar 2010, you wrote: > > >> In other words, 'auto-detection' for 1.x format devices is using an >> initrd/initramfs. >> > > which makes 1.x format useless for everybody who does not want to deal with > initrd/initramfs. > You make this sound like some major big deal. are you running your own distribution? In most cases mkinitrd does the right thing when you "make install" the kernel, and if you are doing something in the build so complex that it needs options, you really should understand the options and be sure you're doing what you want. Generally this involves preloading a module or two, and if you need it every time you probably should have built it in, anyway. My opinion... -- Bill Davidsen <davidsen(a)tmr.com> "We can't solve today's problems by using the same thinking we used in creating them." - Einstein -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: John Robinson on 16 Feb 2010 12:30 On 16/02/2010 14:37, Volker Armin Hemmann wrote: > On Dienstag 16 Februar 2010, John Robinson wrote: >> On 14/02/2010 19:13, Volker Armin Hemmann wrote: >>> On Sonntag 14 Februar 2010, you wrote: >>>> On 14/02/2010 18:40, Volker Armin Hemmann wrote: >>>>> On Sonntag 14 Februar 2010, you wrote: >>>>>> In other words, 'auto-detection' for 1.x format devices is using an >>>>>> initrd/initramfs. >>>>> which makes 1.x format useless for everybody who does not want to deal >>>>> with initrd/initramfs. >>>> True, but afaik every distro uses an initrd/initramfs and bundles tools >>>> making it easy to manage and customise them, so what's the problem? >>> and distros do it because of all the drivers they have to ship. But for >>> example I am not bound by such limitations. Why should I deal with that? >>> It is hard enough not to forget 'make modules_install'. And now add >>> initrd. Autodetecting just works - but if you use an initrd an it >>> doesn't. Where do you start? >>> >>> Initrd's maybe great for distro packagers, but are they really usefull >>> for anybody else? >> Not just for distro packagers, they're useful for distro users, which >> are presumably 99% of Linux users these days, including the vast >> majority of enterprise users who like tested, supported systems. >> >> But even for people building their own kernels, initrd/initramfs are >> useful if you're using LVM, or indeed trying to boot off anything that's >> not a simple device. > > so assume you have an initrd and metadata 1.x without auto assembling. > > You do some changes to the raid and screw up something else. Next boot nothing > works. Mostly because the mdadm.conf in your initrd is not correct. > > You whip out your trusty usb stick with a resuce system - and you are stuck. > If autoassembling would work, you would have working md devices you could > mount and edit the files you have to. But you don't and the mdadm.conf in the > initrd is outdated. > > Sounds like 'you are screwed'. No; mdadm can assemble arrays without needing a conf file (at least arrays which have superblocks). And if you have otherwise screwed something up with the RAID, no amount of in-kernel autoassembly is going to help, in fact it's more likely to get it wrong and make things worse; you need a command line and mdadm to sort it out. Cheers, John. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bill Davidsen on 16 Feb 2010 12:30
Neil Brown wrote: > On Thu, 11 Feb 2010 18:00:23 -0500 (EST) > Justin Piszcz <jpiszcz(a)lucidpixels.com> wrote: > > >> Hi, >> >> I may be converting a host to ext4 and was curious, is 0.90 still the only >> superblock version for mdadm/raid-1 that you can boot from without having >> to create an initrd/etc? >> >> Are there any benefits to using a superblock > 0.90 for a raid-1 boot >> volume < 2TB? >> > > The only noticeable differences that I can think of are: > 1/ If you reboot during recovery of a spare, then 0.90 will restart the > recovery at the start, while 1.x will restart from where it was up to. > 2/ The /sys/class/block/mdXX/md/dev-YYY/errors counter is reset on each > re-assembly with 0.90, but is preserved across stop/start with 1.x > 3/ If your partition starts on a multiple of 64K from the start of the > device and is the last partition and contains 0.90 metadata, then > mdadm can get confused by it. > Given that 4k sector drives make that a lot more likely that it used to be, I suspect some effort will be needed to address this sooner or later. > 4/ If you move the devices to a host with a different arch and different > byte-ordering, then extra effort will be needed to see the array for > 0.90, but not for 1.x > > I suspect none of these is a big issue. > > It is likely that future extensions will only be supported on 1.x metadata. > For example I hope to add support for storing a bad-block list, so that a > read error during recovery will only be fatal for that block, not the whole > recovery process. This is unlikely ever to be supported on 0.90. However > it may not be possible to hot-enable it on 1.x either, depending on how much > space has been reserved for extra metadata, so there is no guarantee that > using 1.x now makes you future-proof. > > And yes, 0.90 is still the only superblock version that supports in-kernel > autodetect, and I have no intention of adding in-kernel autodetect for any > other version. > -- Bill Davidsen <davidsen(a)tmr.com> "We can't solve today's problems by using the same thinking we used in creating them." - Einstein -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |