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 <mch...@suse.com>
Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com> Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
