User: Password:
Subscribe / Log in / New account

Whither btrfsck?

Whither btrfsck?

Posted Oct 12, 2011 1:45 UTC (Wed) by cmccabe (guest, #60281)
Parent article: Whither btrfsck?

In a lot of ways, filesystem development turns the normal rules of software development on their head.

Normally, you want to push something out the door as early as possible so you can gain more users, more developers, and more features than the competition. This is usually phrased as "release early, release often." Releasing often is also generally thought to make you more responsive to what users want ("agile").

When you're developing a filesystem, you want the wider community to deploy your changes infrequently and only after a lot of testing. You only need to lose someone's data once to lose that user forever-- and probably a lot of his friends. It's much, much more important to have something rock solid than it is to have a lot of features. Filesystems have a fairly well-defined role to play, and user feedback is usually limited to letting you know when you've screwed up, rather than suggesting new features.

I hope btrfsck gets out the door soon! I'd like to see how distributions make use of the new btrfs subvolumes and other features.

(Log in to post comments)

Whither btrfsck?

Posted Oct 12, 2011 12:32 UTC (Wed) by iq-0 (subscriber, #36655) [Link]

No it doesn't. But apparently "putting the code out there" seems to be equivalent to "release a program" in this discussion.

Personally I think the thing is the same for filesystems as it is for any other major piece of software. Release early and release often. And don't simply say it's experimental, but tell people very hard that it will eat your data and that you should run it on a copy of the actual filesystem you want to restore. You also want to explicitly flag the release as alpha/experimental/eat-my-data and communicate that so distributions won't pick it up under the assumption that something is better than nothing.

But irrelevant of that: Putting the code out there doesn't make it a release!

Sure people will see it as one when you encouring them to try it (which would constitute an implicit release).
But when you explicitly post stuff (whether as a set of patch or a reference to some repository), add the eat-my-data warnings and explictly state what your intent is for posting it, than shame on any who get burned by it.

And if your intent is to protect people from themselves, than I'd say that purging your beta quality filesystem with a pre-alpha quality auto-repair tool would be the place to start ;-)

Whither btrfsck?

Posted Oct 12, 2011 21:02 UTC (Wed) by cmccabe (guest, #60281) [Link]

I think ideally btrfsck would have been developed alongside the filesystem and at the same level of stability, so that this dilemma wouldn't have come up. We don't live in an ideal world, though, so I understand where Chris is coming from. I guess releasing a read-only fsck might be potentially be a good intermediate step.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds