fsysinfo -r

Hi,

Another weird thing. Typing ‘fsysinfo -r’ while ‘fsysinfo -d 2’ is
already running in another console or Photon window causes the latter
fsysinfo to show a mess instead of just resetting the counter values.
Help please?

Thanks,

  • Nick

Nikolai Gorbunov <n.gorbunov@swd.ru> wrote:

Hi,

Another weird thing. Typing ‘fsysinfo -r’ while ‘fsysinfo -d 2’ is
already running in another console or Photon window causes the latter
fsysinfo to show a mess instead of just resetting the counter values.
Help please?

I’d say don’t do that.

The “fsysinfo -r” command tells Fsys to reset a bunch of its
stats – but the other, running, fsysinfo command doesn’t know
you’ve done this – it just suddenly gets a bunch of data with
counters reset to 0, or close to 0, in areas where the values
are expected to be always increasing. It doesn’t like this.

And, it doesn’t really print a bunch of garbage. What happens
is that the first iteration after the reset, some of the delta
values go to maxint due to integer wrap. After that they recover
and print reasonable values once again. But, in the print run at
maxint, the numbers end up longer than the format for them, so
the line expands, then when re-written after the next update, it
doesn’t wipe out that final column of data from the previous line.
If you ignore the tag ends of the lines that haven’t been wiped
clean, the data coninues to be correct.

During the changeover, the first reprint looks like:

Used Max Alloc’d Limit Hits Misses Ratio


inodes 44 126 2000 2000 4 0 100.00%
names n/a n/a 3000 3000 3 0 100.00%
files 52 134 134 1500
locks 0 4 32 32
threads 0 24 32 32

data hits:delays:misses = 0:0:0 ( -nan%)%)
metadata hits:misses = 1:0 (100.00%)%)

Operation Count /sec Avg.

cache lookups 1 2147482277 0
cache writes 0 2147483177 0
disk reads 0 2147483641 0
disk writes 0 2147483518 0
open calls 0 2147483630 0
stat calls 1 2147483557 0
namei calls 1 2147483490 0
fstat calls 0 2147483642 0
read calls 0 2147483638 0
write calls 0 2147483480 0


The values of 2147482277, 100.00% and -nan% are somewhat unexpected. :slight_smile:

So, a cosmetic problem. I’ve cleaned it up internally, and will
forward the changes to QA for eventual inclusion in a beta, then
release.

-David