[linux-lvm] lvconvert --uncache takes hours
g.danti at assyoma.it
Thu Mar 2 20:47:51 UTC 2023
Il 2023-03-02 19:33 Roger Heflin ha scritto:
> On Thu, Mar 2, 2023 at 11:44 AM Gionatan Danti <g.danti at assyoma.it>
> 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
Which (apart being a totally worst outcome) would be way better than
what required for totally random IO.
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8
More information about the linux-lvm