preallocate working incorrectly in 3.1.3

TR Reardon trr2104 at columbia.edu
Tue Jan 15 02:10:49 UTC 2019


 I believe that the changes to support --preallocate and --sparse together
have broken --preallocate by itself (commit
f3873b3d88b61167b106e7b9227a20147f8f6197)

The previous behavior of --preallocate was to do just that: reserve blocks
in the filesystem WITHOUT setting the size of the file to the final
length.  The reported filesize would change as the preallocated blocks were
actually written.

Unfortunately, the change causes a whole bunch of problems with our
automated backup, and in particular with --append-verify or --inplace.  The
normal sequence we use in our large-file backup system is to combine
preallocate with append-verify.  When a partially written file is
restarted, it no longer goes through proper verification (with
append-verify).  Worse, if you do only --inplace, then the entire file goes
through verification rather than only the previously-transfered portion.  I
believe this is due to the filesize misrepresenting how much data was
actually written.
in syscall.c in appears maybe there is a logic error (that should be
bitwise-OR, not logical-OR):


OFF_T do_fallocate(int fd, OFF_T offset, OFF_T length)
{
        int opts = inplace || preallocate_files ? 0 : DO_FALLOC_OPTIONS;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20190114/ea6f33b6/attachment.html>


More information about the rsync mailing list