zpool_read_label semantics should match OpenZFS
With #12235, the
zpool_read_label() function was moved to libzutil (to match what OpenZFS had done). However, the OpenZFS change also changed the semantics of
zpool_read_label() slightly -- prior to that change,
zpool_read_label() returned on the first label found, and returned -1 if no labels were found, if no memory was available, or if it couldn't stat the device given. The OpenZFS version allows one to optionally pass a pointer that is used to return the number of labels found. More importantly, 0 labels found is not considered an error.
To facilitate porting of OpenZFS, it will be easier to update
zpool_read_label to match the OpenZFS semantics. There's only a few consumers in illumos-gate (and this is a private interface), and
/illumos-joyent/usr/src/cmd/fs.d/zfs/fstyp/fstyp.c is the only caller that needs updating.
Updated by Jason King 9 months ago
To test, I ran the zfs test suite. All the expected tests pass (including the new tests introduced with this change).
Additionally, I create a test zpool with a regular device, an slog, and an l2arc device. I ran fstyp against all three devices, which properly identified them as zfs devices. After destroying the test pool, the regular and slog devices now show unknown_fstyp while the cache device still shows zfs. However, this appears to be an existing bug as I was able to reproduce the behavior on an unmodified BE (running 'zpool labelclear' on the device clears out the label on the cache device though, so there is a workaround).
Updated by Electric Monk 9 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 0ac8993002ee179cc3289243a0fc956ee0db04da Author: Brian Behlendorf <firstname.lastname@example.org> Date: 2020-08-12T02:23:17.000Z 13013 Port OpenZFS zpool label clear improvements 13012 zpool_read_label semantics should match OpenZFS Portions contributed by: Jason King <email@example.com> Reviewed by: Matt Ahrens <firstname.lastname@example.org> Reviewed by: Tim Chase <email@example.com> Reviewed by: Tony Hutter <firstname.lastname@example.org> Reviewed by: Andy Fiddaman <email@example.com> Reviewed by: Toomas Soome <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>