From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Joe Thornber <thornber@redhat.com>
Cc: dm-devel@lists.ewheeler.net, "development,
device-mapper" <dm-devel@redhat.com>,
"Qubes OS Development Mailing List"
<qubes-devel@googlegroups.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Subject: [dm-devel] Thin pool CoW latency
Date: Sun, 5 Mar 2023 15:40:02 -0500 [thread overview]
Message-ID: <ZAT+IoCfuZtRnnhm@itl-email> (raw)
-----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
WARNING: multiple messages have this Message-ID (diff)
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Joe Thornber <thornber@redhat.com>
Cc: "development, device-mapper" <dm-devel@redhat.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Qubes OS Development Mailing List"
<qubes-devel@googlegroups.com>,
dm-devel@lists.ewheeler.net
Subject: Thin pool CoW latency
Date: Sun, 5 Mar 2023 15:40:02 -0500 [thread overview]
Message-ID: <ZAT+IoCfuZtRnnhm@itl-email> (raw)
-----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-----
next reply other threads:[~2023-03-06 6:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-05 20:40 Demi Marie Obenour [this message]
2023-03-05 20:40 ` Thin pool CoW latency Demi Marie Obenour
2023-03-06 9:33 ` [dm-devel] " Joe Thornber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZAT+IoCfuZtRnnhm@itl-email \
--to=demi@invisiblethingslab.com \
--cc=CAJ0trDYAyHHh2crMAQuQPMt3FzFmii0nmLnsL5N-cdhfvWZnMg@mail.gmail.com \
--cc=dm-devel@lists.ewheeler.net \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marmarek@invisiblethingslab.com \
--cc=qubes-devel@googlegroups.com \
--cc=thornber@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.