[Top] [All Lists]


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


> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

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