[xfs-masters] [Bug 822] xfs mapping behavior changed between .28 and .29

Mon May 11 17:00:12 CDT 2009

http://oss.sgi.com/bugzilla/show_bug.cgi?id=822

Dave Chinner <david at fromorbit.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david at fromorbit.com

--- Comment #3 from Dave Chinner <david at fromorbit.com>  2009-05-11 17:00:10 CST ---
> xfs_io -f -c "pwrite 0 4096" -c "pwrite 8192 4096" testfile
> 
> Notice that the resulting file takes 12k, and bmap shows a single
> contiguous extent.
>
> I'd expect 8k disk space used, and data/hole/data

Eric,

The file does not get closed between writes, hence the speculative
allocation @ EOF is not truncated away in ->release(). If you were
to do this as two separate invocations of xfs_io, I think you'll
see data/hole/data. 

IMO, with disks the size they are these days filling small holes
is much nicer behaviour (fewer, larger reads when reading the files),
so I'd say XFS is now behaving as it was designed to do.

FWIW, the length of the speculative allocation is configurable by
mount option (biosize, log value), and the default is "16" (i.e
64k). Hence I think you could turn this off if you really wanted
to...

Cheers,

Dave.

-- 
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.