1 Dec 2006 04:55
Re: File fragmentation
Matt McCutchen <hashproduct+rsync <at> gmail.com>
2006-12-01 03:55:24 GMT
2006-12-01 03:55:24 GMT
On 9/5/06, Matt McCutchen <hashproduct+rsync <at> gmail.com> wrote: > There are, however, two things about the preallocate patch that I mean > to revisit: > (1) Rsync should preallocate locally copied files (e.g., due to > --copy-dest) as well as transferred ones. > (2) posix_fallocate actually extends the file with logical zeros. If > for some reason the file ends up being shorter than rsync expected, > rsync needs to truncate the file to the new size. I know this > situation could arise if a file shrinks while it is being locally > copied; I don't know whether it can arise if a source file shrinks > while the sender is transferring it. I have improved the preallocation patch to handle #1 and #2. The improved version is attached. Please test and comment! Wayne, please consider adding the patch to patches/ of the rsync source code. On 8/26/06, Wayne Davison <wayned <at> samba.org> wrote: > I'm wondering if this will slow down rsync. Since the function changes > the size of the file before rsync writes out the data, does this result > in extra disk I/O, especially for large files? We'd probably need to > test both Windows systems and Linux/unix systems separately and possibly > conditionalize the code (it it does not slow things down somewhere) or > make it a configure (command-line?) option (if someone wants to pay the > price for reduced fragmentation). I did a simple test with a 100MB file on Linux, and preallocation indeed seemed to slow rsync down. I looked at the strace, and posix_fallocate appears to be implemented by writing a zero byte into each needed disk block using pwrite, forcing it to be allocated. Yuck! I guess it works though.(Continue reading)
RSS Feed