samba - Dec 2012 - Difference between real and reported disk usage

(I'm not subscribed to the list: please keep me in CC)

I'm copying files between two samba server using robocopy from a third 
Windows PC and i'm experiencing disk usage that is much higher on the 
destination PC.

The origin samba server is Debian Lenny with samba 3.2.5.
The destination samba server is Debian Wheezy with samba 3.6.9
The PC running robocopy is Windows Server 2003 with robocopy XP026.

I'm copying from //gam/c$ to //gam2/c$. Either source and destination 
shares are mounted on /smbshare on the corresponding PCs, ext3 the 
former and ext4 the latter.

 From gam (the source):
--------------------------
# du -s -h /smbshare/
45G     /smbshare/
# du -s -h --apparent-size /smbshare/
45G     /smbshare/
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              129G   45G   78G  37% /smbshare
--------------------------

And now gam2 (the destination):
--------------------------
# du -s -h /smbshare/
123G    /smbshare/
# du -s -h --apparent-size /smbshare/
45G     /smbshare/
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              210G  123G   77G  62% /smbshare
--------------------------

Reading the destination share size with Windows, i obtain the same size 
of the origin share, which is the same as reported by "du -s -h 
--apparent-size" on the destination. But the real filesystem usage is 
much more, as you can see.

This is the /etc/samba/smb.conf of the destination PC:
[global]
     security = DOMAIN
     workgroup = BERNI
     log file = /var/log/samba/samba-berni.log
     idmap config * : backend = rid
     idmap config * : range = 1000000-1999999
     invalid users = root
     admin users = "+berni\domain admins"
     create mask = 0664
     directory mask = 0771
     vfs object = acl_xattr
     inherit owner = Yes
     hide special files = Yes
     veto files = /lost+found/
     map archive = No
     map readonly = No
     map hidden = No
     map system = No
     store dos attributes = Yes
     strict allocate = yes
     usershare path      restrict anonymous = 2
[c$]
     path = /smbshare
     read only = No

 From dumpe2fs, these are the filesystem features of the destination PC:
Filesystem features:      has_journal ext_attr resize_inode dir_index
                           filetype needs_recovery extent flex_bg
                           sparse_super large_file huge_file uninit_bg
                           dir_nlink extra_isize
Default mount options:    user_xattr acl


What do you think?

Cesare.

Berni CED <ced <at> bernispa.com> writes:
>      strict allocate = yes
I've retried commenting out this line and repeating the entire copy with
robocopy: now the disk usage corresponds to the one reported by Windows and by
"du -s -h --apparent-size".
Are there any technical reason for that? Should i file a bug?

I have an ext4 filesystem and from the smb.conf man page "strict allocate =
yes"
looks like a recommended setup.

Cesare.