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.<\/p>\n
So what does Linux do? Does it zero-fill, or behave sensibly and pre-allocate quickly?<\/p>\n
Let’s look at hte kernel:<\/p>\n
Inside the fallocate implementation (fs\/open.c):<\/p>\n
if (inode->i_op->fallocate)
\nret = inode->i_op->fallocate(inode, mode, offset, len);
\nelse
\nret = -EOPNOTSUPP;<\/p>\n
and for ext4:
\n\/*
\n* currently supporting (pre)allocate mode for extent-based
\n* files _only_
\n*\/
\nif (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))
\nreturn -EOPNOTSUPP;<\/p>\n
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 :)<\/p>\n
But this is just kernel behaviour – i *think* libc ends up wrapping it
\nwith a ENOTSUPP from kernel being “let me zero-fill” (which might be
\nuseful to check). Anybody want to check libc for me?<\/p>\n
This was all on slightly post 2.6.30-rc3 (from git: 8c9ed899b44c19e81859fbb0e9d659fe2f8630fc)<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Continue reading