Currently, I don't add csv support for it because I think it is fine for external parser to do autoscale.
If we need this feature to enable in csv mode please tell me.
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 58964 Build 55851: arc lint + arc unit
Event Timeline
Comment Actions
@imp Hello, I found this needed feature in your idea list. Do you have any problem or feedback?
Comment Actions
Currently, I don't add csv support for it because I think it is fine for external parser to do autoscale.
I think that's probably ok, but then we should make it an error to combine -C and -S.
| usr.sbin/gstat/gstat.8 | ||
|---|---|---|
| 84 | ||
| usr.sbin/gstat/gstat.c | ||
| 94 | To be pedantic, this should be "Mi" (and "Gi" below), I think. I believe kBps and KiBps are the same unit, but I'm not certain. | |
| 501 | Since the original unit is MiBps it'd be better for scale_input() to handle that instead of scaling to kBps here, and then potentially scaling back. | |
| usr.sbin/gstat/gstat.c | ||
|---|---|---|
| 91 | This should be at 10k. Otherwise you go from 999k to 1M Likewise more below. | |
| 94 | kBps vs KiBps can't really be said to be the same... They are and they aren't, mostly they aren't. For Network they are different, because for network speeds, k == 1000 be it bits or bytes. For disks, it's a mixed bag, sometimes it's power of 2 other times it's power of 10. But for this program, historically, it's always been 1024 because DEVSTAT has always been 1024. And pedantically, that may be true today, it's a bigger change, I think. The system is pathologically inconsistent today. I'd recommend using just 'M' and 'G' since it will use much less real estate. Better to give one more digit of output than be pedantic here and waste the space. | |
| 501 | scale is used for different elements, some of which are in kBps, others in Mbps (old-school power-of-2 meaning of those terms). | |
| 502 | I'd be tempted to to print more significant digits here. Rather than 6.0 I'd be tempted to do 6.2... But that kinda messes up the non-scaled output... A note in passing... The ld[2] is hard to read. What's that? But that's a much bigger cleanup. I also think there might be display irreguarities between 1000-1023[kM]... | |
Comment Actions
@khng Tell me that we can use humanize_number(3). What are your opinions? It is a slightly different logic since it will autoscale until it can fit the length of given buffer.
Comment Actions
It's hard to say without seeing the result. Assuming its use is gated by -S, I don't see any major issue with using humanize_number() here.