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
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.