Posted: Nov 29, 17, 10:32 techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Location: East Coast, West Coast? I know it's one of them.
Ah, another difference. In FreeBSD you do not need to be root to run zpool status [device].
At least none of the installs I tested on required that, which was a nice feature because that meant all reports would run as user, which is always the preferred outcome.
I was wondering why the components weren't being listed in the output, that explains it.
The wrapping of ultra long component names will require more work, but I believe the raw logic should now work.
I corrected the issue with zfs and mdraid output reporting a false FAIL, I had to re-lookup this stuff, it's been a while, basically mdraid reports status as (F) or F, or (S) or S, for Fail / Spare, and since all the component ids I'd ever seen were lower case, the test for F or S was enough to be safe on all the systems and datasets I tested with. But that's why other user data is always better than the data I already know, since if the issue had been found in the datasets I already have, there would have been no issue.
I'm curious, I believe following the zfs logic in inxi, that the SECOND mirror should be showing, is that correct? not the first, since inxi has no way I can see to handle more than one per device name.
In a perfect world, the wonderful Perl faerie would have dropped her perl dust on inxi, and I would wake up to find it fully translated to perl, at which point, fixing these types of issues would be simple using multidimensional hashes.
:: Code ::
- [raid type 0][mirror|raid0|raid5]
- [component 0][id]
- [component 1][id]
- [raid type 1][mirror|raid0|raid5]
- [component 2][id]
- [compenent 3][id]
and so on. Right now via hack filled associative / hash array emulation, inxi manages basically 2 levels, a 3rd can be added but it's really nasty and ugly to do it.
Back to top
All times are GMT - 8 Hours