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

Do not activate unused LVM volumes #382

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

Conversation

marmarek
Copy link
Member

This prevents udev from accessing not currently used volumes, and also
makes LVM snapshot operations faster (less locking to do).

There is at least one unsolved problem here: inactive volumes do not have
size listed on lvs output. There is a band-aid by caching the usage from
the last time the volume was active, but it isn't enough for many cases (at
the very least - reporting disk usage of a VM that wasn't started
recently).

There may be also other places that assume existing volumes always have
relevant /dev/ node present.

Fixes QubesOS/qubes-issues#6184

'set -e' prevented the cleanup to be called. Register cleanup with
'trap' instead.

Fixes: 76cd08a "Fix test suite"
This prevents udev from accessing not currently used volumes, and also
makes LVM snapshot operations faster (less locking to do).

There is at least one unsolved problem here: inactive volumes do not
have size listed on `lvs` output. There is a band-aid by caching the
usage from the last time the volume was active, but it isn't enough for
many cases (at the very least - reporting disk usage of a VM that wasn't
started recently).

There may be also other places that assume existing volumes always have
relevant /dev/ node present.

Fixes QubesOS/qubes-issues#6184
@DemiMarie
Copy link
Contributor

Is it possible to avoid using the LVM2 CLI and instead invoke a library and/or kernel interface?

@marmarek
Copy link
Member Author

Last time I checked, python bindings to LVM were very limited (including many missing pieces for thin pools). As for using kernel interface directly - I definitely don't want to re-implement myself all the metadata processing, locking, udev synchronization etc. In any case, see QubesOS/qubes-issues#6184 (comment), likely I won't spent any more time on this PR right now.

@DemiMarie
Copy link
Contributor

Last time I checked, python bindings to LVM were very limited (including many missing pieces for thin pools). As for using kernel interface directly - I definitely don't want to re-implement myself all the metadata processing, locking, udev synchronization etc. In any case, see QubesOS/qubes-issues#6184 (comment), likely I won't spent any more time on this PR right now.

Turns out that the Python bindings for LVM2 (and indeed the LVM2 C API) are deprecated! The recommended replacement is the D-Bus API.

@DemiMarie
Copy link
Contributor

Last time I checked, python bindings to LVM were very limited (including many missing pieces for thin pools). As for using kernel interface directly - I definitely don't want to re-implement myself all the metadata processing, locking, udev synchronization etc. In any case, see QubesOS/qubes-issues#6184 (comment), likely I won't spent any more time on this PR right now.

Turns out that the Python bindings for LVM2 (and indeed the LVM2 C API) are deprecated! The recommended replacement is the D-Bus API.

To elaborate: since LVM2 needs to support modifying the device on which it itself is located, it needs to lock all of its memory into RAM at various points. Otherwise, it could deadlock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants