[storaged] Mount points etc

[Marius Vollmer]

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?

[Stef Walter]

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

[Tomas Bzatek]

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