Am 28.04.2020 um 15:58 hat Bryan S Rosenburg geschrieben: > Kevin Wolf <kw...@redhat.com> 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