Greywolf <greywolf@starwolf.com> writes:

> On Sun, 31 Dec 2000, Peter Seebach wrote:
> 
> # It may be.
> # 
> # >I hope I will never fragment my NetBSD storage into more than, let's
> # >say 8 pieces (/, /var, /usr, /usr/src, /usr/{local,pkg}, /usr/home and
> # >two more) on one disk. Likewise, I sincerely hope I will never have to
> # >run more than the present 3 OSes on my laptop. And if there only was a
> # >VMware for NetBSD I'd be much closer to finally ditching Lunix... ;-)
> # 
> # 8 pieces, sure, but on, say, i386, you can only have 5.  b, c, and d are
> # all spoken for.
> 
> I think you're misreading him.  What he's saying is that he'd like to have

Exactly.

> eight available.  I'd like to be able to do that on one disk as well, since
> most other platforms only have five available (root, swap, disk are taken);
> i386 gets totally screwed down to four (root, swap, BSD-partition, whole
> disk).  So I think you're all in agreement here!

I think so too.

My tongue-in-cheek estimate was that 4 lost to system (/, swap, *c,
*d) plus 4 used as two foreign fs each for two other OSes leaves 8
real partitions to NetBSD use which will be sufficient to me at least.

On one disk, that is. If we're dicussing server design two things
happen: a) more disks and b) no other OSes, so the particular problem
of partition shortage more or less disappears. 

The partition shortage is really very much a laptop problem where it
is common to be limited to one disk while needing several OSes for
various reasons. But there are many laptops in the world.

Sidenote on backups and size of backup media (this is a different
thread, not directly connected to the partition issues):

When the size of disks grow faster than the size of tape you will end
up in misery if you try to structure disks accordingly. With the
present technology trends there are basically two ways to cope with
backup misery:

a) backup to disk rather than tape. Since the cost of disk is
   approaching zero the overhead of tape management is growing
   rapidly. So don't do it. Build a RAID-farm or two and backup to
   that. And you don't even have to move tapes.

b) use a disk cache as a buffer between the tape system and the device
   to be backed up. I.e. do it, but disguise the differences in media
   size. This is typically achieved via an HSM system.

For many years we've dumped all our backups into the HSM system and
thereby more or less shielded ourselves entirely from concerns about
changing relations between the size of different media. As long as the
aggregated bandwidth is sufficient there are no problems.

Alas, the NetBSD-based HSM project at NAS seems to have ground to a
halt just as it was about to go into public betatest. Several people
have spoken about how neat it would be with an LVM. Sure, but when
dicussing useful changes underneath the file systems my vote goes to
HSM any day. 

An integrated HSM would have been a fantastic killer app for a time
with exploding storage needs.

...and now I'll leave the soapbox ;-)

Johan Ihrén
Autonomica AB