Re: [proposal] making filesystem tools more machine friendly

[Theodore Ts'o <tytso@mit.edu>]

On Tue, Jul 04, 2017 at 03:57:38PM +0200, Jan Tulak wrote:
> 
> There are some similar values between filesystems, but they are really
> basic ones - blocks, inodes, and maybe few more other things, so I
> admit the usability of common names for these fields is questionable.
> What I really want is that I can run tune2fs or xfs_info, pass the
> output through a standard, common parser, and get a structure filled
> with data.

Can you make a list of what you might need?  The reason why I was
asking for "user stories" is because I was trying to get you to think
in more detail about exactly what functionality you really need.  Not
just something hand wavy like "tools that want to abstract most of the
differences between various file systems" by exactly what file
systems.  (e.g., create a file system, resize a file system, check a
file system --- what else?)

I think if you make a list of the functionality that you need to
abstract --- and thinking about "user stories" is a common way UI
designers try to get developers to think in terms of "what does the
user want to do", as opposed to the developer-centric "oh, I want an
abstract file system interface" answer.

In terms of what you might need, I'm guessing it won't be much more
than:

* Blocksize
* Number of blocks in the file system
* Number of free blocks in the file system
* Number of inodes in the file system (*)
* Number of free inodes in the file system (*)
* Volume label (**)
* UUID (**)

(*) It's not clear you even need the number of inodes / free inodes.
Try going through potential "user stories" and see what you find.

(**) Already available via libblkid and the blkid CLI.

I suspect you may be making this way more complicated that it needs to
be.  These fields are pretty basic, and have changed in decades.  I'm
pretty sure the original EVMS screen-scraping code that parsed the
output of "dumpe2fs -h" from 10+ years ago would still work today.  So
when you assert that the screen scraping is terrible because the tools
are constantly changing the output --- I'd like to gently challenge
that assertion.

These are also the fields which are *trivially* easy to extract via a
C interface, and which again, even if they were done without the
support of the file system developers would almost certainly be
stable.  The volume ID and UUID are extracted for the superblock of a
large number of file systems in libblkid, and most of the probe code
involved hasn't changed in decades.  Changes were only to support new
file systems, not because file systems are constantly changing the
superblock encoding for where to find the Volume label or UUID.  I
assure you the same would be tree for the fields listed above.

Doing something like libblkid's probe functions for the number of
block/inodes will almost certainly be less work than trying to get
JSON patches crammed into a large number of file system tools.  If you
did it in a standalone, libblkid-like library, it would also have the
benefit that you could query a file system for its basic statistics
even if the file system's userspace tools have been installed in the
distribution.

So perhaps that's something you should consider?

							- Ted