From: Keith Mannthey <kmannth@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jens Axboe <jens.axboe@oracle.com>,
linux-kernel@vger.kernel.org, sekharan@us.ibm.com
Subject: Re: [Patch][RFC] Supress Buffer I/O errors when SCSI REQ_QUIET flag set
Date: Wed, 31 Dec 2008 17:10:00 -0800 [thread overview]
Message-ID: <1230772200.6558.23.camel@keith-laptop> (raw)
In-Reply-To: <20081230113514.fe09d495.akpm@linux-foundation.org>
On Tue, 2008-12-30 at 11:35 -0800, Andrew Morton wrote:
> On Tue, 25 Nov 2008 10:19:18 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
>
> > On Mon, Nov 24 2008, Keith Mannthey wrote:
<snip>
> > +static int quiet_error(struct buffer_head *bh)
> > +{
> > + if (!test_bit(BH_Quiet, &bh->b_state) && printk_ratelimit())
> > + return 0;
> > + return 1;
> > +}
> >
>
> For better of for worse, we have a convention of using cpp-generated
> helper functions for the buffer_head flags. There's no reason why this
> new code needs to diverge from that. The above should use buffer_quiet().
>
> The functions in fs/buffer.c have been nicely commented.
>
> This function is poorly named. What does "quiet_error" *mean*?
There were only theses handful or errors that I encounter in my setup.
"quite_error" in my mind was to meant to mean that the error message
could be suppressed by the new BH_Quiet flag.
> <tries to work it out>
>
> Every caller of this function does `if (!quiet_error(bh))'. Would it
> not make more sense to invert the sense of its return value?
>
> static int permit_bh_errors(struct buffer_head *bh)
> {
> if (buffer_quiet(bh))
> return 0; /* IO layer suppressed error messages */
> return printk_ratelimit();
> }
>
> Did I translate that right? If so, then the addition of the
> printk_ratelimit() to the non-buffer_quiet() buffers is an
> unchangelogged and unrelated alteration.
I will remove the mucking with of the printk_ratelimit as to not disturb
its current implementation.
> The use of printk_ratelimit() needs some thought. It shares
> ratelimiting state with all other printk_ratelimit() callsites. Was
> that desirable? Would it have been better to create a private
> ratelimit_state for buffer_heads? Per physical device? Per
> something-else?
It is unclear to me so I will refrain from touching it.
>
> > + if (unlikely (test_bit(BIO_QUIET,&bio->bi_flags)))
> > + set_bit(BH_Quiet, &bh->b_state);
>
> And the above (which has coding-style errors and has apparently not been
> checkpatched) should use set_buffer_quiet().
sorry about that :(
>
> > --- a/include/linux/buffer_head.h
> > +++ b/include/linux/buffer_head.h
> > @@ -35,6 +35,7 @@ enum bh_state_bits {
> > BH_Ordered, /* ordered write */
> > BH_Eopnotsupp, /* operation not supported (barrier) */
> > BH_Unwritten, /* Buffer is allocated on disk but not written */
> > + BH_Quiet, /* Buffer Error Prinks to be quiet */
> >
> > BH_PrivateStart,/* not a state bit, but the first bit available
> > * for private allocation by other entities
>
> Add
>
> + BUFFER_FNS(Quiet, quiet)
>
> around line 123 to generate the helper functions.
Thanks for the review and information about the helper functions. It
will be Monday before I will be able to retest/resend a new patch.
Thanks,
Keith Mannthey
prev parent reply other threads:[~2009-01-01 1:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 21:26 Keith Mannthey
2008-11-25 9:19 ` Jens Axboe
2008-12-30 19:35 ` Andrew Morton
2008-12-30 19:41 ` Andrew Morton
2008-12-30 20:08 ` Pekka Enberg
2008-12-31 23:04 ` Defrag support for inodes / dentries etc Christoph Lameter
2009-01-02 0:00 ` Dave Chinner
2009-01-01 1:10 ` Keith Mannthey [this message]
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=1230772200.6558.23.camel@keith-laptop \
--to=kmannth@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sekharan@us.ibm.com \
/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
Powered by JetHome