How can I retrieve the mount count for an ext3 volume?

Bill McGonigle bill at bfccomputing.com
Thu Oct 8 18:08:10 EDT 2009


On 10/06/2009 12:31 PM, Ben Scott wrote:
>   If that's your concern, the utility should have an output mode
> that's more friendly to machine interpretation.  :)

yet most don't.  sfdisk is a nice example of one that does.

>   But frankly, for something like mount statistics, it's not worth
> worrying about efficiency, and parsing isn't complicated enough to
> worry about errors.

Complexity isn't the worry, it's fragility.  For:

  Mount Count:		36

this works (probably):

  /^Mount Count:\s+(\d+)/

but if that becomes:

  mount count:		36

it breaks.  Sure, stick an 'i' on the end of the match, but even with
unit tests that's only if the programmer is actively thinking of ways
the e2tools devs may mess with him down the line.  It's neither hard,
nor complex, but it's potentially fragile.

>  An API is an API, regardless of whether it's a C
> struct via ioctl() or text output from e2fsck.  If nothing changes,
> both work equally well, and if things change, the later handles change
> much better.  :)

I'd venture that paths in a /proc or /sys filesystem are less likely to
be tweaked for appearance than command output.

>   You just think the C struct way works better 

oh, yeah?

>   And it's not like /proc or /sys *aren't* giving you text output.  :)

right, but the value is the least likely thing to break.

>   Unix is built on a bunch of small, independent utilities exchanging
> text data. Among other things, that builds an easily diagnosed system,
> and one which handles change gracefully.  :)

first I'd heard of this ;)

>> > I'd have guessed this would be exposed in sysfs ...
>   Just as bad as sticking it in /proc.  Just a different name.  :)

sysfs has a semantic separation from procfs (sysfs is for devices,
procfs for processes), with the idea that kernel device information can
be organized in a predictably parsable hierarchy.  It's the 'everything
is a file' philosophy.  I suppose some may cry of Plan 9 heresy.

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: bill at bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle


More information about the gnhlug-discuss mailing list