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. FYI here is how we're thinking of adding fallocate() and posix_fallocate() to coreutils: http://www.pixelbeat.org/patches/coreutils/inbox_may_2009.html > I put a fallback in the attached tool so that if fallocate() fails, it > goes to posix_fallocate. On recent (not bleeding) glibc, > 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. You'd get most of the functionality by just calling posix_fallocate(). Calling fallocate() explicitly allows you to support the -n option. I.E. this tool you're proposing would be equivalent to `truncate --allocate` which we're going to add to coreutils, with the additional functionality of the -n option. Is that worth a separate tool? Should we add -n functionality to `truncate`? cheers, Pádraig. -- 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
