Re: [2.6] smbfs & "du" illness

[Jeremy Allison <jra@samba.org>]

On Sat, Sep 25, 2004 at 09:41:59AM -0700, Linus Torvalds wrote:
> 
> I hate to say so, but Jeremy is a git in this case.

Thanks, I prefer POSIX fascist myself :-).

> And yes, that's a _fixed_ blocksize. When you use "stat()", and you look 
> at "st_blocks", it's ALWAYS in 512-byte entities. It doesn't matter that 
> "st_blksize" might be something else - when UNIX counts blocks, it counts 
> them in 512-byte chunks.

st_blocks and st_blksize are not in the POSIX spec
(I have one on my desk, and stroke it occasionally :-)
Besides which, on HPUX (which these extensions were
first created for) it returns st_blocks in 8192 byte
units, not 512, so your claim is incorrect.

That's why I got so pissed with the extensions spec
as it didn't specify a unit size. Rather an assume
"all the world is 512" which is plainly wrong, I
decided to make it a unit of bytes on the wire.
The client can then return in the correct blocksize
for it's own system.

> I'm claiming that samba is broken, and we should not try to fix it on the
> client side.  We should ask the samba people to get their act together.  
> They've apparently been able to put _two_ bugs in one single integer:  
> both messing up the block size _and_ then using a totally illogical
> minimum value for the thing.

Well the minimum value is for Windows clients. They go a *lot*
faster with the minimum value as it tweaks some of their internal
buffers when they allocate. You can parameterize it (admittedly at
compile time, not runtime). I can make it runtime parameterized
in a later smbd if you want.

The CIFS client needs to divide the value returned by 512, or
whatever blocksize is being used on the UNIX clients. When
we have a 64-bit space it makes sense to return the absolute
bytes and let the client return it to userspace in whatever blocksize
it wants.

> I bet the minimum value comes from the fact that all files end up using 
> "n" bytes for things like inodes etc. Let's make up some numbers, and 
> assume that somebody thought that the minimum disk-space used was 2kB. 
> Instead of dividing that by 512, and coming up with the value "4", they 
> multiplied it by the block size and came up with the value 1Mb.

Nope. We have strange reasons for things, but they're usually
not *that* strange.

> Whatever the reason, the minimum size is clearly a samba bug, even if you 
> were to (incorrectly, Jeremy) claim that there is no standard blocksize.

It's a Samba *feature* :-). But I agree for UNIX/Linux clients
it doesn't make much sense.

Jeremy.