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

[Michael Chang]

On Mon, Nov 18, 2019 at 01:09:23PM +0100, Daniel Kiper wrote:
> On Mon, Nov 18, 2019 at 08:05:22AM +0000, Michael Chang wrote:
> > 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.
> 
> I would like to see more or less this description in the commit message.
> And I think that you should add similar paragraph to the GRUB manual too.

OK. I will add description to the commit message and manual in next
version sent here for review.

Regards,
Michael

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