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
