bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate


From: Matej Cepl
Subject: Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate
Date: Fri, 27 Feb 2009 18:56:17 +0100
User-agent: slrn/0.9.9p1 (Linux)

On 2009-02-27, 14:48 GMT, Pádraig Brady wrote:
> Thanks for following this up Matej.
> Some very quick comments below. Will review more thoroughly when I've time.

Should I send a patch-to-patch or a new one?

> I would mention that the main reason for this call is
> to ensure blocks are contiguous. I.E. that as well as efficiently creating
> the file, subsequent use may be more efficient.
> I'd probably add "extents" to the index.

fixed

>> +++ b/man/mkfile.8.xml
>
> probably better to stick with the current coreutils man format
> (auto generated from --help).

Sure, I tried to do that -- I left my original manpage just as an 
illustration what I would hope for in the end. Removing now.

>> --- a/src/truncate.c
>> +++ b/src/truncate.c
>> +  {"fallocate", no_argument, NULL, 'a'},
>
> How about just --allocate ?

Done

>> +  /* posix_fallocate() is available since glibc 2.1.94.
>> +   * fallocate is in Linux since kernel 2.6.23.
>> +   */
>> +  if (fallocate_mode)
>> +    {
>> +      int ret = 0;
>> +      if ((ret = posix_fallocate (fd, 0, nsize)) != 0)
>
> what if this function is not available?

That's the reason I mentioned in the comment since when 
posix_fallocate is available, and the reason why I use 
posix_fallocate(3) and not plain fallocate(2).  Isn't there some 
minimal version of glibc required for coreutils?

Otherwise, would something like

    #ifdef posix_allocate

work?

>> +++ b/tests/misc/truncate-fallocate
>> +truncate -a -s $TESTSIZE $TESTFILE || fail=1
>> +
>> +if [ ! $fail -eq 1 ] ; then
>> +    size=$(stat --format="%s" $TESTFILE)
>> +    if [ "$(($size - 204800))" -gt 1024 ] ; then
>
> so fallocate() rounds up to next multiple of block size?

>From fallocate manpage:

# Because allocation is done in block size chunks, fallocate() 
# may allocate a larger range than that which was specified.

> That could be determined exactly.
> Should we warn if user specifies a size that's not a multiple?

As I understand that piece of fallocate manpage (and yes, that 
doesn't have to be true about posix_allocate when some emulation 
is provided) there should be rounding up automatically. The 
result is that we don't guarantee rounding up to happen, just 
that we won't be worse than with dd or something like that.

What do you think?

Matěj





reply via email to

[Prev in Thread] Current Thread [Next in Thread]