ZFS feature flag doesn't exist after upgrading to FreeBSD 9.2-RC3

Hi,

I have upgraded my server from FreeBSD-9.0 to 9.2-RC3, however the feature flag and lz4 compression are not available.

I have tried to upgrade the ZFS pool but it prompts the following message:
Code:
This system is currently running ZFS pool version 28.

Pool 'vol' is already formatted using the current version.

Anyway to change my ZFS pool to 5000 instead of V28?
 
Can you post the output of uname -a and dmesg | grep ZFS? I would expect to see this for the latter.
Code:
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
 
Output as below, but I can find the featureflag.

Code:
# uname -a
FreeBSD storage20 9.2-RC3 FreeBSD 9.2-RC3 #0 r254795: Sat Aug 24 20:25:04 UTC 2013     root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

# dmesg | grep ZFS
ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present;
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)

# zpool get all vol
NAME  PROPERTY       VALUE       SOURCE
vol   size           3.59T       -
vol   capacity       83%         -
vol   altroot        -           default
vol   health         ONLINE      -
vol   guid           7660215245468049485  local
vol   version        28          local
vol   bootfs         -           default
vol   delegation     on          default
vol   autoreplace    off         default
vol   cachefile      -           default
vol   failmode       wait        default
vol   listsnapshots  on          local
vol   autoexpand     off         default
vol   dedupditto     0           default
vol   dedupratio     1.00x       -
vol   free           625G        -
vol   allocated      2.98T       -
vol   readonly       off         -
 
Interesting. Maybe userland is not in sync with the new kernel version and the old zfs/zpool binaries are giving you problems. If this is through freebsd-update you would have had to do:
Code:
freebsd-update upgrade -r 9.2-RC3
freebsd-update install  #first time would be the kernel
shutdown -r now
freebsd-update install  #second time would be userland
shutdown -r now
freebsd-update install  #third time to clean up
 
junovitch said:
Interesting. Maybe userland is not in sync with the new kernel version and the old zfs/zpool binaries are giving you problems. If this is through freebsd-update you would have had to do:
Code:
freebsd-update upgrade -r 9.2-RC3
freebsd-update install  #first time would be the kernel
shutdown -r now
freebsd-update install  #second time would be userland
shutdown -r now
freebsd-update install  #third time to clean up

I guess it doesn't work at all, the server kept prompting me no update is available.

Code:
# freebsd-update upgrade -r 9.2-RC3
freebsd-update: Cannot upgrade from 9.2-RC3 to itself

# freebsd-update install
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.

# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 9.2-RC3 from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 9.2-RC3-p0.

WARNING: FreeBSD 9.2-RC3 is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 0 days.

# freebsd-update install
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.

# zfs set compression=lz4 vol
cannot set property for 'vol': 'compression' must be one of 'on | off | lzjb | gzip | gzip-[1-9] | zle'

# zpool upgrade vol
This system is currently running ZFS pool version 28.

Pool 'vol' is already formatted using the current version.

# zfs upgrade vol
0 filesystems upgraded
1 filesystems already at this version

# zfs set compression=lz4 vol
cannot set property for 'vol': 'compression' must be one of 'on | off | lzjb | gzip | gzip-[1-9] | zle'
 
Do you have a man zpool-features? Something still doesn't seem quite right. Does your system match up to the second example below?

Code:
9.1-RELEASE-amd64# sha256 `which zpool`
SHA256 (/sbin/zpool) = d86043e70e475d411ec36a4813c63e478385e7f57cdfcc2fe17c1c9cc789907f
9.1-RELEASE-amd64#  strings `which zpool` | grep "feature flags"

Code:
9.2-RC3-amd64#  sha256 `which zpool`
SHA256 (/sbin/zpool) = 40b498fde255fb126721b84e4b5045fd04279f16e424ec03f52e7a9e031f91e3
9.2-RC3-amd64#  strings `which zpool` | grep "feature flags"
This system supports ZFS pool feature flags.
All pools are already formatted using feature flags.
Every feature flags pool already has all supported features enabled.
All pools are formatted using feature flags.
Every feature flags pool has all supported features enabled.
be upgraded to use feature flags.  After being upgraded, these pools
Successfully upgraded '%s' from version %llu to feature flags.
 
junovitch said:
Do you have a man zpool-features? Something still doesn't seem quite right. Does your system match up to the second example below?

Code:
9.1-RELEASE-amd64# sha256 `which zpool`
SHA256 (/sbin/zpool) = d86043e70e475d411ec36a4813c63e478385e7f57cdfcc2fe17c1c9cc789907f
9.1-RELEASE-amd64#  strings `which zpool` | grep "feature flags"

Code:
9.2-RC3-amd64#  sha256 `which zpool`
SHA256 (/sbin/zpool) = 40b498fde255fb126721b84e4b5045fd04279f16e424ec03f52e7a9e031f91e3
9.2-RC3-amd64#  strings `which zpool` | grep "feature flags"
This system supports ZFS pool feature flags.
All pools are already formatted using feature flags.
Every feature flags pool already has all supported features enabled.
All pools are formatted using feature flags.
Every feature flags pool has all supported features enabled.
be upgraded to use feature flags.  After being upgraded, these pools
Successfully upgraded '%s' from version %llu to feature flags.

