rfinch@caldwr.water.ca.gov (Ralph Finch) (05/31/90)
We are about to receive two 1.2GB SCSI drives (Wren 7s) :-) :-) .
These will be used mainly for data storage with some space for home
directories and public domain stuff. We are wondering how to
partition these things when they get here. Actually we would like 1
partition per disk if it won't hurt anything.
1) Does partitioning affect performance (capacity and speed)?
2) Does partitioning affect fragmentation? Does one have to worry
about fragmentation with Unix, or SCSI, or ?
--
Ralph Finch 916-445-0088
rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch
Any opinions expressed are my own; they do not represent the DWRbill@TWG.UUCP (Bill Irwin) (05/31/90)
In article <157@locke.water.ca.gov> rfinch@caldwr.water.ca.gov (Ralph Finch) writes: > >1) Does partitioning affect performance (capacity and speed)? > >2) Does partitioning affect fragmentation? Does one have to worry > about fragmentation with Unix, or SCSI, or ? Everything I have ever read about disk management tells me that smaller file systems on a disk are more efficient than large ones. There are far fewer inodes to check, for one thing. I'm not sure if you really mean partitions or file systems. I would strongly recommend your boot disk be split into at least 2 file systems. One for /dev/root, and only put the O/S and things that can't live anywhere else there. The rest of the disk could be a 2nd and/or 3rd file system. Have the O/S on its own file system allows you to reload your O/S without having to reinstall all your software, or cherry pick applications out of a tape archive taken prior to the reload. You do need to be concerned about fragmentation with Unix, but I believe there are fsck options that can reorganize a file system somewhat. I'm not totally familiar with though, so I won't hazzard a wrong suggestion. You get a tremendous feeling of wealth with lots of disk space...but it always seems to get used up again somehow..... -- Bill Irwin TWG The Westrheim Group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604)431-9600 (voice) (604)431-4629 (fax) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
meissner@osf.org (Michael Meissner) (06/01/90)
In article <157@locke.water.ca.gov> rfinch@caldwr.water.ca.gov (Ralph Finch) writes: | We are about to receive two 1.2GB SCSI drives (Wren 7s) :-) :-) . | These will be used mainly for data storage with some space for home | directories and public domain stuff. We are wondering how to | partition these things when they get here. Actually we would like 1 | partition per disk if it won't hurt anything. | | 1) Does partitioning affect performance (capacity and speed)? | | 2) Does partitioning affect fragmentation? Does one have to worry | about fragmentation with Unix, or SCSI, or ? There is some folklore that things placed in the middle of the disk will be accessed quicker than things placed on either end since the head is typically somewhere near the middle. Thus some system managers have placed absolutely critical partitions in the middle to deal with this (yes, I've done this in a previous life). I'm not sure it's worth it, unless you have some fixed size data base that accounts for 80% of your disk traffic (though of course it might be an ideal spot for /usr and/or swap). It is possible that fsck and/or the kernel on some UNIX ports can't deal with a 1.2G disk (which is why the original unix partitioned disks). If your system limits you to 16-bit inodes, you probably should partition the disk, since you are getting into the range that the system won't be able to allocate all of the available disk blocks (I forget where the cutoff value is). Also, cpio can only deal with 16-bit in binary mode or ~18 bits in decimal inodes. Fragmentation will always exist, but UNIX gives you no tools to deal with it (other than full dump and load). -- 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
flint@gistdev.gist.com (Flint Pellett) (06/01/90)
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. That means you have a maximum of that many files in the file system-- which may sound like a lot until you look at that 1.2 GB space and realize that if your average file is less than about 18K bytes you'll run out of inodes long before you are able to take advantage of the disk space. Keeping news in it's own file system (since it tends to use up lots and lots of inodes) is often a good idea. 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, which could then cause other things that aren't theirs to bomb off with no space in /tmp, etc. (Don't laugh- it happens. I had a group of 3 college level users end up copying all of /usr into the home directories of new logins they were creating in /usr2 when they screwed up their creation script. (They were copying /usr/$TEMPLATE to the new location when $TEMPLATE was not set, or something like that.) I first found out about it when they complained that "Creating logins used to take 10 seconds and now it takes 20 minutes per login...") 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. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 INTERNET: flint%gistdev@uxc.cso.uiuc.edu UUCP: uunet!gistdev!flint
andy@syma.sussex.ac.uk (Andy Clews) (06/01/90)
Someone else has already mentioned that partitioning does positively affect performance, but you should also look at it from the practical point of view. Dividing different stuff into partitions means that you can do dumps at varying intervals for stuff that's of varying importance. For example, we have a /scratch partition (used for temporary work files and as a "parking" area) that is never dumped, whereas the user partitions are dumped daily. Having everything on one partition forces you to dump everything and thus use more tape. You might also want to build file systems with different block sizes in order to improve fragmentation. For example, our /news partition has small block sizes due to large number of inodes and relatively small mean file sizes. The user partitions have a wider spectrum of file size, and not so many inodes, so are built with larger block sizes. Should any serious corruption occur it will be far more disruptive to have to rebuild one large partition, rather than to rebuild just a single partition out of several. Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, England JANET: andy@syma.sussex.ac.uk BITNET: andy%syma.sussex.ac.uk@uk.ac -- Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, England JANET: andy@syma.sussex.ac.uk BITNET: andy%syma.sussex.ac.uk@uk.ac
meissner@osf.org (Michael Meissner) (06/02/90)
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
guy@auspex.auspex.com (Guy Harris) (06/02/90)
>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. Speak for yourself. There exist versions of UNIX with more modern file systems that have 32-bit inumbers; the original poster didn't specify what flavor of UNIX they have, so they may or may not have a 64K inode limitation on their file systems.
rfinch@caldwr.water.ca.gov (Ralph Finch) (06/02/90)
In article <3419@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>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. > >Speak for yourself. There exist versions of UNIX with more modern file >systems that have 32-bit inumbers; the original poster didn't specify >what flavor of UNIX they have, so they may or may not have a 64K inode >limitation on their file systems. It's SunOS which I assume uses the 32-bit inumbers. My thinking right now is, one of the 1.2GB drives will be divided into 2 partitions, for /home and /pub stuff; the other just 1 partition, for large files (we run numerical models which tend to generate a few large files). Most concerns expressed so far have been about administering the drives, which is valid, but right now we just want some handy scratch space, mainly. -- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch Any opinions expressed are my own; they do not represent the DWR