Bug 1465462

Summary: stale file handles leads to data loss on loss of client side quorum
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Nag Pavan Chilakam <nchilaka>
Component: replicateAssignee: Ravishankar N <ravishankar>
Status: CLOSED NOTABUG QA Contact: Nag Pavan Chilakam <nchilaka>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rhgs-3.3CC: nchilaka, pkarampu, rhs-bugs, storage-qa-internal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-27 13:56:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nag Pavan Chilakam 2017-06-27 13:31:18 UTC 
Description of problem:
========================
i was trying to verify bz#1463104 - lk fop succeeds even when lock is not acquired on at least quorum number of bricks "

on a 1x3 volume I observe that after an fd is opened on a file and the client quorum is lost , this leads to data loss

I came up with below scenario while verifying it (mentioned in steps)



Version-Release number of selected component (if applicable):
=========
3.8.4-31

How reproducible:
==========
3/3

Steps to Reproduce:
1.create a 1x3 volume(mine was a 2x3) and set client quorum to auto(51%)
2.create a file say f1 and write some data (even a single line will help)
3.now open an fd on this file using "exec 1002>f1"
4. Now bring down b1 and b2 of a replica pair
5. now check the file in backend or do a cat of f1 from mount


Actual results:
========
you won't see the data it should have. Even on backend bricks that data would be lost
Comment 2 Pranith Kumar K 2017-06-27 13:50:11 UTC 
I think exec > f.txt will truncate f.txt if I understand correctly.

This is on plain XFS.
pk@dhcp35-190 - ~ 
19:17:32 :) ⚡ echo abc > a.txt

pk@dhcp35-190 - ~ 
19:17:42 :) ⚡ cat a.txt 
abc

pk@dhcp35-190 - ~ 
19:17:44 :) ⚡ exec 5>a.txt

pk@dhcp35-190 - ~ 
19:18:00 :) ⚡ ls -l /proc/self/fd
total 0
lrwx------. 1 pk pk 64 Jun 27 19:18 0 -> /dev/pts/0
lrwx------. 1 pk pk 64 Jun 27 19:18 1 -> /dev/pts/0
lrwx------. 1 pk pk 64 Jun 27 19:18 2 -> /dev/pts/0
lr-x------. 1 pk pk 64 Jun 27 19:18 3 -> /proc/2767/fd
l-wx------. 1 pk pk 64 Jun 27 19:18 5 -> /home/pk/a.txt

pk@dhcp35-190 - ~ 
19:18:05 :) ⚡ ls -l a.txt
-rw-rw-r--. 1 pk pk 0 Jun 27 19:18 a.txt

pk@dhcp35-190 - ~ 
19:18:36 :) ⚡ exec 5>&-

Could you close this as NOTABUG in case this is what you are calling it as the BUG. I think this is expected.