grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/2] lvm: add lvm cache logical volume handling


From: Daniel Kiper
Subject: Re: [PATCH v4 1/2] lvm: add lvm cache logical volume handling
Date: Fri, 27 Mar 2020 16:56:16 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Mar 19, 2020 at 01:56:13PM +0800, Michael Chang wrote:
> The lvm cache logical volume is the logical volume consisting of the original
> and the cache pool logical volume. The original is usually on a larger and
> slower storage device while the cache pool is on a smaller and faster one. The
> performance of the original volume can be improved by storing the frequently
> used data on the cache pool to utilize the greater performance of faster
> device.
>
> The default cache mode "writethrough" ensures that any data written will be
> stored both in the cache and on the origin LV, therefore grub can be straight
> to read the original lv as no data loss is guarenteed.
>
> The second cache mode is "writeback", which delays writing from the cache pool
> back to the origin LV to have increased performance. The drawback is potential
> data loss if losing the associated cache device.
>
> During the boot time grub reads the LVM offline i.e. LVM volumes are not
> activated and mounted, hence it should be fine to read directly from original
> lv since all cached data should have been flushed back in the process of 
> taking
> it offline.
>
> It is also not much helpful to the situation by adding fsync calls to the
> install code. The fsync did not force to write back dirty cache to the 
> original
> device and rather it would update associated cache metadata to complete the
> write transaction with the cache device. IOW the writes to cached blocks still
> go only to the cache device.
>
> To write back dirty cache, as lvm cache did not support dirty cache flush per
> block range, there'no way to do it for file. On the other hand the "cleaner"
> policy is implemented and can be used to write back "all" dirty blocks in a
> cache, which effectively drain all dirty cache gradually to attain and last in
> the "clean" state, which can be useful for shrinking or decommissioning a
> cache. The result and effect is not what we are looking for here.
>
> In conclusion, as it seems no way to enforce file writes to the original
> device, grub may suffer from power failure as it cannot assemble the cache
> device and read the dirty data from it. However since the case is only
> applicable to writeback mode which is sensitive to data lost in nature, I'd
> still like to propose my (relatively simple) patch and treat reading dirty
> cache as improvement.
>
> Signed-off-by: Michael Chang <address@hidden>

Reviewed-by: Daniel Kiper <address@hidden>

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]