All,
Posix allows access to file through open fds even if name associated with file
is deleted. While this works for glusterfs for most of the cases, there are
some corner cases where we fail.
1. Reboot of brick:
===================
With the reboot of brick, fd is lost. unlink would've deleted both gfid and
path links to file and we would loose the file. As a solution, perhaps we
should create an hardlink to the file (say in .glusterfs) which gets deleted
only when last fd is closed?
2. Graph switch:
=================
The issue is captured in bz 1259995 [1]. Pasting the content from bz verbatim:
Consider following sequence of operations:
1. fd = open ("/mnt/glusterfs/file");
2. unlink ("/mnt/glusterfs/file");
3. Do a graph-switch, lets say by adding a new brick to volume.
4. migration of fd to new graph fails. This is because as part of migration we
do a lookup and open. But, lookup fails as file is already deleted and hence
migration fails and fd is marked bad.
In fact this test case is already present in our regression tests, though the
test checks whether the fd is just marked as bad. But the expectation of filing
this bug is that migration should succeed. This is possible since there is an
fd opened on brick through old-graph and hence can be duped using dup syscall.
Of course the solution outlined here doesn't cover the case where file is not
present on brick at all. For eg., a new brick was added to replica set and that
new brick doesn't contain the file. Now, since the file is deleted, how do
replica heals that file to another brick etc.
But atleast this can be solved for those cases where file was present on a
brick and fd was already opened.
3. Open-behind and unlink from a different client:
==================================================
While open-behind handles unlink from the same client (through which open was
performed), if unlink and open are done from two different clients, file is
lost. I cannot think of any good solution for this.
I wanted to know whether these problems are real enough to channel our efforts
to fix these issues. Comments are welcome in terms of solutions or other
possible scenarios which can lead to this issue.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1259995
regards,
Raghavendra.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
