On 2009-02-06, 23:37 GMT, Pádraig Brady wrote: > Rather than creating a new utility, prehaps a --preallocate > option to the existing truncate utility would be better? > Especially considering you added a --sparse option to mkfile > which does much the same thing (although not allowing shrinking?).
Well, my primary inspiration for writing mkfile (long time before there was any fallocate in the kernel) was that this utility is common on other Unices (http://docs.sun.com/app/docs/doc/816-0211/6m6nc670c?a=view, http://developer.apple.com/documentation/Darwin/Reference/ManPages\ /man8/mkfile.8.html, http://www.freebsdsoftware.org/sysutils/mkfile.html) so I wanted to have it on Linux as well. Introduction of fallocate just introduced additional incentive to complete mkfile and post it here. So, I wouldn't mind if for rexample renaming truncate to mkfile (I think there is a value in using commonly shared names for Unix utilities rather than calling them by name of a system call; moreover, coreutils are not supposed to be Linux only, right?). > BTW, I think the fallocate syscall is a relatively new addition > to linux, and linux filesystems like ext3 don't support it yet. > I would print an error rather than failing back to ftruncate in > those cases. Well, I am not exactly sure, what posix_fallocate (note that I intentionally don't use fallocate directly) does in case of filesystem which doesn't have a native fallocate, but I think userland utilities should leave this to glibc. However, note also that mkfile.c itself, doesn't fall back to ftruncate; it is used only when explicitly requested by the user. Best, Matěj Cepl _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
