<div dir="ltr">
<div>I believe that the changes to support --preallocate and --sparse
together have broken --preallocate by itself (commit
f3873b3d88b61167b106e7b9227a20147f8f6197)<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div class="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-yj6qo gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-ajU"><div id="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-:1dd" class="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-ajR"><img class="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-ajT gmail-m_5721543457868330663gmail-CToWUd gmail-CToWUd" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div>
<div>in syscall.c in appears maybe there is a logic error (that should be bitwise-OR, not logical-OR):</div><div><br></div><div><br></div><div>OFF_T do_fallocate(int fd, OFF_T offset, OFF_T length)<br>{<br> int opts = inplace || preallocate_files ? 0 : DO_FALLOC_OPTIONS;</div>
<div><div dir="ltr" class="gmail-m_5721543457868330663gmail_signature"><br></div></div>
<div><br></div><div><br></div><div><br></div></div>