systemd/rules.d/64-btrfs.rules.in

# do not edit this file, it will be overwritten on update

SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION=="remove", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
ENV{SYSTEMD_READY}=="0", GOTO="btrfs_end"

# let the kernel know about this btrfs filesystem, and check if it is complete
IMPORT{builtin}="btrfs ready $devnode"

# mark the device as not ready to be used by the system
ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"

# reconsider pending devices in case when multidevice volume awaits
ENV{ID_BTRFS_READY}=="1", RUN+="{{ROOTBINDIR}}/udevadm trigger -s block -p ID_BTRFS_READY=0"

LABEL="btrfs_end"
udev: add btrfs support All "btrfs" file systems will be registered with the kernel when they show up. Incomplete multi-device volumes will set SYSTEMD_READY=0, to prevent access until the volume is complete and fully registered. 2012-09-17 01:31:11 +04:00			`# do not edit this file, it will be overwritten on update`

			`SUBSYSTEM!="block", GOTO="btrfs_end"`
			`ACTION=="remove", GOTO="btrfs_end"`
			`ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"`
rules: skip btrfs check if devices are not ready in 64-btrfs.rules (#8304) If any devices are marked with 'SYSTEMD_READY=0' then we shouldn't run any btrfs check on them. Indeed there's no point in running "btrfs ready" on devices that already have SYSTEMD_READY=0 set. Most probably such devices are members of a higher layer aggregate device such as dm-multipath or software RAID. Doing IO on them wastes time at best, and may cause delays, timeouts, or even hangs at worst (think active-passive multipath or degraded RAID, for example). It was initially reported at: https://bugzilla.opensuse.org/show_bug.cgi?id=872929 2018-02-28 12:36:06 +03:00			`ENV{SYSTEMD_READY}=="0", GOTO="btrfs_end"`
udev: add btrfs support All "btrfs" file systems will be registered with the kernel when they show up. Incomplete multi-device volumes will set SYSTEMD_READY=0, to prevent access until the volume is complete and fully registered. 2012-09-17 01:31:11 +04:00
			`# let the kernel know about this btrfs filesystem, and check if it is complete`
			`IMPORT{builtin}="btrfs ready $devnode"`

			`# mark the device as not ready to be used by the system`
			`ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"`

assemble multidevice btrfs volumes without external tools (#6607) assemble multidevice btrfs volumes without external tools This self-contained approach introduce very little overhead, unless someone has a large number of devices composing many btrfs volumes, in which case btrfs device scan would be faster. Still, having robust implementation is a nice to have alternative for btrfs-progs. 2017-09-07 10:58:12 +03:00			`# reconsider pending devices in case when multidevice volume awaits`
meson: use jinja2 for rules.d templates 2021-05-16 16:51:17 +03:00			`ENV{ID_BTRFS_READY}=="1", RUN+="{{ROOTBINDIR}}/udevadm trigger -s block -p ID_BTRFS_READY=0"`
assemble multidevice btrfs volumes without external tools (#6607) assemble multidevice btrfs volumes without external tools This self-contained approach introduce very little overhead, unless someone has a large number of devices composing many btrfs volumes, in which case btrfs device scan would be faster. Still, having robust implementation is a nice to have alternative for btrfs-progs. 2017-09-07 10:58:12 +03:00
udev: add btrfs support All "btrfs" file systems will be registered with the kernel when they show up. Incomplete multi-device volumes will set SYSTEMD_READY=0, to prevent access until the volume is complete and fully registered. 2012-09-17 01:31:11 +04:00			`LABEL="btrfs_end"`