xfs
[Top] [All Lists]

Re: Shrinking an XFS filesystem is a crucial feature!

To: Stephen Lord <lord@xxxxxxx>
Subject: Re: Shrinking an XFS filesystem is a crucial feature!
From: Austin Gonyou <austin@xxxxxxxxxxxxxxx>
Date: 19 Jan 2002 15:41:17 -0600
Cc: Derek Glidden <dglidden@xxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, "Karl M. Hegbloom" <karlheg@xxxxxxxxxxxxxx>
In-reply-to: <3C496C9A.8030204@xxxxxxx>
References: <3C496C9A.8030204@xxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
No offense meant Steve. I was not trying to say anything about
compensation here. Although people using it "in a product" that would
expect this kind of thing and do not contribute and expect someone else
to do it is missing the point of the OSI. 

That said, I was merely trying to offer what I believe the target
audience will want. It seems that the target audience would be those
using Veritas and the like. Sorry for rubbing you the wrong way, I don't
think I meant it in the manner you though. 



On Sat, 2002-01-19 at 06:54, Stephen Lord wrote:
> Austin Gonyou wrote:
> 
> >Think of it like this. For those who use Veritas, there are quite a
> few,
> >and manage "enterprise class" systems, Veritas HAS shrink and grow,
> >despite how well people planned. 
> >
> >The need is more along the lines that if you have a highly dynamic
> >environment which you must tailor to fit a rapid growth pattern,
> >regardless if you tried to plan for it or how well, sometimes the need
> >arises to resize file systems. Regardless of which direction + or -. 
> >
> >That said, for those wishing to change from Veritas and use something
> >"free" or Open Source, or cheap, whatever, they'll be looking for the
> >same things they can get out of whatever they're trying to replace. 
> >
> >If you're looking to switch from Veritas or whatever else, then most
> >likely you'll want to be able to shrink and grow FS. Not to mention not
> >all people who use Veritas are running "enterprise class" systems. They
> >may not want to PAY for the extra disk space, or may want to shrink a
> >volume which will be recycled for a different purpose. Rather than
> >re-striping, or relaying the FS, one could merely shrink it and just
> >migrate data off of that volume, rather than looking at "down time" or
> >"service outages". 
> >
> 
> They also appear to want us to write more code for them, which they also
> do not pay for so that they do not have to pay for disk drives.
> Something
> is wrong with this model I think.
> 
> Oh, and in this case it is 'for use in a product', so add not pay for 
> something
> they want to make money off......
> 
> Sorry,  but this rubbed me up the wrong way.
> 
> Of the two thinks Karl asked for, the repair change is probably
> about a days work for someone who does not know the code. And then
> some very careful init script work to make sure the only way you ever
> use it is in single user mode followed by an immediate shutdown. Online
> repair is the equivalent of pulling the table cloth out from under the
> bone china dishes without anyone noticing. With ext2 its a tea party for
> 4, with xfs it is a banquet for 100 people. With vxfs it was designed
> in from the start.
> 
> As for shrinking a filesystem, there may be a feasable solution people
> can
> work on without major knowledge of xfs internals. This is the in place
> filesystem converter already mentioned on the list. I have not used it,
> but it sounds like it is fairly slow, and needs some packaging work.
> This
> would only work offline since you basically move the data from one
> volume to another. A technique like this is about the only way in place
> shrinking is ever going to happen with xfs - at least as far as SGI is
> concerned. To do it within xfs itself, go put a dollar figure on several
> months work by a highly paid engineer (add in a couple of months tester
> time), then add in the fact that all the engineers are already at least 
> 100%
> committed to things.
> 
> And Karl, please read the part in the debian contract in your sig about
> contributing back to the community.
> 
> Steve
> 
> 
> 
> 
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@xxxxxxxxxxxxxxx

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>