Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tuesday 05 June 2007 14:44:07 Ross S. W. Walker wrote: > > -----Original Message----- > Then in remote sites C, D and E you can mount these NFS shares on > Solaris boxes that provide a nice local storage backing store which > caches the files as they are accessed, verifying they are current > on each access. First access will feel the latency, but all other > accesses afterward should be quick, unless some other site changes > the file, then it will be slow untill latest cached copy is > downloaded. I see... Except, how do you know the caches are current without at least doing a stat on the file? And wouldn't that stat itself starve? Kind of a waste, though, since "C, D, and E" in your example are the same box as A. > > Nowdays, even with synchronous replication (over a slow DSL > > link, over a VPN), > > the whole backup process takes a little under an hour, mostly > > thanks to > > BackupPC's pooling and compression. Since this happens > > overnight, I'm not > > even there to notice slow reads. > > If you keep backups local and replicate them behind the scenes > to a central repository that might help. I'm not sure what you mean by that. It sort of sounds like what we're doing already. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070605/aff4b873/attachment.pgp>