Fragmentation on XFS

[Rob Bosch]

>For a meaningful test, you should actually write 77GB of data into a new
>file and an ftruncated file and see if there's any difference in the
>resulting fragmentation.
>
>In your patch, you should use fallocate in place of ftruncate.  If your
>glibc is like mine and doesn't provide direct access to fallocate,
>you'll have to use syscall and __NR_fallocate .
>
>Matt

I ran these tests with these results... I couldn't get fallocate function to
work since my kernel doesn't support it.  

Destination file on Ext3
	- ftruncate, 123MB file, Execution time 25 secs, 62 extents
	- posix_fallocate, 123MB file, Execution time 11 secs, 53 extents

Destination file on XFS
	- ftruncate, 123MB file, Execution time 11 secs, 1 extents
	- posix_fallocate, 123MB file, Execution time 10 secs, 1 extents
	- without preallocate, 123MB file, Execution time 14 secs, 1 extents
	- ftruncate, 59GB file, Execution time 52776 secs, 1235 extents
	- posix_fallocate, 59GB file, Execution time 53919 secs, 11 extents

The tests were run using a single file first rsync'd to the destination and
then using rsync to send the file again.  The source and destination are the
same so I used the -I option to force a sync.  The tests seem to show the
ftruncate doesn't do anything to avoid fragmentation as you pointed out.
The posix_fallcoate also doesn't seem to have an impact on overall runtime.
You're patch to use fallocate if available seems like the best way to go,
nice work!

The odd thing is that a huge amount of the file was resent again even though
the files are identical at the source and destination.  Here are the stats
on the transfer:

rsync[7752] (sender) heap statistics:
  arena:         655360   (bytes from sbrk)
  ordblks:            3   (chunks not in use)
  smblks:             0
  hblks:              0   (chunks from mmap)
  hblkhd:        655360   (bytes from mmap)
  allmem:       1310720   (bytes from sbrk + mmap)
  usmblks:     20250624
  fsmblks:            0
  uordblks:     1238408   (bytes used)
  fordblks:       72312   (bytes free)
  keepcost:       62248   (bytes in releasable chunk)

Number of files: 1
Number of files transferred: 1
Total file size: 60381007872 bytes
Total transferred file size: 60381007872 bytes
Literal data: 52482277376 bytes
Matched data: 7898730496 bytes
File list size: 44
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 38928961023
Total bytes received: 3685406

sent 38928961023 bytes  received 3685406 bytes  722051.33 bytes/sec
total size is 60381007872  speedup is 1.55

Both the ftruncate and posix_fallocate runs have exactly the same stats
which makes sense.  Resending 38GB of the data doesn't make sense.

Rob