From: Dave Chinner <david@fromorbit.com>
To: Jeff Liu <jeff.liu@oracle.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v2] xfs: probe data buffer from page cache for unwritten extents
Date: Tue, 26 Jun 2012 12:38:00 +1000 [thread overview]
Message-ID: <20120626023800.GE19223@dastard> (raw)
In-Reply-To: <4FE85C7B.3010909@oracle.com>
On Mon, Jun 25, 2012 at 08:41:31PM +0800, Jeff Liu wrote:
> Hello,
>
> Using the start offset rather than map->br_startoff to calculate the starting page index could
> get more accurate data offset in page cache probe routine.
> With this refinement, the old max_t() could be able to remove too.
....
> + }
> + /*
> + * xfs_bmapi_read() can handle repeated hole regions,
> + * hence it should not return two extents both are
> + * holes. If the 2nd extent is unwritten, there must
> + * have data buffer resides in page cache.
> + */
> + BUG();
That's wrong. A hole can be up to 32bits in length. When the hole is
longer than that, you'll get two extents that are holes. Try working
with sparse files that have holes in the order of a 100TB in them...
Also, as I've said before - BUG() does not belong in filesystem code
that can return an error. Shut the filesystem down with an in-memory
corruption error and maybe put an ASSERT(0) there so debug kernels
trip over it. However, no filesystem "can not happen" logic error is
a reason to panic a production machine.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-26 2:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 12:41 [PATCH v2] xfs: probe data buffer from page cache for unwritten extents Jeff Liu
2012-06-25 16:13 ` Mark Tinguely
2012-06-26 2:38 ` Dave Chinner [this message]
2012-06-26 6:45 ` Jeff 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=20120626023800.GE19223@dastard \
--to=david@fromorbit.com \
--cc=jeff.liu@oracle.com \
--cc=xfs@oss.sgi.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