[Top][All Lists]
[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
- [PATCH] mkfile -- create large files efficiently, (continued)
- [PATCH] mkfile -- create large files efficiently, Matej Cepl, 2009/02/06
- Re: mkfile -- create large files efficiently, Pádraig Brady, 2009/02/06
- Re: mkfile -- create large files efficiently, Matej Cepl, 2009/02/07
- Re: mkfile -- create large files efficiently, Pádraig Brady, 2009/02/07
- Re: mkfile -- create large files efficiently, Matej Cepl, 2009/02/08
- Re: mkfile -- create large files efficiently, Pádraig Brady, 2009/02/08
- Re: mkfile -- create large files efficiently, Jim Meyering, 2009/02/09
- [PATCH] Trying to finalize loose ends of truncate.c fallocate, Matej Cepl, 2009/02/27
- Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate, Eric Blake, 2009/02/27
- Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate, Pádraig Brady, 2009/02/27
- Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate,
Matej Cepl <=
- Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate, Eric Blake, 2009/02/28
- Re: mkfile -- create large files efficiently, Matej Cepl, 2009/02/27
- [PATCH] Following up on the comments from the upstream, Matej Cepl, 2009/02/27
- Re: mkfile -- create large files efficiently, Jim Meyering, 2009/02/28