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
> >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.
> is wrong with this model I think.
> Oh, and in this case it is 'for use in a product', so add not pay for
> 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
> 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.
> 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
> committed to things.
> And Karl, please read the part in the debian contract in your sig about
> contributing back to the community.
Systems Architect, CCNA
"It is the part of a good shepherd to shear his flock, not to skin it."
Description: This is a digitally signed message part