Does pool creation allow selection pool features?

[Arwen]

Something occured to me. I know, that's bad, (thinking .

It's been too long since I created my FreeNAS pool, I don't remember if we can select the pool features at pool creation time. I don't really have a decent method to check or test. The documentation does not seem to show any options for pool feature (de-)selection.

Can we (de-)select pool feature(s) at pool creation time?
With either the old GUI or new?

If not, I'd suggest an expert mode on pool creation to allow this. I'll create the bug / feature report if needed.

Or is there a reason we don't have that option?

 

[m0nkey_]

Pools are created with the feature flags available at the time of creation. For example, FreeNAS 11.2 has the device_removal feature, where as 11.1 would not have this. Providing you don't actually use that feature, then the pool would mount without issue on 11.1. There is no way within FreeNAS or FreeBSD to be selective about the features to enabled.

To see a comprehensive list of ZFS features available for the OS you're currently running, you can run man zpool-features for a list and descriptions.

 

[Chris Moore]

No features are selectable in the old GUI.

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[Arwen]

Okay, I added a bug;

Bug #54222 - GUI - Expert mode to (de-)select pool features

Let's see what the developers think.

 

[Arwen]

...
There is no way within FreeNAS or FreeBSD to be selective about the features to enabled.
...

Not sure if you meant the GUIs, but this has been there for years;

Code:

man zpool
...
zpool create
...
-d	  Do not enable any features on the new pool.  Individual features can be enabled
		by setting their corresponding properties to enabled with the -o option.  See
		zpool-features(5) for details about feature properties.

This is sometimes necessary when a new feature in added that Grub may not like. I now routinely create my backup boot media pools with limited features known to work with the version of Grub I currently use. (All my Linux computers have SD card slots, slow, but quite usable for recovery.)

 

[m0nkey_]

Not sure if you meant the GUIs, but this has been there for years;

You're correct. My brain included FreeBSD in that sentence when it shouldn't have done.

 

[Arwen]

There has been a lot of discussion recently on the OpenZFS mailing list & ZFSonLinux Github about changing the default pool creation for feature flags to a more limited set. At present, it's still just discussion. Many of the people agree that using a set, (by default, or option based), that is more common between FreeBSD, ZFSonLinux, Illumos, and MacOS is a good idea. Or having an option to allow creating a compatible pool.

One commenter even said the using -d was not a good choice, as that removes less used features like Async Destroy, that can be devestating if not understood. (I worked at Sun Microsystems during the time when customer's called in complaining their storage pools were hung after a ZFS destroy. So they rebooted, AND were still screwed.)

 

[Arwen]

Here is a link to the mailing list discussion;

OpenZFS feature flag at zpool create proposal

A comment from yesterday, (Dec. 7), even mentions putting this on the FreeNAS GUI for pool creation. Exactly what I was suggesting .

The gist of it is this;

• zpool create -o features=portable
• zpool upgrade -o features=portable
• zpool set feature@portable=enabled

 

[Chris Moore]

A comment from yesterday, (Dec. 7), even mentions putting this on the FreeNAS GUI for pool creation. Exactly what I was suggesting :).

I would say that portable should be the default. If there is some specific feature you want to enable, such as device removal, and that would make the pool non-portable, you should have to find this out before you enable the feature. A way to force users to learn the consequences before taking the action.

 

[Arwen]

I would say that portable should be the default. If there is some specific feature you want to enable, such as device removal, and that would make the pool non-portable, you should have to find this out before you enable the feature. A way to force users to learn the consequences before taking the action.

Agreed.

On the other hand, the developers declined my suggestion.

 

[Chris Moore]

On the other hand, the developers declined my suggestion.

That is sad news.