At 11:00 PM 12/29/2008, Krishna Srinivas wrote: >Keith, > >It was fixed in the sense, AFR will return stat of the same subvol >everytime, before it used to return stat from one of the subvols. But >still if the subvol-server clock is different than that of client, the >time stamp will be of the server and not client. so, in the case where they both differ, how will we know which time will be associated with a file? and will it fix the on-disk stamp or just ignore it provided the other subvol is online? ideally, it will pick one, and make sure all the others are 'reset' to that so that if the preferred vol goes offline, timestamps don't suddenly get weird. as for the server times differing. I suppose it's possible, if so it's by microseconds as they're both synced hourly to the universal clock via ntpd. >Krishna > >On Tue, Dec 30, 2008 at 12:22 PM, Krishna Srinivas ><krishna at zresearch.com> wrote: > > Keith, > > It was fixed in patch-804. > > Krishna > > > > On Tue, Dec 30, 2008 at 6:07 AM, Keith Freedman > <freedman at freeformit.com> wrote: > >> I have a problem with file mod times using AFR. > >> > >> this is really bad: > >> server1# ls -al vfc017.jpg > >> -rw-r--r-- 1 user1 group1 47660 2008-07-10 14:06 vfc017.jpg > >> server1# ls -alu vfc017.jpg > >> -rw-r--r-- 1 user1 group1 47660 2008-07-10 14:06 vfc017.jpg > >> > >> server2# ls -al vfc017.jpg > >> -rw-r--r-- 1 user1 group1 47660 2008-12-23 09:25 vfc017.jpg > >> server2# ls -alu vfc017.jpg > >> -rw-r--r-- 1 user1 group1 47660 2008-12-29 15:55 vfc017.jpg > >> > >> so, there are programs and such which look for files modified after a > >> certain date, and does stuff to them. > >> if this is a web app, for example, and it hits the server with the > >> newer date (the date AFR copied the file I presume?) then it thinks > >> every single thing is new and does it's processing. > >> > >> Shouldn't AFR set the file mod and create times to that of the > >> original source file? > >> > >> However, once it's in this state, I'm not sure how to fix it in an > >> automated way, but hopefully there will be a patch so that this > >> doesn't happen in the future. > >> > >> Keith > >> > >> > >> _______________________________________________ > >> Gluster-users mailing list > >> Gluster-users at gluster.org > >> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > >> > >
