On Tue, Jul 4, 2017 at 9:07 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > 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. For ext4/xfs, that's almost all. But it get's worse with btrfs, as you can see in this list: * create/resize/remove/check a filesystem on a volume * get basic stats (label, uuid, size, free space, blocksize) * set/edit/unset quotas (disk, user, group, project) * add/remove device from a pool * create/delete/mount subvolumes and snapshots in a pool The reason why I include the pool and subvolume capabilities of btrfs (and possibly zfs) is that other filesystems can achieve similar results with LVM and the tools I mentioned are bridging and hiding this difference. So, for ext4/xfs, I need only to add the fields regarding quotas to the list and that should be all I can think of now. Btrfs is another issue, though. > > 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. OK, I exaggerated how much it changes. Still, even a new field can cause trouble (depending on how the parser is written), which is an unnecessary issue. > > 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 An independent tool is a good idea at the beginning, making it accessible to more people (who doesn't have to rebuild *progs), but we still have another layer for a functionality that could be done directly within the fs tools. While I may go this way initially, I would still consider a merge as a goal. I think that this way might be reasonable and acceptable for everyone: Start with the wrappers, first for tools where the situation is the worst, and meanwhile do some small changes in *progs which are useful for everyone - e.g. ensure that every tool can be run non-interactively when required (some time ago, there were issues with Anaconda getting stuck when a fs tool waited for a confirmation, but I can't find the bugs right now to check the details and if the tools were fixed or Anaconda made a workaround). And when the bonus of the new interface is clear and there are some users, we can talk about how to merge it. Cheers, Jan -- Jan Tulak jtulak@xxxxxxxxxx / jan@xxxxxxxx
