Re: Shrinking an XFS filesystem is a crucial feature!

[Stephen Lord <lord@xxxxxxx>]

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