Pádraig Brady wrote:
> Eric Sandeen wrote:
...
>> 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".
But "size of a file" in the truncate sense only means "set the EOF offset."
"size of the file" in the truncate sense doesn't imply blocks or disk
space - this is what allocation does. (blocks * blocksize) can be more
than, less than, or same as the "size" (max offset) of the file, even
after you truncate up or down.
and indeed,
# truncate --size 1k blah
does just
open("blah", O_WRONLY|O_CREAT|O_NONBLOCK, 0666) = 3
ftruncate(3, 1024) = 0
truncate(1) is just a handy userspace interface to truncate(2). Making
it do anything else is just confusing well-defined interfaces &
semantics, imho.
I guess I don't -really- care if "truncate" grows an "--allocate"
option, but I'd still like to see a nice "fallocate" in util-linux-ng ;)
Thanks,
-Eric
> 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
