This is a PoC patch that improves archive creation performance at least in
certain configurations (ubuntu x64 14.04, virtualized infrastructure, SAN
storage) by using posix_fadvise to signal the intent to sequentially read the
whole file.
gnulib currently does not provide posix_fadvise. On pla
always yields EINVAL.
> On Mar 30, 2017, at 3:01 AM, Mark wrote:
>
> On Wed, March 29, 2017 10:01, Joerg Schilling wrote:
>> Paul Eggert wrote:
>>
>>> On 03/27/2017 07:02 AM, Carlo Alberto Ferraris wrote:
>>>> This is a PoC patch that improves arch
n this configuration almost doubled the tar throughput.
The change itself should be pretty safe, since we’re using the semantics of the
fadvise hints quite to the letter.
Carlo
> On Mar 29, 2017, at 6:03 AM, Paul Eggert wrote:
>
> On 03/27/2017 07:02 AM, Carlo Alberto Ferraris wrote:
>>
Paul, Mark,
so what is the current consensus? Reject, merge as-is or merge with changes?
Carlo
> On Mar 31, 2017, at 1:24 AM, Paul Eggert wrote:
>
> On 03/30/2017 09:01 AM, Mark wrote:
>> I think it would be a good idea to add an option to tell tar whether to
>> use POSIX_FADV_NOREUSE, POSIX_FA
Just as a comment about why in my patch I use len explicitly instead of 0: it’s
to workaround a bug in linux versions <2.6.6.
> In kernels before 2.6.6, if len was specified as 0, then this was interpreted
> literally as "zero bytes", rather than as meaning “all bytes through to the
> end of th
Paul,
friendly ping.
Carlo
> On Apr 5, 2017, at 10:16 AM, Carlo Alberto Ferraris
> wrote:
>
> Just as a comment about why in my patch I use len explicitly instead of 0:
> it’s to workaround a bug in linux versions <2.6.6.
>
> > In kernels before 2.6.6, if len wa
filesystem (on a SAN volume) this patch doubles tar's throughput. This is
because when linux is provided the FADV_SEQUENTIAL hint it doubles the
readahead on the underlying block device.
Any feedback is welcome.
Carlo
> On Apr 13, 2017, at 1:32 PM, Carlo Alberto Ferraris
> wrote
