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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
