[vdo-devel] vdo 8.1.x - any documentation?

[Gionatan Danti]

Il 2022-02-01 15:49 Andrew Walsh ha scritto:
> Please don't apologize!  I have had this question in my inbox, but it
> keeps slipping further down the page.  I apologize for that.

Hi Andrew, thank you for the kind reply. I really appreciate it.

> Currently, the LVMVDO implementation is limited to a single logical
> volume atop the VDO storage.  With that in mind, the same kind of
> workaround can be achieved, assuming you enable scan_lvs.  It makes
> for a slightly complicated looking output from `lsblk`, but it is
> achievable like it was in the past.  It can become complicated pretty
> quickly, so it must be very carefully deployed.
> 
> Here is an example of a process I followed to create this on a test
> machine that I would probably never end up using in production for
> various reasons (such as using a loopback device), but displays the
> steps needed.
> ...

Ok, so basically I need to nest multiple LVM. Quite doable for simple 
stack, somewhat more difficult (but bearable) for more convoluted ones.

> Would you mind sharing what you like to use this stack for?  It would
> be great to know how people are leveraging VDO out in the public.

My main use case (testing only, for now) would be to use a single LVMVDO 
as backend for a thinpool with multiple thin volumes and snapshots. In 
previous testbed, the vdo utility provided a simple and effective method 
to create and control the VDO volume. I wondered how to do the same with 
LVMVDO and I skipped the nested-LVM case, but I remember the 
thinpool-over-VDO to be fully supported in previous RHEL.

At the same time the VDO+thinpool combo seems somewhat discouraged on 
the LVM mailing list, mainly on error recovery grounds if/when ENOSP 
hits.

Can I ask what are the current recommendations about VDO and thinlvm?
Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8