Re: [RFC] fallocate utility

[Eric Sandeen]

Giuseppe Scrivano wrote:
> Hello,
> 
> Pádraig Brady <address@hidden> writes:
> 
>> Tilman Schmidt wrote:

...

>>> Why not make it, in the best Unix tradition, a single
>>> executable whose action depends on the name it is run as?
>> Hmm. Good idea.
>> There is precedent for that already in coreutils.
> 
> What do you think about having two separate executables?  Considering
> fallocate and truncate will share almost all code, these differences can
> be separed at compilation-time.  It seems that the same approach is
> already used by md5sum and shaXXXsum.

I'm curious - how much code will be shared, really?

in terms of functionality, truncate currently has:

       -c, --no-create
              do not create any files
       -o, --io-blocks
              Treat SIZE as number of IO blocks instead of bytes
       -r, --reference=FILE
              use this FILE’s size
       -s, --size=SIZE
              use this SIZE
       --help display this help and exit
       --version
              output version information and exit

the_util_previously_known_as_fallocate would have something like:

       -c, --no-create
              do not create any files
       -o, --offset=OFFSET
              start allocation at this OFFSET (0 default)
       -l, --length=LENGTH
              allocate this LENGTH starting at OFFSET (or 0)
       -n, --no-size-update
              do not change i_size (allow blocks past EOF)
       --help display this help and exit
       --version
              output version information and exit

I suppose -c might be shared between the two; it's a question of O_CREAT
or not, right.  But that's just a line or two.

the k/m/g/t/p/e parsing would be shared, but hopefully that's in a
library somewhere?

the allocation tool, if done portably, would have a whole whack of
configure-time options, I'd expect, based on which OS it's trying to
allocate on, and what interface the OS provides.

AFAIK, truncate(2) is truncate(2) just about everywhere.

If it really makes sense to share, fine, but I'm surprised that it'd be
a lot of common code.  Maybe after it gets written it'd be more obvious.

Thanks,
-Eric