From: Steve French <smfltc@us.ibm.com>
To: Dave Kleikamp <shaggy@linux.vnet.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: Mon, 06 Nov 2006 18:26:38 -0600 [thread overview]
Message-ID: <454FD2BE.2090302@us.ibm.com> (raw)
In-Reply-To: <1162852069.11030.70.camel@kleikamp.austin.ibm.com>
Dave Kleikamp wrote:
> On Mon, 2006-11-06 at 15:50 -0600, Eric Sandeen wrote:
>
>> The inode diet patches first did this to generic_fillattr():
>>
>> - stat->blksize = inode->i_blksize;
>> + stat->blksize = PAGE_CACHE_SIZE;
>>
>> but by 2.6.19-rc3 this was changed again:
>>
>> - stat->blksize = PAGE_CACHE_SIZE;
>> + stat->blksize = (1 << inode->i_blkbits);
>>
>> I can't find for sure why this was done; perhaps because it exposed a bug
>> in cifs[1]
>>
>
> Steve has fixed the bug in cifs_readdir().
>
>
>> However, if we are going to pick a default for generic_fillattr, it should probably
>> be what most filesystems were using before, and let filesystems which need something
>> else re-set it to according to their needs. As it stands today, doing readdirs and
>> the like in block-sized chunks rather than page sized will probably not be the
>> best thing for performance.
>>
>
> I agree.
>
>
>> so I would propose the following patch to make PAGE_CACHE_SIZE the default (again),
>> and let filesystems which need something -else- do that on their own.
>>
>> [1] http://lists.samba.org/archive/linux-cifs-client/2006-September/001481.html
>>
>> Thanks,
>> -Eric
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>
>> --- linux.orig/fs/stat.c 2006-11-05 23:27:04.962482569 -0600
>> +++ linux/fs/stat.c 2006-11-05 23:27:29.394396050 -0600
>> @@ -33,7 +33,7 @@
>> stat->ctime = inode->i_ctime;
>> stat->size = i_size_read(inode);
>> stat->blocks = inode->i_blocks;
>> - stat->blksize = (1 << inode->i_blkbits);
>> + stat->blksize = PAGE_CACHE_SIZE;
>> }
>>
>> EXPORT_SYMBOL(generic_fillattr);
>>
>
> Looks good. Since cifs is affected by this patch, I propose that cifs
> explicitly set stat->blksize:
>
> CIFS: Explicitly set stat->blksize
>
> CIFS may perform I/O over the network in larger chunks than the page size,
> so it should explicitly set stat->blksize to ensure optimal I/O bandwidth
>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
>
> diff -Nurp linux.orig/fs/cifs/inode.c linux/fs/cifs/inode.c
> --- linux.orig/fs/cifs/inode.c 2006-11-03 13:44:04.000000000 -0600
> +++ linux/fs/cifs/inode.c 2006-11-06 16:11:21.000000000 -0600
> @@ -1089,8 +1089,10 @@ int cifs_getattr(struct vfsmount *mnt, s
> struct kstat *stat)
> {
> int err = cifs_revalidate(dentry);
> - if (!err)
> + if (!err) {
> generic_fillattr(dentry->d_inode, stat);
> + stat->blksize = CIFS_MAX_MSGSIZE;
> + }
> return err;
> }
>
>
>
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. 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, 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.
next prev parent reply other threads:[~2006-11-07 0:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-06 21:50 [RFC/PATCH] - revert generic_fillattr stat->blksize to PAGE_CACHE_SIZE Eric Sandeen
2006-11-06 22:27 ` Dave Kleikamp
2006-11-06 22:37 ` Eric Sandeen
2006-11-07 0:26 ` Steve French [this message]
2006-11-07 13:40 ` Dave Kleikamp
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
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=454FD2BE.2090302@us.ibm.com \
--to=smfltc@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=shaggy@linux.vnet.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;
as well as URLs for NNTP newsgroup(s).