The upstream fallocate syscall allows efficient space preallocation for filesystems which support it (today: ext4, xfs, and ocfs2). To fully support new ext4 features for the tech preview in 5.3, we should backport this new syscall. Relevant upstream commits for the OS infrastructure: http://git.engineering.redhat.com/?p=linux-2.6.git;a=commitdiff;h=97ac73506c0ba93f30239bb57b4cfc5d73e68a62 http://git.engineering.redhat.com/?p=linux-2.6.git;a=commitdiff;h=0d786d4a2773f06a791e8c3730d049077fb81df6 We should probably also update glibc to wire posix_fallocate to this interface as well. Thanks, -Eric
There are 2 tricky bits to this w.r.t. KABI 1. it requires a new inode operation, ->fallocate. This gets tested: + if (inode->i_op && inode->i_op->fallocate) + ret = inode->i_op->fallocate(inode, mode, offset, len); so it is not safe to do for out-of-tree filesystems; ->fallocate will point off into junk. One thought is to add a superblock s_flags flag, MS_HAS_FALLOC, and filesystems which do have ->fallocate can set this. Then we only test for fallocate in the presence of that flag. The only risk is if some other out of tree filesystem stole that flag for some reason, but I that's an acceptable/small risk. 2. it requires BH_Unwritten support (unwritten = allocated but uninitialized). This is a buffer head flag not present in RHEL5, and we capped useable flags with BH_PrivateStart for individual filesystem use. It might be reasonably safe to put BH_Unwritten up at bit 31, and assume (hope?) that no out of tree filesystem uses so many flags as to use up that slot... it's far from foolproof though. -Eric
in kernel-2.6.18-115.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-0225.html