Dne 03. 02. 22 v 1:23 Demi Marie Obenour napsal(a):
On Wed, Feb 02, 2022 at 11:04:37AM +0100, Zdenek Kabelac wrote:
Dne 02. 02. 22 v 3:09 Demi Marie Obenour napsal(a):
On Sun, Jan 30, 2022 at 06:43:13PM +0100, Zdenek Kabelac wrote:
Dne 30. 01. 22 v 17:45 Demi Marie Obenour napsal(a):
On Sun, Jan 30, 2022 at 11:52:52AM +0100, Zdenek Kabelac wrote:
Dne 30. 01. 22 v 1:32 Demi Marie Obenour napsal(a):
On Sat, Jan 29, 2022 at 10:32:52PM +0100, Zdenek Kabelac wrote:
Dne 29. 01. 22 v 21:34 Demi Marie Obenour napsal(a):
Ensuring all steps in state-machine are always correct is not exactly simple.
But since I've not heard about off-by-one problem for a long while - I
believe we've managed to close all the holes and bugs in double-commit
system
and metadata handling by thin-pool and lvm2.... (for recent lvm2 & kernel)
How recent are you talking about? Are there fixes that can be
cherry-picked? I somewhat recently triggered this issue on a test
machine, so I would like to know.
I'd avoid cherry-picking unless you have deep knowledge about all connections
between patches.
Always use the latest released kernel for your comments whether things are
slow or fast.
Here you are missing the core of problem from kernel POV aka
how the memory allocation is working and what are the approximation in
kernel with buffer handling and so on.
So whoever is using 'loop' devices in production systems in the way
described above has never really tested any corner case logic....
In Qubes OS the loop device is always passed through to a VM or used as
the base device for an old-style device-mapper snapshot. It is never
mounted on the host. Are there known problems with either of these
configurations?
Inefficient design - you should prefer to pass devices directly.
AKA you might have some benefits at creation times, but overall performance of
VM will be lower during its actual usage... pick your poison...
Especially if the backend is made by NVMe - any layer adds tremendous amount
of latencies (and in fact DM alone is also noticeable)...
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
