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" <address@hidden>
To: "devel" <address@hidden>
Cc: "Raghavendra Gowdappa" <address@hidden>, "Krishnan
Parthasarathi" <address@hidden>, "Jeff Darcy"
<address@hidden>, "Amar Tumballi" <address@hidden>
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