Unix Extension & "du"

[Jeremy Allison]

On Fri, Sep 17, 2004 at 12:52:46AM +0200, Samuel Thibault wrote:
> Hi,
> 
> 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
> rgulier
> 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 1.149.4.47):
> 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
> 2.5.40)
>         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:
> http://uranus.it.swin.edu.au/~jn/linux/smbfs/Byron_Deadwiler_Paper.doc
> 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
means.

> 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).

Jeremy.