On Wed, 2004-09-15 at 11:13, Rudi Chiarito wrote: > On Wed, Sep 15, 2004 at 10:43:57AM -0400, Bryan K. Wright wrote: > > directories, though. On my laptop, I have about 20GB of user files > > (images, maps, data, documents) and it takes a few minutes of disk > > grinding for rsync just to walk the tree and decide what's changed. > > This might be prohibitive (or at least prohibitively annoying) for the > > user. It also cuts into the battery life. > > Another problem to worry about is saturation of the link upstream. I'm > sure the average user wouldn't want the browser choked by rsync. Yes, > you can tell rsync to use at most N KB/s, but that's not always easy to > get right, if the user is in the position to estimate it at all - not to > mention that link speed might change at any time for e.g. mobile users. > And you run into the risk of the opposite scenario: you are forcing > rsync to use only a fraction of the bandwidth, when there's nothing else > using the rest. > > Or do we just assume that there's going to be enough bandwidth? A > saturated DSL is likely to be still more responsive than a saturated 56k > connection. Well, a bigger problem with rsync is that in many cases, the listing files part is the biggest time sync. And if that gets interrupted, you start from the beginning. (*) So, starting a backup via wireless/vpn when you open your laptop for 5 minutes at the coffee shop doesn't usually make sense. So, you might want to look at it as "backup only when on these networks". I think it's pretty reasonable to assume that people have lots of bandwidth at home and at work these days. Regards, Owen (*) This may actually not be the case for most people's home directories; they probably don't have source trees, maildir folders, etc, so perhaps 200 files is more typical than the 50,000 you might find in a hacker's homedir.
Description: This is a digitally signed message part