public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Mark Tinguely <tinguely@sgi.com>
Cc: jeff.liu@oracle.com, Ben Myers <bpm@sgi.com>,
	Chris Mason <chris.mason@oracle.com>,
	xfs@oss.sgi.com
Subject: Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5
Date: Thu, 12 Jan 2012 11:22:10 -0500	[thread overview]
Message-ID: <20120112162210.GA3925@infradead.org> (raw)
In-Reply-To: <4F0DF9C1.2060302@sgi.com>

With all the complications that we got compared to the initial version,
namely multiple hole extents, dirty unwritten extent detection and
so on I think it's time to stop using xfs_bmapi_read against Dave's
initial suggestion, and switch to using xfs_bmap_search_extents
directly.

The rationale for that is that

  a) using xfs_bmapi_read makes hole detection more complex, given
     that it has to fill potentially multiple xfs_bmbt_irec structures
     instead of skipping over them
  b) reading two extents at a time means we have to duplicate all the
     detection code.

if we use xfs_bmap_search_extents we need a bit of boilerplate code,
but xfs_seek_data becomes really simple - we just loop over
xfs_bmap_search_extents until we either find an extent or EOF.
If we find an extent and it's unwritten we might have to probe for
dirty areas from one single point, or just skip it but the code is
still simple.  xfs_seek_hole is just as simple - if
xfs_bmap_search_extents fits the condition for a hole as written
down in xfs_bmapi_read we've found it, if not we might again have
to do the unwritten extent probing, but just from a single place
instead of duplicating it twice.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-01-12 16:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-06 13:28 Introduce SEEK_DATA/SEEK_HOLE to XFS V5 Jeff Liu
2012-01-10 17:18 ` Ben Myers
2012-01-11  5:45   ` Jeff Liu
2012-01-11 21:06     ` Mark Tinguely
2012-01-12 16:22       ` Christoph Hellwig [this message]
2012-01-12 17:50         ` Ben Myers
2012-01-11 21:07     ` Mark Tinguely
2012-01-12 13:29       ` Jeff Liu
2012-01-12 16:39       ` Christoph Hellwig
2012-01-13  2:14         ` Jeff Liu
2012-01-11 21:12     ` Mark Tinguely
2012-01-12 13:52       ` Jeff Liu
2012-01-12 15:01         ` Mark Tinguely
2012-01-12 16:41           ` Christoph Hellwig
2012-01-12 17:39             ` Ben Myers
2012-01-13  2:41           ` Jeff Liu
2012-01-11 15:43 ` Ben Myers
2012-01-11 22:28   ` Ben Myers
2012-01-12 13:21     ` Jeff Liu
2012-01-12 12:53   ` 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=20120112162210.GA3925@infradead.org \
    --to=hch@infradead.org \
    --cc=bpm@sgi.com \
    --cc=chris.mason@oracle.com \
    --cc=jeff.liu@oracle.com \
    --cc=tinguely@sgi.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