[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 11:06:15AM -0700, Linus Torvalds wrote:

    > You cannot claim that the number samba now puts there makes _any_ sense.

    Yes I can :-).

    > Why the apparent 1MB minimum limit? And if it's just the size of the file
    > in bytes, then why bother with it at all? And if you cannot get a
    > blocksize from the OS, why make up a nonsensical number?

    As I've mentioned. The 1MB mess is to do with Windows clients
    (it makes them faster with Samba). I apologise for that, you
    can publicly beat me for it etc. and I promise to fix it for
    Linux clients in future, but it works well for the majority
    clients we have to support.

    Also, the minumum size isn't the same issue as the st_blocks

    > CIFS Extensions for UNIX systems V1
    > LARGE_INTEGER NumOfBlocks
    > Number of file system block used to store file
    > again? Was it a CIFS Extension for POSIX? Or was it for UNIX like the
    > documentation specifies? Was it bytes, or was it blocks, like the
    > documentation says?

    Some history. I turn up at HP and look at the patch they
    have for this. They're putting the contents of st_blocks
    from the OS (HPUX in their case) into this field. I then
    write smbclient test code to test these extensions. Naturally
    (and as god intended :-), I assume 512 byte blocks in this
    value. When I look at the numbers they make no sense. So
    I go digging. I find that 512 byte blocks are *not* guarenteed
    (btw, thanks for your apology on being wrong on that... I'm
    sure it's in the post :-) and so any clients using this have
    no idea what this value actually means. So I have to decide
    what this actually means. Yes, I could scale to 512 byte
    blocks, but what if it's a HPUX client that expects 8192
    byte blocks ? So I decide, unilaterally (like you in the
    kernel I am god in the UNIX extensions space :-) to make this
    the number returned from st_blocks scaled as bytes. After
    all we have a 64 bit field so it has room. And then the
    client can scale it to whatever strange block size the
    userspace programs expect on that system.

    My argument that POSIX doesn't have st_blocks was more
    about the "it's always 512" issues, than what the code
    does. Of course the code uses it if it's there.

    Does it all make more sense now ?

    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.025 / U:10.260 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site