brown@kpno.UUCP (01/10/84)
This is the much overdo summary of disk layout replies I promised over a month and a half ago. Some of the comments are appropriate to all versions of Unix I am familiar with, others don't apply to the 4.* bsd systems from Berkeley. To everyone who responded to my question, Thank you very much and I apologize for the delay in putting this summary together. -------- 1. Go to 6250 bpi tape drives 2. Individual small file systems are a pain because individual partitions run out of space. Also on large drives you can easily have more than 8 partitions if the drive is large (If you didn't know, 8 is the maximum number of device partitions. 40Mb = 1 tape level 0 dump, so 320 Mb disk max) 3. Set the drive up with a clear partition for "dd" backups. (dump is better for non-full drives, dd for full) 4. Move root (/) to the center of the disk (fix /boot) (Interesting but not really what I was after) 5. V7 systems mung file systems easier than Berkeley so keep the partitions small to minimize info lossage. 6. divvy the disk up in partitions ~33 Mb so a level 0 dump will fit comfortably on a single 2400' tape. You can stack many level 9 dumps on a single tape, though this makes the restores a bit tricky. 7. don't do level 0 dumps as often. level 0 not more often than 6 mos. level 3 each month level 5 each week level 9 daily If the dailys get too big add a level 7 midweek. My own biased opinions after reviewing these responses and considering my situation are: 1 I'd love a 6250 tape drive, there seem to be cheaper ones now. 2,3,5 & 6 I think these are not appropriate for large disks, see caveat on 2 about partitions. 4 I'm gonna try this on our RA81s if we ever get 4.2BSD and our new 750. 7 Sounds like a better schedule than our current one. One person responded with a nice discussion of the whole situation of disks on Unix and some goals to keep in mind while configuring the system. I'll just reproduce his letter below for you: ============================================================================ Subject: Re: Disk partition sizes on big disks My question is, if you have four smaller partitions, each of which takes an entire tape to backup, have you gained anything? There are several things to consider in allocating disk partitions. 1) You can only specify eight distinct partitions per controller-type. 2) Certain system-related file systems get hit harder than others. 3) Load should be balanced over all seek arms. 4) /tmp should be a mounted file system. 5) You should swap off multiple drives. 6) Static file system pieces should be isolated. 7) The Bell or Berkeley-distributed partitions are not sacred. Some explanation. Most people consider it good practice to have root, /usr, and /tmp on separate disks whenever possible. Next, spread users evenly over the drives. This really makes a noticable difference. If your system crashes, chances are /tmp will have file system inconsistencies, since, in theory, all files in /tmp are open most of the time. I've found it useful to make /tmp a separate file system and put a mkfs or newfs for it in my /etc/rc before the mount -a. Then, naturally, you don't fsck it. Another useful thing to do is mount /usr/spool. The result is that /usr then becomes a relatively static file system and can be dumped less often. We have found that incremental dumps of the remaining /usr comprise mostly log files from /usr/adm (like wtmp and acct). There is a motivation for mounting /usr/src on a disk other than the one that /usr is on - if you lose /usr due to serious failure, you can reconstruct most of it from sources. This also lets you mount /usr/src read-only on those machines that simply hold viewable (not modifiable) sources. On RA81's, the Berkeley-distributed partitions are a mess and should be completely revised. I chose partitions in even cylinder group multiples (i.e. multiples of 16 cylinders). For example, my 'a' partition is 32 cylinders (22848 blocks) and 'b' is 48 cylinders (34272 blocks). For the remaining space, I have one partition that covers it all, two more that divide that roughly in half, and two more that divide the first of those in half (about 30/70). If this sounds vaguely like a buddy system, you're right. I kept 'c' has the full-disk partitions, which is basically useless in winchesters. If you're not running 4.1c or 4.2 BSD, having a very large partition is not such a good idea, since all the inodes are concentrated at the beginning of the file system. One more detail. On RA81s, or any disk for that matter, make sure your partition size mod your block size is zero. Fsck fails otherwise when it tries to read the 'last' block on the partition. (Name Deleted) (Institution Deleted) PS Get a 6250 BPI tape drive if you possibly can. ============================================================================= regards, Mike Brown Kitt Peak National Observatory Tucson, Arizona (602) 325-9249 UUCP: {...,allegra,arizona,decvax,hao,ihnp4,sdcsvax,unc} !kpno!brown ARPA: kpno!brown@LBL-CSAM.ARPA
thomas@utah-gr.UUCP (Spencer W. Thomas) (01/11/84)
Re doing full saves only every 6 months. You should make D**M sure that those tapes are readable and have NO errors (or potential errors)! I have been bit too many times by unreadable save tapes. Luckily, we do full saves once a month, so I can usually back up a month and still get the file I want. If I had to back up almost a year, there would be much less chance of it being there. A simple check is dd if=/dev/rmt8 of=/dev/null bs=20b In fact, J Lepreau here modified our (4.1) dump program to re-read each tape in a save-set after writing it, checking for errors. If a read bombed, it would then prompt to remount a NEW tape and resave that volume. This was after we found that tape 5 of a 10 tape filesave had a nasty bad spot in the middle. Moral: Don't assume that just because it's been put on a save tape you can get it back. =Spencer