[Top] [All Lists]


To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5
From: Ben Myers <bpm@xxxxxxx>
Date: Thu, 12 Jan 2012 11:39:59 -0600
Cc: Mark Tinguely <tinguely@xxxxxxx>, jeff.liu@xxxxxxxxxx, Chris Mason <chris.mason@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20120112164148.GB22223@xxxxxxxxxxxxx>
References: <4F06F71A.2010301@xxxxxxxxxx> <20120110171855.GX6390@xxxxxxx> <4F0D21E5.7010908@xxxxxxxxxx> <4F0DFB20.7030704@xxxxxxx> <4F0EE5B6.2040408@xxxxxxxxxx> <4F0EF5DC.1070207@xxxxxxx> <20120112164148.GB22223@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Jan 12, 2012 at 11:41:48AM -0500, Christoph Hellwig wrote:
> On Thu, Jan 12, 2012 at 09:01:48AM -0600, Mark Tinguely wrote:
> > >Sorry, am was well understood your opinions in this point for now.
> > >IMHO, we can only find and return the data buffer offset at a dirty or
> > >unwritten page once the first page was probed.
> > >
> > 
> > From my tests, xfs_bmapi_read() can only find holes if they cross or
> > start on a 64KB boundary. It would be nice if unwritten extents were
> > at least that good at finding holes.
> Are you testing on ia64 with 64k blocks? :)  xfs_bmapi_read will
> find holes down to block granularity, that's how it's implemented.
> However recent XFS does fairly aggressive preallocation, so you probably
it is speculative delay in this case, I think.


> won't find small holes unless you explicitly punch them out using
> XFS_IOC_UNRESVSP or fallocate with the hole punch flag.

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