public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jeff Liu <jeff.liu@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: SEEK_DATA/SEEK_HOLE support
Date: Tue, 4 Oct 2011 10:43:05 +1100	[thread overview]
Message-ID: <20111003234305.GM3159@dastard> (raw)
In-Reply-To: <4E89343B.4030007@oracle.com>

On Mon, Oct 03, 2011 at 12:04:11PM +0800, Jeff Liu wrote:
> On 10/03/2011 01:59 AM, Christoph Hellwig wrote:
> 
> > On Mon, Oct 03, 2011 at 12:06:37AM +0800, Jeff Liu wrote:
> >> IMHO, to avoid data loss in some user application like cp(1), for
> >> unwritten extents, we always need to check the pages status.  Just as
> >> you mentioned above, return the map offset if pages are dirty for
> >> SEEK_DATA, or a hole found.
> > 
> > I'd suggest to first implement the simple versions I schemed below,
> > which would treat unwritten extents as data.  That is sub-optimal,
> > but a) safe and b) easy to implement.  The second step would be to
> > add probing for unwritten extents, which is even something we could
> > do as a common helper routine shared by filesystems.
> 
> So I'll wait for Dave's patch become ready, and then continue to improve
> it if necessary.
> In the meantime, I'll try to figure out how to add a helper which can be
> shared by all file systems for UNWRITTEN extents.

The lookup is pretty simple - if there's cached data over the
unwritten range, then I'm considering it a data range. If there's no
cached data over the unwritten extent, it's a hole. That makes the
lookup simply a case of finding the first cached page in the
unwritten extent.

It'll end up reading something like this:

	iomap = offset_to_extent(offset);
	first_index = extent_to_page_index(iomap);

	nr_found = pagevec_lookup(&pvec, inode->i_mapping, first_index, 1);
	if (!nr_found)
		break;

	offset = page->index << PAGECACHE_SHIFT;
	pagevec_release(&pvec);

	/* If we fell off the end of the extent lookup next extent */
	if (offset >= end_of_extent(iomap)) {
		offset = end_of_extent(iomap);
		goto next_extent;
	}

All the extent manipulations are pretty filesystem specific, so
there's not much that can be extracted into generic helper, I
think...

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2011-10-03 23:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-02 15:04 SEEK_DATA/SEEK_HOLE support Jeff Liu
2011-10-02 15:42 ` Christoph Hellwig
2011-10-02 16:06   ` Jeff Liu
2011-10-02 17:59     ` Christoph Hellwig
2011-10-02 19:11       ` Andi Kleen
2011-10-03  4:04       ` Jeff Liu
2011-10-03 23:43         ` Dave Chinner [this message]
2011-10-04 13:02           ` Christoph Hellwig
2011-10-05  4:36             ` Dave Chinner
2011-10-05  5:32               ` Jeff Liu
2011-10-05  9:23                 ` Dave Chinner
2011-10-05 13:56                   ` Jeff Liu
2011-10-05  7:34               ` Michael Monnerie
2011-10-05  9:36                 ` Dave Chinner
2011-10-05 18:22                   ` Michael Monnerie
2011-10-06  0:32                     ` Dave Chinner
2011-11-14 10:24 ` Christoph Hellwig
2011-11-14 12:47   ` Jeff Liu
2011-11-14 12:50     ` Christoph Hellwig
2011-11-19  8:29       ` XFS SEEK_DATA/SEEK_HOLE support V1 Jeff Liu
2011-11-19  8:34         ` Jeff Liu
2011-11-19  8:37         ` [PATCH] Introduce SEEK_DATA/SEEK_HOLE support to XFS V1 Jeff Liu
2011-11-19 19:11           ` Christoph Hellwig
2011-11-20 13:15             ` Jeff Liu
2011-11-20  0:30           ` Dave Chinner
2011-11-20 13:59             ` Jeff Liu
2011-11-20 15:30               ` Christoph Hellwig
2011-11-20 22:34                 ` Dave Chinner

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=20111003234305.GM3159@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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