[dm-devel] Thin pool CoW latency

[dm-devel] Thin pool CoW latency

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Like Eric, I am very concerned about CoW latency and throughput.  I
am almost certain that allocating new blocks and snapshot copy-on-write
are _the_ hot paths in Qubes OS.  In particular, I suspect that
workloads such as building an image in a throwaway VM or installing
packages onto a root volume that had just been shapshotted are dominated
by metadata operations, rather than by in-place updates.  I suspect that
frequently-snapshotted volumes will observe similar behavior in general.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmQE/iEACgkQsoi1X/+c
IsHLFxAAyWT4SlSueR15VxrwG07T9cEl7vnQwKHKWdzFBoWl0KhvyjLr52t0ip1J
HPmwTVaor+53E+0bLUlgqA7G56a6PwxWWAQ6CsHHdxQ1xo3Serigkhys2hmwRq+e
WPVrDSVRQLzOj/Qg6MsF2PPzdL5aNjK2QeHnWVcyXvfwZDhDCJKzz2iJC/ENjFNW
X2bD3wazu6A+aFsxjLHtf5wAa0+PhppcEhUZNSgQiC9SiT5DPFabLIIi7jgb0Nlg
v5GciAp1w0J+SUq2Wh4atrPR11Sj878AnJ872/Ku+pLseVu8h7N/60p8OwBm47Ak
GNZlgq7XF1lien/3eFq9mfJKGc97MxveEkiqI46ankVs+bDQOlUbXriMlINEeT8r
AzCar8pYx5W/xFb/gvYPnksATlOxLAaQ1jPZ1j0dIRaPtoOngtQ64TC5alRirGCK
uqQ7c1Soj7D3SjahrbQkoqcyODmRoC/55Pu8Klb2l96S91rSRtvca+EV05GNXmyN
eaArdGNuWPmzq6E8mQj3YrYnn18Z/x3WRr77xGVTAjUCGDPCE01+o/0G9P/+4cpv
olMs1/ludL/WzbBe9scp2JK442dGwE/pcBiWI34DmxbLZTb1baG4BEX6mbDdfnpk
SmIQv1RcHtbf16nvuhg+QVXnjAL5qQNiGVWxF9PTH8799wmcsdM=
=/KY9
-----END PGP SIGNATURE-----

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

Thin pool CoW latency

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Like Eric, I am very concerned about CoW latency and throughput.  I
am almost certain that allocating new blocks and snapshot copy-on-write
are _the_ hot paths in Qubes OS.  In particular, I suspect that
workloads such as building an image in a throwaway VM or installing
packages onto a root volume that had just been shapshotted are dominated
by metadata operations, rather than by in-place updates.  I suspect that
frequently-snapshotted volumes will observe similar behavior in general.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmQE/iEACgkQsoi1X/+c
IsHLFxAAyWT4SlSueR15VxrwG07T9cEl7vnQwKHKWdzFBoWl0KhvyjLr52t0ip1J
HPmwTVaor+53E+0bLUlgqA7G56a6PwxWWAQ6CsHHdxQ1xo3Serigkhys2hmwRq+e
WPVrDSVRQLzOj/Qg6MsF2PPzdL5aNjK2QeHnWVcyXvfwZDhDCJKzz2iJC/ENjFNW
X2bD3wazu6A+aFsxjLHtf5wAa0+PhppcEhUZNSgQiC9SiT5DPFabLIIi7jgb0Nlg
v5GciAp1w0J+SUq2Wh4atrPR11Sj878AnJ872/Ku+pLseVu8h7N/60p8OwBm47Ak
GNZlgq7XF1lien/3eFq9mfJKGc97MxveEkiqI46ankVs+bDQOlUbXriMlINEeT8r
AzCar8pYx5W/xFb/gvYPnksATlOxLAaQ1jPZ1j0dIRaPtoOngtQ64TC5alRirGCK
uqQ7c1Soj7D3SjahrbQkoqcyODmRoC/55Pu8Klb2l96S91rSRtvca+EV05GNXmyN
eaArdGNuWPmzq6E8mQj3YrYnn18Z/x3WRr77xGVTAjUCGDPCE01+o/0G9P/+4cpv
olMs1/ludL/WzbBe9scp2JK442dGwE/pcBiWI34DmxbLZTb1baG4BEX6mbDdfnpk
SmIQv1RcHtbf16nvuhg+QVXnjAL5qQNiGVWxF9PTH8799wmcsdM=
=/KY9
-----END PGP SIGNATURE-----

Re: [dm-devel] Thin pool CoW latency

[Joe Thornber]

[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]

On Sun, Mar 5, 2023 at 8:40 PM Demi Marie Obenour <
demi@invisiblethingslab.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Like Eric, I am very concerned about CoW latency and throughput.  I
> am almost certain that allocating new blocks and snapshot copy-on-write
> are _the_ hot paths in Qubes OS.  In particular, I suspect that
> workloads such as building an image in a throwaway VM or installing
> packages onto a root volume that had just been shapshotted are dominated
> by metadata operations, rather than by in-place updates.  I suspect that
> frequently-snapshotted volumes will observe similar behavior in general.
>
>
Yes, provisioning and breaking sharing are relatively slow operations.  As
discussed with Eric
I'm not intending to change how either of these operations is implemented.
If the performance
profile is not suitable for your application your company can either do
some work to improve it yourselves, or
select a different solution.

- Joe

[-- Attachment #1.2: Type: text/html, Size: 1449 bytes --]

[-- Attachment #2: Type: text/plain, Size: 98 bytes --]

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel