From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
To: Steve French <smfltc@us.ibm.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Theodore Tso <tytso@mit.edu>
Subject: Re: [RFC/PATCH] - revert generic_fillattr stat->blksize to PAGE_CACHE_SIZE
Date: Tue, 07 Nov 2006 07:40:45 -0600 [thread overview]
Message-ID: <1162906845.8123.11.camel@kleikamp.austin.ibm.com> (raw)
In-Reply-To: <454FD2BE.2090302@us.ibm.com>
On Mon, 2006-11-06 at 18:26 -0600, Steve French wrote:
> I assumed that the original intent of the "inode diet patch" was to
> remove fields in the inode,
> which most filesystems can get out of the superblock.
I think I may have planted the idea that you could get i_blkbits from
sb->s_blocksize_bits, but I was wrong. Consider a block device. It's
blocksize is not related to the superblock of its containing filesystem.
> If
> inode->blksize and inode->blkbits were
> related (2**blkbits == blksize) , it also makes sense to me that someone
> (Ted?) removed one and left the other
> as one would be redundant,
They were never really related. Some filesystems treated them as if
they were, but the vfs always used i_blkbits for the block size.
i_blksize was only really used for returning stat->blksize.
> but some filesystems like cifs have a large
> recommended i/o size (16K),
> but if someone wants to remove both from the inode that is fine by me,
> as long as cifs
> stat->blksize is set as you suggested on the way out of cifs_getattr.
> Eventually cifs should set
> the stat->blksize to a smaller value for one rarer case. For the most
> common case
> cifs should still set it to 16K (CIFS_MAX_MSGSIZE) as that is the most
> common negotiated
> buffer size but if the server does not negotiate large read support, and
> the server also is so old
> that it negotiates a buffer size smaller than 16K (e.g. Windows95
> negotiates 2K IIRC)
> then we could set stat-blksize to the smaller negotiated buffer size -
> but since those servers are
> getting rarer it is probably not that important. More interesting
> will be the future cases in
> which we will be able to set this value larger to more servers, as in
> general for modern
> network adapters, the larger network i/o size the better.
It would probably be best to just set stat->blksize to the negotiated
buffer size.
--
David Kleikamp
IBM Linux Technology Center
next prev parent reply other threads:[~2006-11-07 13:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-06 21:50 Eric Sandeen
2006-11-06 22:27 ` Dave Kleikamp
2006-11-06 22:37 ` Eric Sandeen
2006-11-07 0:26 ` Steve French
2006-11-07 13:40 ` Dave Kleikamp [this message]
2006-11-07 15:34 ` Dave Kleikamp
2006-11-07 15:50 ` Steve French
2006-11-06 23:05 ` Christoph Hellwig
2006-11-06 23:15 ` Eric Sandeen
2006-11-06 23:17 ` Christoph Hellwig
2006-11-06 23:28 ` Eric Sandeen
2006-11-07 0:08 ` Andreas Dilger
2006-11-07 0:13 ` Hua Zhong
2006-11-07 1:39 ` Eric Sandeen
2006-11-07 3:43 ` Theodore Tso
2006-11-07 4:02 ` Eric Sandeen
2006-12-03 13:21 col-pepper
2006-12-03 13:48 ` Adrian Bunk
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=1162906845.8123.11.camel@kleikamp.austin.ibm.com \
--to=shaggy@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=smfltc@us.ibm.com \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®