Re: [PATCH v2] e2fsck: take flock(LOCK_EX) on whole-disk device during filesystem check

["Theodore Tso" <tytso@mit.edu>]

On Wed, Aug 26, 2026 at 07:04:48AM -0500, Nandakumar Raghavan wrote:
> This was on purpose and not something I missed. The sd_device_get_parent_with_subsystem_devtype
> requires libsystemd v251+, and e2fsck needs to keep working in contexts where
> that dependency isn't available or isn't guaranteed to be new enough - non-systemd distros, older
> LTS systems doing root-fs repair before userspace is fully up, embedded/recovery images, etc.

Cqn you name any other OS that has implemented

	https://systemd.io/BLOCK_DEVICE_LOCKING/

*other* than systemd?  So for non-systemd distros, who cares if we
don't have the functionality?  So what we could do is to use autoconf
with something like this:

AC_CHECK_LIB(libsystemd, sd_device_get_parent_with_subsystem_devtype,
	AC_DEFINE(HAVE_SD_DEVICE_GET_PARENT_WITH_SUBSYSTEM_DEVTYPE, 1,
		[Define to 1 if libsystemd has sd_device_get_parent_with_subsystem_devtype]))

We would only do the flock(LOCK_EX) if and only if the function is
present.  If it isn't, say on MacOS, FreeBSD, or RHEL 7 we won't play
the systemd locking game --- which is fine, because it doesn't matter
on those platforms.

If you care about running e2fsck built on RHEL 8 on RHEL 7, that's an
easy problem to solve.  A executable linked using shared libraries
won't work already since the shared libraries on RHEL 8 are too new.
But we have a solution already, which is to use e2fsck.static, which
is statically linked.

> Taking a hard runtime dependency on a versioned libsystemd API for a tool this fundamental felt
> like a much bigger cost than by parsing (/sys/dev/block/MAJ:MIN/partition, .../dev), which only
> relies on a stable kernel ABI with no library and no version floor. Happy to reconsider if
> the project wants to take the dependency, but wanted to flag the tradeoff explicitly rather
> than silently pick one side.

If we really cared about taking a binary built on a system with
libsystemd. and running on a system without libsystemd, another
solution that we've used is dlopen.

For an example of that's done, see misc/create_inode_libarchve.c and
the associated autoconf tests in configure.ac in the e2fsprogs
sources.  This is how "mke2fs -d embed_rootfs.tar.gz -t ext4 embed.img
1G" is handled without needing a hard dependency on libarchive being
installed.  If it's not installed then you'll just get the error
message "you need libarchive to be able to process tarballs".

I don't think the dlopen() approach is needed here, though.

Cheers,

					- Ted