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:41:48 -0500
Cc: jeff.liu@xxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4F0EF5DC.1070207@xxxxxxx>
References: <4F06F71A.2010301@xxxxxxxxxx> <20120110171855.GX6390@xxxxxxx> <4F0D21E5.7010908@xxxxxxxxxx> <4F0DFB20.7030704@xxxxxxx> <4F0EE5B6.2040408@xxxxxxxxxx> <4F0EF5DC.1070207@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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
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>