hole punching performance

[Bradley C. Kuszmaul]

I'm doing direct I/O.

The definition of "extent" that I'm probing is how much inode or metadata
must be read in order to execute the first read of a file.

The file will always be sparse.

On Tue, Jan 15, 2013 at 10:22 PM, Dave Chinner <david at fromorbit.com> wrote:

> On Tue, Jan 15, 2013 at 09:46:36PM -0500, Bradley C. Kuszmaul wrote:
> > But if I populate the file with a collection of near-1MB writes at random
> > offsets, I'm likely to end up with one extent per write.
>
> Maybe. What you get depends on a lot of factors
>
> e.g. buffered IO will give different extent allocations to direct
> IO. Synchronous buffered IO will give different patterns to async
> buffered IO. Adding random fdatasync() calls will give different
> patterns again. And even better, if you are doing async buffered IO,
> different amounts of memory pressure can give you different
> results...
>
> > Each non-hole
> > line in xfs_bmap is an extent, right?
>
> Well, that depends on your definition of an extent. e.g. is a
> contiguous region on disk that alternates between written and
> unwritten state one extent? From an physical perspective
> it is a single extent, but from a logical perspective (i.e.
> for indexing) it is multiple extents....
>
> FWIW, if you are intending that the file is non-sparse at the end of
> all the writes (i.e. you fill all the holes), they preallocating the
> file before starting any writes is a good idea because it guarantees
> you'll end up with a minimal number of physical extents when the
> file is completely written....
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david at fromorbit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20130115/a9483d7a/attachment.html>