eho@cognito.princeton.edu (Eric Ho) (07/19/89)
Has anyone out there worked on filesystems that either eliminates partitions. The only reason that I can see to have the notion of partitions around from the OS standpoint is to limit filesystem size (& to make a filesystem) and maybe easier for doing backups. The problem with this approach is that the layout is pretty static -- everytime you need to change the layout or mostly partition sizes, you'll have to backup that disk, run format and restore everything again. This is pretty stupid really -- I mean if I want to expand one partition/filesystem into the space previously occupied by another partition/filesystem, why should I've to go thro' all the backup/restore hassels. Eric Ho Cognitive Science Lab., Princeton University voice = 609-987-2819 (x2987) email = eho@confidence.princeton.edu eho@bogey.princeton.edu
chris@mimsy.umd.edu (Chris Torek) (07/28/89)
eho@cognito.princeton.edu (Eric Ho) asks: >Has anyone out there worked on filesystems that either eliminates >partitions. (Either that or what?) >The only reason that I can see to have the notion of partitions around >from the OS standpoint is to limit filesystem size (& to make a filesystem) >and maybe easier for doing backups. A disk has a size. (I think no one can disagree with this.) Unless you concatenate disks---which is possible; Convex, for instance, have this ability in their kernels---there is thus a hard limit on file system size, namely the size of the disk. All that partitions do is allow you, the system administrator, to divide that hard limit into several smaller hard limits. They do NOT *require* that you do so. The main reason for partitions is to limit file system size (adminstrators may have their own reasons for doing this; the kernel does not care, so long as the FS sizes fit in the 32 bit numbers the kernel uses) and/or to create separate file systems on a single physical medium. >... I mean if I want to expand one partition/filesystem into the >space previously occupied by another partition/filesystem, why should I've >to go thro' all the backup/restore hassels. Clearly the one that is being expanded into will have to be saved first, because the expansion process will overwrite it. The other file system need not be backed-up, but its size is maintained statically, so it will never notice the extra space unless you re-create it. It is not necesssary to reformat, but it is necessary to run newfs. The real question here may be `why is it necessary to run newfs?' Well, you could write a `dynamic' file system in which it was not necessary. You will lose some performance in the process. Given that I change file system sizes less often than once a year, I would rather have the performance. Or, you could write a special version of `newfs' that carefully expands an existing file system without disturbing any of the data contained therein (except of course the free block maps and cylinder group summaries). There are some constraints on how well this would work, but I imagine it would make a good project for someone. In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
zjat02@uunet.uu.net (Jon A. Tankersley) (08/06/89)
You wouldn't have to format the entire disk in that scenario. Just change the partition maps to reflect your changes and then newfs and restore. It is a hassle, but there are some valid reasons for some limits. The biggest is runaway programs. Some other ways out of the problem can be done via symlinks, or other mechanisms. Some nice products do allow you to specify an environment variable to set up it's default path. That makes it real easy to put things where you have the space. Frame for example has FMHOME. Of course, to be on the safe side, you do have a duplicate root and usr partition on another spindle (and controller of course) in case something bad happens :-). An a SCSI on every server :-). -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */ tank@apctrc.trc.amoco.com ..!uunet!apctrc!tank
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/21/89)
? From: Chris Torek <chris@mimsy.umd.edu> ? eho@cognito.princeton.edu (Eric Ho) asks: ? >The only reason that I can see to have the notion of partitions around ? >from the OS standpoint is to limit filesystem size (& to make a filesystem) ? >and maybe easier for doing backups. ? The main reason for partitions is to limit file system size (adminstrators ? may have their own reasons for doing this; the kernel does not care, so ? long as the FS sizes fit in the 32 bit numbers the kernel uses) and/or to ? create separate file systems on a single physical medium. Well, yes, this is a very good reason for the existence of partitions. Of course, there are others. For example, an application (or group of them) which uses large amounts of space can be fenced in by partitions. However, my favorite use of them is as read-only space. Take all your distribution tapes, sources, etc., put them in a RO partition, and make symlinks links elsewhere to them. They are now uncorruptible, even by root. They are also quick to access; no updating atimes. Root Boy Jim Have GNU, Will Travel.