Clean up /proc/lvm/global formatting
Quoted 4 lines · Heinz J . Mauelshagen
The only objection which comes to my mind is related to potential parsers out there. Please request on the linux-lvm, if soembody complains about changing the output format (to the better one you come up with :-) because of potential parser breaks.
So, the question is - does anyone parse the output of /proc/lvm/global for scripts? I would hope not, since it is quite a mess, and you are better off reading from /proc/VGs/<vg>/{LVs,PVs}/* for your information.
Cheers, Andreas
Quoted 81 lines · Andreas Dilger
Quoted 80 lines
Heinz,
I'm wondering if you have any objection to me committing a change tolvm-fs.cwhich cleans up the output formatting of/proc/lvm/global? It is a rather large patch line-wise (it includes some code formatting changes), but does some other things as well.It removes the third pass through the VG/LV/PV structs when collecting the {vg,lv,pv}_counts values*, and also ensures that we do not have a buffer overrun if a VG/LV/PV is added at the same time we are reading from
/proc/lvm/global**(which could easily happen if the LVM config is changed between the first and second passes).(*) Since the first time through we don't actually care about the actual
values of {vg,lv,pv}_counts (we are only counting string lengths) it doesn't matter what these values are. As a result, we can use the first pass to do find {vg,lv,pv}_counts and add a small margin onto the total string length to accomodate the final number of digits.
(**)We usesnprintf()when printing into the buffer, to avoid any buffer
overflows when generating the output. If we run out of buffer space because a VG/LV/PV was added while we were writing in the second pass we restart with a larger buffer.The output format goes from (old and new samples):
=========================== old format ===================================== LVM driver version 0.9.1_beta2 (18/01/2001)
Total: 2 VG 3 PV 6 LV (2 LVs open) Global: 31944 bytes malloced IOP version: 10 5 days 21:18:14 activeVG: vgboot [1 PV, 1 LV/0 open 0 times] PE Size: 1024 KB
Usage [KB/PE]: 7168 /7 total 7168 /7 used 0 /0 free
PV: [AA] hda2 7168 /7 7168 /7 0 /0
LV: [AWDL ] lvboot 7168 /7 closeVG: vgtest [2 PVs, 5 LVs/2 open 2 times] PE Size: 4096 KB
Usage [KB/PE]: 6152192 /1502 total 5935104 /1449 used 217088 /53 freePVs: [AA] hda6 3076096 /751 3076096 /751 0 /0 [AA] hda8 3076096 /751 2859008 /698 217088 /53 LVs: [AWDL ] lvtest 5124096 /1251 1x open [AWDL ] lvjournal 131072 /32 close [AWDL ] lvreiser 102400 /25 close [AWDL ] lvjbd 65536 /16 close [AWDL ] lvswap 512000 /125 1x open=========================== new format ===================================== LVM module LVM version 1.0.1-rc4(03/10/2001)
Total: 2 VG 3 PV 6 LV (2 LV open) Global: 31944 bytes allocated IOP version: 10 Active: 8d12:12:13VG: vgboot [1 PV, 1 LV/0 open] PE Size: 1024 kB
Total Used Free [kB/PE]: 7168/7 7168/7 0/0 PV: [AA] hda2 7168/7 7168/7 0/0 LV: [AWDL ] lvboot 7168/7 (closed)VG: vgtest [2 PV, 5 LV/2 open] PE Size: 4096 kB
Total Used Free [kB/PE]: 6152192/1502 5935104/1449 217088/53 PV: [AA] hda6 3076096/751 3076096/751 0/0 PV: [AA] hda8 3076096/751 2859008/698 217088/53 LV: [AWDL ] lvtest 5124096/1251 1x open LV: [AWDL ] lvjournal 131072/32 (closed) LV: [AWDL ] lvreiser 102400/25 (closed) LV: [AWDL ] lvjbd 65536/16 (closed) LV: [AWDL ] lvswap 512000/125 1x open============================================================================
Notable differences:
1) all of the total, used, free columns are aligned so it is easy to compare PV/VG/LV usage of each in either kB or PE sizes
2) all of the PV and LV rows are marked as such
3) only show "open x times" if the number of opens is different than the number of open LVs
4) remove "plurals" from names (not very important anyways)
5) remove annoying line wrap problems from PV output
6) more space to hold LV namesI kept the order and number of all the columns (mostly) consistent with the original output, in case it is parsed by scripts (shouldn't be very common in any case).
Quoted 7 lines
Quoted 7 lines
I _was_ going to make all of the size outputs in MB instead of kB (only very strange setups would have PE size < 1MB, and it would give us more room for large LVs), but then I decided against it. It would really confuse scripts, and all other disk values are in kB also (like
/proc/partitions, df, du, etc).As it is, I have left room for 9.99TB values.
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert