Mailinglist Archive: opensuse-factory (776 mails)

< Previous Next >
Re: [opensuse-factory] Re: BtrFS as default fs?
Hi,

I know I am a bit late, I was away....

On 09/03/2013 07:59 PM, Jeff Mahoney wrote:
On 9/3/13 7:00 PM, Jim Henderson wrote:
On Tue, 03 Sep 2013 19:55:49 -0300, Claudio Freire wrote:

Also, consider the target audience of default filesystems.

These aren't for the power users, which will consciously pick the
filesystem they like best. Default filesystems are for the granny and
the newbie, those that cannot and will not fix low-level filesystem
issues.

I haven't used BtrFS recently, but unless it's granny-proof, I'd think
twice before making it default.

+1. Changing the default to btrfs is going to increase the number of
people having problems posting in the forums. It still seems to be
considered "unstable" or "experimental", and if so, shouldn't be selected
as the default.

Well that's the main thrust behind the "allow unsupported" module
option. We have the feature set that we've evaluated to be mature and
that's what we allow by default.

When I cast a wide net across forums and mailing lists last month asking
for user experiences, I got a lot of uninformed opinion and very little
concrete data. Most of the negative data was in the area of snapper
being too aggressive in creating snapshots and not aggressive enough in
cleaning them up. There was some negative opinion WRT the file system
itself, but most of it was in the realm of "I heard..." or "I don't
trust it" based on too much hearsay and too little experience. It's that
kind of rumor-response that is unhelpful in making decisions or
improving the pain points with the file system.

I agree with you that the "rumor and armchair" comments, perceptions and responses are not useful for improving the state of btrfs. However, the "rumor and armchair" perceptions are exactly what we have to overcome. If everyone thinks it's "unstable", whether true or not, and we announce "openSUSE 13.1 has Btrfs as default" we will have a big perception problem and for better or worse "perception is reality."

In principle separating the features into "rock solid" and "immature" and enabling only the "rock solid" features when choosing btrfs as default will address usage issues, but will do little for the perception issue. Action to address usage in and of itself is most often insufficient and appropriate messaging has to go with it.

There were a few reports
of people having troubles with the file system itself, but they tended
to be with compression or RAID enabled -- the features that we don't
entirely trust yet and want to disable so the casual user doesn't become
an unwitting beta tester.

So whether it's "considered" unstable or experimental largely depends on
what features are being tested and who's doing the testing. A lot of
times it involves armchair punditry and no testing at all.

Unfortunately there is no getting away from "Monday morning quarterbacks" and we will have to overcome the perception of "unstable" and/or "not for granny". This, for better or worse also includes the tools around btrfs, such as snapper. See the comment in this thread with the 20GB VM that runs out of disk space when running "zypper up" (I had that same experience by the way and it is very annoying.) Things like the snapper problem reflect on the filesystem and thus give it a probably undeserved bad rep. Therefore, focusing on the filesystem alone in this case is probably insufficient.

In the end I think the "granny question" is valid.

If we make btrfs the default for 13.1, will granny run into any issues?

Does the drive fill up because of created snapshots?
Does she run out of space although there should be plenty of space on the drive?

It's the more "silly" stuff we have to worry about.

My $0.02
Robert


--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@xxxxxxxx
rschweik@xxxxxxxxxx
781-464-8147
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >