Re: statmount: requesting more information: statfs, devname, label

[Thiago Macieira <thiago.macieira@intel.com>]

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

On Thursday 30 May 2024 07:42:09 GMT-3 Christian Brauner wrote:
> Let me rephrase what I mean as I probably wasn't clear enough in my
> first mail. My objection is mostly that I don't want us to start putting
> stuff in there that's not generic. And yes, some statfs() fields might
> make sense to put in statmount(). But I think stuff like "f_files" or
> "f_ffree" is really something that's misplaced in statmount().

I'll take what I can get. My class's API exposes the total size of the 
filesystem (f_blocks), the bytes available and free (f_bfree and f_bavail), the 
block size and whether the filesystem is read-only. For the latter, I don't 
know if it's the same as MOUNT_ATTR_RDONLY.

Keeping statfs() is not a problem. My biggest problem is matching the mounted 
filesystems from either mountinfo or listmounts() with what is actually visible 
in the system. For example, what happens if you mount something that makes a 
mountpoint invisible? Both df and the Qt class hide the entry too, but it was 
guess work until the mount IDs were exposed in statx().

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5152 bytes --]