Re: Bitmaps Kernel Versions
On Wed, Mar 15, 2006 at 09:08:17PM +1100, Neil Brown wrote: On Wednesday March 15, [EMAIL PROTECTED] wrote: Hi, I'm planning to use bitmaps on some of our RAID1 arrays. I'm wondering how bitmaps are handeled by older kernels. Eg: I create a raid array with a bitmap under a 2.6.15 kernel. I now want to boot under 2.6.12, or even 2.4 Hos is it handeled? Will it work even if this is my / partition? On older kernel will not notice the bitmap and will behave 'normally'. strange, last time i tried an older kernel would refuse to activate an md with a bitmap on it. I am far from home on a business trip and i don't have kernel-sources at hand, but i seem to remember that the kernel was very strict on the feature bitmap in the superblock. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A random initramfs script
On Wednesday March 15, [EMAIL PROTECTED] wrote: On 08:29, Nix wrote: I try to avoid running daemons out of initramfs, because all those daemons share *no* inodes with anything else you'll ever run: more permanent memory load for as long as those daemons are running, although at least it's swappable load. Fair enough, but portmap is needed to mount NFS filesystems. How much memory would be saved if I'd kill portmap after the mount and restart it afterwards from a mounted filesystem? You shouldn't need portmap to mount an NFS filesystem unless you enable locking, and you shouldn't enable nfs locking on the root filesystem, so you shouldn't need portmap in the initramfs. The following works pretty well for me: echo DEVICE /dev/hd*[0-9] /dev/sd*[0-9] /dev/md[0-9] /etc/mdadm.conf mdadm --examine --scan --config=/etc/mdadm.conf /etc/mdadm.conf mdadm --assemble --scan Yeah, that would work. Neil's very *emphatic* about hardwiring the UUIDs of your arrays, though I'll admit that given the existence of --examine --scan, I don't really see why. :) He likes to compare the situation with /etc/fstab. Nobody complains about having to edit /etc/fstab, so why keep people complaining about having to edit /etc/mdadm.conf? Indeed! And if you plug in some devices off another machine for disaster recovery, you don't want another disaster because you assembled the wrong arrays. I would like an md superblock to be able to contain some indication of the 'name' of the machine which is meant to host the array, so that once a machine knows its own name, it can automatically find and mount its own arrays, but that isn't near the top of my list of priorities yet. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A random initramfs script
On 20:56, Nix wrote: What I meant is that it never gets overmounted by a real rootfs. The rootfs never overmounts anything. Do you mean `it never gets overmounted by a real root filesystem'? Yes, that's what I tried to say. Sorry about the confusion. Basically I have three similar setups that work with the same init script: The main server which has all its filesystems on lvm. There is only one vg and only one pv, a raid 10 array. /bin, /etc, /home, /lib /root, /sbin, /tmp, /usr and /var are all lvs. They are mounted by the the init script of the initramfs. That script does the full boot and finally execs busybox init just do start the getty processes. A bunch of NFS clients. They boot similarly, but mount everything (except /etc) via NFS. The rescue system. Still the same, but does not mount anything as everything is contained in the initramfs. None of these have a real root filesystem. nfsroot support isn't even compiled in for the NFS clients. If so, that's a... most peculiar setup: I don't think I've ever heard of anything but systems meant to run on diskless kiosks and the occasional live cd running like that. It works pretty well. My diskless desktop is up for more than 100 days and the main server had a similar uptime before I rebooted some days ago (to try out dccp). ... but looking at init/initramfs.c, you should be safe as long as the initramfs can be loaded at all (on i386 I think there's a 16Mb limit on that but it depends on the arch and the bootloader and all sorts of horrid arcana: most arches have a much higher limit). I just booted a rescue system on i386 which is definitely larger than 16MB compressed. I always thought an N MB initramfs cuts about N MB of the main memory, plus some housekeeping data, but that's all. This view is probably a little bit too naive ;) It does, *unless* you switch root filesystems appropriately, that is, you unlink everything in the initramfs before `exec chroot'ing into the real root filesystem. In practice this has to be done by a dedicated C program in order to get away with deleting /dev and the very chroot binary itself :) and that's what busybox's switch_root does. In view of this chicken-egg problem it looks much cleaner to me to avoid the chroot :) ifconfig? route? ick. ip(8) is the wave of the future :) far more flexible and actually has a comprehensible command line as well. Thanks for the tip. I'll give it a try. http://lartc.org/ describes many of its myriad extra features in more detail. All that stuff seems to be fairly old, linux-2.6. isn't mentioned at all and the cvs server doesn't work. Is it still up do date? I try to avoid running daemons out of initramfs, because all those daemons share *no* inodes with anything else you'll ever run: more permanent memory load for as long as those daemons are running, although at least it's swappable load. Fair enough, but portmap is needed to mount NFS filesystems. How much memory would be saved if I'd kill portmap after the mount and restart it afterwards from a mounted filesystem? All of it. The only reason running daemons from initramfs wastes memory is that if you've got the binaries open/running and you delete them, in standard Unix fashion the space used by them won't be reclaimed until they're closed/stopped --- and the standard procedure for switching from an initramfs involves unlinking everything on the filesystem. There's *nothing* special about the rootfs filesystem on which initramfs runs except that it's a ramfs filesystem, and as such nonswappable, and that it's the start and end of the kernel's list of mount points (which means that unmounting it, mount --moving it, and so on, is impossible). It behaves just like a POSIX filesystem because it is one. In fact it's almost exactly the same as a tmpfs except that it's not swap-backed, and its maximum size can't be limited in the way tmpfs can. (tmpfs is a small hack atop ramfs.) Thanks for the explanation. I really appreciate it! so why is dynamic scanning the preferred method in LVM, yet discouraged in the md world? I see some conflicted messages here ;) I'm afraid, only Neil will be able to answer this. BTW: I agree with you and do not see the point in hardwiring the UUIDs either. mdev is `micro-udev', a 255-line tiny replacement for udev. It's part of busybox. Cool. Guess I'll have to update busybox.. done. The new busybox (from SVN) seems to work fine, just like the old one did. The init script doesn't use mdev yet, but from a first reading this is just a matter of translating /etc/udev/udev.conf to the mdev syntax. You need SVN uClibc too (if you're using uClibc rather than glibc); older versions don't maintain the d_type field in the struct dirent, so mdev's scanning of /sys gets very confused and you end up with an empty
Re: A random initramfs script
On Thu, 16 Mar 2006, Neil Brown wrote: On Wednesday March 15, [EMAIL PROTECTED] wrote: On 08:29, Nix wrote: Yeah, that would work. Neil's very *emphatic* about hardwiring the UUIDs of your arrays, though I'll admit that given the existence of --examine --scan, I don't really see why. :) He likes to compare the situation with /etc/fstab. Nobody complains about having to edit /etc/fstab, so why keep people complaining about having to edit /etc/mdadm.conf? Indeed! And if you plug in some devices off another machine for disaster recovery, you don't want another disaster because you assembled the wrong arrays. Well, I can't have that go wrong because I assemble all of them :) One thing I would like to know, though: I screwed up construction of one of my arrays and forgot to give it a name, so every array with a V1 superblock has a name *except one*. Is there a way to change the name after array creation? (Another overloading of --grow, perhaps?) (I'm still quite new to md so rather queasy about `just trying' things like this with active arrays containing critical data. I suppose I should build a test array on a sparse loopback mount or something...) I would like an md superblock to be able to contain some indication of the 'name' of the machine which is meant to host the array, so that once a machine knows its own name, it can automatically find and mount its own arrays, ... and of course you could request the mounting of some other machine's arrays if you cart disks around between machines :) Seems like a good idea. -- `Come now, you should know that whenever you plan the duration of your unplanned downtime, you should add in padding for random management freakouts.' - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
