From: Jeremy Allison <jra@samba.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "Jeremy Allison" <jra@samba.org>,
"YOSHIFUJI Hideaki / 吉藤英明" <yoshfuji@linux-ipv6.org>,
samuel.thibault@ens-lyon.org, linux-kernel@vger.kernel.org
Subject: Re: [2.6] smbfs & "du" illness
Date: Sat, 25 Sep 2004 11:29:07 -0700 [thread overview]
Message-ID: <20040925182907.GS580@jeremy1> (raw)
In-Reply-To: <Pine.LNX.4.58.0409251054490.2317@ppc970.osdl.org>
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
issue.
> 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 ?
Jeremy.
next prev parent reply other threads:[~2004-09-25 18:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-17 20:54 [2.6] smbfs & "du" illness Samuel Thibault
2004-09-25 16:41 ` Linus Torvalds
2004-09-25 17:11 ` Jeremy Allison
2004-09-25 17:14 ` Jeremy Allison
2004-09-25 17:41 ` YOSHIFUJI Hideaki / 吉藤英明
[not found] ` <20040925174406.GP580@jeremy1>
2004-09-25 18:06 ` Linus Torvalds
2004-09-25 18:12 ` Linus Torvalds
2004-09-25 18:20 ` Jeremy Allison
2004-09-25 18:25 ` Samuel Thibault
2004-09-25 18:32 ` Jeremy Allison
2004-09-25 19:16 ` Linus Torvalds
2004-09-25 19:22 ` Jeremy Allison
2004-09-25 19:27 ` Samuel Thibault
2004-09-25 18:29 ` Jeremy Allison [this message]
2004-09-25 18:31 ` Jeremy Allison
2004-09-25 19:20 ` Linus Torvalds
2004-09-25 19:25 ` Jeremy Allison
2004-09-25 19:52 ` Jeremy Allison
2004-09-25 20:21 ` Linus Torvalds
2004-09-25 21:10 ` Jeremy Allison
2004-09-25 21:59 ` Linus Torvalds
2004-09-25 22:08 ` Jeremy Allison
2004-09-25 22:18 ` Linus Torvalds
2004-09-25 22:23 ` Jeremy Allison
2004-09-25 22:40 ` Samuel Thibault
2004-09-26 0:41 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040925182907.GS580@jeremy1 \
--to=jra@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=torvalds@osdl.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox