[opensuse-factory] Re: [opensuse-kernel] BtrFS as default fs?
El 03/09/13 11:53, Jeff Mahoney escribió:
As I said then, the point isn't to take away functionality from anyone. If we have the ability to enable it in YaST (with a warning) or do it automatically (with a warning) if the features are already enabled on an older file system, nobody's lost anything. The point is that it will prevent users from losing their file systems using a feature set that hasn't been well tested.
It's great that you want to try features out that we don't consider safe yet. That's how we get bug reports that we can use to improve and further gauge the quality of a particular feature set. I just don't think that /all/ openSUSE users want to have that particular experience without knowing what's up beforehand.
Jeff, I do not object to the idea of warning people that certain features are unstable or dangerous a log message: "btrfs warning: FOOBAR is unstable".. will suffice in achiving this result. what I do strongly object is this pervasive tendency to add SUSE specific flags that are not documented anywhere else other than probably a wiki page or the openSUSE documentation, has distribution specific semantics,is not in upstream plus will cause confusion and increase the load of volunteers that answer questions in mailing list and the forums. This makes sense for SLE where you only want to support things known to be production quality and therefore reducing the number of support incidents. in the openSUSE land will only cause confusion (pretty much like the "unsupported module flag") -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/3/13 12:24 PM, Cristian Rodríguez wrote:
El 03/09/13 11:53, Jeff Mahoney escribió:
As I said then, the point isn't to take away functionality from anyone. If we have the ability to enable it in YaST (with a warning) or do it automatically (with a warning) if the features are already enabled on an older file system, nobody's lost anything. The point is that it will prevent users from losing their file systems using a feature set that hasn't been well tested.
It's great that you want to try features out that we don't consider safe yet. That's how we get bug reports that we can use to improve and further gauge the quality of a particular feature set. I just don't think that /all/ openSUSE users want to have that particular experience without knowing what's up beforehand.
Jeff, I do not object to the idea of warning people that certain features are unstable or dangerous a log message: "btrfs warning: FOOBAR is unstable".. will suffice in achiving this result. what I do strongly object is this pervasive tendency to add SUSE specific flags that are not documented anywhere else other than probably a wiki page or the openSUSE documentation, has distribution specific semantics,is not in upstream plus will cause confusion and increase the load of volunteers that answer questions in mailing list and the forums.
Your approach is favoring the experienced user over the inexperienced user, which can be reasonable especially if that's where we want to focus as a project. But it's dangerous when you also suggest a completely unintuitive method of informing the user. Nobody checks the log after successfully mounting a file system to see if there were any warnings. Documenting that in the release notes as a "best practice" isn't going to fly either. People do check the log when something unexpected happens and that's why we issue a message like the following when we reject a mount with immature features: "btrfs: compression is not supported, load module with allow_unsupported=1" (We can change the wording of that for openSUSE so that it reads "compression is considered an immature feature, load module with allow_unsupported=1".) I'm not sure many users will be comforted by being asked if they see a warning in their log after they've used an immature feature and discovered the hard way why it's considered immature. That's why I think an automated approach during upgrade and a yast checkbox to allow unsupported features is the way to go. Experienced users still get the full feature set to play with. Users with existing file systems with immature features enabled get to continue using them[1]. Inexperienced users get a reasonable picture of what is considered mature and what isn't and enjoy better data safety as a result. I'd prefer a better name than "allow_unsupported" but since this feature comes from SLES, it's better to use the existing name than to introduce another incompatibility.
This makes sense for SLE where you only want to support things known to be production quality and therefore reducing the number of support incidents. in the openSUSE land will only cause confusion (pretty much like the "unsupported module flag")
The unsupported module flag was removed from openSUSE for exactly that reason. This case is different, though. This isn't about managing support cases. Well, I suppose it is, but that's a nice side-effect of ensuring that users expecting that their file system uses only mature features have their expectations met. The naming of the module option is independent of the meaning of the option. That's largely a messaging thing and in the UI, it should be presented as "unstable" or "immature" feature enablement rather than trying to make a distinction over supportability. -Jeff [1] With the exception of file systems not in /etc/fstab. -- Jeff Mahoney SUSE Labs
On Tue 03 Sep 2013 01:26:38 PM EDT, Jeff Mahoney wrote:
On 9/3/13 12:24 PM, Cristian Rodríguez wrote:
El 03/09/13 11:53, Jeff Mahoney escribió:
As I said then, the point isn't to take away functionality from anyone. If we have the ability to enable it in YaST (with a warning) or do it automatically (with a warning) if the features are already enabled on an older file system, nobody's lost anything. The point is that it will prevent users from losing their file systems using a feature set that hasn't been well tested.
It's great that you want to try features out that we don't consider safe yet. That's how we get bug reports that we can use to improve and further gauge the quality of a particular feature set. I just don't think that /all/ openSUSE users want to have that particular experience without knowing what's up beforehand.
Jeff, I do not object to the idea of warning people that certain features are unstable or dangerous a log message: "btrfs warning: FOOBAR is unstable".. will suffice in achiving this result. what I do strongly object is this pervasive tendency to add SUSE specific flags that are not documented anywhere else other than probably a wiki page or the openSUSE documentation, has distribution specific semantics,is not in upstream plus will cause confusion and increase the load of volunteers that answer questions in mailing list and the forums.
Your approach is favoring the experienced user over the inexperienced user, which can be reasonable especially if that's where we want to focus as a project. But it's dangerous when you also suggest a completely unintuitive method of informing the user. Nobody checks the log after successfully mounting a file system to see if there were any warnings. Documenting that in the release notes as a "best practice" isn't going to fly either. People do check the log when something unexpected happens and that's why we issue a message like the following when we reject a mount with immature features:
"btrfs: compression is not supported, load module with allow_unsupported=1"
(We can change the wording of that for openSUSE so that it reads "compression is considered an immature feature, load module with allow_unsupported=1".)
I'm not sure many users will be comforted by being asked if they see a warning in their log after they've used an immature feature and discovered the hard way why it's considered immature.
That's why I think an automated approach during upgrade and a yast checkbox to allow unsupported features is the way to go. Experienced users still get the full feature set to play with. Users with existing file systems with immature features enabled get to continue using them[1]. Inexperienced users get a reasonable picture of what is considered mature and what isn't and enjoy better data safety as a result.
I'd prefer a better name than "allow_unsupported" but since this feature comes from SLES, it's better to use the existing name than to introduce another incompatibility.
This makes sense for SLE where you only want to support things known to be production quality and therefore reducing the number of support incidents. in the openSUSE land will only cause confusion (pretty much like the "unsupported module flag")
The unsupported module flag was removed from openSUSE for exactly that reason.
This case is different, though. This isn't about managing support cases. Well, I suppose it is, but that's a nice side-effect of ensuring that users expecting that their file system uses only mature features have their expectations met. The naming of the module option is independent of the meaning of the option. That's largely a messaging thing and in the UI, it should be presented as "unstable" or "immature" feature enablement rather than trying to make a distinction over supportability.
-Jeff
[1] With the exception of file systems not in /etc/fstab.
How does it handle a computer that looses power versus EXT4? -- Cheers! Roman ------------------------------------------------------- openSUSE -- Get it! Discover it! Share it! ------------------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/3/13 2:16 PM, Roman Bysh wrote:
On Tue 03 Sep 2013 01:26:38 PM EDT, Jeff Mahoney wrote:
On 9/3/13 12:24 PM, Cristian Rodríguez wrote:
El 03/09/13 11:53, Jeff Mahoney escribió:
As I said then, the point isn't to take away functionality from anyone. If we have the ability to enable it in YaST (with a warning) or do it automatically (with a warning) if the features are already enabled on an older file system, nobody's lost anything. The point is that it will prevent users from losing their file systems using a feature set that hasn't been well tested.
It's great that you want to try features out that we don't consider safe yet. That's how we get bug reports that we can use to improve and further gauge the quality of a particular feature set. I just don't think that /all/ openSUSE users want to have that particular experience without knowing what's up beforehand.
Jeff, I do not object to the idea of warning people that certain features are unstable or dangerous a log message: "btrfs warning: FOOBAR is unstable".. will suffice in achiving this result. what I do strongly object is this pervasive tendency to add SUSE specific flags that are not documented anywhere else other than probably a wiki page or the openSUSE documentation, has distribution specific semantics,is not in upstream plus will cause confusion and increase the load of volunteers that answer questions in mailing list and the forums.
Your approach is favoring the experienced user over the inexperienced user, which can be reasonable especially if that's where we want to focus as a project. But it's dangerous when you also suggest a completely unintuitive method of informing the user. Nobody checks the log after successfully mounting a file system to see if there were any warnings. Documenting that in the release notes as a "best practice" isn't going to fly either. People do check the log when something unexpected happens and that's why we issue a message like the following when we reject a mount with immature features:
"btrfs: compression is not supported, load module with allow_unsupported=1"
(We can change the wording of that for openSUSE so that it reads "compression is considered an immature feature, load module with allow_unsupported=1".)
I'm not sure many users will be comforted by being asked if they see a warning in their log after they've used an immature feature and discovered the hard way why it's considered immature.
That's why I think an automated approach during upgrade and a yast checkbox to allow unsupported features is the way to go. Experienced users still get the full feature set to play with. Users with existing file systems with immature features enabled get to continue using them[1]. Inexperienced users get a reasonable picture of what is considered mature and what isn't and enjoy better data safety as a result.
I'd prefer a better name than "allow_unsupported" but since this feature comes from SLES, it's better to use the existing name than to introduce another incompatibility.
This makes sense for SLE where you only want to support things known to be production quality and therefore reducing the number of support incidents. in the openSUSE land will only cause confusion (pretty much like the "unsupported module flag")
The unsupported module flag was removed from openSUSE for exactly that reason.
This case is different, though. This isn't about managing support cases. Well, I suppose it is, but that's a nice side-effect of ensuring that users expecting that their file system uses only mature features have their expectations met. The naming of the module option is independent of the meaning of the option. That's largely a messaging thing and in the UI, it should be presented as "unstable" or "immature" feature enablement rather than trying to make a distinction over supportability.
-Jeff
[1] With the exception of file systems not in /etc/fstab.
How does it handle a computer that looses power versus EXT4?
It's designed to be safe in that case. The CoW behavior means that the old blocks aren't overwritten until the refcount drops to zero. The refcount can't drop to zero until the new blocks are safely on disk. -Jeff -- Jeff Mahoney SUSE Labs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-09-03 a las 13:26 -0400, Jeff Mahoney escribió:
Your approach is favoring the experienced user over the inexperienced user, which can be reasonable especially if that's where we want to focus as a project. But it's dangerous when you also suggest a completely unintuitive method of informing the user. Nobody checks the
...
That's why I think an automated approach during upgrade and a yast checkbox to allow unsupported features is the way to go. Experienced users still get the full feature set to play with. Users with existing file systems with immature features enabled get to continue using them[1]. Inexperienced users get a reasonable picture of what is considered mature and what isn't and enjoy better data safety as a result.
I agree. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlImawAACgkQja8UbcUWM1yrOgD/ftmI1bokk9Hza2M8Yz4fdy0p aE4hqioSDNOAe8tVoMgA/1n4Yq52dcIsoMQJFXMjEoI0XRxadtB2dRVxjCMrgiFQ =S0Q/ -----END PGP SIGNATURE-----
El 03/09/13 13:26, Jeff Mahoney escribió:
Your approach is favoring the experienced user over the inexperienced user, which can be reasonable especially if that's where we want to focus as a project. But it's dangerous when you also suggest a completely unintuitive method of informing the user. Nobody checks the log after successfully mounting a file system to see if there were any warnings. Documenting that in the release notes as a "best practice" isn't going to fly either.
Ok, Jeff, since I am a reasonable person I will concede that your argument is reasonable and workable. I still do not like the idea of SUSE specific parameter but there are much bigger fish to catch around to continue this argument. Just some questions: - How and who will determine what it is stable/production-ready? - How will you deal with the parameter going away ? I ask because the kernel moves at the pace of a cheetah and YAST like a old turtle. suggesting that a configuration option has to be added to YAST turns a kernel implementation detail into an userspace interface. does parameter stays forever as as no-op when everything becomes "stable" ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Carlos E. R. -
Cristian Rodríguez -
Jeff Mahoney -
Roman Bysh