:Should the mtime/ctime on the slave pfs match the master.
: From the Master
:ls -l /pfs/data/yy
:-rw-r--r-- 1 root wheel 78 Mar 31 22:22 /pfs/data/yy
: From the Slave
:ls -l /pfs/data/yy
:-rw-r--r-- 1 root wheel 78 Mar 30 22:03 /pfs/data/yy
ctime should. mtime and atime not necessarily. And mtime/atime
certainly will not match on snapshots.
:Also on the remote slave system I have the /pfs/data mounted as /data
:but the data in the mount does not seem to change unless I umount and re
:mount it.
: From the remote machine
:ls -l /data/yy /pfs/data/yy
:-rw-r--r-- 1 root wheel 39 Mar 30 22:03 /data/yy
:-rw-r--r-- 1 root wheel 78 Mar 30 22:03 /pfs/data/yy
:
:Thanks,
:Dylan
A slave PFS softlink uses the transaction id of the most recent
mirror synchronization. When you null-mount the softlink you
basically freeze the transaction id for that mount to whatever the
null mount code saw in the softlink as-of the time of the mount.
So you have to umount/mount if you want to see it updated. Most
people don't bother mounting slave PFSs, they just CD into the
softlink and re-CD if they want to see it updated.
This isn't a bug. The filesystem can't safely rip-out (make changes)
to the topology without telling the kernel about it and that is
basically impossible to track when mirroring, so any mount or cd into
a slave PFS freezes the transaction id for that mount/cd.
-Matt
Matthew Dillon
<dil...@backplane.com>
