rsync - Oct 2009 - can a .rsync-filter improve performance?

Hi,

I know certain subtrees I want to backup are written once
and never deleted.

So to reduce the time it takes rsync to run, I was thinking
of putting the following .rsync-filter in each of these subtrees:

P /**

I can see this stops the files on the receiver side from being 
deleted.

Does this filter also improve performance?

It looks like it does. If I do a manual test and delete
a file in this subtree on the sender side, when I look at the output
from the "building file list", it does  not show the deleted file.

So will this help improve performance (time it takes to build file list and
time it takes to update receiver)?

Is there a better way to prune, when you have subtrees that are 
only written once and you don't need rsync to keep visiting these
subtrees?

Thanks,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20091005/3db68348/attachment.html>

Trying rsync with --verbose and --progress flags looks like the .rsync-filter
only complicates the matter. The filter first causes rsync to protect the
files/directories
that match, and then rsync later checks them to see whether they are uptodate.

Is there a way to stop rsync from visiting a subtree entirely? I was thinking I
could
add this (whatever it is) dynamically after the subtree had been written.

Thanks,

Mike
  ----- Original Message ----- 
  From: Mike Connell 
  To: rsync at lists.samba.org 
  Sent: Monday, October 05, 2009 11:08 PM
  Subject: can a .rsync-filter improve performance?


  Hi,

  I know certain subtrees I want to backup are written once
  and never deleted.

  So to reduce the time it takes rsync to run, I was thinking
  of putting the following .rsync-filter in each of these subtrees:

  P /**

  I can see this stops the files on the receiver side from being 
  deleted.

  Does this filter also improve performance?

  It looks like it does. If I do a manual test and delete
  a file in this subtree on the sender side, when I look at the output
  from the "building file list", it does  not show the deleted file.

  So will this help improve performance (time it takes to build file list and
  time it takes to update receiver)?

  Is there a better way to prune, when you have subtrees that are 
  only written once and you don't need rsync to keep visiting these
  subtrees?

  Thanks,

  Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20091006/e0fc8b04/attachment.html>