-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Partitioning locking and refactoring #955
base: master
Are you sure you want to change the base?
Conversation
975be64
to
342c90f
Compare
I'm still thinking whether we should try harder with acquiring exclusive lock when busy - 500ms might not be enough. Specifically the mentioned blogpost says:
|
4a11af0
to
6514f0d
Compare
self.udev_settle() | ||
time.sleep(5) | ||
device.Format('empty', d, dbus_interface=self.iface_prefix + '.Block') | ||
pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to keep the retry here for the wipefs
call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a great improvement.
a7feb6e
to
f059859
Compare
This is a partial revert of commit cf47eee that depends on full object update after partitioning. That is still work in progress (see storaged-project#955) and prone to race conditions. ====================================================================== FAIL: test_60_resolve_device (test_10_basic.UdisksBaseTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/workspace/udisks-pr/arch/x86_64/distro/centos_9s/type/udisks/src/tests/dbus-tests/test_10_basic.py", line 335, in test_60_resolve_device self.assertEquals(part_name_val, part_label) AssertionError: dbus.String('', variant_level=1) != 'PRTLBLX'
Advisory locking of block devices undergoing major changes is getting increasingly useful and subject for extended use over the daemon. See this great writeup: https://systemd.io/BLOCK_DEVICE_LOCKING/
Nowadays with synthetic uevent tagging in use partitioning can become more predictable. The right approach should be to acquire an advisory lock, make changes, unlock and trigger re-read. Changing the shared lock to exclusive seems to make a big difference and the underlying libblockdev-3 partitioning copes with it just fine.
Rather advisory this alerts the state cleanup thread to avoid touching this device.
Advisory BSD lock is now held on a partition table block device and extra BLKRRPART ioctl is issued on it afterwards.
In case a protective partition table is created by a particular mkfs tool, avoid issuing BLKRRPART on a partition block device and find a parent device that is supposed to hold a partition table.
Should not be necessary anymore now that we're more predictable. Added proper wipe on cleanup though.
This reverts commit 3c41385.
Constantly failing tests in #933 led me to chase for an explanation and managed to find a deficiency in object update after partitioning. Just another race condition that only reproduced in the CI, never locally.
The biggest difference made changing the advisory lock from shared to exclusive.