On Thursday 06 January 2005 02:19 pm, Greg Folkert wrote: > Oh, yes my child... all you haav to do is remove udev for the time being > or recompile a kernel with raid* compiled in statically. Dear Greg,
Thanks for your support on this problem and your careful and thoughtful advice! I am glad that you are there on this issue, as I was going a little crazy about this setting up RAID with sarge issue... I was up all last night till 7am.... Let me begin with a question. I am switching over from hardware raid to software raid5. I am used to hardware raid - using adaptec 2400a and 3ware 7506 cards to set up ide raids of about a terabyte (4 or 5 250GB ide drives). With hardware raid, if the raid5 degrades, and if I replace the bad hard drive, and then begin the rebuild of the raid, and then if I need to reboot the machine , the hardware raid device will not mind and will resume the rebuild of the raid from where it left off. I can reboot any number of times, and it resumes from where it left off. This is useful, as I have noticed that it can take 24 hours to rebuild the raid 5 array with a terabyte of data on raid5 on the drives. Similarly, I just set up 750 GN software raid using software raid today, and I notice it is taking approximately 48hours to build the raid5 on a machine with a athlon 64 and a Gigabyte of ram. My question is that it seems to me that I don't know how to start the process of rebuilding a software raid5 and then how to suspend and resume the build of the software raid from where it left off. I suspect that it may be impossible, but am not sure. I want to check that this is impossible with you. Intuitively, this makes sense, as how do we tell the build the RAID process to keep track of where it is up to. Here are two snapshots of the the software RAID rebuild resync process ( here are two outputs during different stages of the rebuild, 18 hours apart). ********* >cat /proc/mdstat Personalities : [raid5] md0 : active raid5 hdg1[3] hde1[2] hdc1[1] hda1[0] 732587712 blocks level 5, 32k chunk, algorithm 2 [4/4] [UUUU] [>....................] resync = 0.6% (1666688/244195904) finish=5541.6min speed=729K/sec unused devices: <none> ******** >cat /proc/mdstat Personalities : [raid5] md0 : active raid5 hdg1[3] hde1[2] hdc1[1] hda1[0] 732587712 blocks level 5, 32k chunk, algorithm 2 [4/4] [UUUU] [=====>...............] resync = 27.8% (67918720/244195904) finish=1994.0min speed=1472K/sec unused devices: <none> Notice: 1) the build process is 2x as fast when I am not running mkfs.ext3 on the same array. :) 2) it takes a long time... Now this seems to me to mean that I can't set up a machine, run mkfs.ext3 and then shut it down and and then move it into the production environment for two days, as I can't turn off the machine in my office and then and then turn on the machine somewhere else, without beginning the raid rebuild from scratch. I could just do that with hardware raid. Am I right that I can't here? Secondly, I am still a newbie in Sarge installs. I am using the sarge netinstall with linux2.6 kernel, I am using RC 2 (release candidate 2 of the netinstall disk) which is very nice to me. Well, what do I do to "get rid of udev" as you advise me. I would prefer to use stock kernels at the moment and am willing to add raid5 module to an initrd.img, unless you tell me it is impossible... I notice that the debian kernel config has the following settings in kernel-image-2.6.8-1-386 # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y does this mean that if I remove the userland tools udev by apt-get remove --purge udev that I will revert to using devfs the standard for the 2.4 kernel series? Moreover- do I actually have to remove the udev? Can I simply turn it off (dangerous) by doing (Warning: I am working at the outer limits of my knowledge here... I am reading UDEV Primer from http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html). OK, so (if you can hold my hand...). Will the following work? #I blast away udev apt-get remove --purge udev. # I notice that devfsd is NOT in the standard Sarge install. I also notice thatthe documentation says that I do not actually ***need*** it. Quote from apt-cache show devfsd " You need to have devfs mounted at boot for this to work. If you don't, your system will keep working as before (with normal on-disc device files). See README.Debian for hints on how to do this. . Your system will work perfectly well without devfs, it is by no means a requirement. Alternatives for devfs are: - common on-disk device files. This is what you get by default. " Question one: Do I install devfsd or just wing it. I am only using this machine as a server. I really dont have any need for usb devices on it. # So now if i do mknod will it be permanent????? mknod /dev/md0 b 9 0 #add modules for raid5 to initrd 1. add following line to /etc/mkinitrd/modules file raid5 2. run the following for the 2.6.8-1-386 mkinitrd -o initrd.img-2.6.8-1-386 /lib/modules/2.6.8-1-386 3. I am running grub so no change to menu.lst # create the raid using raidtools2 or mdadm # i apologize i only know how to use mkraid :( from the software raid howto :( mkraid /dev/md0 # format the file system mkfs.ext3 /dev/md0 #wait and wait and wait until the raid is full resynced ..... # and wait and wait and wait #now run dpkg-reconfigure mdadm (or deprecated raidtools2) to tell it to start # the raid on boot # now create a mount point and # mount the file system and enter it into the /etc/fstab Is this correct??? Additional Question: Is it safe to use tunefs to tell the system NOT to run fsck after 28 reboots or 180 days whichever comes sooner? After all we are running a journaling file system ... And this is a humongous system of 750GB... very long fsck. Thank you so much for this chance to ask my questions!!! Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]