civileme wrote: > Lyvim Xaphir wrote: > >> On Mon, 2002-03-18 at 09:51, Sridhar Dhanapalan wrote: >> >>> I am thinking of purchasing a new computer with two hard drives of >>> the same type >>> and size. I am interested in implementing a Linux software RAID0 >>> (striping) >>> setup. I have a few questions on this. >>> >> >> One more thing. Here are the mount points for the raid devices: >> >> [root@tamriel proc]# less mounts >> /dev/root / ext3 rw 0 0 >> /dev /dev devfs rw 0 0 >> /proc /proc proc rw 0 0 >> /dev/md0 /boot ext3 rw 0 0 >> none /dev/pts devpts rw 0 0 >> none /dev/shm tmpfs rw 0 0 >> /dev/hda1 /mnt/win_c vfat rw 0 0 >> /dev/md3 /tmp ext3 rw 0 0 >> /dev/md5 /usr ext3 rw 0 0 >> /dev/md4 /var ext3 rw 0 0 >> /proc/bus/usb /proc/bus/usb usbdevfs rw 0 0 >> /dev/scd0 /mnt/cdrom iso9660 ro,nosuid,nodev 0 0 >> /dev/hdc /mnt/dvd iso9660 ro,nosuid,nodev 0 0 >> >> The following is not necessarily related to raid per se. The system >> here has been arranged according to file lifetimes; in other words, it's >> totally configured from the standpoint of filesystem activity. In my >> personal scheme of things, the activity categories are as follows: >> >> 1) Sacred (root/boot and associated binaries) >> >> 2) Low (Mainly the /usr directory and binaries, but not including src >> and where the source rpms are compiled) >> >> 3) Medium (/var and /home. /home is moved to /var/home and symlinked >> to ../../home. Thus essentially "home" is on the /var partition.) >> >> 4) High (/tmp directory) >> >> The philosophy behind the filesystem activity arrangement is partly >> performance and mostly safety. Filesystem performance is just a neat >> side benefit. The higher the activity of a filesystem, the greater the >> probability that something can go awry in that filesystem. By dividing >> the system up by file lifetimes, damage is contained more efficiently >> and effectively. Symlinks allow us to maintain compatibility with the >> Filesystem Hierarchy Standard. Of course the partitions are placed on >> the hard disks where activity and performance coincide, thus further >> maximizing the strategy and effects. >> >> Example: The /tmp directory has the highest level of activity, >> consequently it also carries with it the greatest level of risk. If by >> chance the /tmp directory was on the root partition, a faux pas in the >> tmp directory would possibly put the entire root partition at risk. In >> the above scenario, a /tmp blowout would be totally non fatal. Just one >> possible scenario. >> >> The partition sizes described in the first message I sent in this thread >> were derived from an experimental LM81 install and hand-picked >> packages. The size of that custom install and the directories were >> assessed, taking into account the final physical resting place and >> possible future expanded size of all the directories, including >> /home. With that information in hand, the LM81 install was wiped and the >> configuration I sent you the first time was installed. >> >> The lion's share of the space goes to the /var partition, which >> physically houses /home, /usr/local, and /usr/src dirs while maintaining >> consistency of locality (to the FHS) via symlinks. Additionally this >> means we have alot of expandability possiblilities with /home without >> having to worry with a /home partition being outstripped spacewise >> because of shortsightedness. Same for game installs in /usr/local. >> Consolidation of space ends up being efficient but not at the expense of >> cramming everything together unilaterally. >> >> >> _________________________________________________________ >> Do You Yahoo!? >> Get your free @yahoo.com address at http://mail.yahoo.com >> >> >> >> ------------------------------------------------------------------------ >> >> Want to buy your Pack or Services from MandrakeSoft? Go to >> http://www.mandrakestore.com >> > One thing should be obvious, since linux software RAID lets you mix > and match, is that you do _not_ need identical type and size drives. > I am running software RAIDs with one IDE and one SCSI. The indetical > type and size sort-of applies to the so-called "hardware" IDE RAID > controllers which work fine to give Windows a single RAID (which you > can partition). Those controllers are of course really BIOS > extensions secret, proprietary and so on ad nauseum, but even they > will work with different drives, just your maximum single extent will > be the size of the smaller drive. > > Civileme > To add last thing, you can try LVM to alocate your partitions (at least relatively) dynamically. You wold probably have to put LVM on top of RAID devices (and not the other way) to use both ;-)
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
