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: Michael Evans on 14 Feb 2010 15:10 On Sun, Feb 14, 2010 at 11:34 AM, Henrique de Moraes Holschuh <hmh(a)hmh.eng.br> wrote: > On Sat, 13 Feb 2010, Michael Evans wrote: >> I remember hearing that 1.x had /no/ plans for kernel level >> auto-detection ever. �That can be accomplished in early-userspace >> leaving the code in the kernel much less complex, and therefore far >> more reliable. > > Yes, it is far more reliable kernel side, if only because it doesn't do > anything. > > But the userspace reliability is _not_ good. �initrds are a source of > problems the moment things start to go wrong, and that's when they are not > the problem themselves. > > And the end result is a system that needs manual intervention to get its > root filesystem back. > > In my experience, every time we moved critical codepaths to userspace, we > ended up decreasing the *overall* system reliability. > > -- > �"One disk to rule them all, One disk to find them. One disk to bring > �them all and in the darkness grind them. In the Land of Redmond > �where the shadows lie." -- The Silicon Valley Tarot > �Henrique Holschuh > Maybe you'd like a simple, easy to customize initramfs creator. That's exactly what I was aiming for when I made AEUIO https://sourceforge.net/projects/aeuio There are some things that could use improvement, but if your system can boot without loading modules it should be more than sufficient even across kernel versions. -- 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: Asdo on 14 Feb 2010 15:30 H. Peter Anvin wrote: > On 02/13/2010 12:07 PM, Justin Piszcz wrote: > > 0.90 has a very bad problem, which is that it is hard to distinguish > between a RAID partition at the end of volume and a full RAID device. > This is because 0.90 doesn't actually tell you the start of the device. > > Then, of course, there are a lot of limitations on size, number of > devices, and so on in 0.90. > > -hpa > I don't understand... In a system we have, the root filesystem on a raid-6 which is on second (and last) partitions of many disks. It always assembled correctly, it never tried to assemble the whole device. (on the first partition there is a raid1 with boot) So what's the problem exactly with not marking the beginning? -- 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: Asdo on 14 Feb 2010 15:50 Henrique de Moraes Holschuh wrote: > On Sat, 13 Feb 2010, Michael Evans wrote: > >> I remember hearing that 1.x had /no/ plans for kernel level >> auto-detection ever. That can be accomplished in early-userspace >> leaving the code in the kernel much less complex, and therefore far >> more reliable. >> > > Yes, it is far more reliable kernel side, if only because it doesn't do > anything. > > But the userspace reliability is _not_ good. initrds are a source of > problems the moment things start to go wrong, and that's when they are not > the problem themselves. > > And the end result is a system that needs manual intervention to get its > root filesystem back. > > In my experience, every time we moved critical codepaths to userspace, we > ended up decreasing the *overall* system reliability. > I don't see it like this. You have the same chance to screw up the system by making mistakes in the files in /etc, in the networking config, the firewall, the server applications... (note: I speak for Debian/Ubuntu, redhat's initramfs I think is more messy.) 1.x autodetection worked great for me in initramfs. Basically you only need /etc/mdadm/mdadm.conf copied to initramfs (via update-initramfs), the rest is done by Debian/Ubuntu standard initramfs procedure. Also consider 1.x allows to choose which arrays are autoassembled (hostname written in the array name equal to hostname in the machine or specified in mdadm.conf): this is more precise than 0.9 which autoassembles all, I think. -- 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: Henrique de Moraes Holschuh on 14 Feb 2010 16:20 On Sun, 14 Feb 2010, Michael Evans wrote: > Maybe you'd like a simple, easy to customize initramfs creator. If the distro doesn't use it (as its default initramfs creator, even), it is a lot more chance for breakage. Less testing, and all that... And if I am deploying a specific kernel in a server, you better believe it is important enough that all due care will be taken so that it won't need an initrd to mount the root filesystem to begin with ;-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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 14 Feb 2010 16:20
On 02/14/2010 12:25 PM, Asdo wrote: > I don't understand... > In a system we have, the root filesystem on a raid-6 which is on second > (and last) partitions of many disks. > It always assembled correctly, it never tried to assemble the whole device. > (on the first partition there is a raid1 with boot) > So what's the problem exactly with not marking the beginning? In Fedora 12, for example, Dracut tries to make the distinction between whole RAID device and a partition device, and utterly fails -- often resulting in data loss. With a pointer to the beginning this would have been a trivial thing to detect. IMO it would make sense to support autoassemble for 1.0 superblocks, and making them the default. The purpose would be to get everyone off 0.9. However, *any* default is better than 1.1. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/ |