Re: kernel.bkbits.net off the air

[Davide Libenzi]

On Mon, 10 Nov 2003, H. Peter Anvin wrote:

> >>The best way to fix this isn't to add locking to rsync, but to add two
> >>files inside or outside the tree, each one is a sequence number, so you
> >>fetch file1 first, then you rsync and you fetch file2, then you compare
> >>them. If they're the same, your rsync copy is coherent. It's the same
> >>locking we introduced with vgettimeofday.
> >>
> >>Ideally rsync could learn to check the sequence numbers by itself but I
> >>don't mind a bit of scripting outside of rsync.
> > 
> > Wouldn't a simpler  "stop-rsync -> update-root -> start-rsync" work? If 
> > you'll hit an update you will get a error from your local rsync, that will 
> > let you know to retry the operation.
> 
> Part of the problem is that there are multiple steps in the rsync chain, 
> some of which can't be stopped in this way.
> 
> The sequence number idea looks sensible to me.  Larry, would it be too 
> much work to have the cvs repository generator generate these files?

So the update of the rsync repo should do something like:

update file1
update repo
update file2

Isn't it? I do not understand how this guarantee coherency:

Kernel.org             Me
                       get file1 (old value)
update file1           get repo-file1 (old value)
update repo-file1
...
update repo-fileJ
...                    get repo-fileJ (new value)
update repo-fileN      get file2 (old value)
update file2




- Davide



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/