Messages in this thread | | | Date | Sat, 25 Sep 2004 10:11:04 -0700 | From | Jeremy Allison <> | Subject | Re: [2.6] smbfs & "du" illness |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |