The new listmount() syscall returns a list of unique mount IDs (just
uint64_t per node, nothing else). It makes it very fast and efficient.
* libmount supports two scenarios:
- fetch the whole mount table by mnt_table_fetch_listmount(); this is
an alternative to mnt_table_parse_file()
- on demand; this mode is an extension to the current functionality,
when enabled by mnt_table_enable_listmount(), then mnt_table_next_fs()
will ask the kernel for data by listmount.
If mnt_table_next_fs() iterates on the mount table in reverse order
(MNT_ITER_BACKWARD), then it reads mount nodes from the kernel in
reverse order too.
The advantage of the on-demand mode is that on machines with a huge
mount table (thousands of nodes), we can work with only a subset of
the table (usually the last few nodes with the most recently
mounted filesystems), and the kernel does not have to compose a complete
huge table. This should be an improvement over the mountinfo file.
The default is to read 512 nodes (IDs) by one listmount() call. This
size can be altered by mnt_table_listmount_set_stepsiz(). The default
size should be large enough for usual Linux machines.
It's also possible to set a sub-tree by mnt_table_listmount_set_id()
and a namespace by mnt_table_listmount_set_ns().
If libmnt_statmnt (on-demand statmount()) is assigned to the table,
then all filesystems in the table are automatically assigned to this
statmount() setup too. This allows for a completely on-demand
scenario.
while (mnt_table_next_fs(tb, itr, &fs) == 0) {
if (strcmp("vfat", mnt_fs_get_fstype(fs)) == 0)
print("%s", mnt_fs_get_fs_options(fs));
}
In this example, mnt_table_next_fs() serves as the frontend for
listmount() and mnt_fs_get_...() serves as the frontend for
statmount(). The fs-options are read from kernel only for "vfat"
filesystems.