On Thu, Jan 12, 2017 at 4:35 PM, Raghavendra G <raghavendra.hg@xxxxxxxxx> wrote:
On Thu, Jan 12, 2017 at 9:20 AM, B.K.Raghuram <bkrram@xxxxxxxxx> wrote:cc'ing devel as well for some developer insight..---------- Forwarded message ----------
To: gluster-users <gluster-users@xxxxxxxxxxx>I had a question on the expected behaviour of simple distributed volumes when a brick fails for the following scenarios (as in, will the scenario succeed for fail) :- New file creation if that file name hashes to the failed brick
Fails- New file creation if that file name hashes to one of the remaining functional brickSucceeds- New directory creation if that file name hashes to the failed brick
Fails- New directory creation if that file name hashes to one of the remaining functional brickSucceeds. Layout is spread only to the functional bricks. Non-functional bricks are not part of layout of the directory. In other words files of the directory won't be stored in non-functional bricks
- File modifications/deletions if that file name hashes to the failed brickFails
Fails mostly. However, let's say if the inode of file has been looked up when hashed-brick was up, then operations succeed even if hashed-brick goes down later. Following sequence of ops succeed:
1. hashed-brick up
2. Lookup (file) => success
3. open (file) => success (fd)
4. hashed-brick goes down
5. write/read (fd) => success
Note that if the inode is cached in vfs/kernel after 2, even path based operations like stat, open, chmod etc can succeed if hashed-brick goes down immediately after successful lookup. The point is only fresh lookups fail if hashed brick/subvol is down.
- File modifications/deletions if that file name hashes to one of the remaining functional brickSucceeds
- Directory renames/deletions if that file name hashes to the failed brickFails
- Directory renames/deletions if that file name hashes to one of the remaining functional brickFails
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
--Raghavendra G
--
Raghavendra G
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users