At 09:39 PM 12/30/2008, Raghavendra G wrote: >On Tue, Dec 30, 2008 at 12:29 PM, Keith Freedman ><<mailto:freedman at freeformit.com>freedman at freeformit.com> wrote: > > > > so, in the case where they both differ, how will we know which > time will be > > > associated with a file? > > > >The first subvol mentioned in the list is considered, if it is down, > >then the next is considered. > >ok, so I made sure that my subvolume list on the servers is in the same order. >I had always listed the local volume first and the remote one second, >but it sounds like this would lead to each node using it's own >timestamps or do all the servers in the AFR elect a preferred 'first' subvol? > > > > and will it fix the on-disk stamp or just ignore it provided the other > > > subvol is online? > > > >It will not fix the time stamp if they differ. > >how about new files being replicated.. they'll get the timestamp of >the server from which the source file is available? > >in other words.. if I add a new empty volume, and AFR copies >everything to it... what dates will be on the local files? > > >During self-heal afr sets the timestamps (atime and mtime) to that >of the file on the source node. this works fine. to solve my problem, I created a script which gets the file times for each file and creates a set of "touch -d " commands to set the dates on the other server. that was preferable to deleting the directory tree and having things auto-healed since it's roughly 12 GB's And, it seems it's not something that would be a problem in the future. Keith
