<div>You are spot-on!</div><div><br></div><div>After clearing the non-dirty cache I get the correct filesize with du -hs</div><div><br></div><div>I will add the fstab option you suggested to my NFS server's fstab</div>

<div><br></div><div>Thank you!<br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 1:04 PM, Matthias Schniedermeyer <span dir="ltr"><<a href="mailto:ms@citd.de" target="_blank">ms@citd.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On 05.02.2013 12:32, <a href="mailto:milos.kaurin@gmail.com">milos.kaurin@gmail.com</a> wrote:<br>
> I have a script that syncs my backups to an NFS mount every day<br>
><br>
> The script works fine, without any errors, but there is a problem when<br>
> it comes to some large files<br>
><br>
> Let's take my pst file (8.9 gig) as an example<br>
><br>
> Source:<br>
><br>
> du -hs mypst.pst<br>
> 8.9G    mypst.pst<br>
> ls -alh mypst.pst<br>
> -rw-rw---- 1 me me 8.9G Jan 25 17:07 mypst.pst<br>
><br>
> That seems OK<br>
><br>
><br>
> Let's do that on the destination:<br>
><br>
> du -hs mypst.pst<br>
> 17G     mypst.pst<br>
> ls -alh mypst.pst<br>
> -rw-rw---- 1 root root 8.9G Jan 25 17:07 mypst.pst  # Permissions here  are<br>
> fine, disregard<br>
><br>
><br>
> Real file size is almost double size!<br>
><br>
><br>
> Extra info:<br>
><br>
> Source dir is an xfs partition<br>
> The NFS mount is also xfs on the NFS server<br>
> NFSv4<br>
><br>
> Full cmdline for the daily backup:<br>
> /usr/bin/rsync -rltgoD --no-perms --no-owner --no-group --delete <src><br>
> <dest><br>
><br>
> For the testing purposes, I've tried doing:<br>
> rsync /srcdir/mypst.pst /nfsmount/mypst.pst<br>
> and the result is the same: du reports 17 gigs, and ls -alh reports 8.9<br>
><br>
> Is there any way around this?<br>
<br>
</div></div>This is a feature of XFS called "speculative preallocation". If you<br>
open/append/close a file repeatetly XFS preallocates space in<br>
anticipation of more appends, the feature helps to prevent or at least<br>
reduce fragmentation.<br>
<br>
You can see the extents of a file with xfs_bmap.<br>
<br>
You can get rid of the preallocation in several ways:<br>
- Trash your buffer-cache with unreleated things<br>
  (The prellocation gets dropped when the inode of the file is evicted<br>
from cache)<br>
- umount/mount cycle<br>
- Drop whole cache, as root:<br>
echo 3 > /proc/sys/vm/drop_caches<br>
This drops the whole non-dirty cache of Linux!<br>
<br>
There was talk on the maillinglist to drop preallocations after some<br>
time (like 5 minutes), but AFAIR there weren't patches. So IFF that is<br>
implemented that means kernel 3.9 or later at the earliest.<br>
<br>
If you don't want speculative preallocation you can disable it with the<br>
mount-option allocsize. e.g. "allocsize=4k"<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
--<br>
<br>
Matthias<br>
</font></span></blockquote></div><br></div>