Skip to content
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

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

tbzatek
Copy link
Member

@tbzatek tbzatek commented Jan 8, 2022

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.

@tbzatek
Copy link
Member Author

tbzatek commented Jan 9, 2022

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:

... in case systemd-udevd is still processing the device the tool will wait for it to finish.

@tbzatek tbzatek force-pushed the part-locking branch 2 times, most recently from 4a11af0 to 6514f0d Compare January 9, 2022 14:14
self.udev_settle()
time.sleep(5)
device.Format('empty', d, dbus_interface=self.iface_prefix + '.Block')
pass
Copy link
Member

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.

Copy link
Member

@vojtechtrefny vojtechtrefny left a 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.

@tbzatek tbzatek marked this pull request as draft July 22, 2022 12:07
@tbzatek tbzatek changed the title Partitioning locking and refactoring WIP: Partitioning locking and refactoring Sep 8, 2022
@tbzatek tbzatek force-pushed the part-locking branch 2 times, most recently from a7feb6e to f059859 Compare October 18, 2022 14:53
tbzatek added a commit to tbzatek/udisks that referenced this pull request Nov 4, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants