Technical Spec, better upgrade/rollback control

[Josh Boyer]

On Fri, Feb 21, 2014 at 4:36 AM, Christian Schaller <cschalle at 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