From: Eric Sandeen <sandeen@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
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 19:39:10 -0600 [thread overview]
Message-ID: <454FE3BE.2040502@redhat.com> (raw)
In-Reply-To: <20061107000840.GF6012@schatzie.adilger.int>
Andreas Dilger wrote:
> On Nov 06, 2006 17:15 -0600, Eric Sandeen wrote:
>> Christoph Hellwig wrote:
>>> I agree with the conclusion, but the patch is incomplete. You went down
>>> all the way to find out what the fileystems do in this messages, so add
>>> the hunks to override the defaults for non-standard filesystems to the
>>> patch aswell to restore the pre-inode diet state.
>> Well, agreed. I put 80% or more back to pre-patch state, but not all.
>> :) So it's less broken with my patch than without, so at least it's
>> moving forward. So... Ted's patches get in w/o fixing up all the other
>> filesystems (left as an exercise to the patch reader) but mine can't? :)
>
> Actually, rather than blindly revert to pre-patch behaviour it would be
> worthwhile to determine if PAGE_SIZE isn't the better value. In some
> cases people don't understand that i_blksize is the "optimal IO size"
> and instead assume it is the filesystem blocksize. I saw a few that were
> e.g. 512 and that can't be very useful.
I'm willing to either revert everyting to pre-inode-diet behavior, or leave it
at the (newly re-proposed) page size default and let the other fs maintainers
sort it out for their own codebase, but I don't pretend to know what is best
for, say, qnx4 etc... I'd be willing to cc: all maintainers asking them to take
another long hard look at their code. :)
As we saw with cifs, these changes can have unintended consequences (not picking
on cifs, it's just one that ran into issues with the broad-stroke change).
-Eric
next prev parent reply other threads:[~2006-11-07 1:39 UTC|newest]
Thread overview: 18+ 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
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 [this message]
2006-11-07 3:43 ` Theodore Tso
2006-11-07 4:02 ` Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
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=454FE3BE.2040502@redhat.com \
--to=sandeen@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.