Hi Tomas,
let's talk a bit about storaged, fstab, mount points, etc. :)
(I have CCed cockpit-devel, is there a better mailing list for storaged?)
Going forward, we would like to remove all storage related code from cockpitd and talk to storaged and udisksd directly from JavaScript. Most of the cockpitd code right now is a boring proxy/merger for storaged and udisksd, but some of it is non-trivial and should be moved into storaged or udisksd.
That code is for cleaning up fstab when wiping/deleting some storage object:
https://github.com/cockpit-project/cockpit/blob/master/src/daemon/storageman...
For example, when deleting a partition, any entry in fstab that refers to it should be removed.
The tricky bit is that we also want to do this for block devices that might not currently exist, such as a stopped mdraid, a inactive logical volume, or a locked encrypted device.
We have some test cases for this, which might help to explain what this is all about:
https://github.com/cockpit-project/cockpit/blob/master/test/check-storage#L8...
Does this fit into your plans for storaged?
On 07.10.2014 09:12, Marius Vollmer wrote:
Hi Tomas,
let's talk a bit about storaged, fstab, mount points, etc. :)
(I have CCed cockpit-devel, is there a better mailing list for storaged?)
Going forward, we would like to remove all storage related code from cockpitd and talk to storaged and udisksd directly from JavaScript. Most of the cockpitd code right now is a boring proxy/merger for storaged and udisksd, but some of it is non-trivial and should be moved into storaged or udisksd.
I like this, but can't help but wonder if there are some actions for which an interrupted WebSocket would leave the system in an invalid state. You know better than I do what these might be.
Stef
Hi Marius,
On Tue, 2014-10-07 at 10:12 +0300, Marius Vollmer wrote:
(I have CCed cockpit-devel, is there a better mailing list for storaged?)
We should be getting David's answer next week, after that depending on the decision we'll hopefully announce the project publicly and create a place to host it.
That code is for cleaning up fstab when wiping/deleting some storage object:
https://github.com/cockpit-project/cockpit/blob/master/src/daemon/storageman...
For example, when deleting a partition, any entry in fstab that refers to it should be removed.
This could live in libudisks2 (or "libstoraged") as it contains other utility functions. I find it useful in some use cases, so why not.
The tricky bit is that we also want to do this for block devices that might not currently exist, such as a stopped mdraid, a inactive logical volume, or a locked encrypted device.
Got your point, but don't have an idea for the moment, without the need to activate the volumes first. One solution would be to use string paths with a danger of not resolving symlinks (alternative paths) and leaving traces behind.
We have some test cases for this, which might help to explain what this is all about:
https://github.com/cockpit-project/cockpit/blob/master/test/check-storage#L8...
Does this fit into your plans for storaged?
Sure, I'll add this to my TODO list, there are other priorities now however.
-- Tomas Bzatek tbzatek@redhat.com
cockpit-devel@lists.fedorahosted.org
-
Marius Vollmer -
Stef Walter -
Tomas Bzatek