Nope, it seems like there might be something wrong after I upgraded.
Code:
# uname -a
FreeBSD 9.2-RC3 FreeBSD 9.2-RC3 #0 r254795: Sat Aug 24 20:25:04 UTC 2013     root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
# sha256 `which zpool`
SHA256 (/sbin/zpool) = e0d8f4494fc94c30e0f9767ed585c72bd3e808e35a5833dfeb44f1ec95a0ea0e
# strings `which zpool` | grep "feature flags"
#
# man zpool-features
No manual entry for zpool-features
 
Excellent. At least we know what is going on now. Just curious, what's the result of # freebsd-update IDS? Below is mine as an example. You should only see stuff from /etc in there. If you are seeing lots of stuff (or everything) from the various bin directories then that wouldn't be good.

I would think the fastest fix would just to compile from source and upgrade per the handbook. That's what I would do. Alternatively you can try # freebsd-update rollback and try to upgrade again following a successful rollback. I would suggest asking in a new thread in the installation and upgrading forum if you need help for that.

Example:
Code:
# freebsd-update IDS
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 9.1-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Inspecting system... done.
/etc/crontab has SHA256 hash 711f2382c19ef913e3fa0e1d1c17d738ad71c261644cb5a1a4f8b2eea7005d3c, but should have SHA256 hash a42b097f56add787350b8c115bafecfd093d9a2614f2c102e0ae16522061eaf0.
/etc/group has SHA256 hash 9512b6ad3d012ae986cc94fe263f2a73db053596ffadd6c2f42f5ea9d92241e4, but should have SHA256 hash d788718c25a04a14cc1818ac2afa8b76a3fd899583691972d0d5127947e3504f.
/etc/mail/mailer.conf has SHA256 hash af7196e4c9e1d8d391a57ff5e6ada087138b1ecdf52f7e2f28d87689e244f915, but should have SHA256 hash f8fa900d1594f97a3936969870839f751a989a0ca54c0274202ec77434ee3e36.
/etc/master.passwd has SHA256 hash 8941e911cbfb759169665ea4c695bb8b99cf36995c6f53c081c41c9fe41dcaca, but should have SHA256 hash 6f1da238cc0a55ed360a215039bc6cb5ce5369d20b8fbceb8a1941c5124e6a4e.
/etc/motd has SHA256 hash c879df0f774019d74776abb13870109df706e54b4a7f3ab0d921dde69329febd, but should have SHA256 hash 98f082efc89da5e887e72bc4dcfa3e5fc8bada9d19db4bdbba9a32692a7c82a7.
/etc/newsyslog.conf has SHA256 hash 19a205d777ed295984a295ca001f39853c04e78425f509a1a3e9da2d59833592, but should have SHA256 hash 70b41ababd234533c9b58e6ff155062b793896bc667cd17254f7c172a23df1cd.
/etc/passwd has SHA256 hash 3ea9fb84699d138cd1215193d2e63df96f78d0d0c2ed0b4fa16961309263b77e, but should have SHA256 hash 3135de169a0ff94c0c97aeb525a07ea10e5ed81c9b825e219f7eea8deb97c444.
/etc/periodic/daily/450.status-security has SHA256 hash 104c5e0051c392bf017256501199dbf6596793f40c52cd6c6df0ef15a0d1f5bc, but should have SHA256 hash 8dc2e2d3d8b4630d348a1f9a18196174558cc7a44851d4cec2250c02958e09e5.
/etc/pwd.db has SHA256 hash 9e4f67137a5f06550302dd6f2de09f6e7639c0fa028803ebe4643004cbd2a7ba, but should have SHA256 hash bf86739ee052821992412b61a6673811588c382fa63ab38cc47c1a59305376eb.
/etc/shells has SHA256 hash 4c25fb7c79fe5057217a70cfa1c27f41959bb7daa703a94774ec5ac9d29a9266, but should have SHA256 hash beab7e474ee12b051b98889f368bbd490340a908f6f2287f9238e818b830a1fd.
/etc/spwd.db has SHA256 hash 9f9ec0292d8b30aa93cfa19990e154ab256e0646b360102f50202cfdcb8efbd1, but should have SHA256 hash 1cbfbea78d316e4e8d29f53f0770b8ff1f3a731e993c3ae717f36304715d7a5b.
/etc/ssh/sshd_config has SHA256 hash 3753675a89eb8a45d7afc9f8ba71df481af76beef613f5afbe84d34ad16f9798, but should have SHA256 hash ae8d4fe53f2c727f74b0b0762f5446981dc5241aeb206a5113a977ffb4bc275f.
/etc/sysctl.conf has SHA256 hash 8f9f49076d0fb59be5f6e3bf65a23f31691718d5b482688abaf6828fe07c16d2, but should have SHA256 hash a58368e7488c7d97618cd24c2e1e534448d2cf51594b196cf3ae5a9222ba435f.
/etc/syslog.conf has SHA256 hash 95f70d0ee49faf7cf7973000f68f7c500a577a0597116ea519a4ddbf31b392ee, but should have SHA256 hash 4b8947aadb1599d1e767d6f2163bdafc3333c275ee9e1ef9ec7974889bb21365.
 
Back
Top