Re: Ideas for btrfs-convert fix(or rework)

[Duncan <1i5t5.duncan@cox.net>]

Austin S Hemmelgarn posted on Thu, 12 Nov 2015 09:38:03 -0500 as
excerpted:

> I'm not arguing that [btrfs-convert] should just go away, I'm trying to
> argue that it shouldn't be a development priority if it works correctly.

Agreed.

If you go back to my reply that started this subthread, the statement I 
took issue with was that btrfs couldn't be accepted as stable unless 
btrfs-convert was stable.

I simply argued that wasn't the case, since a convert tool is entirely 
optional, and many fully stable filesystems do entirely without one.  
Btrfs as a filesystem doesn't /have/ to have this tool, it's optional, so 
btrfs as a filesystem should be able to stabilize just fine, just as have 
all the filesystems without a convert tool, no matter the condition of 
this tool.

Of course having a convert tool and having it working is indeed nice to 
have, and I said that, but the condition of a convert tool, or even 
having one at all, really shouldn't hold up stabilization of the 
filesystem as a whole, just as it hasn't held up stabilization of all the 
other filesystems that don't have such a tool.

/Because/ btrfs-convert is a very nice to have tool, yes, time spent 
working on it is worthwhile time.  But nobody, least of all me, was 
arguing otherwise.  I was just saying that the overall stability of btrfs 
as a filesystem shouldn't be affected by the stability of this tool, as 
it's optional, and many other accepted as stable filesystems don't have 
such tools, so just because btrfs does, if the tool doesn't happen to be 
stable, should have nothing to do with whether the filesystem itself is 
stable or not.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman