Unix Extension & "du"
jra at samba.org
Thu Sep 16 23:44:45 GMT 2004
On Fri, Sep 17, 2004 at 12:52:46AM +0200, Samuel Thibault wrote:
> When smbmounting some samba-served share and running du on linux with
> smbfs, one gets crazy results:
> $ ls -l file
> -rwxr-xr-x 1 samy thibault 348K 2004-05-12 18:04 file*
> $ du file
> 512M file
> $ stat file
> File: `putty.exe'
> Size: 356352 Blocks: 1048576 IO Block: 4096 fichier
> Device: bh/11d Inode: 80199 Links: 1
> Access: (0755/-rwxr-xr-x) Uid: ( 1000/sthibaul) Gid: ( 101/ vmware)
> Access: 2004-09-15 23:33:53.000000000 +0200
> Modify: 2004-05-12 18:04:28.000000000 +0200
> Change: 2004-05-12 18:04:28.000000000 +0200
> This can be reproduced with a 2.6 kernel reading at any recent samba
> server (2.2 or 3.0).
> What happens is that samba & kernel's smbfs don't agree on the meaning
> of the 2nd 64-bit value in unix extension: samba/smbd/trans2.c tells
> (and has always told since addition, cvs rev 184.108.40.206):
> SOFF_T(p,0,get_allocation_size(NULL,&sbuf)); /* Number of bytes used on disk - 64 Bit
> while the kernel does (and has always been doing since addition to
> fattr->f_blocks = LVAL(p, 8);
> I.e. takes it as a number of sectors.
I changed this to number of bytes on disk, not number of sectors, as
there is no POSIX agreement on how many bytes per sector. This we
report the number of bytes as a 64-bit number, and the local client can work that out in
terms of number of sectors.
> Who is wrong ? I could find some draft here:
> which tells that:
> CIFS Extensions for UNIX systems V1
> LARGE_INTEGER NumOfBlocks
> Number of file system block used to store file
> Which is on the kernel's side...
And is wrong. As there is no agreement in POSIX on what that number
> And btw, why is samba rounding the minimum size up to 1MB ?
An optimisation for Windows clients. If we do this they allocate actually
run faster against a Samba server (based on tests done by a NAS vendor).
More information about the samba-technical