Re: [Qemu-block] [PATCH for-2.6 v2 0/3] Bug fixes for gluster

[Rik van Riel]

On Wed, 2016-04-20 at 13:46 +0200, Kevin Wolf wrote:
> Am 20.04.2016 um 12:40 hat Ric Wheeler geschrieben:
> > 
> > On 04/20/2016 05:24 AM, Kevin Wolf wrote:
> > > 
> > > Am 20.04.2016 um 03:56 hat Ric Wheeler geschrieben:
> > > > 
> > > > On 04/19/2016 10:09 AM, Jeff Cody wrote:
> > > > > 
> > > > > On Tue, Apr 19, 2016 at 08:18:39AM -0400, Ric Wheeler wrote:
> > > > I still worry that in many non-gluster situations we will have
> > > > permanent data loss here. Specifically, the way the page cache
> > > > works, if we fail to write back cached data *at any time*, a
> > > > future
> > > > fsync() will get a failure.
> > > And this is actually what saves the semantic correctness. If you
> > > threw
> > > away data, any following fsync() must fail. This is of course
> > > inconvenient because you won't be able to resume a VM that is
> > > configured
> > > to stop on errors, and it means some data loss, but it's safe
> > > because we
> > > never tell the guest that the data is on disk when it really
> > > isn't.
> > > 
> > > gluster's behaviour (without resync-failed-syncs-after-fsync set)
> > > is
> > > different, if I understand correctly. It will throw away the data
> > > and
> > > then happily report success on the next fsync() call. And this is
> > > what
> > > causes not only data loss, but corruption.
> > Yes, that makes sense to me - the kernel will remember that it
> > could
> > not write data back from the page cache and the future fsync() will
> > see an error.
> > 
> > > 
> > > 
> > > [ Hm, or having read what's below... Did I misunderstand and
> > > Linux
> > >   returns failure only for a single fsync() and on the next one
> > > it
> > >   returns success again? That would be bad. ]
> > I would need to think through that scenario with the memory
> > management people to see if that could happen.
> Okay, please do. This is the fundamental assumption we make: If an
> fsync() succeeds, *all* successfully completed writes are on disk, no
> matter whether another fsync() failed in between. If they can't be
> written to the disk (e.g. because the data was thrown away), no
> consequent fsync() can succeed any more.
> 

Is that actually desirable behaviour?

What would it take to make fsync succeed again
on that file at any point in the future?

Umount of the filesystem?

Reboot of the whole system?

Restore from backup?