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 17 Feb 2010 17:30 On Wed, 17 Feb 2010, Nick Bowler wrote: > On 13:17 Wed 17 Feb , david(a)lang.hm wrote: >> On Wed, 17 Feb 2010, Nick Bowler wrote: >> >>> On 10:41 Wed 17 Feb , david(a)lang.hm wrote: >>>> On Wed, 17 Feb 2010, Nick Bowler wrote: >>>>> It takes about half a second for mdadm to assemble my root array, is >>>>> that what you're referring to? >>>>> >>>>> I assume that kernel auto-assembly is no faster, although I've never >>>>> used it. Regardless, half a second isn't very long to wait. >>>> >>>> If you are aiming for a 5-second boot time it's 10% of your total boot >>>> time. That's a lot for a feature that's not needed. >>> >>> Only if the kernel auto-assembly takes zero time, which it obviously >>> does not. >> >> the assembly time would probably be the same, but the initramfs being >> proposed did not include that time either. > > This was the *only* time that was included. Quoting myself: > >> It takes about half a second for mdadm to assemble my root array sorry, I misunderstood, I thought you were referring to the time added by using the initramfs itself. 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: Neil Brown on 17 Feb 2010 18:20 On Tue, 16 Feb 2010 08:14:21 -0500 (EST) Justin Piszcz <jpiszcz(a)lucidpixels.com> wrote: > > > 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. > I believe the linux-raid wiki is open for anyone to update. Feel free :-) NeilBrown -- 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: Goswin von Brederlow on 17 Feb 2010 22:40 Nick Bowler <nbowler(a)elliptictech.com> writes: > On 09:41 Wed 17 Feb , david(a)lang.hm wrote: >> for a distro that is trying to make one kernel image run on every >> possible type of hardware features like initramfs (and udev, modeules, >> etc) are wonderful. >> >> however for people who run systems that are known ahead of time and >> static (and who build their own kernels instead of just relying on the >> distro default kernel), all of this is unnessesary complication, which >> leaves more room for problems to creep in. > > Such people can easily construct an initramfs containing busybox and > mdadm with a shell script hardcoded to mount their root fs and run > switch_root. It's a ~10 minute jobbie that only needs to be done once. Except when mdadm, cryptsetup, lvm change you need to update it. Esspecially when you set up a new system that might have newer metadata. Also at least Debian doesn't (yet) support a common initramfs for their kernel packaging. You either build a kernel without need for one or you have a per kernel initramfs that is automatically build and updated whenever anything in the initrmafs changes. Not often, but still too often, the initramfs then doesn't work. Does any other distribution allow building kernel image rpms that will use a common initramfs for all kernels? MfG Goswin -- 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: Goswin von Brederlow on 17 Feb 2010 22:50 Gabor Gombas <gombasg(a)digikabel.hu> writes: > On Wed, Feb 17, 2010 at 02:26:46PM +0100, Frans Pop wrote: > >> That's simply not true, at least not for Debian. If you actually use the >> distro tools [1] the only assumptions are made at kernel *installation* >> time, not at kernel build time. > > And that's why network-booted diskless clients and virtual guests have > all sort of useless modules loaded; the HW where the kernel package was > installed in this case is very different from the HW where the kernel > will run. If only there were a switch to prohibit ever looking at the > current machine's configuration when generating the initramfs... From my experience you must boot up your client/guest and install the kernel in there. Then copy the kernel and initrmafs over to the boot server for use. Initramfs was never designed to generate an image for another system, or worse, for a pool of different systems. You can probably make it work on a case by case basis but that wasn't thought of during the design phase. Interesting idea though. >> I've been using initramfs-tools generated initrds for years without >> problems, and that includes "root on LVM on LUKS encrypted partition" >> and "root on LVM on RAID" setups. > > I've tried a couple of times to use a Debian-built initramfs with a > custom built kernel. The kernel worked fine without an initramfs (it had > everything built in), but it did not boot with the initramfs. > > Gabor 'make-kpkg ... --initrd kernel-image' should build you your custom kernel with all the magic required to generate a working initramfs. If not then please do file bugs. MfG Goswin -- 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: Ian Dall on 18 Feb 2010 04:50
On Tue, 2010-02-16 at 23:18 +0100, Volker Armin Hemmann wrote: > On Dienstag 16 Februar 2010, Nick Bowler wrote: > > On 22:06 Tue 16 Feb , Volker Armin Hemmann wrote: > > > On Dienstag 16 Februar 2010, Bill Davidsen wrote: > > > > 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... > > > > > > I am running my own kernels - and of course everything that is needed to > > > boot and get the basic system up is built in. Why should I make the disk > > > drivers modules? > > > That does not make sense. > > > > I agree that it makes little sense to make something a module when you > > can't unload it anyway, but... > > > > > And the reason is simple: even when the system is completely fucked up, I > > > want a kernel that is able to boot until init=/bin/bb takes over. > > > > I put a complete set of recovery tools into my initramfses so that when > > the system is completely fucked up, I have a kernel that is able to boot > > until rdinit=/bin/zsh (or /bin/bb, if you prefer) takes over. > > > > This has the added advantage of working when the root filesystem cannot > > be mounted at all: a scenario which does not seem too far-fetched when > > the filesystem is located on a raid array. > > and what do you do if you have to boot from a cd/usb stick and need to access > the raid? > > Simple with auto assembling. Not so much without. I'm not sure what the problem is. I've had to do this (because the disk with grub on the MBR was the one that failed - now I put grub on them all). I booted of the fedora install disk in rescue mode. Told it not to try and mount any system disks, got into a shell and ran mdadm -As I'm not sure what else a kernel auto-assemble would be expected to do that mdadm -As wouldn't... -- Ian Dall <ian(a)beware.dropbear.id.au> -- 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/ |