This is a discussion on Unix Extension & "du" - Samba ; 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: ...
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
$ stat file
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 188.8.131.52):
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.
Who is wrong ? I could find some draft here:
which tells that:
CIFS Extensions for UNIX systems V1
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... )