Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

H. Peter Anvin wrote:
> Chuck Lever wrote:
>> The advantage is that it doesn't have strong user space dependencies on
>> its format like /proc/mounts does.
>>
>> If you have NFS mount points, you will see that it includes a great deal
>> of additional information about each mount.
> 
> OK, I see now:
> device raidtest:/export mounted on /net/raidtest/export with fstype nfs
> statvers=1.0
>         opts:
> rw,vers=3,rsize=131072,wsize=131072,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys
>         age:    5
>         caps:   caps=0x9,wtmult=4096,dtsize=4096,bsize=0,namelen=255
>         sec:    flavor=1,pseudoflavor=1
>         events: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>         bytes:  0 0 0 0 0 0 0 0
>         RPC iostats version: 1.0  p/v: 100003/3 (nfs)
>         xprt:   tcp 686 0 2 0 5 8 8 0 8 0
>         per-op statistics
>                 NULL: 0 0 0 0 0 0 0 0
>              GETATTR: 2 2 0 264 224 1 0 1
>              SETATTR: 0 0 0 0 0 0 0 0
>               LOOKUP: 0 0 0 0 0 0 0 0
>               ACCESS: 1 1 0 116 120 0 0 0
>             READLINK: 0 0 0 0 0 0 0 0
>                 READ: 0 0 0 0 0 0 0 0
>                WRITE: 0 0 0 0 0 0 0 0
>               CREATE: 0 0 0 0 0 0 0 0
>                MKDIR: 0 0 0 0 0 0 0 0
>              SYMLINK: 0 0 0 0 0 0 0 0
>                MKNOD: 0 0 0 0 0 0 0 0
>               REMOVE: 0 0 0 0 0 0 0 0
>                RMDIR: 0 0 0 0 0 0 0 0
>               RENAME: 0 0 0 0 0 0 0 0
>                 LINK: 0 0 0 0 0 0 0 0
>              READDIR: 0 0 0 0 0 0 0 0
>          READDIRPLUS: 0 0 0 0 0 0 0 0
>               FSSTAT: 1 1 0 132 84 0 1 1
>               FSINFO: 1 1 0 132 80 0 0 0
>             PATHCONF: 0 0 0 0 0 0 0 0
>               COMMIT: 0 0 0 0 0 0 0 0
> 
> This format is just awful for parsing.  It's pretty clearly totally
> ad-hoc.  It's not even self-consistent (it uses different separators,
> etc, in the same file!)  It's reasonably compact for human consumption,
> but it doesn't show what the arrays mean.
> 
> Heck, XML would have been better than this mess...

Sigh.  So where where you when I asked for review time and again?

I have a couple of simple Python scripts that can parse this without any 
difficulty.

I resent your tone.  Quite a bit.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 291 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel/
version:2.1
end:vcard