picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs: clarify that udev watches for IN_CLOSE_WRITE (and not IN_CLOSE) 

Also, while we are at it, explain that udev won't reprobe if users just
release the lock, they have to close the block device too.
This commit is contained in:
Lennart Poettering 2020-10-09 16:10:40 +02:00 committed by Zbigniew Jędrzejewski-Szmek
parent 6c08f84ac6
commit 5fa661a4fb
1 changed files with 20 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/BLOCK_DEVICE_LOCKING.md
View File

@ -28,23 +28,34 @@ returns `EBUSY`), it refrains from processing the device. If it manages to take
the lock it is kept for the entire time the device is processed. the lock it is kept for the entire time the device is processed.
Note that `systemd-udevd` also watches all block device nodes it manages for Note that `systemd-udevd` also watches all block device nodes it manages for
`inotify()` `IN_CLOSE` events: whenever such an event is seen, this is used as `inotify()` `IN_CLOSE_WRITE` events: whenever such an event is seen, this is
trigger to re-run the rule-set for the device. used as trigger to re-run the rule-set for the device.
These two concepts allow tools such as disk partitioners or file system These two concepts allow tools such as disk partitioners or file system
formatting tools to safely and easily take exclusive ownership of a block formatting tools to safely and easily take exclusive ownership of a block
device while operating: before starting work on the block device, they should device while operating: before starting work on the block device, they should
take an `LOCK_EX` lock on it. This has two effects: first of all, in case take an `LOCK_EX` lock on it. This has two effects: first of all, in case
`systemd-udevd` is still processing the device the tool will wait for it to `systemd-udevd` is still processing the device the tool will wait for it to
finish. Second, after the lock is taken, it can be sure that finish. Second, after the lock is taken, it can be sure that `systemd-udevd`
`systemd-udevd` will refrain from processing the block device, and thus all will refrain from processing the block device, and thus all other client
other client applications subscribed to it won't get device notifications from applications subscribed to it won't get device notifications from potentially
potentially half-written data either. After the operation is complete the half-written data either. After the operation is complete the
partitioner/formatter can simply close the device node. This has two effects: partitioner/formatter can simply close the device node. This has two effects:
it implicitly releases the lock, so that `systemd-udevd` can process events on it implicitly releases the lock, so that `systemd-udevd` can process events on
the device node again. Secondly, it results an `IN_CLOSE` event, which causes the device node again. Secondly, it results an `IN_CLOSE_WRITE` event, which
`systemd-udevd` to immediately re-process the device — seeing all changes the causes `systemd-udevd` to immediately re-process the device — seeing all
tool made — and notify subscribed clients about it. changes the tool made — and notify subscribed clients about it.
Ideally, `systemd-udevd` would explicitly watch block devices for `LOCK_EX`
locks being released. Such monitoring is not supported on Linux however, which
is why it watches for `IN_CLOSE_WRITE` instead, i.e. for `close()` calls to
writable file descriptors referring to the block device. In almost all cases,
the difference between these two events does not matter much, as any locks
taken are implicitly released by `close()`. However, it should be noted that if
an application unlocks a device after completing its work without closing it,
i.e. while keeping the file descriptor open for further, longer time, then
`systemd-udevd` will not notice this and not retrigger and thus reprobe the
device.
Besides synchronizing block device access between `systemd-udevd` and such Besides synchronizing block device access between `systemd-udevd` and such
tools this scheme may also be used to synchronize access between those tools tools this scheme may also be used to synchronize access between those tools