[Libguestfs] [PATCH nbdkit] plugins: file: More standard cache mode names

[Richard W.M. Jones]

On Sun, Aug 09, 2020 at 01:28:58AM +0300, Nir Soffer wrote:
> On Sun, Aug 9, 2020 at 12:28 AM Richard W.M. Jones <rjones at redhat.com> wrote:
> >
> > On Sat, Aug 08, 2020 at 01:24:02AM +0300, Nir Soffer wrote:
> > > The new cache=none mode is misleading since it does not avoid usage of
> > > the page cache. When using shared storage, we may get stale data from
> > > the page cache. When writing, we flush after every write which is
> > > inefficient and unneeded.
> > >
> >
> > Hmm.  This isn't actually what the cache=none parameter is currently
> > doing.
> >
> > cache=none evicts pages from the cache "soon" after they are last
> > needed by the plugin, whether that is for read or write.  It's true
> > that it does not completely avoid the page cache (so I agree it's not
> > precisely like O_DIRECT), but it tries to minimize the time that pages
> > spend there.
> 
> Yes, for this we flush after every write, and the common name for this
> is writethrough.
> 
> > > Rename the cache modes to:
> > > - writeback - write complete when the system call returned, and the data
> > >   was copied to the page cache.
> > > - writethrough - write completes when the data reach storage. read marks
> > >   pages as not needed to minimize use of the page cache.
> >
> > I'm not convinced that writethrough is the same as cache=none.  In
> > qemu it only applies to writes, and says nothing about reads AFAIK.
> > Where do you get the information that writethrough (in qemu, or
> > anywhere else) marks pages as not needed if they are only read and
> > never written?
> 
> qemu does not use DONTNEED, but otherwise current cache=none
> is what qemu and LIO call writethrough.
> 
> Using a cache and evicting the pages does not make much sense, since
> when reading the pages are not in the cache. So why do you use the cache?

It's a modification of the technique recommended by Linus.  It avoids
using O_DIRECT which complicates the server as well as pushing
unknowable complexity to all clients.  Note your original patch using
memalign to allocate the buffer in the server doesn't work if you
consider filters.

> I think we are mixing different things in the current code. Flushing
> after every write is almost never needed, but if needed it should be
> possible to use it without fadvice=DONTNEED to keep a useful cache
> when reading.

You shouldn't use cache=none if you need the cache afterwards
(obviously from the name, but also how this feature is documented).

> I think the DONTNEED flag should be separate from
> cache=writesthrough. In dd this can be done using iflag=nocache or
> oflag=nocache, and syncing after every write can be done using
> oflag=dsync/sync. If you want both you can use oflag=nocache,dsync.
>
> > I'm not convinced by this change.
> 
> cache=none should mean no cache, and it should not require syncing after
> every write. What we have now is not useful.

I disagree!  It avoids evicting other pages from the page cache, so
it's a useful feature.

> It could be useful if the kernel was doing smarter flushing when
> using DONTNEED, for example flushing the data asynchronically every
> few seconds, instead of writing gigabytes of data at once.

The kernel could be smarter.  I don't understand what you mean by
"writing gigabytes of data at once".

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW