Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 06 Oct 1996 11:59:41 -0400
From:      "Kevin P. Neal" <kpneal@pobox.com>
To:        Darren Reed <avalon@coombs.anu.edu.au>
Cc:        terry@lambert.org (Terry Lambert), avalon@coombs.anu.edu.au, jrg@demon.net, mrg@eterna.com.au, hackers@freebsd.org
Subject:   Re: VPS mailing list, BSD interest?
Message-ID:  <1.5.4.32.19961006155941.00691300@mindspring.com>

next in thread | raw e-mail | index | archive | help
At 07:13 PM 10/6/96 +1000, Darren Reed wrote:
>In some mail from Terry Lambert, sie said:
>> 
>> > Ok. Doesn't this assume that whatever is sitting on top of the partition
>> > is a filesystem? What if it isn't? What if a database or something or
>> > other is sitting on top? Would resizing be possible? Wouldn't the mechanism
>> > of communicating the resize be different because of the user program 
>> > hitting the disk instead of going through a filesystem?
>> 
>> You would only allow vetted changes.  I there was a database (actually,
>> a private FS for a database) there, then the change would probably not
>> be vetted.  If it's not vetted, it's disallowed (and a veto is given
>> using the default vetting code).
>
>What you might want to do is disallow changes (in size) to any partition
>that is "open" and is not of a (mounted) type which recognises shrink/grow
>dynamically.

Hmmm. Ah, yes sounds good. 

>Being able to "rationalize" disk space would be nice too, so that if you've
>used 60% of a logical volume and want to reduce it to make space for
>elsewhere, you can make sure that 60% is compactly used and not scattered.

Which still requires the LVM to talk to the FS. The FS has to be told to
get out of the way of a shrink. The FS has to tell the LVM the smallest it
can go (this might not be an obvious number).

>If you're using something like ingres and have a logical volume set up for
>your log file, obviously you're going to need to rerun the ingres program
>that makes it usable by ingres.

It's going to have to be very flexable....Sounds error prone.

>Another concept which might be useful is that of "contiguous allocation".
>It may be useful to require a swap area be contiguous.  With respect to
>growing a swap area, why not just make a new swap area and swapon ?

What if I want to _delete_ swap space. Shrink a partition? Can the FreeBSD
VM system move pages out of the way (didn't someone else say it couldn't?),
and if not, how hard is that to add?

Can the FreeBSD VM system add random partitions to be swap space, like NetBSD's
system can't?
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \   kpneal@pobox.com
XCOMM  "Corrected!" -- Old Amiga tips file  \  kpneal@eos.ncsu.edu
XCOMM Visit the House of Retrocomputing:    /      Perm. Email:
XCOMM     http://www.pobox.com/~kpn/       /   kevinneal@bix.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1.5.4.32.19961006155941.00691300>