Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!chinacat!chip From: chip@chinacat.Lonestar.ORG (Chip Rosenthal) Newsgroups: comp.unix.xenix Subject: Re: How to increase inode allocation on disk Message-ID: <1067@chinacat.Lonestar.ORG> Date: 12 Mar 90 21:46:42 GMT References: <80@tygra.UUCP> <647@tuura.UUCP> <226@bradf.UUCP> Organization: Unicom Systems Development, Austin (yay!) Lines: 65 In article <226@bradf.UUCP> brad@bradf.UUCP (Bradley W. Fisher) writes: >This I'm sure works quite dandy under UNIX systems that have separate >filesystems for "root" (/) and "usr" (/usr/spool/news), but the default >for SCO Xenix is to install with *one* file system. It really is a good idea to break out at least news into a seperate file system. This is for two reasons: management of disk space and disk performance improvement. Arguably, your news spool area is one of the most dynamic on the system, and therefore fragments most quickly. By moving news off to another filesystem, fragmentation creep in your other areas should be slowed. There is also the problem that your news spool is essentially open to the world. If somebody wants to create a 10Meg turd and drop it into news.announce.important, you've got it. If /usr/spool/news and /tmp happen to be on the same filesystem, you're in big time trouble if that was your last 10Meg. I also like the psychological thing of having fixed boundaries on the news filesystem -- that's all the space I'll give it, and things are tweaked to keep it within bounds. These fixed walls keep the disk used by news from having an impact on the space allocated for important and productive things :-) >I think the only solution >will be to mount my root floppy disk, edit the "mkfs" part of the >installation scripts, and then reinstall using the modified version. >If anyone has a better idea for SCO, I'm sure John and I are not the >only ones in this boat and would like to hear any ideas. Here is my suggestion. Get pencil and paper and calculator and spreadsheet, and design yourself a set of filesystems. For example, I split up my 150Meg disk into four filesystems: root, local, user, and usenet. Among other considerations, backup policy drove my setup, your mileage may vary. With the aid of du, figure out how much space to give each of these filesystems. Now, do your backups and re-run the SCO installation script, but create the individual filesystems. After completing the SCO installation but before restoring from your backups, run "mkfs" on your USENET filesystem remake it with the number of inodes you want. Now do your restore. By the way, watch out for the sparse files (most notably the USENET history file) on the restore - real disk blocks might get eaten to fill the holes on the restore. You might need to do a rebuild of your sparse files after the restore. Fsck will tell you which inodes are spares (via the "wrong size" error message), and ncheck will convert the i-numbers to file pathnames. One poster said he had 25,000 inodes for a 70M news filesytem (that is 357 inodes/Meg), and found that acceptable. I have 5664 inodes for a 22M filesystem (257 inodes/Meg), and find that to be just on the hairy edge. I took the SCO default, by the way. Another factor is that I also keep the news library and sources on this filesystem, and these are less inode-usage intensive than news articles (English translation: they are bigger on the average than news articles). If I had nothing but news articles on this filesystem then I'd have been dead long before I ran out of disk blocks. I just ran some quick stats on my spool directory (not the entire filesystem -- just the spool directory), and found the total usage to be 3562 inodes and 11135 1K blocks, which translates to 328 inodes/Meg. Hmmm...after all this talkin' I suppose I should get down to it and rebuild my usenet filesystem! -- Chip Rosenthal | Yes, you're a happy man and you're chip@chinacat.Lonestar.ORG | a lucky man, but are you a smart Unicom Systems Development, 512-482-8260 | man? -David Bromberg