zpool: Fix column alignment with long zpool names

[gg7]

Description

zpool status normally aligns NAME/STATE/etc columns:

    NAME                       STATE     READ WRITE CKSUM
    dummy                      ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        /tmp/dummy-long-1.bin  ONLINE       0     0     0
        /tmp/dummy-long-2.bin  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        /tmp/dummy-long-3.bin  ONLINE       0     0     0
        /tmp/dummy-long-4.bin  ONLINE       0     0     0

However, if the zpool name is longer than the zvol names, alignment issues
arise:

    NAME                  STATE     READ WRITE CKSUM
    dummy-very-very-long-zpool-name  ONLINE       0     0     0
      mirror-0            ONLINE       0     0     0
        /tmp/dummy-1.bin  ONLINE       0     0     0
        /tmp/dummy-2.bin  ONLINE       0     0     0
      mirror-1            ONLINE       0     0     0
        /tmp/dummy-3.bin  ONLINE       0     0     0
        /tmp/dummy-4.bin  ONLINE       0     0     0

zpool iostat is also affected:

                  capacity     operations     bandwidth
    pool        alloc   free   read  write   read  write
    ----------  -----  -----  -----  -----  -----  -----
    dummy        104K  1.97G      0      0    152  9.84K
    dummy-very-very-long-zpool-name   152K  1.97G      0      1    144  13.1K
    ----------  -----  -----  -----  -----  -----  -----

My patch fixes column alignment:

    NAME                       STATE     READ WRITE CKSUM
    dummy                      ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        /tmp/dummy-long-1.bin  ONLINE       0     0     0
        /tmp/dummy-long-2.bin  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        /tmp/dummy-long-3.bin  ONLINE       0     0     0
        /tmp/dummy-long-4.bin  ONLINE       0     0     0

    NAME                             STATE     READ WRITE CKSUM
    dummy-very-very-long-zpool-name  ONLINE       0     0     0
      mirror-0                       ONLINE       0     0     0
        /tmp/dummy-1.bin             ONLINE       0     0     0
        /tmp/dummy-2.bin             ONLINE       0     0     0
      mirror-1                       ONLINE       0     0     0
        /tmp/dummy-3.bin             ONLINE       0     0     0
        /tmp/dummy-4.bin             ONLINE       0     0     0

                                       capacity     operations     bandwidth
    pool                             alloc   free   read  write   read  write
    -------------------------------  -----  -----  -----  -----  -----  -----
    dummy                             104K  1.97G      0      1    308  19.9K
    dummy-very-very-long-zpool-name   152K  1.97G      0      2    278  25.2K
    -------------------------------  -----  -----  -----  -----  -----  -----

How Has This Been Tested?

Manually. You can reproduce the zpool setup like this:

george@george:~$ for i in $(seq 1 4); do dd if=/dev/zero of=/tmp/dummy-long-$i.bin bs=1 count=0 seek=1G; done
george@george:~$ sudo zpool create dummy mirror /tmp/dummy-long-{1,2}.bin mirror /tmp/dummy-long-{3,4}.bin
george@george:~$ for i in $(seq 1 4); do dd if=/dev/zero of=/tmp/dummy-$i.bin bs=1 count=0 seek=1G; done
george@george:~$ sudo zpool create dummy-very-very-long-zpool-name mirror /tmp/dummy-{1,2}.bin mirror /tmp/dummy-{3,4}.bin

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.
• Change has been approved by a ZFS on Linux member.

[tonyhutter]

Looks good, just fix the commitcheck error:

error: commit message body contains line over 72 characters
Makefile:1435: recipe for target 'commitcheck' failed
make: *** [commitcheck] Error 1

[behlendorf]

And please rebase this branch against the latest master.

[gmelikov]

What does this comment mean? my machine?

[gg7]

On my machine all root vdev names are root-0 (for all zpools).

I wasn't sure if it was possible for them to be something else (e.g. root-1, or other-type-10), but from a brief look at the codebase I now think root vdev names will always be root-0.

Code updated. If my understanding is incorrect, please let me know.

[gg7]

error: commit message body contains line over 72 characters

@tonyhutter The only lines exceeding 72 characters are the ones showing command output verbatim:

                                       capacity     operations     bandwidth
    pool                             alloc   free   read  write   read  write
    -------------------------------  -----  -----  -----  -----  -----  -----
    dummy                             104K  1.97G      0      1    308  19.9K
    dummy-very-very-long-zpool-name   152K  1.97G      0      2    278  25.2K
    -------------------------------  -----  -----  -----  -----  -----  -----

