Date: Mon, 22 Jan 2007 19:48:25 +0100 (CET) From: Christian Baer <christian.baer@uni-dortmund.de> To: freebsd-questions@freebsd.org Subject: Re: more than 7 partitions on a SCSI-drive Message-ID: <ep30tp$1sp9$1@nermal.rz1.convenimus.net> References: <ep0jcf$1meb$10@nermal.rz1.convenimus.net> <a969fbd10701211254ha01cb66q4ca4fe474c0dfdb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Jan 2007 11:54:40 -0900 Jeff Mohler wrote: One polite request: Would you please quote properly? I know this is not the usenet, but quoting serves a purpose and should make reading you question/comment easier. > If there is a fundamental reason why we still partition things like we > only have 10, 20, or 40Mb RLL. or slightly larger ESDI drives from > back in the day..im willing to learn. In the good ol' days HDs weren't divided up into many partitions. They were usually too small to be of much good then. That actually began when the space that single HDs had became bigger and therefore single HDs could function almost as two or three on the same system. If an error on a filesystem accurs that can take down the entire system if all you have is /. The idea is to limit the amount of damage that can be done to a system by dividing the data up intelligently. Usually most write actions are on /tmp and /var. So if the power goes down before you can shut down the system cleanly, the chances are high that you will have errors on these file systems. If they are all on / then that's bad news. But think about what would happen if data in /tmp ist lost because of a filesystem error. Exactly: nobody cares! Different partitions also have the advantage that they can be mounted with different options, have different block sizes, more or less inodes or can be encrypted. Here are a few ideas as to why I divide my drives up, including some of the reasons why I divided the drives up the way I showed. / ist usually mounted with synchronous writing only (and not soft updates). That is usually relatively slow but doesn't matter on /. You don't want to mess up this filesystem or you could end up not being able to start the system at all. It's best to keep this filesystem small. /usr contains all the programs files, usually the ports and source tree too. Writing to this filesystem isn't that frequent but fast access is definately wanted. /tmp and /var contain quickly changing, usually not too important data. Fast access is important and writing is very frequent. If the system crashes or the filesystems are not unmounted cleanly you usually have errors on these filesystems. A swap partition is there for obvious reasons. :-) /var/spool/news used to contain a lot of files (one file per article) and required more inodes than the other filesystems. This can apply today aswell if you choose byfile storage of news. /home is useful to stop the users filling up /usr, which can be quite a pain. I know this could also be done by using disc quota. /home/christian is mirrored and encrypted as I keep all my personal stuff on there like (e)mail, bank stuff and things from work. But also personal things like my personal diary. I don't want to encrypt all my system as that slows down access dramatically. And it's completely useless waisting CPU-cycles on decrypting the executables of KDE, Firefox and OO. /usr/obj can be put in a seperate filesystem to increase performance. The information in there isn't too important so if anything gets lost because of a power out while doing a make buildworld, just erase it and start over. The performance can be increased if the HDs are the bottleneck. The idea is to read from one drive containing /usr/src and writing to another containing /usr/obj. This partition can be optimized for fast writes rather than safety. I have mounted this filesystem with async. Is my concept a little clearer now? Regards Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ep30tp$1sp9$1>