Re: hammer mirror shows differrent results from differrent terminals
:Now in xterm1 I create a test file in the master pfs : :# touch test :# ls -l :total 0 :... :# hammer mirror-copy /Backup1/Data /Backup2/Data :Mirror-read: Mirror from 0001000204b1 to 0001000204f0 :Mirror-read /Backup1/Data succeeded :# :Now I check the slave in xterm2 : :# pwd :/Backup2/pfs/@@0x0001000204b0:1 :# ls :# :it shows nothing. :but if I check it with the full path ( in xterm2 ) it shows the file :is mirrored. :# ls -l /Backup2/Data/ :total 0 :-rw-r--r-- 1 root wheel 0 Jul 7 13:44 test : :Why is this so? Take a look at the transaction id's in the path. When you CD into the slave you are CD'ing into a snapshot on the slave. That is what that softlink is. It is dynamically generated by HAMMER but once you CD into it you are locked into a transaction id. So to see the changes you have to re-CD into the slave via the original softlink. All slave accesses are snapshot accesses, always. Accesses to master PFSs use a transaction id of -1 (0xULL) and are thus always 'current' accesses, requiring no re-cd. It is not a good idea to CD into a slave using a transaction id of -1 because you may catch ongoing mirroring operations as they are running, instead of after they've completed. :# rm test :# hammer mirror-copy /Backup1/Data /Backup2/Data :Mirror-read: Mirror from 000100020371 to 000100020370 :Mirror-read: No work to do :Mirror-read /Backup1/Data succeeded : :It says no work to do! :and the file is left in the slave. :... :thanks : :--Siju That work is still in kernel memory. It hasn't been flushed to the media yet. Mirroring operations only work on data flushed to the media. This will occur automatically every 30-60 seconds or when you sync. sync runs asynchronously though so it is best to use 'hammer synctid '. -Matt Matthew Dillon
hammer mirror shows differrent results from differrent terminals
Hi,
I have a master pfs and slave pfs in two differrent disks.
#hammer pfs-status /Backup1/Data
/Backup1/Data PFS #1 {
sync-beg-tid=0x0001
sync-end-tid=0x0001000204b0
shared-uuid=94063778-6ac7-11de-a994-011617202aa6
unique-uuid=940637b5-6ac7-11de-a994-011617202aa6
label=""
operating as a MASTER
snapshots dir for master defaults to /snapshots
}
#hammer pfs-status /Backup2/Data
/Backup2/Data PFS #1 {
sync-beg-tid=0x0001
sync-end-tid=0x0001000204b0
shared-uuid=94063778-6ac7-11de-a994-011617202aa6
unique-uuid=b015e877-6ac7-11de-a994-011617202aa6
slave
label=""
operating as a SLAVE
snapshots directory not set for slave
}
master in null mounted and slave has a soft link to the real pfs
/Backup1/pfs/@@-1:1 on /Backup1/Data (null, local)
dfly-bkpsrv# ls -l /Backup2/Data
lrwxr-xr-x 1 root wheel 17 Jul 7 13:18 /Backup2/Data -> /Backup2/pfs/Data
Now I ssh into the system through an xterm (xterm1) and move to the master.
# pwd
/Backup1/Data
Now I ssh into the system through another xterm (xterm2) and move to slave
# pwd
/
# cd /Backup2/Data
# pwd
/Backup2/pfs/@@0x0001000204b0:1
#
Now in xterm1 I create a test file in the master pfs
# touch test
# ls -l
total 0
-rw-r--r-- 1 root wheel 0 Jul 7 13:44 test
#
Then I do a hammer mirror copy ( in xterm1 ) to slave
# hammer mirror-copy /Backup1/Data /Backup2/Data
Mirror-read: Mirror from 0001000204b1 to 0001000204f0
Mirror-read /Backup1/Data succeeded
#
Now I check the slave in xterm2
# pwd
/Backup2/pfs/@@0x0001000204b0:1
# ls
#
it shows nothing.
but if I check it with the full path ( in xterm2 ) it shows the file
is mirrored.
# ls -l /Backup2/Data/
total 0
-rw-r--r-- 1 root wheel 0 Jul 7 13:44 test
Why is this so?
now I delete the "test" file and mirror-copy again.
# rm test
# hammer mirror-copy /Backup1/Data /Backup2/Data
Mirror-read: Mirror from 000100020371 to 000100020370
Mirror-read: No work to do
Mirror-read /Backup1/Data succeeded
It says no work to do!
and the file is left in the slave.
Unfortunately the "no work to do" part could not be reproduced by me.
But the first part is reproducible.
thanks
--Siju
WARNING - libpthread changes
I committed the change which "syncs" our threading libraries. As a result a lot of more features are available now in libpthread - barriers, spinlocks and some more: pthread_attr_getguardsize pthread_attr_setguardsize pthread_barrier_destroy pthread_barrier_init pthread_barrier_wait pthread_barrierattr_destroy pthread_barrierattr_getpshared pthread_barrierattr_init pthread_barrierattr_setpshared pthread_condattr_getclock pthread_condattr_getpshared pthread_condattr_setclock pthread_condattr_setpshared pthread_mutex_timedlock pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock pthread_spin_init pthread_spin_destroy pthread_spin_trylock pthread_spin_lock pthread_spin_unlock pthread_timedjoin_np Note, that all this is really functional if you use libthread_xu only, libc_r has only stubs for these which always retun a failure. Please make sure that /usr/lib/libpthread.so.0 is a symlink to libthread_xu.so in your system. It's default and using libc_r isn't something you should do in production system anyway. libc_r is there for testing purposes only. I can also guarantee that it introduces at least some problems with building pkgsrc packages. There shouldn't be any problem running packages built before that change though. I'm in vacation next four weeks, so I'm not able to work on this much, but I hope to get most of pkgsrc in shape again (to fix failures in essential packages at least) during this week. -- Hasso Tepper
