On second thought, this corner case is triggered only for cases where reopen after handshake is failed. Hence this definitely is not a regression and we can ignore this case.
----- Original Message ----- > From: "Raghavendra Gowdappa" <rgowd...@redhat.com> > To: "Pranith Kumar Karampuri" <pkara...@redhat.com> > Cc: "Anand Avati" <aav...@redhat.com>, "Amar Tumballi" <atumb...@redhat.com>, > "devel" <gluster-devel@nongnu.org>, > "Mohammed Junaid" <jun...@redhat.com> > Sent: Monday, January 7, 2013 4:46:59 PM > Subject: Re: [Gluster-devel] Need review for client-reopen changes > > Pranith, > > This comment is on the second patch. While the implementation looks > fine, I've some concerns related to the idea itself. Consider > following situation with a replicate volume of two subvolumes: > > 1. process 1 (p1) acquires a mandatory lock. > 2. stop first server, replace disk > 3. reopen of fd opened by p1 fail (since file is not present). > 4. self heal completes. parent is notified that child is up. However > fd is not opened yet. > 5. now, there is a possibility that another process p2 can > successfully write to another fd opened on the same file (on > server1), since lock (from p1) is not yet acquired on server1. > > Similar situation can arise even without this patch, but only when p1 > and p2 are not running on same mount point. With this patch it can > happen even on single mount point too. I am not sure whether we can > ignore this corner case. Others, please let us know your opinion on > this. > > regards, > Raghavendra. > > ----- Original Message ----- > > From: "Pranith Kumar Karampuri" <pkara...@redhat.com> > > To: "devel" <gluster-devel@nongnu.org> > > Cc: "Raghavendra Gowdappa" <rgowd...@redhat.com>, "Krishnan > > Parthasarathi" <kpart...@redhat.com>, "Jeff Darcy" > > <jda...@redhat.com>, "Amar Tumballi" <atumb...@redhat.com> > > Sent: Monday, January 7, 2013 10:15:36 AM > > Subject: Need review for client-reopen changes > > > > hi, > > http://review.gluster.org/#change,4357 > > http://review.gluster.org/#change,4358 > > > > are the changes I made to handle re-opens of files in the case > > where > > a disk is replaced while a brick is offline. The idea is to attempt > > re-opens after self-heal completes and the file could be opened. > > With these changes readv/fxattrop/writev/findelk for fds with > > remote-fd -1 are attempted using anon-fds and if the fop succeeds > > then the re-open is attempted for every 1024th success. 1024 is an > > arbitrary number I used. The re-open of files could fail because of > > posix lock re-acquisition failure, that is the reason re-opens are > > attempted periodically (for every 1024 successful fops on that fd). > > > > I think the re-attempt logic could be better. > > For instance, we can attempt re-open on the first success on > > anon-fd > > instead of waiting till 1024th success and if this re-open fails we > > could fall-back on 'periodic attempts' i.e. for every 1024 > > successes > > on the anon-fd. > > > > Let me know your thoughts. > > > > Pranith > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel