Bug 1465462 - stale file handles leads to data loss on loss of client side quorum
stale file handles leads to data loss on loss of client side quorum
Status: CLOSED NOTABUG
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: replicate (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Ravishankar N
nchilaka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-27 09:31 EDT by nchilaka
Modified: 2017-06-27 09:56 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-27 09:56:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description nchilaka 2017-06-27 09:31:18 EDT
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 09:50:11 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.