--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 18, 2002 at 10:13:11AM -0800, Greywolf wrote:
> Unfortunately, this is the case.
[...]
> Unfortunately, this, too, is the case.

Oh well. I can deal. I'll just have to buy the new 80 (or 100! or
160!  Wheeeee!) GB drive along with the 40 GB one for another
machine at the same time, use the 40 GB for temporary storage, make
the ccd, and dump things back. (Or, um, actually get a backup system
for that machine. :^>)

What I do when the ccd runs out of space, of course, gets to be a
complicated problem. Perhaps it's time to just get a real backup
system for that machine.

> It could certainly benefit from extensibility.  The trick,
> as I understood it to be, is that as you change the "geometry" of
> the disk, the result of the spare-superblock calculation also changes,
> so unless you commit a list of superblocks somewhere, or unless you
> find someplace to stash the old ones, and preserve the data blocks that
> inhabit the place where superblocks are going to live, you're going
> to lose something.

Hrm. I'm not sure I want having my mp3s on a (logically) huge disk
to end up in my extending ccd. Though doing so does sound interesting.

(I'm also not convinced that it's really fixing a problem that
actually exists. I mean, sure, I may want to do it this way to be
cheap and not have to copy 40 GBs of music--which I do own,
thankyouverymuch--back and forth, but most people would just use
hardware RAID for this.)

Making ccd allow the addition of drives (and the creation of a new
ccd from an extant file system) doesn't sound like it'd be
completely horrendous (erm, creating with striping from an extant
file system actually seems like it would be a nightmare, but it
wouldn't be the end of the world to disallow that). But that
shouldn't come off as my volunteering to do it (or demanding that
anyone else should ;^>).

> The reorganization of such an operation is not, from my extremely
> limited point of view, exactly what I would term as "trivial",
> but as I'm not a fs hacker, what do I know...?  Anyone have any
> insight as to how Solaris, HP/UX, AIX or IRIX manage to do this?

All of the above have (or third parties have created) software disk
organizer tools that can join partitions (or disks), create mirrors,
and so forth from extant logical disks (which could well be and
often are hardware RAIDs) without necessarily reformatting the
components. It's something that'd be kind of nice to have for
NetBSD, but it's a huge project. (I'd say having things like LWP and
SMP be part of the main tree is more important to me, and probably
to more people. Without that stuff, NetBSD wouldn't be attacking
the kind of high-end server market where such disk management is
routinely necessary.)

Thanks for the response...

--=20
gabriel rosenkoetter
gr@eclipsed.net

--HlL+5n6rz5pIUxbD
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjxIb7AACgkQ9ehacAz5CRp5JgCfQMcTOLQ6iQKgjor0drMrI6RS
UI4AoKhf129fPaiSZqvT1v9KFFjub6lG
=iwHa
-----END PGP SIGNATURE-----

--HlL+5n6rz5pIUxbD--