geo@necis.UUCP (George Aguiar ext. 224) (02/22/86)
I'm always running out of blocks on my root file system and it is a fixed size. This makes me wonder what other people do. So if you have time and some interesting input please fill out this survey, I'll summerize if there is enough response. How big is the typical root file system? ________ Blocks Does your particular implementation allow you to change the size of the root file system? If so, what criteria do you consider when deciding how big to make the root file system? What hardware? What O.S.? Comments: Thanks, linus!encore!necis!geo -- "If you are completely blind, attach a statement to your Return to this effect." 1985 Federal Income Tax Forms and Instructions ;->
chris@umcp-cs.UUCP (Chris Torek) (02/28/86)
In article <253@necis.UUCP> geo@necis.UUCP (George Aguiar) ... asks about typical root file system sizes. Unfortunately, his survey reads as follows: >How big is the typical root file system? ________ Blocks `Blocks' are not a good measure, as the block size of different file systems varies. Kilo- or mega-bytes is a better basic unit. Incidentally, I went to ~30 megabyte roots during our 4.3 Beta conversion. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
philip@axis.UUCP (Philip Peake) (03/03/86)
In article <253@necis.UUCP> geo@necis.UUCP (George Aguiar ext. 224) writes: > > I'm always running out of blocks on my root file system and it is a fixed >size. This makes me wonder what other people do. > >How big is the typical root file system? ________ Blocks > >What criteria do you consider when deciding how big to make the root >file system? > Choosing the size for a root filesystem is always a compromise. The manufactures of small "packaged" UNIX systems (almost) invariably give too little space. However, if you have enough sources to re-configure some of the system configuration, the following may be of some help. There are normaly three types of activity on a root filesystem: 1) "Normal", ie, file updates (modification of passwd file etc), and modification of various inode values (especially on tty special devices. This does not normaly involve "eating" any disc space. 2) /tmp activity (this is where a fair proportion of your blocks dissapear). You really do need several Mb of tmp space for any system supporting more than one user and doing any real work. 3) Pipes. Normaly inodes and data blocks will be allocated, but not written to (unless the system is heavily loaded). However, the blocks are allocated, and so are temporarily unavailable. To help isolate these activities, and to improve "crash resistance", I normaly suggest the following: Use a seperate filestore for /tmp. If this is where your space dissapears it will soon become obvious. This also has other advantages; a system crach may leave the /tmp filestore mangled, but this is preferable to a mangled root ! In reducing activity on root you improve its reliability. At boot time it is probably faster to do an mkfs on the tmp filesystem than to do an fsck, it also cleans it out for you ! Change the pipedev (device on which pipes are created) from the root system to the /tmp file system. If you look at the damage after a crash, a large proportion of the garbage on the root system comes from pipes, so, putting these on the tmp system again improves root reliability. If you make these two changes then the root system becomes virtualy "read only" - not quite, because of inode changes, and things like the passwd file. However, activity is very much reduced. The space required is then simply the space required for all of the files normaly present on your root, plus a bit spare for new utilities, passwd file growth etc. Things to watch for if you use this approach are: 1) You can't use pipes until the pipedev is mounted. This isn't normaly a problem. If you are going to work in single user mode just remember to mount the filesystem. For multi user mode, make the mount the first thing in /etc/rc 2) If you use a seperate filesystem for /tmp, don't make the mistake I have seen one manufacturer make, which is to create some temporary files *before* mounting on /tmp, and then wondering why the free space on root is slowly dissapearing ... Philip Peake. ------------------------------------------------------
bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (03/03/86)
Something you can do immediately on any UNIX system that you are running out of root space on is follow the lead of 4.3, SUN and others and create a /usr/etc area and move things out of /etc that aren't going to run unless /usr is up anyhow such as some of the networking daemons. Modify rc and rc.local as appropriate (or make symbolic links from /etc if you run 4.2bsd, tho I would still recommend changing rc's rather than create complexity where there needn't be any, one exception to this might be termcap, a symbolic link is a good idea for that one.) Obviously, use your common sense and think through a little what you might need if you have to recover the /usr file system from single-user mode (don't move dump or restore, for example.) -Barry Shein, Boston University