On Sun, 15 Jun 2014 18:06:34 John Williams wrote: > Why does it take 2 minutes? On XFS or ext4, fallocate is almost > instantaneous, even for multi-Terabyte allocations. > > According the fallocate man page, preallocation should be quick and > require no IO: > > " fallocate is used to manipulate the allocated disk space for a > file, either to deallocate or preallocate it. For filesystems which > support the fallocate system call, preallocation is done quickly by > allocating blocks and marking them as uninitialized, requiring no IO to > the data blocks. This is much faster than creating a file by filling > it with zeros."
No IO to data blocks but there is IO to metadata. But I think that BTRFS may need some optimisation for such things. While fallocate() on 24G is probably a very unusual case it will probably matter to some people (I can imagine scientific computing needing it) and it's likely that much smaller fallocate() calls also take longer than desired. The issue was system CPU time, extending the file in that test was proceeding at a speed of about 200MB/s for allocated space - while the system was writing something less than 2MB/s to the device (sometimes it went for 10+ seconds without writing any data). The SSD in question can sustain about 200MB/s of data written so in that case the BTRFS speed for allocating disk space was about equal to the speed it should be able to write real data. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
