Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #35823

e2fsprogs - maybe we don't get the fix

Show all headers | View raw

Interesting mailing list message from Ted Tso:

"Cqn [sic] 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]))
"

https://lore.kernel.org/linux-ext4/20260824224006.GB6038@frogsfrogsfrogs/t/#m4743eec8fcce7a519b0b0e69ca5a6ce5c4b45e6a

So yay that e2fsprogs will still build on slackware if they end up being
the project that takes responsibility for acquiring the missing
lock. But boo-hoo that there's no awareness that this hypothetically
affects us too. Or maybe I don't know what I'm talking about.

In short...

1. we get symlinks in /dev/disk/by-uuid because of these udev
   rules in 60-persistent-storage.rules:

   # probe filesystem metadata of disks
   KERNEL!="sr*", IMPORT{builtin}="blkid"

   # by-label/by-uuid links (filesystem metadata)
   ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
   ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"

2. ENV{ID_FS_UUID_ENC} only can exist if the earlier import from the
   builtin libblkid code succeeds in reading the filesystem uuid
   out of the superblock

3. If e2fsck is in there writing (and, I believe, even if it just
   updates a couple fields in the superblock after finding the fs to be
   clean) while eudev's liblkid calls are also in there reading, well,
   trouble. Unless there's locking between e2fsck and udevd (and a lock
   that's actually on the same device, the disk device, which is not
   currently the case)

4. eudev does its part and takes a read (shared) lock in
   worker_lock_block_device() in udevd.c:
    if (flock(fd, LOCK_SH|LOCK_NB) < 0)
         return log_device_debug_errno(dev, errno, "Failed to flock(%s): %m", val);

5. The subject of the e2fsck thread linked above is about how there's
   been no other end of that lock for more than a decade now, since
   util-linux fsck stopped taking its lock on the whole disk in favour
   of a private lock file under /run.

I'm not at all convinced this only effects systemd systems. What
protects us other than fortunate timing for uevents vs. when rc.S runs
fsck?

- Mike Sm.

Back to alt.os.linux.slackware | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

e2fsprogs - maybe we don't get the fix Mike Small <smallm@panix.com> - 2026-09-29 19:32 -0400
  Re: e2fsprogs - maybe we don't get the fix Mike Small <smallm@panix.com> - 2026-09-29 20:25 -0400

csiph-web