mikej@lilink.UUCP (Michael R. Johnston) (07/14/89)
For some time now I've heard from various people that it is unwise to NOT partition large Xenix file systems. For example, we typically install systems with 103 meg hard drives in our franchise offices. To simplify the installation I normally only create one large filesystem. I suspect that there are several advantages to partitioning that are not apparently obvious. My main intent is to keep the installations as simple as possible. My questions are: 1- What are the advantages of using multiple smaller partitions? 2- If using smaller partitions is advantageous, what is the rule of thumb (if any) that one uses to determine partition size. Many thanks. -- Michael R. Johnston System Administrator rutgers!lilink!mikej LILINK Public Access Xenix (516) 872-2137/2138/2349 1200/2400 Login: new
edhew@xenitec.uucp (Ed Hew) (07/20/89)
In article <774@lilink.UUCP> mikej@lilink.UUCP (Michael R. Johnston) writes: >For some time now I've heard from various people that it is unwise to >NOT partition large Xenix file systems. For example, we typically install >systems with 103 meg hard drives in our franchise offices. To simplify the >installation I normally only create one large filesystem. I suspect that >there are several advantages to partitioning that are not apparently >obvious. My main intent is to keep the installations as simple as possible. The only reason I can think of why someone might want to have multiple xenix partitions would be to enable you to boot selective different xenix systems, but perhaps someone else can provide other reasons. I will make the assumption that you don't mean multiple partitions, but rather multiple filesystems. >My questions are: > > 1- What are the advantages of using multiple smaller partitions? (assuming we mean fs's) You can limit problems with specific parts of your system "overflowing" and grinding a single fs system to a halt. For example, I have the following here: Mount Dir Filesystem blocks used free % used iused ifree %iused / /dev/root 140000 112366 27634 80% 5659 11829 32% /src /dev/src 71742 64330 7412 90% 2664 6296 30% /usr/spool/ /dev/news 140000 111444 28556 80% 18885 6107 76% /usr/spool/ /dev/uucp 40000 12162 27838 30% 204 7796 3% so, if my news filesystem overflows, it doesn't eat my root filesystem and bring the system to a semi-crashing halt for lack of disk space. So, I loose some news, oh well, I would have anyhow, but the system as a whole stays alive and I can rectify things relatively easily. Another simple reason is that of course it makes backups much easier. My root fs changes can usually fit onto a floppy monthly, whereas (if I followed my own advice after buying a _still_larger_ drive) my user files (/dev/u which I should have) would (and does) change by the minute. Again, news is nice, but I don't back it up daily, so having it in it's own fs makes this easy. Same with /dev/uucp (which is mounted on /usr/spool/uucp ). ..... you get the picture..... Actually, I have one *more* fs than is shown above, but I only mount it when I need it, so it's effectively hidden. I know it lives and can mount it, nobody else knows about it. :-) Even if my users did (from reading this article perhaps), it's not user mountable. This could be a useful security precaution for sensitive data. I'm sure there are more reasons, those are the ones which come to mind at the moment. > 2- If using smaller partitions is advantageous, what is the rule > of thumb (if any) that one uses to determine partition size. Simply estimate what the contents of the proposed fs require, tempered with the physically available space overall, and make your filesystems accordingly. Each site is different in this respect. At the same time, decide whether the default number of inodes created are appropriate to your use of that fs. >For example, we typically install >systems with 103 meg hard drives in our franchise offices. To simplify the >installation I normally only create one large filesystem. I suspect that >there are several advantages to partitioning that are not apparently >obvious. My main intent is to keep the installations as simple as possible. You'll have to decide whether the advantages are sufficient for your 103meg sites. Typically for storage of that nature, I would make a root fs and a /u fs and leave it at that, as you're not likely to be running things like news on it or feeding a number of uucp sites. --ed {edhew@xenitec.uucp} >Many thanks. >Michael R. Johnston, System Administrator rutgers!lilink!mikej Ed. A. Hew Technical Trainer Xeni/Con Corporation work: edhew@xenicon.uucp -or- ..!{uunet!}utai!lsuc!xenicon!edhew home: edhew@egvideo.uucp -or- ..!{uunet!}watmath!egvideo!edhew home: changing to: edhew@xenitec.uucp [but be patient for new maps] # I haven't lost my mind, it's backed up on floppy around here somewhere!
brad@looking.on.ca (Brad Templeton) (07/21/89)
Multiple filesystems have another important use. You can try to keep the root filesystem, or its main components (/usr, /lib etc.) as pure as possible and as close to the SCO release. Put your local mods and binaries into your own directories on another FS whenever you can. Then when it comes time to update your OS, it's a lot easier to do. Just backup the few changes you had to make (/etc/passwd and so on) and do a fresh install of the distribution. Or if they have an "upgrade" system, it is more likely to work if you have a filesystem that looks as much like they expect it to look. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473