[lkml]   [2004]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.022 / U:8.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site