Re: mkfile -- create large files efficiently

[Matej Cepl]

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