Messages in this thread | | | Date | Mon, 10 Nov 2003 19:37:22 +0100 | From | Andrea Arcangeli <> | Subject | Re: kernel.bkbits.net off the air |
| |
On Mon, Nov 10, 2003 at 10:27:33AM -0800, Davide Libenzi wrote: > 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
you must pick file2 before file1:
you:
do get file2 get repo-file1-j get file1 while file2 != file1 && sleep 10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |