Date: Fri, 9 Apr 1999 11:54:05 +0930 From: Greg Lehey <grog@lemis.com> To: remy@synx.com Cc: hackers@FreeBSD.ORG Subject: Re: Volume managers (was: Separate boot partition?) Message-ID: <19990409115405.F2142@lemis.com> In-Reply-To: <199904080955.LAA08304@rt2.synx.com>; from Remy Nonnenmacher on Thu, Apr 08, 1999 at 11:55:23AM %2B0200 References: <19990408182917.G2142@lemis.com> <199904080955.LAA08304@rt2.synx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 8 April 1999 at 11:55:23 +0200, Remy Nonnenmacher wrote: > On 8 Apr, Greg Lehey wrote: >> On Thursday, 8 April 1999 at 10:44:15 +0200, Remy Nonnenmacher wrote: >>> On 8 Apr, Greg Lehey wrote: >>>> On Thursday, 8 April 1999 at 8:52:24 +0100, Dom Mitchell wrote: >>>>> On 8 April 1999, Greg Lehey proclaimed: >>>>>> I can't see why not, since it's possible now. What we still need to >>>>>> do is find a way to extend a file system, but that's a ufs issue >>>>>> (which has a solution), not a volume manager issue. >>>>> >>>>> What about shrinking an fs? Is that feasible? Possible? >>>> >>>> According to Kirk McKusick, no. >>>> >>> too bad !! >>> >>> Really, merging the best of all worlds (AIX PV migration, fs 'live' >>> extendability) *AND* fs shrinking would be a really impressive >>> performance. >>> >>> Think about it : A set of SCA, hot-pluggable disks. Every fs movable, >>> resizable (up/down), every disk content movable from/to every other >>> one.... the perfect power-on once, run till-end-of-universe server. >> >> Well, with the exception of the file system shrinking, we have all >> that. I honestly don't think we'll find a need to shrink file systems >> too often. >> > > Sure, but 'not too often' is not 'never' and when case raises, for > exemple with these messages : (assuming you can't hot-add disks...) > > - "too bad: you are 100MB too short on this fs. 200MB are wasted here > and here. watch and cry!!" > - "Ha Ha !! 100MB needed for install, 50 MB available. Anyway, have a > look around there: 10 fs with 50MB wasted on each one!!" > > The main problem is that you need to plan a shutdown and a time-costly > work (nightly ;). > > BTW, a workaround (with spares) would be to be able to create a new, > downsized, fs and then migrate content of the old one to the new one. > Steps something like : > > - Have everybody using the old one freeze (hands up!) If you're prepared to do this, sure. An easier way would be simply to create another plex on the new disk and synchronize it. > - sync the old fs Remove the old plex(es). > - Move the content of the old fs Create a new file system in the physical disk space which the old one used to occupy. > - alias old->new Copy. > - Everybody warm. No need. > - free space owned by the old fs. > > Feasible ? The way I suggest is better, since it can happen on-line. Vinum already has everything you need for that. > (ANW, would be helpfull sometime to freeze every process using a > fs...) Ideally, you should never need to freeze processes. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990409115405.F2142>