Sounds like xfs's space preallocation - it allocates extra space
at the end of a file, on the assumption that you're going to keep
writing to it. Overall, this is a performance improvement. As the
files close, the extra space at the end gets returned back to freespace.
I think that various levels of sync also return this freespace.
However, as the filesystem fills up, it is supposed to push harder
on flushing/freeing this preallocated space, so it seems a little
odd that you'd actually get ENOSPC, then have more free after a few
seconds. Maybe Steve will chime in with some ideas. :)
-Eric
On Tue, 23 Sep 2003, Blizbor (IMA) wrote:
> Hi,
>
> I have observed something curious.
>
> When I start "watch -n 1 df -m" and on the second console I'm copying
> big tree (i.e. four different kernel sources) I see df results going up,
> let's say
> 750MB then down to lets' say 730 then againg going up.
> After filling up whole filesystem (980MB for tests) mc used to make copy
> reports no space left. "df" shows the same however after few seconds
> (about 10,
> maybe 15) df shows that there is again 40MB free.
>
> Could anybody explain that ?
> Is this "by design" or it's some kind of error ?
>
> Regards,
> Blizbor
>
>
|