> There's still the question of how to initialise the second device in > the mirror-to-be. I would have copyworm-ed f(w5w1) to f(w2). I'm > nervous that copying from cw0f(w5w1) may not yield exactly the same > bytes as copying from f(w5w1).
Ok, thanks! I've tried looking at the code but (at this time of day) initially only got more confused - /sys/src/fs/port/config.c:^wormof seems not get the worm part of a cw, which is what I would expect it to do (instead, it seems to take are of a cw within an fworm?). I then realized that the copyworm code I run today was older: /n/sourcesdump/2003/0314/plan9/sys/src/fs/port/config.c it did copy the f(w5w1) part of cw0f(w5w1) (the written blocks). copying worm from f(w5w1) to fw2, starting in 8 seconds limit 1505835 copying worm fworm: read 0 0 not written fworm: read 1 1 not written block 20000 Tue Oct 17 15:57:26 2006 [...] copied 1505835 blocks from f(w5w1) to fw2 Even earlier today I had tried the same with the slightly newer kernel (code from march 14 2003) which I had patched to allow recover to work, and then it not only did not give exactly the same bytes, but it failed: copying worm from cw0f(w5w1) (worm cw0f(w5w1)) to fw2, starting in 8 seconds devsize(cw0f(w5w1)) = 1505936 fworm: read 0 i/o error reading cw0f(w5w1) block 0 panic: no blocks to copy on cw0f(w5w1) I did not compare in detail, but the code seems to be essentially the same as in the current version on sources. my first superblock seems to be block 2 - that explains fworm: read 0? related to the 'fworm of mirror' vs. 'mirror of fworms': I guess that copyworm would not be able to deal with the case of 'cached worm where worm is mirror of fake worms' (or would it?) Axel. (turns out I have to redo the copy anyway because confused by the big numbers of half-k and 4k blocks I chose a too small w2 disk that won't allow much growth - but is was big enough to hold the written part of f(w5w1) so I guess at least I have a backup)
