Re: [linux-lvm] lvconvert --uncache takes hours

Il 2023-03-02 19:33 Roger Heflin ha scritto:
> On Thu, Mar 2, 2023 at 11:44 AM Gionatan Danti <[email protected]> 
> 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: [email protected] - [email protected]
GPG public key ID: FF5F32A8

_______________________________________________
linux-lvm mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/