Feature #11969

Solaris zfs/zpool version detection

Added by Nan Liu 4 months ago. Updated 5 days ago.

Status:Closed Start date:01/16/2012
Priority:Normal Due date:
Assignee:Nan Liu % Done:

0%
Category:library
Target version:2.0.0
Keywords:solaris, zfs, zpool Affected Facter version:1.6.4
Branch:https://github.com/puppetlabs/facter/pull/146
Votes: 0

Description

For the Solaris ZFS provider since there are several changes in different version. It would be beneficial to detect ZFS version.

zpool upgrade -v
This system is currently running ZFS pool version 33.
The following versions are supported:
VER  DESCRIPTION
---  --------------------------------------------------------
1   Initial ZFS version
2   Ditto blocks (replicated metadata)
3   Hot spares and double parity RAID-Z
4   zpool history
5   Compression using the gzip algorithm
6   bootfs pool property
7   Separate intent log devices
8   Delegated administration
9   refquota and refreservation properties
10  Cache devices
11  Improved scrub performance
12  Snapshot properties
13  snapused property
14  passthrough-x aclinherit
15  user/group space accounting
16  stmf property support
17  Triple-parity RAID-Z
18  Snapshot user holds
19  Log device removal
20  Compression using zle (zero-length encoding)
21  Deduplication
22  Received properties
23  Slim ZIL
24  System attributes
25  Improved scrub stats
26  Improved snapshot deletion performance
27  Improved snapshot creation performance
28  Multiple vdev replacements
29  RAID-Z/mirror hybrid allocator
30  Encryption
31  Improved 'zfs list' performance
32  One MB blocksize
33  Improved share support
For more information on a particular version, including supported releases,
see the ZFS Administration Guide.

History

#1
Updated by Nan Liu 4 months ago

  • Subject changed from Solaris ZFS version detection to Solaris zfs/zpool version detection
  • Keywords changed from solaris, zfs to solaris, zfs, zpool

#2
Updated by Daniel Pittman 4 months ago

  • Status changed from Unreviewed to Needs Decision

In the Illumos community, which is more or less the upstream point for this code in the open source community, they are working on a “feature flag” system to compliment the version numbering. In light of that change in one of the two major forks of ZFS, does this still make sense?

What form should the data take to represent this?

#3
Updated by Daniel Pittman 4 months ago

  • Status changed from Needs Decision to Needs More Information
  • Assignee set to Nan Liu

#4
Updated by Dominic Cleal 4 months ago

  • Status changed from Needs More Information to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/facter/pull/146
  • Affected Facter version set to 1.6.4

I think the version number by itself is useful for Oracle Solaris servers, despite what Illumos are doing with flags – you’ve just got to be aware that it’s specific to your OS and not completely generic.

Since the pull request exists, I’m changing the status. Also added comments to the pull request.

#5
Updated by Ken Barber 3 months ago

  • Status changed from In Topic Branch Pending Review to Tests Insufficient
  • Target version set to 186

I’ve made some comments a few weeks ago in pull request on the tests and use of fixtures and failure testing.

#6
Updated by Ken Barber 3 months ago

Just 1 more change Nan – use my_fixture_read instead of your own wrapper. This will require you to move all your fixtures around though to suit its locations, but the content shouldn’t need changing. Sorry – I should have mentioned this much much earlier.

#7
Updated by Ken Barber 3 months ago

  • Status changed from Tests Insufficient to Merged - Pending Release
  • Target version changed from 186 to 2.0.0

#8
Updated by Matthaus Litteken 5 days ago

  • Status changed from Merged - Pending Release to Closed

Released in facter 2.0.0rc1

Also available in: Atom PDF