partitions (bad idea ??)

Chris Torek chris at mimsy.umd.edu
Fri Jul 28 20:01:09 AEST 1989


eho at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.sys.sun mailing list