Use fsync()/fdatasync() to prevent possible data corruption

[socketpair]

No description provided.

[joachimmetz]

Can you be more descriptive what possible corruption, where?

If you want things to get addressed you'll have to be more descriptive and explain what and why you want things changed.

[joachimmetz]

Also how portable are fsync()/fdatasync()?

[socketpair]

Simple scenario:

1. write some data to qcow2 file. program complete.
2. powerfail.
3. power-on
4. image is corrupted.

The same may happen during internal qcow2 data manipulation. You should understand that any incomplete write (not acknowledged by fsync() or fadasync()) may corrupt image. So, you should fdatasync() opened file descriptor at appropriate time. and maybe change data manipulation agorithms in a way that incomplete write never corrupt them.

For example, qemu-img never corrupts image structure. And if write operations in it is complete, data is really permanent.

[socketpair]

fdatasync:

Conforming To
4.3BSD, POSIX.1-2001.

[socketpair]

Also, we need an option to inhibit fsyncing like qemu-img's cache=unsafe. And fdatasync only at image closing. (or even never)

[joachimmetz]

https://www.humboldt.co.uk/fsync-across-platforms/

write some data to qcow2 file. program complete.

Libqcow does not write images at this point in time.

[socketpair]

Much better would be implementing of all caching modes of qemu - i.e. write-back, write-through, unsafe, none, directsync. Don't know if it is possible to work with qcow2 file in O_DIRECT mode, since it requires all IO to be page-aligned.

[socketpair]

O! sorry, I did not know that libqcow2 is read-only. Just started to do experiments (and read really works).

[joachimmetz]

Thx for the suggestion. I close this issue for now and revisit if/when write is added.