Re: fdatasync semantics and block device backup

[Kevin Wolf]

Am 28.04.2020 um 15:58 hat Bryan S Rosenburg geschrieben:
> Kevin Wolf <address@hidden> wrote on 04/28/2020 07:11:24 AM:
> > I think "don't do that" is a good answer actually.
> > 
> > You may want to put an NBD indirection between QEMU and your object
> > store, so that the close() syscall will just block a qemu-nbd process
> > that has already closed its connection to QEMU instead of blocking all
> > of QEMU.
> > 
> > It is possible to disable fdatasync() by specifying cache=unsafe for
> > the block device, so you could avoid the penalty of repeated syncs on
> > s3fs.
> > 
> > Of course, if s3fs requires an fsync before data is actually stable, in
> > this case you couldn't consider your backup completed when the backup
> > block job finishes successfully, but you would have to issue an fsync
> > manually and wait for its result before you can consider the backup
> > successful.
> > 
> > Kevin
> 
> Thanks, Kevin.
> 
> It sounds like we should be specifying cache=unsafe when using 
> rclone-mount, at least, so qemu won't think the file system is 
> implementing fdatasyncs when it's not.

I don't think it makes a difference in this case. In the end, whether
QEMU throws the fdatasync away or a lower layer does so, the result is
the same.

cache=unsafe would only be to disable fdatasync in cases where it is
very expensive, and with the idea that you later do a (single) fdatasync
manually.

Kevin