Hammer mirror-copy issue

[Tim Darby]

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.


Tim


On Thu, Jul 18, 2013 at 6:41 PM, Matthew Dillon <dillon at apollo.backplane.com
> wrote:

>
> :- Verified that the files on the backup drive were good
> :- Stopped the mirror stream
> :- Successfully did a pfs-upgrade on the backup drive's PFS 1
> :- Formatted the primary drive and created a PFS 1 on it slaved to the
> :backup drive's PFS 1
> :- Started a mirror-copy from the backup drive's PFS 1 to the main drive's
> :PFS 1
> :
> :A
> :=E2=80=8Bny ideas on how the mirror-copy could have skipped some of the
> fil=
> :es?=E2=80=8B
> :
> :Tim
>
>     I don't think you needed to upgrade the backup drive's PFS 1.  You
>     can mirror-copy a slave to a slave.
>
>     If the files are present on the backup PFS 1 they should be present on
>     the slave PFS 1.  Hmm.  Are the transaction ids the same?  A slave PFS
>     will have a transaction id in the softlink that looks something like
>     this:
>
>         mirrors -> @@0x000000030a16daa4:00001
>
>     The actual slave PFS softlink is @@-1:00001 but when you ls it HAMMER
>     automatically prints out the last synchronized transaction id.  (For
>     master PFS's it always leaves it @@-1:<blah>).  Every time the slave
>     updates from the mirror-copy or mirror-stream the softlink should
>     update too.
>
>     Sometimes people accidently leave themselves CD'd into the slave, then
>     wonder why they aren't seeing updates.  You have to re-CD to get the
>     latest transaction id.
>
>     Othertimes people duplicate the PFS softlink but wind up writing out
>     a fixed transaction id instead of @@-1:<blah>.
>
>     It's possible that you accidently did the latter.  Try explicitly
> CD'ing
>     into the slave PFS via @@-1:00001.  If that turns out to be the problem
>     you can delete and recreate the PFS softlink (using -1) and it should
>     always read the latest transaction id again.
>
>     That's for slave PFS's.  Master PFS's should always have a PFS softlink
>     of @@-1:<blah>.  Perhaps there was a bug when you upgraded the backup
>     from slave to master.
>
>     In anycase, see if you can verify that both sides are synchronized to
>     the same transaction id.  The mirror-copy program will tell you what
>     the source is, and you can check the target's slave PFS softlink to see
>     what that is.
>
>                                                 -Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20130718/b60bb439/attachment-0002.html>