On Thu, Jul 30, 2009 at 12:44:55PM -0500, Eric Sandeen wrote: > Attached is a first stab at an fallocate utility, which will preallocate > blocks to a file. This can be useful for virtual images, database > files, testing, etc. Normally we'd hope that various tools will start > using preallocation internally, but until then such a utility may be > useful, and could be scripted as well. > > There are some bits of trickiness here .... > > We need a perfect storm for this all to work smoothly. :) > > * we need a kernel with sys_fallocate > * we need to operate on a filesystem that supports fallocate > * we need a glibc that maps fallocate() to sys_fallocate > > fallocate(2) isn't supported by anything but bleeding-edge glibc, and > has a few problems even then > (https://bugzilla.redhat.com/show_bug.cgi?id=500487) > > I put a fallback in the attached tool so that if fallocate() fails, it > goes to posix_fallocate. On recent (not bleeding) glibc, Well, this is command line wrapper around fallocate Linux syscall. Right? Then I don't see a reason for the posix_fallocate based fallback, particularly if: > posix_fallocate tries to call sys_fallocate, and resorts to writing 0s > if that fails. On even older glibc, it goes straight to 0-writing. The > user won't know which one happened, unless they allocate a few gigabytes > and notice the delay. Karel -- Karel Zak <kzak@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
