LWN: Comments on "listmount() and statmount()"

listmount() and statmount()

cavok — Thu, 16 Nov 2023 20:28:19 +0000

I'm so used to `cat /proc/partitions` instead :)

listmount() and statmount()

mezcalero — Thu, 16 Nov 2023 09:00:10 +0000

BTW, one addendum. The reason why systemd considers the mount ID a 32bit entity is simply because the kernel exports it like that. i.e. name_to_handle_at() was the first kernel API to expose the mount ID to userspace in binary form, and it used an "int" for that, see man page. We then adopted that, since that's apparently what the kernel wants us to use.

Lennart

listmount() and statmount()

intelfx — Mon, 13 Nov 2023 10:29:45 +0000

> I found the output of "lsblk -f" to be really good.

There's also `findmnt` (esp. `findmnt --real`) that works in the opposite direction.

listmount() and statmount()

marcH — Mon, 13 Nov 2023 00:23:34 +0000

> ... few of which correspond to partitions on actual storage devices.

I stopped using the "mount" command for that reason. I found the output of "lsblk -f" to be really good.

listmount() and statmount()

atnot — Sun, 12 Nov 2023 12:33:01 +0000

> One problem with big-endian numbers ... if you had little-endian, anybody retrieving a u64 into an i32 would have a rude awakening straight away ...

Did you mean the other way around? Either way it doesn't really matter because unless you got the type definition for the syscall wrong or accidentally did the arcane incantations required to do a bit cast in C, it will just cast it numerically and endianness is irrelevant.

listmount() and statmount()

Wol — Sat, 11 Nov 2023 22:42:26 +0000

One problem with big-endian numbers ... if you had little-endian, anybody retrieving a u64 into an i32 would have a rude awakening straight away ...

But if statx has *always* been u64, why do you need another argument? Any consumers that mis-use it will break, but surely they would break anyway? (Or have a kernel switch about re-using IDs.)

Cheers,
Wol

listmount() and statmount()

atnot — Sat, 11 Nov 2023 20:39:16 +0000

> As a way of avoiding confusion between the two IDs, the lowest unique mount ID is set to 232.

I feel like this should just be done in general for any 32 bit ID in the future to avoid this issue... Otherwise someone will inevitably store it in a c int some point :)

listmount() and statmount()

snajpa — Sat, 11 Nov 2023 09:46:20 +0000

haha but procfs made almost entirely of such text files is still considered a good idea :-D haha :-D

listmount() and statmount()

iustin — Fri, 10 Nov 2023 19:04:40 +0000

Thanks for the article. This kind of post is why I am very happy to be a subscriber!

listmount() and statmount()

bluca — Fri, 10 Nov 2023 17:09:20 +0000

This is a very welcome development, been waiting for this for a long time, very happy to see it move forward