[PATCH 3/3] Inform kernel of FADV_DONTNEED hint in receiver

Use the FADV_DONTNEED fadvise hint after finishing writing to a destinataion fd in the receiver. --- receiver.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/receiver.c b/receiver.c index d90fa25..b151cf8 100644 --- a/receiver.c +++ b/receiver.c @@ -742,6 +742,12 @@

[PATCH 2/3] Inform kernel of FADV_DONTNEED hint in sender

Use the FADV_DONTNEED fadvise hint after finishing reading an origin fd in the sender. --- sender.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sender.c b/sender.c index 59dae7d..e442933 100644 --- a/sender.c +++ b/sender.c @@ -338,6 +338,12 @@ void send_files(int

[PATCH 1/3] Add fadvise interface wrapper

With recent discussion on the LKML[1], it seems likely that Linux will finally support posix_fadvise in a useful way with the FADV_DONTNEED flag. This should allow us to minimize the effect of rsync on the system's working set. Add the necessary wrapper to syscall.c. [1] http://lkml.org/lkml/2010/

FADV_DONTNEED support

While going through an old todo list I found that these patches had fallen by the way-side. About a year ago I initiated a discussion[1] with the Linux kernel folks regarding the lack of any useable fadvise support on the kernel side. As a result, I was observing extremely poor performance on my se

Re: Re: cwRsync got killed...

> Side question: Does anyone know the probability of generating a file with > the same md5 and sha256 which is still looks valid with the expected content Uhh, zero. Problem is, the author never bothered with or knew about PKI signatures. So the hashes on the web could be wrong. Note also that th