On 01/07/2013 04:46 PM, Raghavendra Gowdappa wrote:
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
hi,
Appreciate everyone for the code-reviews. I will make the
changes suggested to the code. Before that, Do you have any comments on
re-open attempts? Are you guys ok with waiting for 1024 successes every
time? is 1024 ok? or should it be more. I am not sure how to arrive at a
good number for this actually.
Pranith.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel