From: Joel Becker <jlbec@evilplan.org>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] Treat writes as new when holes span across page boundaries
Date: Tue, 22 Feb 2011 00:36:49 -0800 [thread overview]
Message-ID: <20110222083648.GC30966@noexit> (raw)
In-Reply-To: <AANLkTimXr0rA5FV_ep-y9uetUVcD3w+9MuTZeBnLXDvG@mail.gmail.com>
On Sun, Feb 20, 2011 at 11:44:05PM -0600, Goldwyn Rodrigues wrote:
> >> > ? ? ? ?Secondly, ocfs2_should_read_blk() already checks for blocks past
> >> > i_size and skips reading them. ?So if you are trying to avoid reading
> >> > them, it is already handled.
> >>
> Sorry, I was wrong in my previous explanation on why
> ocfs2_should_read_blk returns 1. ocfs2_should_read_blk returns 1
> because of ocfs2_sparse_alloc() and hence forces the garbage read.
You're right, that's why ocfs2_should_read_block() returns 1.
But why would it ever want to read blocks that are outside i_size?
We've guaranteed that they won't be initialized...
I wonder if that's the bug? We originally used to zero to EOC.
For sparse files, that could never be any clusters past i_size. With
the fix I put in for writepage, we no longer zero the blocks past
i_size. I think the sparse check there is no longer accurate.
Please try the attached patch and see if it fixes the problem.
It should work on its own, without your changes. If I have it wrong,
we'll continue to evaluate the problem. I'd test it myself, but my VM
setup is currently broken.
> On a different note, what I have not been able to explain as yet is,
> when the file is created on a nosparse filesystem, the holes have junk
> (not 0xbaadfeed, ie what was written previously but junk). Could you
> think of a reason why? In any case, this patch resolves this issue.
Do they have junk without your patch, or just with your patch?
Joel
--
"Always give your best, never get discouraged, never be petty; always
remember, others may hate you. Those who hate you don't win unless
you hate them. And then you destroy yourself."
- Richard M. Nixon
http://www.jlbec.org/
jlbec at evilplan.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ocfs2-Don-t-read-blocks-past-i_size-they-re-not-init.patch
Type: text/x-diff
Size: 1609 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20110222/be785faf/attachment.bin
next prev parent reply other threads:[~2011-02-22 8:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 15:44 [Ocfs2-devel] [PATCH] Treat writes as new when holes span across page boundaries Goldwyn Rodrigues
2011-02-20 7:09 ` Joel Becker
2011-02-20 18:45 ` Goldwyn Rodrigues
2011-02-21 2:08 ` Joel Becker
2011-02-21 5:44 ` Goldwyn Rodrigues
2011-02-22 8:36 ` Joel Becker [this message]
2011-02-22 9:37 ` Joel Becker
2011-02-22 19:02 ` Goldwyn Rodrigues
2011-02-22 21:39 ` Joel Becker
2011-02-22 21:54 ` Joel Becker
2011-02-22 22:09 ` Goldwyn Rodrigues
2011-02-22 23:34 ` Joel Becker
2011-02-23 0:05 ` Goldwyn Rodrigues
2011-02-23 9:39 ` Joel Becker
2011-02-23 14:43 ` Goldwyn Rodrigues
2011-02-23 19:13 ` Joel Becker
2011-02-23 19:28 ` Joel Becker
2011-02-23 21:00 ` Goldwyn Rodrigues
2011-02-23 21:23 ` Joel Becker
2011-02-23 20:54 ` Goldwyn Rodrigues
2011-02-23 21:17 ` Joel Becker
2011-02-23 21:35 ` Goldwyn Rodrigues
2011-02-23 21:37 ` Joel Becker
2011-02-23 21:44 ` Joel Becker
2011-02-23 22:31 ` Goldwyn Rodrigues
2011-02-28 18:03 ` Joel Becker
2011-02-28 19:07 ` Goldwyn Rodrigues
2011-02-28 19:40 ` Joel Becker
2011-03-01 2:11 ` Goldwyn Rodrigues
2011-02-24 16:32 ` Goldwyn Rodrigues
2011-02-24 18:16 ` Mark Fasheh
2011-02-23 21:09 ` Goldwyn Rodrigues
2011-02-23 21:21 ` Joel Becker
2011-03-26 22:48 ` 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=20110222083648.GC30966@noexit \
--to=jlbec@evilplan.org \
--cc=ocfs2-devel@oss.oracle.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).