Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jeff Putney <jeffrey.putney <at> gmail.com>
Subject: Re: Honest timeline for btrfsck
Newsgroups: gmane.comp.file-systems.btrfs
Date: Friday 7th October 2011 15:58:55 UTC (over 5 years ago)
The rescue tool may have a lot of the logic I personally am most
interested in reading.  Thank you for that!

> The problem is people won't just read it, they will use it.

I've read every last line of the current btrfsck, even though it
doesn't do anything.  I am interested in the source specifically to
read it.

> I wrote a
> basic repair tool for a user in Fedora who seemed to have a very
> specific kind of corruption, and earlier this week almost a month after
> my initial repair tool I had to write another tool to go in and just
> pull all his data off his disk because a bug in my repair tool made his
> fs _WORSE_, to the point I'm not sure I can fix it.

These are specifically the types of one off solutions that are having
to be done because the source hasn't been released for the community
to finish up.

> Fsck has the
> potential to make any users problems worse, and given the increasing
> number of people putting production systems on btrfs with no backups the
> idea of releasing a unpolished and not fully tested fsck into the world
> is terrifying, and would likely cause long term "I heard that file
> system's fsck tool eats babies" sort of reputation.

I fail to see the distinction between releasing an unpolished fsck vs
releasing an unpolished fs driver.  They are collaborating parts of
the same system.  Whether they say btrfsck eats babies or btrfs eats
babies, they are still saying that the babies are getting eaten.

> Release early and release often is nice for web browsers and desktop
> environments, it's not so nice with things that could result in data
> loss, especially when our user base is growing in leaps and bounds and
> aren't necessarily informed enough on the dangers of using an file
> system that's still under heavy development.

What you are saying is that the specter of increased data loss somehow
outweighs the combined benefit that the community has to offer.
Unless the current state of the project IS due solely to the work of
Chris and Josef, and you don't feel that the community at large has
provided meaningful contributions, than I think that's a pretty
skeptical and unappreciative attitude towards all of the people who
HAVE contributed to this project.

The 'specialness' of an fsck tool is highly suspect.  Current
development versions of all the other fsck tools are available in
their respective repositories, and yet headlines of their eating
babies are still pretty scarce.
I'm glad that Linus didn't use your logic when it came to releasing
the linux kernel.  Do you think the entire linux kernel is more like a
web browser, or a desktop environment?

This smells more like post hoc justification of being territorial over
a pet project than it does actual reasons for keeping the source a
state secret of oracle.  Unless their is no intention of releasing the
source, and Oracle intends to keep it a closed source product for
their own linux distributions alone.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 4ms