Il 2023-03-02 19:33 Roger Heflin ha scritto:
On Thu, Mar 2, 2023 at 11:44 AM Gionatan Danti <g.danti@xxxxxxxxxx>
wrote:
It is a 100G cache over 16TB, so even if it flushes in order the may
not be that close to each other (1 in 160).
Yes, but destaging in LBA order (albeit far apart) is much better than
in random order.
Also if pieces are decided and added to the cached then the cache is
not in order on the ssd and proper coalescing would require reading
the entire cache and sorting the 3,000,000 location entries before
starting the de-stage. And that complication of a de-stage is likely
not been coded yet if I was just guessing, the de-stage starts at the
beginning and continues to the end of the cache.
I would expect reordering and coalescing to happen in reasonably sized
window (ie: collect 64 MB of data, reorder and flush them). At the same
time, considering how lvmcache works, you are probably right: cached
chunks are going to be flushed as discovered (random order).
Even coded though, if the you have enough blocks cached and if the
blocks spread say one or 2 on each track it would break down to having
to write a tiny bit on each track with seeks between mostly breaking
down to the time required to simply read/write the HD end to end. At
150MB/sec (should be about the platter speed) that would take 3.5
hours.
Which (apart being a totally worst outcome) would be way better than
what required for totally random IO.
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
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/
