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
