Subject: Re: partition bookkeeping
To: None <tech-kern@netbsd.org>
From: Chuck McManis <cmcmanis@mcmanis.com>
List: tech-kern
Date: 10/04/1999 11:04:13
All,
Bear with me while I ask a stupid(tm) question:
What purpose do partitions serve?
The Mouse's partitions got me thinking a bit (and since you know the start
point you can compute the time of thought based on the headers :-) and I
also had read this morning about IBM getting 31GB/sq inch on disks in the
lab (see www.news.com) which means we've got cheap 50 - 80 GB disks in our
future.
And at first glance 63 partitions might not be enough, except that I
remembered that one of the cool things about the UNIX fs is that it
aggregates many disks as if they were a single "space" from where files are
found (and drive prefixes on DOS are soooooo evil.)
So if I sat down today to design an operating system I would not be
particularly concerned about how to aggregate multiple disks as parts of a
logical whole, rather I would be more concerned about how to aggregate
"qualities" of disk storage.
Many people use partitions because they have two desirable properties:
1) They can be attached or detached from the file system
as a unit.
2) They are constrained by the kernel not to exceed a particular
size.
Since most of these disks aren't "removable" in the classic sense #1 is of
limited value with the new giant disks and #2 could be achieved alternately
with a decent kernel based quota management system.
Even the existing system would work fine if we wrote a meta driver that did
nothing but raw block management (think of it as a super nexus over a scsi
driver) and then created as man virtual disk units from that sea of blocks
for use as "drives" in the UNIX sense. Perhaps using the politically
incorrect designation of 'vd' ( virtual disk ) and an aggregate driver of
rd (raw disk) you could have rd0 export 100e6 raw blocks to the vd driver
and vd0 through vd99 could each request 1e6 blocks for their use, exporting
the standard 8 partitions if you chose (although you must admit that one
would typically "size" the disk to be the desired size and just use the c
partition) And it was in this point of my thinking that I wondered, "If all
the disks were virtual disks, and they were all sized to be exactly the
size needed, then why would we need partitions?"
I'll take it even further and suggest that virtual disks be growable and
shrinkable (done several times before (to wit the Sun meta-disk-driver).
And then go still further and suggest that the block pool be able to assign
attributes to the blocks, qualities like "fast", "redundant", "permanent",
and "removable."
Raw disk devices could contribute blocks to the pool with various
attributes and logical disk devices are constructed by fstab (or equiv)
with pools of blocks with the desired attributes.
Anyway, I am still wondering if rethinking the problem might not solve it
differently.
--Chuck