fallocate overhead

fallocate overhead

[Markus Trippelsdorf]

I was playing with the new hdparm wiper script (
http://sourceforge.net/projects/hdparm/files/) on my Vertex SSD and
it appears that btrfs needs a huge space overhead when dealing with
fallocate system calls. Basically what the wiper script does is to
fallocate one huge file using all free space minus a safety margin.
And this margin has to be about 30% on btrfs, e.g.:

# df -T /
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/root    btrfs    31266648  10464096  20802552  34% /
# hdparm --fallocate 20002552 test_temp
test_temp: No space left on device
# hdparm --fallocate 16002552 test_temp
test_temp: No space left on device
# hdparm --fallocate 15002552 test_temp
#

and from dmesg:
no space left, need 20482613248, 4096 delalloc bytes, 9786335232 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 25545211904 total
no space left, need 16386613248, 4096 delalloc bytes, 9786335232 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 25545211904 total

My question is if 30% isn't a bit too much overhead?
-- 
Markus

Re: fallocate overhead

[Chris Mason]

On Thu, Aug 13, 2009 at 04:07:32PM +0200, Markus Trippelsdorf wrote:
> I was playing with the new hdparm wiper script (
> http://sourceforge.net/projects/hdparm/files/) on my Vertex SSD and
> it appears that btrfs needs a huge space overhead when dealing with
> fallocate system calls. Basically what the wiper script does is to
> fallocate one huge file using all free space minus a safety margin.
> And this margin has to be about 30% on btrfs, e.g.:

We're actively fixing this ;)  The margin is just a hard coded limit to
try and avoid enospc oopsen.  It should improve in 2.6.32.

-chris