Re: [PATCH] lvm: add lvm cache logical volume handling

[Michael Chang]

On Thu, Oct 24, 2019 at 05:21:04PM +0200, Daniel Kiper wrote:
> On Thu, Oct 24, 2019 at 04:43:58AM +0000, Michael Chang wrote:
> > On Wed, Oct 23, 2019 at 12:48:23PM +0200, Daniel Kiper wrote:
> > > On Wed, Oct 16, 2019 at 06:15:30AM +0000, 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 go
> > > > 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, IMHO 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.
> > >
> > > Is it possible to enforce all GRUB writes to the original device instead
> > > of cache during installation process?
> >
> > I couldn't give concrete answer whether it is possible, but it sounds to
> > me not good idea because in general bypassing the cache could
> > potentially break the consistency of data and the data being cached.
> >
> > Perhaps some system calls could help to sync the data out of the lvm
> > cache to the original LV during installation process. It seems fsync
> > does it for us, but I didn't have good idea either if it is enough.
> 
> May I ask you to investigate that and if it is needed add required
> install code. I mean fsync(), etc.

As far as what I learned, the fsync did not write back dirty cache to
the orginal device, instead it would update associated cache metadata to
complete the write transaction with the cache device and then having the
write cache up to date. Without the operation, metadata is commited
every second and data would be completely lost/evaporated if power
failure happened in between. 

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. Instead 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, it seems no way to enforce all grub writes to the
original device. That means grub may suffer from power failure that
leads to dirty cache not being flushed and is inept reading data flagged
as dirty in cache. But even though, as long as such case is only
subjected to writeback mode that is generally difficult to deal with
data lost whenever accident comes up, I'd still like to propose my
(relatively simple) patch and treat reading dirty data in cache as an
enhancement to be more resilience to potential data loss.

Thanks,
Michael

> 
> Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel