DragonFly BSD
DragonFly users List (threaded) for 2013-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Hammer mirror-copy issue


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 18 Jul 2013 18:41:03 -0700 (PDT)

:- 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



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]