From: Joel Becker <Joel.Becker@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Chinner <david@fromorbit.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
ocfs2-devel@oss.oracle.com, Tao Ma <tao.ma@oracle.com>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@lst.de>, Mark Fasheh <mfasheh@suse.com>
Subject: Re: [Ocfs2-devel] [PATCH] Revert "writeback: limit write_cache_pages integrity scanning to current EOF"
Date: Mon, 28 Jun 2010 18:58:23 -0700 [thread overview]
Message-ID: <20100629015822.GD24343@mail.oracle.com> (raw)
In-Reply-To: <AANLkTil1R9I94pVXLE50JAMPIwpiaZuroJAg4wcwyBUb@mail.gmail.com>
On Mon, Jun 28, 2010 at 06:12:35PM -0700, Linus Torvalds wrote:
> On Mon, Jun 28, 2010 at 5:54 PM, Joel Becker <Joel.Becker@oracle.com> wrote:
> > Your contention is that we've never gotten those tail blocks to
> > disk. Instead, our code either handles the future extensions of i_size
> > or we've just gotten lucky with our testing. Our current BUG trigger is
> > because we have a new check that catches this case. Does that summarize
> > your position correctly?
>
> Maybe Dave has some more exhaustive answer, but his point that
> block_write_full_page() already just drops the page does seem to be
> very valid. Which makes me suspect that it would be better to remove
> the ocfs2 BUG_ON() as a stop-gap measure, rather than reverting the
> commit. It seems to be true that the "don't bother flushing past EOF"
> commit really just uncovered an older bug.
Well, shit. Something has changed in here, or we're really
really (un)lucky. We visited this code a year ago or so when we had
serious zeroing problems, and we tested the hell out of it. Now it is
broken again. And it sure looks like that block_write_full_page() check
has been there since before git.
> So maybe ocfs2 should just replace the bug-on with invalidating the
> page (perhaps with a WARN_ONCE() to make sure the problem doesn't get
> forgotten about?)
Oh, no, that's not it at all. This is a disaster. I can't see
for the life of me why we haven't had 100,000 bug reports. You're going
to have an ocfs2 patch by the end of the week. It will be ugly, I'm
sure of it, but it has to be done. For every extend, we're going to
have to zero and potentially CoW around old_i_size if the old allocation
isn't within the bounds of the current write.
Joel
--
"In a crisis, don't hide behind anything or anybody. They're going
to find you anyway."
- Paul "Bear" Bryant
Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2010-06-29 2:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-28 17:35 [PATCH] Revert "writeback: limit write_cache_pages integrity scanning to current EOF" Joel Becker
2010-06-29 0:24 ` Dave Chinner
2010-06-29 0:54 ` Joel Becker
2010-06-29 1:12 ` Linus Torvalds
2010-06-29 1:58 ` Joel Becker [this message]
2010-06-29 2:20 ` [Ocfs2-devel] " Linus Torvalds
2010-06-29 2:44 ` Dave Chinner
2010-06-29 8:16 ` Joel Becker
2010-06-30 1:30 ` Joel Becker
2010-07-06 19:06 ` Joel Becker
2010-06-29 1:56 ` Dave Chinner
2010-06-29 2:04 ` Joel Becker
2010-06-29 2:27 ` Dave Chinner
2010-06-29 7:18 ` Joel Becker
2010-07-02 22:49 ` [PATCH] ocfs2: Zero the tail cluster when extending past i_size Joel Becker
2010-07-03 21:32 ` [PATCH 1/2] ocfs2: Zero the tail cluster when extending past i_size v2 Joel Becker
2010-07-03 21:33 ` [PATCH 2/2] ocfs2: No need to zero pages past i_size. " Joel Becker
2010-07-04 15:13 ` Tao Ma
2010-07-05 1:38 ` Tao Ma
2010-07-06 7:10 ` Joel Becker
2010-07-06 7:09 ` Joel Becker
2010-07-06 18:39 ` [Ocfs2-devel] " Joel Becker
2010-07-05 3:51 ` [PATCH 1/2] ocfs2: Zero the tail cluster when extending past " Tao Ma
2010-07-06 7:17 ` Joel Becker
2010-07-06 7:54 ` Tao Ma
2010-07-06 11:58 ` Joel Becker
2010-07-07 0:42 ` Tao Ma
2010-07-07 2:03 ` Joel Becker
2010-07-06 18:48 ` Joel Becker
2010-07-06 18:57 ` Joel Becker
2010-07-07 11:16 ` [PATCH 0/3] ocfs2: Tail zeroing fixes Joel Becker
2010-07-12 22:45 ` [Ocfs2-devel] " Joel Becker
2010-07-07 11:16 ` [PATCH 1/3] ocfs2: When zero extending, do it by page Joel Becker
2010-07-07 15:19 ` Tao Ma
2010-07-07 20:04 ` Joel Becker
2010-07-08 3:44 ` Tao Ma
2010-07-08 9:51 ` Joel Becker
2010-07-07 11:16 ` [PATCH 2/3] ocfs2: Zero the tail cluster when extending past i_size Joel Becker
2010-07-07 11:16 ` [PATCH 3/3] ocfs2: No need to zero pages " Joel Becker
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=20100629015822.GD24343@mail.oracle.com \
--to=joel.becker@oracle.com \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=tao.ma@oracle.com \
--cc=torvalds@linux-foundation.org \
/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