xfs
[Top] [All Lists]

Re: SEEK_DATA/SEEK_HOLE support

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: SEEK_DATA/SEEK_HOLE support
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 4 Oct 2011 09:02:08 -0400
Cc: Jeff Liu <jeff.liu@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20111003234305.GM3159@dastard>
References: <4E887D7F.2010306@xxxxxxxxxx> <20111002154259.GA14543@xxxxxxxxxxxxx> <4E888C0D.9060701@xxxxxxxxxx> <20111002175902.GA9420@xxxxxxxxxxxxx> <4E89343B.4030007@xxxxxxxxxx> <20111003234305.GM3159@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Oct 04, 2011 at 10:43:05AM +1100, Dave Chinner wrote:
> 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...

Actually pretty similar code will work just fine if you passt the
start + len of the extents in (which we got from looking it up
fs-specificly):

Note that we have to look for both dirty and writeback pages to
make it safe.

<Prev in Thread] Current Thread [Next in Thread>