Re: [RFC] fallocate utility

[Eric Sandeen]

Pádraig Brady wrote:
> Eric Sandeen wrote:
>> 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."
> 
> I don't see a problem in extending the meaning of the truncate command.
> Now truncate isn't the best name for the command but that name
> already existed in BSD and so I thought it best to align with that.
> So what about also having an fallocate command in coreutils?
> Well it would benefit from all the existing options of the truncate command,
> I.E. would share most of the code, so I'm not convinced.

Well, truncate is indeed a great name for a command that truncates.  :)

Does truncate do more than that in bsd?

>> 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 ;)
> 
> A reason to have this functionality in coreutils is that the core
> functionality of posix_fallocate() is not linux specific.
> Also fallocate() like functionality is exposed on solaris
> for example through fcntl(fd, F_ALLOCSP, ...).

Ok, having an aptly-named block-allocation-tool in coreutils sounds
reasonable, if it the core functionality that can be supported across
several OSes.

> BTW I think your fallocate util might benefit from
> calling truncate(2) to allow one to shrink files also?

No, that's what truncate(1) is for IMHO.  "Do one thing and do it well,"
right? :)

-Eric

> cheers,
> Pádraig.