Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!think!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.unix.questions Subject: Re: Why partition disks? Message-ID: Date: 1 Jun 90 18:32:10 GMT References: <157@locke.water.ca.gov> <154@TWG.UUCP> <912@gistdev.gist.com> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 50 In-reply-to: flint@gistdev.gist.com's message of 31 May 90 22:31:38 GMT In article <912@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett) writes: | Reasons for having more than one file system: | | 1. Each file system can have at most 65,535 inodes, because the inode | number is stored in a 16 bit field in the directories. ... Berkeley based systems typically use a long to hold the inode. | 2. If you have any users you don't completely trust - (perhaps because | they are still naive and don't know what they are doing, not necessarily | because they are dishonest) you can restrict them to one file system, | but if there is only one file system then they may do something wrong | and use up all the space everywhere ... Quotas in BSD are meant to solve this problem, but every BSD system I've seen disables quotas. However, in the cases where I was a system admin, I prefered to use either full disks or partitions of disks for each project, so that there was no gripping that project XYZ used all of the disk space, and the people involved are out at a customer site until next week. | 3. You need to think about how you are going to do backups. If you have | a tape unit that handles 1.2GB/tape maybe this doesn't matter, or if you | have backup software better than the usual default of a cpio to the | tape it may not matter. But if you are copying onto 150MB tapes with | the normal backup scripts that cpio one filesystem at a time to a series | of tapes it does matter- having to recover a single file that someone | accidentally deletes from the 7th tape of an 8 tape cpio archive will be | pretty painful and slow. If you created 4 partitions of 300MB each, | then each backup will use at most 2 tapes; recovering a file becomes | a lot less of a chore, because you won't have to hunt through more | than 2 tapes to find it. This also makes the backups more "secure": | if tape 2 of your 8 tape backup is unreadable because Sally Operator | spilled Pepsi on it, only part of your backup becomes unuseable, not | all of it. I believe that BSD's dump puts the index on the first tape, and doesn't need to sequentially go through each tape, though I haven't used dump directly in awhile. That assumes that you can break your projects into little 300M cubby holes as well. You can partition too much, and spend mucho time chasing symbolic links to make everything look like one massive disk again (assuming you have a system that lets you use symlinks). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so