Eric Sandeen wrote: > Pádraig Brady wrote: >> 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 > > Ah ok, sorry for being behind. :) > > Actually I guess I saw some of that fly by, too, and forgot... Thanks for mentioning the bug BTW. I'll add the already written patch immediately on getting clarification of the fallocate interface. > It's probably not that critical, though some people may wish it [-n] were > there. They can always RFE if they need it I guess. > > Having the ability to allocate at a given offset may be nice too. It seems to me that that functionality would only be needed within apps. If someone can provide valid use cases though we'll be open to add it. > For usefulness in test scripts, exposing all of fallocate's interfaces > would be nice. Handy for the test writers but I'm not sure it's required to expose this complexity to every user. > TBH I think "truncate --allocate" sounds a little odd. (Now that I > think back, I think I mentioned this before). truncate(1) and > truncate(2) specifically refer to i_size, which to fs people like me, > has nothing to do with the actual blocks allocated to a file. Well truncate(2) does, but I think truncate(1) is higher level and is used to "set the size of a file". In that context an --allocate option seems to fit I think. Also truncate(2) is required to shrink an fallocated file. 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
