[opensuse-factory] Btrfs features
Hi all - In another thread, someone posted about wanting an updated btrfsprogs (it's coming, as soon as I finish writing this email). He mentioned it in terms of wanting to try out the RAID5 code. One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems. So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet. For example, the RAID5 code in particular is still fairly fragile. -Jeff -- Jeff Mahoney SUSE Labs
On 07/23/2013 09:33 AM, Jeff Mahoney wrote:
Hi all -
In another thread, someone posted about wanting an updated btrfsprogs (it's coming, as soon as I finish writing this email). He mentioned it in terms of wanting to try out the RAID5 code.
One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet. For example, the RAID5 code in particular is still fairly fragile.
Jeff, This approach seems very sensible to me. Since the option to use btrfs appeared in the installation page, it has been selected by users who have little idea of the history of btrfs, and are not well prepared to handle fragility in their file systems. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-07-23 a las 10:33 -0400, Jeff Mahoney escribió:
One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well?
Yes, please. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHvDVQACgkQja8UbcUWM1wJBwD/TaJ10y5D7hk8DuWRoVNaCNHx rveoxRbx9PelTBJUPlYA/18swFa7CVortx07TgJ9WoTUHcAVBUJqyJsII1VOxhP4 =raf5 -----END PGP SIGNATURE-----
On 23-07-2013 15:33, Jeff Mahoney wrote:
Hi all -
In another thread, someone posted about wanting an updated btrfsprogs (it's coming, as soon as I finish writing this email). He mentioned it in terms of wanting to try out the RAID5 code.
One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet. For example, the RAID5 code in particular is still fairly fragile.
-Jeff
Hi Jeff, I personally think we should have all the options available, but I do realise that this could be a major headache for all involved. If there was a way to have the bleeding edge features available for those that are more prepared to cut themselves, yet hidden from those that don't want the bloodshed then great. Failing having the happy medium, maybe the SLE team could advise on what features they think would make sense should they be stable enough and then we could test it to see how stable things really are. If things don't get tested and bugs reported it will never improve, so we almost need to implement the new features to get a better product. Regards, Andy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-07-24 a las 08:41 +0100, Andrew Wafaa escribió:
On 23-07-2013 15:33, Jeff Mahoney wrote:
our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
I personally think we should have all the options available, but I do realise that this could be a major headache for all involved. If there was a way to have the bleeding edge features available for those that are more prepared to cut themselves, yet hidden from those that don't want the bloodshed then great.
That is what he says they are doing on SLES: a mount option enables those features. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHvsFMACgkQja8UbcUWM1wTVgD/Qa1DJnwFbRwka77EculVmEqM goVlDVLOC4F1He38fPgA/jVDNTlQDgsOhhkGkk/jG6qsB9g8NZBZJO1lBKvkNl1e =HNYx -----END PGP SIGNATURE-----
On 7/24/13 6:45 AM, Carlos E. R. wrote:
El 2013-07-24 a las 08:41 +0100, Andrew Wafaa escribió:
On 23-07-2013 15:33, Jeff Mahoney wrote:
our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
I personally think we should have all the options available, but I do realise that this could be a major headache for all involved. If there was a way to have the bleeding edge features available for those that are more prepared to cut themselves, yet hidden from those that don't want the bloodshed then great.
That is what he says they are doing on SLES: a mount option enables those features.
Oops, I misspoke above. It's actually a module option. Fire and forget once you've set the system up. Probably even possible to set up within YaST if we really wanted to (in order to allow those features for the rootfs). -Jeff -- Jeff Mahoney SUSE Labs
On 7/24/13 3:41 AM, Andrew Wafaa wrote:
On 23-07-2013 15:33, Jeff Mahoney wrote:
Hi all -
In another thread, someone posted about wanting an updated btrfsprogs (it's coming, as soon as I finish writing this email). He mentioned it in terms of wanting to try out the RAID5 code.
One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet. For example, the RAID5 code in particular is still fairly fragile.
-Jeff
Hi Jeff,
I personally think we should have all the options available, but I do realise that this could be a major headache for all involved. If there was a way to have the bleeding edge features available for those that are more prepared to cut themselves, yet hidden from those that don't want the bloodshed then great.
Failing having the happy medium, maybe the SLE team could advise on what features they think would make sense should they be stable enough and then we could test it to see how stable things really are. If things don't get tested and bugs reported it will never improve, so we almost need to implement the new features to get a better product.
Yep. Absolutely. Bug reports are what drives product quality. The problem is that when we know certain features need a little more time to stabilize and that distinction isn't made clear to users who'd rather not be the ones filing the bug reports. To be clear, we're talking about disabling some of btrfs's most publicized features: compression, multivolume support, etc, so users may think that they're safe to use everywhere. I don't want to take the choice away from anyone. I just want to make it clear that some features are considered stable and others aren't. If you are an advanced user, you can drop the 'options btrfs allow_unsupported=1' (or whatever we want to name it) line into /etc/modprobe.d and you have the full set of features available to you. We *do* want those bug reports, but it's good to set parameters for what we consider a bug fix for an unstable feature and what we consider a bug fix for something that should be rock solid. -Jeff -- Jeff Mahoney SUSE Labs
On Tuesday 23 July 2013 10.33:30 Jeff Mahoney wrote:
Hi all -
In another thread, someone posted about wanting an updated btrfsprogs (it's coming, as soon as I finish writing this email). He mentioned it in terms of wanting to try out the RAID5 code.
One of the things that's made it possible for SUSE to support btrfs in our enterprise products is often overlooked in media reports and casual analysis: We limit the feature set we support. In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet. For example, the RAID5 code in particular is still fairly fragile.
-Jeff
If it make sense to disable certain feature, this could be introduced in openSUSE as well. BUT as we let users in 12.1, 12.2, 12.3 ( like me ) doing crazy tests on dedicated computers we should take care to not put them in a dead end. Like using raid1 raid10 & compression which work quite well. (at least no bug report on my side) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot
On Tuesday 2013-07-23 16:33, Jeff Mahoney wrote:
In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet.
It seems sort of pointless to attempt rejecting mounting of a multivol filesystem, because the user has already expressly given his consent to wanting to run such a multivol setup, at the time of mkfs.btrfs/btrfs device add. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/2/13 3:40 PM, Jan Engelhardt wrote:
On Tuesday 2013-07-23 16:33, Jeff Mahoney wrote:
In SLE11 SP3, we actively limit the feature set without a mount option enabling access to those features. We don't enable compression or multi-volume file systems.
So, the question is: Is this something we should consider for openSUSE as well? The goal isn't to ever deny users access to the available features or to force them to rebuild the kernel to enable them, but to shield unsuspecting users from features that may not be fully baked yet.
It seems sort of pointless to attempt rejecting mounting of a multivol filesystem, because the user has already expressly given his consent to wanting to run such a multivol setup, at the time of mkfs.btrfs/btrfs device add.
Except that the stability of multivolume file systems isn't defined by the mkfs. It's defined by the kernel implementation. We're informing users that certain features aren't deemed stable in a particular kernel release. So even if we warned users about the stability of certain features in mkfs, the warnings would follow the mkfs version instead of the kernel version, unless we had some way export that information up front. That, I think, is pointless. -Jeff -- Jeff Mahoney SUSE Labs
participants (6)
-
Andrew Wafaa -
Bruno Friedmann -
Carlos E. R. -
Jan Engelhardt -
Jeff Mahoney -
Larry Finger