On 08/31/2011 05:43 AM, Sunil Mushran wrote: > On 8/30/2011 8:29 PM, Dave Chinner wrote: >> And that's -exactly- the ambiguous, vague definition that has raised >> all these questions in the first place. I was in doubt about whether >> unwritten extents can be considered a hole, and by your definition >> that means it should be data. But Andreas seems to be in no doubt it >> should be considered a hole. > > Fair enough. Let me rephrase. > > Data: > A range in a file when read could return something other than nulls. > > Hole: > A range in a file when read only returns nulls. > > Considering preallocated extents only return null, they should > be considered holes. I would concur with this. Treating preallocated extents as holes will allow them to be processed quickly by `cp` etc. What we lose is the ability to copy the allocation from src to dst. But that's less important in comparison, and could probably be done on a per file rather than per extent basis anyway. Note preallocation would be good for disk layout and timely ENOSPC. Note fiemap gives us greater control by distinguishing holes and empty extents, thus allowing us to both efficiently copy and maintain allocation. But that interface currently requires a sync of the file on some file systems, which we couldn't enable for performance reasons in cp. cheers, Pádraig. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
