xfs
[Top] [All Lists]

Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 12 Jan 2012 11:22:10 -0500
Cc: jeff.liu@xxxxxxxxxx, Dave Chinner <david@xxxxxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4F0DF9C1.2060302@xxxxxxx>
References: <4F06F71A.2010301@xxxxxxxxxx> <20120110171855.GX6390@xxxxxxx> <4F0D21E5.7010908@xxxxxxxxxx> <4F0DF9C1.2060302@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.

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