Alexander V. Nikolaev

Would be nice to implement `archive` endpoint. https://docs.docker.com/engine/reference/api/docker_remote_api_v1.24/#/get-an-archive-of-a-filesystem-resource-in-a-container https://docs.docker.com/engine/reference/api/docker_remote_api_v1.24/#/extract-an-archive-of-files-or-folders-to-a-directory-in-a-container PS I'd like to try implement it myself, but possible need little guiding/hinting

Most of lvm subcommands have direct links in bin/ like `lvcreate`, `lvs`, etc. We use them mainly by historic reason (because lvm.* is reimplementation some early python code in golang)....

subsequent calls to fake.Read("lvs") shoud return different values, after fake.Run("vgcreate") call. Current implementation with bool flag inside FakeLVM, looks very kludgy

Now we have few own wrappers on exec.Command() inside resource/lvm/lowlevel, resource/shell, and resource/user. Would be nice to refactor it to common, easy mockable thin wrapper, with well defined behaviour, disticnction...

Sometimes we want to show some debug (like command execution/some output) but our module executed on server side, and logs invisible for user. In some cases code like ``` status...

We need to use proper systemd escaping, now only "/" replaced with "-", and trailing/leading "/" stripped.

`mountpoint -x ` and `mountpoint -d` should have some data enough to query device path from system, and compare with requested one.

It should exists, be a directory, and have proper permissions.

In some cases LVM treat case suffix specially: ```Capitalise to use multiples of 1000 (S.I.) instead of 1024. Can also specify custom units e.g. --units 3M```` Also special `Ss` suffix...