<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Thanks Matt, great info. I didn't realize that you could mirror copy a slave to a slave. It looks like I must have accidentally done the PFS softlink duplication thing you mentioned.</div>
<div class="gmail_extra"><br clear="all"><div><div><br></div>Tim</div>
<br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 6:41 PM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@apollo.backplane.com" target="_blank">dillon@apollo.backplane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
:- Verified that the files on the backup drive were good<br>
<div class="im">:- Stopped the mirror stream<br>
:- Successfully did a pfs-upgrade on the backup drive's PFS 1<br>
:- Formatted the primary drive and created a PFS 1 on it slaved to the<br>
:backup drive's PFS 1<br>
:- Started a mirror-copy from the backup drive's PFS 1 to the main drive's<br>
:PFS 1<br>
:<br>
:A<br>
</div>:=E2=80=8Bny ideas on how the mirror-copy could have skipped some of the fil=<br>
:es?=E2=80=8B<br>
:<br>
:Tim<br>
<br>
I don't think you needed to upgrade the backup drive's PFS 1. You<br>
can mirror-copy a slave to a slave.<br>
<br>
If the files are present on the backup PFS 1 they should be present on<br>
the slave PFS 1. Hmm. Are the transaction ids the same? A slave PFS<br>
will have a transaction id in the softlink that looks something like<br>
this:<br>
<br>
mirrors -> @@0x000000030a16daa4:00001<br>
<br>
The actual slave PFS softlink is @@-1:00001 but when you ls it HAMMER<br>
automatically prints out the last synchronized transaction id. (For<br>
master PFS's it always leaves it @@-1:<blah>). Every time the slave<br>
updates from the mirror-copy or mirror-stream the softlink should<br>
update too.<br>
<br>
Sometimes people accidently leave themselves CD'd into the slave, then<br>
wonder why they aren't seeing updates. You have to re-CD to get the<br>
latest transaction id.<br>
<br>
Othertimes people duplicate the PFS softlink but wind up writing out<br>
a fixed transaction id instead of @@-1:<blah>.<br>
<br>
It's possible that you accidently did the latter. Try explicitly CD'ing<br>
into the slave PFS via @@-1:00001. If that turns out to be the problem<br>
you can delete and recreate the PFS softlink (using -1) and it should<br>
always read the latest transaction id again.<br>
<br>
That's for slave PFS's. Master PFS's should always have a PFS softlink<br>
of @@-1:<blah>. Perhaps there was a bug when you upgraded the backup<br>
from slave to master.<br>
<br>
In anycase, see if you can verify that both sides are synchronized to<br>
the same transaction id. The mirror-copy program will tell you what<br>
the source is, and you can check the target's slave PFS softlink to see<br>
what that is.<br>
<br>
-Matt<br>
<br>
</blockquote></div><br></div></div>