f3ffcfe9ba
Commit https://github.com/QubesOS/qubes-linux-utils/commit/c1d42f1 --
"qfile-unpacker: do not call fdatasync() at each file" fixing
QubesOS/qubes-issues#1257 -- increased the chance of data loss with
qvm-move-to-vm: Say it nominally succeeds, and *deletes* the files from
the source VM. Soon after, the destination VM or the system could crash,
or an external drive hosting ~/QubesIncoming/srcVM could get unplugged
by accident, all before the data had really been persisted to disk.
But reverting the commit (ignoring the performance issue) wouldn't
completely solve this:
"Calling fsync() does not necessarily ensure that the entry in the
directory containing the file has also reached disk. For that an
explicit fsync() on a file descriptor for the directory is also
needed." - fsync(2)
It gets even worse for "slow symlinks" (whose target is too long to be
stored directly in the inode metadata), apparently they can't be synced
at all individually.
So instead, just call syncfs() once after everything has been unpacked:
+ Should prevent all data loss (if fs and disk are well behaved)
+ Allows caching and reordering -> no slowdown with many small files
- Blocks until any unrelated writes on the filesystem finish :\
(cherry picked from commit
|
||
---|---|---|
.. | ||
buffer.c | ||
copy-file.c | ||
crc32.c | ||
crc32.h | ||
exec.c | ||
ioall.c | ||
ioall.h | ||
libqrexec-utils.h | ||
libqubes-rpc-filecopy.h | ||
Makefile | ||
qrexec.h | ||
txrx-vchan.c | ||
unix-server.c | ||
unpack.c | ||
write-stdin.c |