On Fri, Feb 21, 2014 at 4:36 AM, Christian Schaller <cschalle(a)redhat.com> wrote:
I think most times when this feature has been discussed it has been
in the context of btrfs.
I think the current text in the technical specification doesn't got deeper on the
subject partly
because we are all a little on the fence for at what time we feel confident enough about
btrfs to
dare propose it as the default filesystem for the desktop. I spoke with the btrfs
developer at Red Hat
during a conference on the US West Coast towards the end of last year, and he thought
that btrfs was
ready for the desktop usecase, although he was not ready to recommend it for server use
due to the
(small) risk of data corruption. The argument being that if lets say you need to rollback
to a half
a day older snapshot due to data corruption once a year on a desktop that is probably
fine due to
desktops local data usually being slow moving, while on a database server is not really
an option.
That said, I think this item has stalled a bit due to a feeling of uncertainty if that
once a year
occurrence is really fine. (On the other hand it is not that the current options are 100%
risk free either).
I discussed btrfs with some of our FS experts at DevConf a couple
weeks ago, and then further via email after. I'm not convinced it's
ready to be the default FS for any product in Fedora yet. I'm hoping
that I can get some/one of these experts to attend Flock this year and
give a talk on btrfs. Where it's at, what it needs to be the default
fs, etc. We may wind up with a feature-reduced btrfs option in the
not too distant future being viable (e.g. no multi-device spanning, no
RAID).
I realize btrfs is something people are really excited about and
really want, but I'm not willing to let hype or "mostly" working
features swing our decision. People have been living without
fs-rollback for years, and I think they can wait a bit longer. The
last thing we need is to get bad hype because people start losing
their data if we force the issue.
josh