Hello,
Some time ago we traced a large scale booting issue back to the
utimensat() call that mnt_is_readonly() makes when mounting a
read-write, but root-squashed parallel filesystem.
This is caused by many clients mounting nearly simultaneously, failing
the access() call earlier (because the FS is root-squashed) and then
calling utimensat() at about the same time. Because it attempts to
write to the mount point, the remote filesystem manager serializes the
passage through utimensat().
The filesystem is already mounted at this point and it appears that the
utimensat() call is really only used to append a "ro" to the apparent
mount flags for /etc/mtab, it seems that this is a high cost to make
this determination.
It seems this was discussed in this thread previously:
https://marc.info/?l=util-linux-ng&m=148405286532392&w=2
<https://marc.info/?l=util-linux-ng&m=148405286532392&w=2>
However, I think it would be preferable to not be required to have a
custom-build of util-linux to avoid this problem. Is this secondary
check with utimensat() really necessary? Perhaps an alternative to
removing it would be to have a check to see if /etc/mtab is writable
before aggressively collecting data that may not be able to be outputted
to it, for example, in the case that /etc/mtab is a symlink to
/proc/mounts this logic could be skipped. Skimming through the libmount
code, perhaps adding a check against mnt_context_mtab_writable() here:
https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L1001
<https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L1001>
would be feasible.
Thank you,
Doug
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
