From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: add ratelimiting to ext4 messages
Date: Sun, 20 Oct 2013 07:18:00 -0400 [thread overview]
Message-ID: <20131020111800.GA31086@thunk.org> (raw)
In-Reply-To: <52631017.6010001@redhat.com>
On Sat, Oct 19, 2013 at 06:04:55PM -0500, Eric Sandeen wrote:
>
> Maybe the ratelimit should depend on that then? I'm just concerned about
> the possibility of filtering messages that, rather than being a nuisance,
> are vital to figuring out what went wrong.
>
> (granted, it's probably the first error or two that matters)
The default rate limit threshold that we've set is ten messages per 5
seconds. I have a really hard time believing that the 11th message is
going to containing any critical information that won't be in the
first ten. :-)
> Or maybe it's only relevant with errors=continue, and errors=remount-ro
> will be self-limiting in any case.
Even with remount-ro, there are certainly cases where things will not
be self limiting, simply because user processes continually try
referencing the same corrupted directory or file.
> > When xfs "shuts down" the file system, it doesn't allow any read or
> > write accesses, right? So it's basically an even stronger version of
> > errors=remount-ro. We should perhaps discuss whether it would be
> > better to squelch errors if we've remounted the file system read-only,
> > or whether we should implement a complete shutdown errors option.
>
> Yeah, there is no errors=continue type option, that is probably too
> dangerous in general for the majority of users.
What I was asking was whether it might make sense for us to implement
a errors=shutdown-fs option which causes all read operations (in
addition to write operations) to immediately return EIO. That would
certainly reduce the error flood risk, but if you did this on the root
file system, you might as well set errors=panic. This is what XFS's
default behavior on fserrors, correct?
- Ted
next prev parent reply other threads:[~2013-10-20 11:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 1:28 [PATCH] ext4: add ratelimiting to ext4 messages Theodore Ts'o
2013-10-18 13:08 ` Lukáš Czerner
2013-10-18 14:08 ` Eric Sandeen
2013-10-18 18:59 ` Theodore Ts'o
2013-10-19 23:04 ` Eric Sandeen
2013-10-20 11:18 ` Theodore Ts'o [this message]
2013-10-20 23:15 ` Dave Chinner
2013-10-21 9:43 ` Zheng Liu
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=20131020111800.GA31086@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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;
as well as URLs for NNTP newsgroup(s).