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.
Attachment:
signature.asc
Description: This is a digitally signed message part
