I'm doing direct I/O.  <div><br></div><div>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.</div><div><br></div><div>The file will always be sparse.<br>

<br><div class="gmail_quote">On Tue, Jan 15, 2013 at 10:22 PM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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