Re: confused. sarge raid5 -should i use mdadm or raidtools2
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
Reply to: