xfs
[Top] [All Lists]

Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5
From: Ben Myers <bpm@xxxxxxx>
Date: Thu, 12 Jan 2012 11:50:16 -0600
Cc: Mark Tinguely <tinguely@xxxxxxx>, jeff.liu@xxxxxxxxxx, Dave Chinner <david@xxxxxxxxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20120112162210.GA3925@xxxxxxxxxxxxx>
References: <4F06F71A.2010301@xxxxxxxxxx> <20120110171855.GX6390@xxxxxxx> <4F0D21E5.7010908@xxxxxxxxxx> <4F0DF9C1.2060302@xxxxxxx> <20120112162210.GA3925@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
Hey,

On Thu, Jan 12, 2012 at 11:22:10AM -0500, Christoph Hellwig wrote:
> 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.
    c) having a cursor here means that Jeff can always get the job done
       with a single btree search, which could be an important
       optimisation for heavily preallocated workloads.

> 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.

I agree that this is a good idea.  I would like to reiterate my
suggestion that Jeff go for the 'simple' implementation (assume
unwritten extents contain data) before going about scanning unwritten
extents for holes/data.

Regards,
        Ben

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