<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 9/11/2013 8:07 PM, Loren M. Lang
      wrote:<br>
    </div>
    <blockquote cite="mid:52312FD4.3000508@alzatex.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      There is also three levels of duplication I can see. One is
      duplication of files on a single filesystem. If there are
      duplicated files on a server, they should be hard-linked on the
      original filesystem which will then transfer to dirvish/rsync
      automatically, but that can only be done if it's acceptable to
      have the same metadata. It doesn't work if they have different
      ownership, for example, due to some kind of per-user jail that is
      being done.<br>
      <br>
      The second is duplication between images. Dirvish/rsync should
      handle this automatically and only create duplicate copies of data
      when there is a metadata change.<br>
      <br>
      The third duplication is between vaults due to identical software
      installed on multiple servers. This will result in duplication
      when files are changed or added, but can be squashed post-rsync
      with a command like hardlink(1). But again, this will squash
      metadata to one version. While permissions will probably be the
      same, times may not be. Is it OK to squash this information?<br>
    </blockquote>
    <br>
    Oh, there is one case that I forgot to mention. If a file is moved
    in the source filesystem, but unchanged, Rsync won't track it and,
    instead, will copy a fresh version of it. Rsync only detects
    unchanged files by their original path. I've considered adding a
    method to track files by their inode numbers to fix this case,
    otherwise, moving the root of a large tree of files will cause the
    entire tree to be re-copied. Rsync does detect and preserve
    hardlinks on the original filesystem so one workaround is to
    hardlink the large tree into it's new location, then trigger (or
    wait) for the next Dirvish cycle to complete. Once the files are
    backed up at their old and new location, you can safely delete the
    old file tree. You can use cp with the -l option to hard-link a
    whole tree into a new location.<br>
    <br>
    <blockquote cite="mid:52312FD4.3000508@alzatex.com" type="cite"> <br>
      <blockquote cite="mid:522F569A.2080503@versanet.de" type="cite">
        <pre wrap="">
Cheers

V.

</pre>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Dirvish mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Dirvish@dirvish.org">Dirvish@dirvish.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.dirvish.org/mailman/listinfo/dirvish">http://www.dirvish.org/mailman/listinfo/dirvish</a>
</pre>
      </blockquote>
      <br>
      <br>
      <pre class="moz-signature" cols="72">-- 
Loren M. Lang
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:lorenl@alzatex.com">lorenl@alzatex.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.alzatex.com/">http://www.alzatex.com/</a>


Public Key: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="ftp://ftp.tallye.com/pub/lorenl_pubkey.asc">ftp://ftp.tallye.com/pub/lorenl_pubkey.asc</a>
Fingerprint: 10A0 7AE2 DAF5 4780 888A  3FA4 DCEE BB39 7654 DE5B
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Loren M. Lang
<a class="moz-txt-link-abbreviated" href="mailto:lorenl@alzatex.com">lorenl@alzatex.com</a>
<a class="moz-txt-link-freetext" href="http://www.alzatex.com/">http://www.alzatex.com/</a>


Public Key: <a class="moz-txt-link-freetext" href="ftp://ftp.tallye.com/pub/lorenl_pubkey.asc">ftp://ftp.tallye.com/pub/lorenl_pubkey.asc</a>
Fingerprint: 10A0 7AE2 DAF5 4780 888A  3FA4 DCEE BB39 7654 DE5B
</pre>
  </body>
</html>