and

    dummy-very-very-long-zpool-name   152K  1.97G      0      1    144  13.1K

Should I truncate the lines or leave them as they are?

I have rebased the branch and have also added an if as a small optimisation.

[behlendorf]

@gg7 for the sake of readability I think we can ignore the usual line length limit in the commit message.

[behlendorf]

It's possible for a NULL zhp to be passed to max_width which results in segmentation fault. This is why you're seeing all the failures from the automated testing. At a minimum you'll need to add a NULL check here. I think it would also be worthwhile to move this logic down in to zpool_vdev_name() for printing the pool name instead of root-0. This would then allow you to properly handle the case where the pool guid is printed instead of its name. If it's needed we could add another vdev_name_t to the enum to optionally control this.

[gg7]

Thank you for the feedback. I will redo my patch soon.

[behlendorf]

Let's move this up in to the block comment above the function and clearly describe that callers are expected to pass 0 for max.

[gg7]

@behlendorf I have moved the "get zpool name" logic inside of zpool_vdev_name(), as you suggested. I hope the tests will pass now (the 1+ hour test times aren't great).

Could you please tell me how to get the zpool name if zhp is null? AFAIK that happens when the zpool hasn't been imported. zpool import output isn't aligned in that case:

george@george:~/zfs$ sudo ./cmd/zpool/zpool import -d /tmp/
   pool: dummy-very-very-long-zpool-name
[...]
        dummy-very-very-long-zpool-name  ONLINE
          mirror-0            ONLINE
            /tmp/dummy-1.bin  ONLINE
            /tmp/dummy-2.bin  ONLINE
          mirror-1            ONLINE
            /tmp/dummy-3.bin  ONLINE
            /tmp/dummy-4.bin  ONLINE

I tried doing nvlist_lookup_string(nv, ZPOOL_CONFIG_POOL_NAME, &zpool_name), but that didn't work (non-zero return code).

[behlendorf]

Thanks for reworking this.

You can run the ZFS Test Suite locally to more quickly iterate on specific test cases.

For example, if you rebase on master you can quickly run the zpool import test cases which will trigger this by running the following in-tree.

./scripts/zfs.sh
./scripts/zfs-tests.sh -v -T zpool_import

[behlendorf]

Could you please tell me how to get the zpool name if zhp is null?

This will happen when using the zpool import -D to import a previously destroyed pool. Since this is such an uncommon case I don't think it's critical that we handle it and we can drop this TODO.

[gg7]

@behlendorf As mentioned above, the pool could have been exported (and not destroyed), which is a more common scenario:

george@george:~$ sudo zpool export dummy-very-very-long-zpool-name
george@george:~$ sudo zpool import -d /tmp
   pool: dummy-very-very-long-zpool-name
     id: 15691137324734536224
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

	dummy-very-very-long-zpool-name  ONLINE
	  mirror-0            ONLINE
	    /tmp/dummy-1.bin  ONLINE
	    /tmp/dummy-2.bin  ONLINE
	  mirror-1            ONLINE
	    /tmp/dummy-3.bin  ONLINE
	    /tmp/dummy-4.bin  ONLINE

This is annoying me, but if you think it's not worth fixing then I will remove the TODO.

[behlendorf]

That is annoying, for the show_import() case how about something like this to address it.

diff --git a/cmd/zpool/zpool_main.c b/cmd/zpool/zpool_main.c
index b6b6f0c..8493f28 100644
--- a/cmd/zpool/zpool_main.c
+++ b/cmd/zpool/zpool_main.c
@@ -2216,7 +2216,8 @@ show_import(nvlist_t *config)
 
        (void) printf(gettext(" config:\n\n"));
 
-       cb.cb_namewidth = max_width(NULL, nvroot, 0, 0, VDEV_NAME_TYPE_ID);
+       cb.cb_namewidth = max_width(NULL, nvroot, 0, strlen(name),
+           VDEV_NAME_TYPE_ID);
        if (cb.cb_namewidth < 10)
                cb.cb_namewidth = 10;
 

[gg7]

Awesome, it works! Thank you.

[behlendorf]

nit: can you invert this so the NULL check comes before the strcmp().

[gg7]

Good idea, fixed.

[gg7]

You can run the ZFS Test Suite locally

Thank you for the suggestion, but my /home fs is on ZFS and I can't easily unload my zfs modules. A run-tests-in-qemu-kvm.sh script would have been useful IMHO.

I have implemented your suggestions and have also removed an extra call to nvlist_lookup_string (which needs reviewing).