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: david on 15 Feb 2010 22:20 On Mon, 15 Feb 2010, H. Peter Anvin wrote: > On 02/15/2010 04:27 PM, Neil Brown wrote: > > There are three options: > > a) either don't boot from it (separate /boot); > 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 have had no problems with XFS partitions and lilo as the bootloader. I've been doing this for a couple of years now without realizing that there is supposed to be a problem. David Lang -- 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 15 Feb 2010 23:50 On 16/02/2010 03:18, david(a)lang.hm wrote: > On Mon, 15 Feb 2010, H. Peter Anvin wrote: > >> On 02/15/2010 04:27 PM, Neil Brown wrote: >> >> There are three options: >> >> a) either don't boot from it (separate /boot); >> 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 have had no problems with XFS partitions and lilo as the bootloader. > I've been doing this for a couple of years now without realizing that > there is supposed to be a problem. There isn't, if you use partitions. It could (would) go wrong if you tried to put an XFS filesystem, or md RAID with a v1.1 superblock, on a whole disc without a partition table *and* you tried to put a bootloader on. I can't say it's ever occurred to me to do that, because I always assumed that whatever I put in a partition used all of it, and I couldn't expect to double-book the beginning of it and have it work. 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: H. Peter Anvin on 16 Feb 2010 02:10 On 02/15/2010 07:18 PM, david(a)lang.hm wrote: > On Mon, 15 Feb 2010, H. Peter Anvin wrote: > >> On 02/15/2010 04:27 PM, Neil Brown wrote: >> >> There are three options: >> >> a) either don't boot from it (separate /boot); >> 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 have had no problems with XFS partitions and lilo as the bootloader. > I've been doing this for a couple of years now without realizing that > there is supposed to be a problem. > LILO also can be stuffed in the MBR (and then uses block-pointers from there). There is one more option that I didn't mention, which is to put the bootloader of a separate partition, OS/2 style. Again, breaks the standard chainloading model. -hpa -- 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: Rudy Zijlstra on 16 Feb 2010 03:50 H. Peter Anvin wrote: > On 02/15/2010 07:18 PM, david(a)lang.hm wrote: >> On Mon, 15 Feb 2010, H. Peter Anvin wrote: >> >>> On 02/15/2010 04:27 PM, Neil Brown wrote: >>> >>> There are three options: >>> >>> a) either don't boot from it (separate /boot); >>> 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 have had no problems with XFS partitions and lilo as the bootloader. >> I've been doing this for a couple of years now without realizing that >> there is supposed to be a problem. >> > > LILO also can be stuffed in the MBR (and then uses block-pointers from > there). There is one more option that I didn't mention, which is to > put the bootloader of a separate partition, OS/2 style. Again, breaks > the standard chainloading model. There is another configuration that fails. Use partitioned md. I do not think it matters whether over whole device or with a partition table. Neither grub nor lilo will boot off from it. I've tested that exensively with a partition on the disks. I am using PXE boot to boot 2 servers with that configuration. That adds a dependency on the pxe boot server, but considering the function of those servers they are moot if that pxe server is dead anyways.... Cheers, Rudy -- 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: Justin Piszcz on 16 Feb 2010 08:20
On Tue, 16 Feb 2010, 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. > 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. > > NeilBrown > Hi Neil, Thanks for the response, this is exactly what I was looking for and probably should be put in a FAQ. Justin. -- 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/ |