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:39:43 -0500
Cc: jeff.liu@xxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4F0DFA11.7030305@xxxxxxx>
References: <4F06F71A.2010301@xxxxxxxxxx> <20120110171855.GX6390@xxxxxxx> <4F0D21E5.7010908@xxxxxxxxxx> <4F0DFA11.7030305@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jan 11, 2012 at 03:07:29PM -0600, Mark Tinguely wrote:
> 
> xfs_bmapi_read() returns the br_state == XFS_EXT_NORM for a hole.
> There are a couple places that a hole can trigger a data test.
> BTW, I could not generate a large enough hole that xfs_bmapi_read()
> would return as more than one hole entry, so I will ignore those
> situations and just list the couple places that a hole may be match
> a data rule:

We've been through this before, you need to overflow the 32-bit extent
length counter to get there.  Jeff, did you manage to create a test
case for that particular scenario?

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