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

Query size of device using devpath rather than devname - also enables more logging on error #144

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

ogayot
Copy link
Member

@ogayot ogayot commented Apr 25, 2024

In LP:#2063433 and private reports associated to it, we observe that sometimes, accessing /sys/class/block/<devname>/size fails with FileNotFoundError.

It isn't easy to determine whether the size file does not exist or the parent directory itself.

We now rely on a new way to retrieve the size, using the devpath instead of the devname. Hopefully, the devpath should always exist in sysfs if udev says so?

As for errors, we will now try to list the files from the parent directory when a FileNotFoundException is found as the result of the new function.

The existing read_sys_block_size_bytes functions forces us to guess
where to find a given device in the /sys/class/block hierarchy. While
most of the time, /sys/class/block/<device>/size seems to be the right
place to look, there have been reports of the file missing.

We now provide another way to read the size using the DEVPATH udev
variable instead. Hopefully, this should be a more accurate way to find
the information we are looking for.

Signed-off-by: Olivier Gayot <[email protected]>
If read_sys_devpath_size_bytes fails with ENOENT, we want to know
whether it's the directory that does not exist of the file named "size".

If the caller requests it, on error we now list the files contained in
the /sys/<devpath> directory.

If the directory does not exist, we will have a nested
FileNotFoundError exception.

Signed-off-by: Olivier Gayot <[email protected]>
This also enabled logging so we can figure out whether the directory or
the file does not exist.

Signed-off-by: Olivier Gayot <[email protected]>
@ogayot
Copy link
Member Author

ogayot commented Apr 25, 2024

Looks like it requires #145 (or I can simply revisit the type hints to use Union)

@mwhudson
Copy link
Collaborator

Isn't it at least possible this is the race condition where udev processing a block device causes the device nodes for the devices partitions to disappear briefly? In that case I'd expect the devpath-based path to be missing too.

Do we understand / remember why storage.py:blockdev_probe doesn't just look at the size attribute from udev? (it might give strange results for extended partitions perhaps?)

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