rsync - Dec 2013 - lastes sources don't include "drop_cache" option

Was there some reason that patch got dropped?

Otherwise rsync eats up all the buffer memory.

Note -- I tried directio -- didn't work due to alignment
issues -- buffers have to be aligned to sectors.

The kernel, if I remember correctly, has been on again/off again
on requiring alignment on directio -- because most of the drivers
and devices do for directio to work, at.

"dd" throughput is about 20-30% faster with direct_IO (on the target
side,
not on the read side... no benefit on read -- but that's where drop
cache helps..

On Mon, 02 Dec 2013 00:30:58 -0800, Linda A. Walsh wrote:
> Was there some reason that patch got dropped?
AFAIK it was never applied in the first place. I disagree with the
reasoning, but whatever. This just came up this morning on Gentoo:
https://bugs.gentoo.org/show_bug.cgi?id=475408

..and as I looked for solutions that don't require the patch I found:
https://github.com/Feh/nocache

This seems to work and is useful to other applications as well, if you can
live with the naive assumption that buffer cache behaviour is global to an
entire application/command.

-h

On Mon, Dec 2, 2013 at 12:30 AM, Linda A. Walsh <rsync at tlinx.org>
wrote:
> Was there some reason that [drop_cache] patch got dropped?
>
It was only ever a diff in the patches repository, and I dropped it because
it was too much of a kluge for a file copy program to have in its code
(especially the updated version that had a delayed block-dropping loop or
some such).  I like the concept of a general tool that can make any program
drop its file use from the cache, and the nocache program that Holger cites
looks like a nice solution for that (judging by its docs -- I haven't tried
it yet).

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20131203/5dc0cf34/attachment.html>