In an email disscussion for pre-allocating binlogs for MySQL (something we’ll likely have to do for Drizzle and replication), Yoshinori brought up the excellent point of that in some situations you don’t want to be doing zero-fill as getting up and running quickly is the most important thing.
So what does Linux do? Does it zero-fill, or behave sensibly and pre-allocate quickly?
Let’s look at hte kernel:
Inside the fallocate implementation (fs/open.c):
if (inode->i_op->fallocate)
ret = inode->i_op->fallocate(inode, mode, offset, len);
else
ret = -EOPNOTSUPP;
and for ext4:
/*
* currently supporting (pre)allocate mode for extent-based
* files _only_
*/
if (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))
return -EOPNOTSUPP;
XFS has always done fast pre-allocate, so it’s not a problem there and the only other filesystems to currently support fallocate are btrfs and ocfs2 – which we don’t even have to start worrying too much about yet :)
But this is just kernel behaviour – i *think* libc ends up wrapping it
with a ENOTSUPP from kernel being “let me zero-fill” (which might be
useful to check). Anybody want to check libc for me?
This was all on slightly post 2.6.30-rc3 (from git: 8c9ed899b44c19e81859fbb0e9d659fe2f8630fc)
See Ted T’so’s blog, the kernel fallocate returns enosupp, but glibc posix_fallocate will try fallocate then do it manually (which sucks). So you’ll need to wait for new glibc (or eglibc, the glibc fork with pleasant maintainers that Debian’s going to use), or use syscall(2).
Lazily not looking, but it’s my understanding that posix_fallocate() will fall back to zero-filling (which is what it always used to do anyway) but fallocate() should either do a fast prealloc, or nothing, if the filesystem doesn’t support it.