Unix Extension & "du"

[Samuel Thibault]

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.

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 btw, why is samba rounding the minimum size up to 1MB ?

I don't mind which way it be corrected, but please do get agree with
kernel people, or else "du" gives crazy numbers (well, I'd love to have
such space on my hard drive, but... ;) )

Regards,
Samuel Thibault