http://oss.sgi.com/bugzilla/show_bug.cgi?id=822
--- Comment #4 from Eric Sandeen <sandeen-xfs@xxxxxxxxxxx> 2009-05-11 17:05:16
CST ---
(In reply to comment #3)
> 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.
yep, you will.
> 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...
There may be some diabolical cases here where we are having a pretty bad ratio
of filled-holes-to-what-we-thought-was-sparse, I'll poke at it a bit more.
I didn't think xfs -used- to do this, but ... not sure.
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
|