| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5 |
| From: | Jeff Liu <jeff.liu@xxxxxxxxxx> |
| Date: | Fri, 13 Jan 2012 10:14:57 +0800 |
| Cc: | Mark Tinguely <tinguely@xxxxxxx>, Ben Myers <bpm@xxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <20120112163943.GA22223@xxxxxxxxxxxxx> |
| Organization: | Oracle |
| References: | <4F06F71A.2010301@xxxxxxxxxx> <20120110171855.GX6390@xxxxxxx> <4F0D21E5.7010908@xxxxxxxxxx> <4F0DFA11.7030305@xxxxxxx> <20120112163943.GA22223@xxxxxxxxxxxxx> |
| Reply-to: | jeff.liu@xxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 |
On 01/13/2012 12:39 AM, Christoph Hellwig wrote: > 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? Ok, I'll try it out. Thanks, -Jeff > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs |
| Previous by Date: | Re: [PATCH 1/4] fs: Improve filesystem freezing handling, Dave Chinner |
|---|---|
| Next by Date: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Jeff Liu |
| Previous by Thread: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Christoph Hellwig |
| Next by Thread: | Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5, Mark Tinguely |
| Indexes: | [Date] [Thread] [Top] [All Lists] |