Zarcstat bug (maybe)

OpenZFS
1

On my system OpenZFS 2.4.1 zarcstat in continuous scroll mode (e.g. zarcstat 1 for one update per second) is oblivious to changes in the number of terminal lines (i.e. stty size). It’s meant to re-print the column header just as the old header scrolls out of view.

The output of stty size is accurate and picks up changes on-the-fly. So I reckon my terminal app + session are OK here.

If this is truly a bug I figure something so obvious would’ve been caught a long time ago? Anyway, can someone please try zarcstat 1 with a very short terminal window and let me know if the header reprints as intended? Trying to not annoy OpenZFS devs unless there’s a genuine problem.

image
image763×209 27.1 KB

If you DO reproduce this bug, can you try again with a copy of /usr/bin/zarcstat where lines 466+467 are edited from:

data = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, '1234')
sz = struct.unpack('hh', data)

…to…

data = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, b'\x00' * 8)
sz = struct.unpack('hhhh', data)

I think the script’s except Exception: pass may be covering (i.e. silent fail) for a technique that worked in older Python.

Thanks!

2

I don’t know whether this is any help since I’m on Linux and using arcstat as shipped on Debian (technically Proxmox 8), but for me, the headers are correctly reprinted when it scrolls off the screen even after I resize the terminal during its execution. I unfortunately can’t determine the version. Here’s the ZFS version, though, which seems to be behind yours:

$ sudo modinfo zfs | rg -F version
version:        2.2.6-pve1
srcversion:     E73D89DD66290F65E0A536D
3

arcstat.py had a recent rewrite. I guess the bug(?) was introduced then…

1 Like