From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Plan 9 wiping itself? From: "Russ Cox" Date: Wed, 28 Nov 2007 09:35:25 -0500 In-Reply-To: <140e7ec30711272343x6f017db3v90053f21cb161884@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20071128143526.D3AE21E8C22@holo.morphisms.net> Topicbox-Message-UUID: 0d607c30-ead3-11e9-9d60-3106f5b1d025 > The changes sound great, and eliminate my above doomsday scenario... > unless something goes really wrong with the replica log. Is it > replica/updatededb that is the culprit or just the way it is run in > replica/scan? It strikes me that if it is forced to abort for some > reason it should avoid updating the log at all. Actually the problem was that updatedb *wasn't* aborting. The network connection got lost halfway, so a lot of files "disappeared" so updatedb thought they had been deleted. And then it found them the next time it ran. I just submitted a fix so that it will notice network errors and stop before inferring file deletions. This won't happen again (and if it does, pull is smarter anyway). > By they way, any idea why the replica/pull -n output is so confusing > in this situation? It lists a lot of "a"s for files which already > exist (eg 386/9pc 386/auth/factotum sys/src/9/boot/boot.h) (in > alphabetic order?), then a lot of "d"s (in reverse alphabetical > order?), and then I have some legitimate c/a/ds (sys/src/games/mp3enc) > on account of I haven't pulled in awhile. But the initial > additions/deletions are disjoint sets as far as I can tell - why don't > I see deletions followed by additions for the same files? The log occasionally gets compressed (really, canonicalized) to remove redundant events. When that happens, the canonical replacement form is an "a" event for every file on the system followed by a "d" for every file that existed in the past and got deleted. Putting the "d" events in reverse alphabetical order deletes files before their parent directories. The two sets are disjoint because redundant event sequences have been collapsed into a single "a" or "d". Geoff compressed the log yesterday so that the big "delete /sys/src and then recreate it" sequence would go away. And then after compressing the log a few more entries got added. There's not a lot of difference between "a" and "c". If the log says "a" but the file already exists (and was created by replica) then it's treated as a "c". The "a" events you saw were really the "c" events that had happened before the log got compressed and that you hadn't yet pulled. Probably "c" should go away. Russ