| 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? |
| Previous by Date: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Christoph Hellwig |
|---|---|
| Next by Date: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Christoph Hellwig |
| Previous by Thread: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Jeff Liu |
| Next by Thread: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Jeff Liu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |