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

RFE: Native daemon #76

Open
DemiMarie opened this issue Mar 31, 2022 · 1 comment
Open

RFE: Native daemon #76

DemiMarie opened this issue Mar 31, 2022 · 1 comment

Comments

@DemiMarie
Copy link

This is an RFE for a persistent lvm2 daemon that would take care of actually performing lvm2 operations. The existing lvm2 commands would be changed to perform IPC calls to the daemon, instead of performing the operations themselves.

This has several advantages over the current situation:

  • The lvm2 commands no longer need to run in a constrained environment. They don’t have to lock memory, run while some devices are suspended, or preallocate memory to avoid deadlocks. This makes an lvm2 library feasible.
  • The lvm2 commands are now stateless. Therefore, they can safely be run in a container without risk of metadata corruption due to locking problems.

It also offers many opportunities for future enhancements:

  • The daemon can perform access control and permission checking. For instance, one might want any user in the adm group to be able to list LVs, but only allow the superuser to modify anything.
  • When clustering is disabled, the daemon can keep state in memory, rather than having to reload it from disk every time.
  • A remote management API can be offered via TLS or SSH.
@zkabelac
Copy link

This was always consider as plan B - however this plan B has serious problem - error paths...
So while some sort of 'activation' daemon would have been doing a nice work in the world without errors - as soon as you need to start to solve any failure path on suspend/reload - you are running in big problems - and effectively you end with just 'permanently' running full lvm2 command - which then occupies resources forever (kind of dBus interface idea we had - but due to lack of man power and limited knowledge and somewhat technical difficulties on the whole dBus concept - it's ATM just a 'experimental' project)

Since our team is very small and we are quite loaded with a lot of other work, so I'm afraid, this is one of many other RFEs we currently have in our queue as 'nice-to-have'....

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

No branches or pull requests

2 participants