On Mon, Dec 29, 2008 at 04:53:04AM -0800, Craig Barratt wrote:

> > BTW: Why would that ease support for rsync 3.x? (Just curious.)
> 
> Instead of updating File::RsyncP to rsync 3.x protocol, the idea
> would be to use native rsync on both sides of the connection,
> and the BackupPC trickery would be hidden behind FUSE.

Ah, I see. That's a rather tempting design. I'd take a look at the file
system operations rsync performs before implementing that. I remember
that it always creates a new temporary file beside the one it is
transferring. You'd need some kind of copy-on-write (which you'll need
anyway for a writable FUSE) for in-place replacement.

> It's just an idea at this point.  The rsync protocol isn't
> documented; File::RsyncP was developed by carefully reading the
> rsync source.  It's certainly possible to update File::RsyncP for
> rsync 3.x, but the development and testing effort is relatively
> high.  Two benefits of using native rsync on the server side are
> that a fuller set of command-line options could be used, and the
> robustness would be better.  One drawback is the rsync checksum
> caching wouldn't work with FUSE.

While it's tempting, you lose a lot of control (and therefore
optimization opportunities) by letting native rsync do all the work and
hiding BackupPC behind a file system layer which knows nothing of
differential transfers, pooling etc... of course, a writable FUSE
view would open a lot more usage scenarios like, for example, providing
some "just drop your files here for backup" space in the network.

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.craniosacralzentrum.de

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/