On 09/04/2013 08:05 AM, Jeff Mahoney wrote:
On 9/3/13 8:25 PM, Lew Wolfgang wrote:
On 9/3/13 7:57 PM, Lew Wolfgang wrote:
On 09/03/2013 02:02 PM, Jeff Mahoney wrote:
On 09/03/2013 03:04 PM, Jeff Mahoney pecked at the keyboard and wrote: > On 9/3/13 2:54 PM, Ken Schneider - openSUSE wrote: >> On 09/03/2013 10:32 AM, Jeff Mahoney pecked at the keyboard and >> wrote: >>> Hi all - >>> >>> Last month I posted queries to this list (and several other >>> locations, >>> including the forums) asking about people's experiences with >>> btrfs. For >>> the most part it seemed like the experience had improved over time. >>> Most >>> of the concerns were either with interactions with zypper or old >>> perceptions of instability that were based more on old impressions >>> than >>> new testing. With the exception of an ENOSPC issue that had been >>> recently fixed, users actively using the file system seemed pretty >>> satisfied with it. >>> >>> I posted a followup question a week or two later asking what people >>> thought about limiting the 'supported' feature set in the way we >>> do in >>> SLES so that it's clear to all users which parts of the file >>> system are >>> considered stable. >>> >>> A quick table of what that looks like: >>> >>> Supported Unsupported >>> --------- ----------- >>> Snapshots Inode cache >>> Copy-on-Write Auto Defrag >>> Subvolumes RAID >>> Metadata Integrity Compression >>> Data Integrity Send / Receive >>> Online metadata scrubbing Hot add/remove >>> Manual defrag Seeding devices >>> Manual deduplication (soon) Multiple devices >>> "Big" Metadata (supported >>> read-only) >>> >>> Over time this table will change. Items from the Unsupported list >>> will >>> move to the Supported list as they mature. >>> >>> That proposal was pretty well received except, predictably, by >>> those >>> using the features listed. In practice, all that's required for >>> those >>> users to continue uninterrupted is to add the 'allow_unsupported=1' >>> option to the btrfs module either on the kernel command line or >>> /etc/modprobe.d. There is nothing inherently limiting to any >>> openSUSE >>> user with this practice. The features are all still in the code and >>> available immediately just by setting a flag. It can even be done >>> safely >>> after module load or even after file systems that don't use the >>> unsupported features have been mounted. I intend to introduce this >>> functionality into openSUSE soon. >>> >>> One other aspect to consider: Even though they are independent >>> projects, >>> we've been focusing heavily on btrfs support in the SLES product. >>> As a >>> result, the openSUSE kernel will end up getting much of that work >>> 'for >>> free' since most of the same people maintain the kernel for both >>> projects. >>> >>> So that's the "why it's safe" part of the proposal. I haven't >>> gotten to >>> the "why" yet, but then you probably already know the "whys". >>> Subvolumes. Built-in snapshots that don't corrupt themselves >>> when an >>> exception table runs out of space. Built-in integrity verification >>> via >>> checksums. Built-in proactive metadata semantic checking via >>> scrubbing. >>> Online defrag. Soon we'll see online deduplication of arbitrary >>> combinations of files. The code is written, it just needs to be >>> pulled >>> in. You've seen the rest of the feature set. Once we test more >>> of it >>> under load and ensure that it's mature enough to roll out, >>> you'll get >>> those features for free. >>> >>> So, I'd like to propose that we use btrfs as the default file >>> system >>> for >>> the 13.1 release before we release the first beta. >>> >>> Thanks for your time. >>> >>> -Jeff >>> >>> >> Not as long as any items are in the unsupported colume and as >> long as > The unsupported features might as well be "unimplemented" for the > purposes of this discussion. > >> there is no tool to repair a broken filesystem. > There is a btrfsck tool. OK, I was not aware of this. I just hate to see an "experimental" filesystem made the default. I also don't want to see the debacle that we saw with making KDE4 the default when it was clearly alpha at best. That's why we make the effort of marking some features as immature. The core file system is stable. It's the additional features that need some testing time. They may work fine. We just haven't invested the time to determine which other features are ready and don't want to represent
On 9/3/13 4:56 PM, Ken Schneider - openSUSE wrote: them as such.
Well, btrfs didn't work for me when trying to configure a single partition of about 18-TB on 12.3. The filesystem could be created, but would crash half way through a "fill-em-up" timing test. I'll try the test again with factory if I can within the next few days. Do you have a bugzilla ID for this?
On 09/03/2013 04:59 PM, Jeff Mahoney wrote: 828229. I filed it on July 12 2013, but haven't heard a thing since then. Ok, that's a spurious ENOSPC. That's an area where there have been many fixes in the past year. I don't suppose you still have this array available to retest with 3.11?
No, the original system is in production. But five more just came in that I can play with. I hope to get some time with them within a week or so. Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org