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@xxxxxxxxxxxxx> wrote:
On Tue, Jan 15, 2013 at 09:46:36PM -0500, Bradley C. Kuszmaul wrote:Maybe. What you get depends on a lot of factors
> 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.
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...
Well, that depends on your definition of an extent. e.g. is a
> Each non-hole
> line in xfs_bmap is an extent, right?
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....
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
