Description of problem: it is possible to append a file in immutable and undeletable state on a file-based worm volume Version-Release number of selected component (if applicable): 3.11.2 How reproducible: [vagrant@client1 share]$ date && echo "testfile" >> testfile Wed Aug 30 09:03:51 CEST 2017 [vagrant@client1 share]$ date && rm testfile Wed Aug 30 09:04:07 CEST 2017 rm: cannot remove ‘testfile’: Read-only file system [vagrant@client1 share]$ date && echo "testfile" >> testfile Wed Aug 30 09:04:12 CEST 2017 [vagrant@client1 share]$ date && echo "testfile" >> testfile Wed Aug 30 09:05:17 CEST 2017 [vagrant@client1 share]$ date && rm testfile Wed Aug 30 09:05:21 CEST 2017 [vagrant@client1 share]$ Steps to Reproduce: 1.create volume. enable file-based worm 2.features.worm-file-level: on features.default-retention-period: 60 features.auto-commit-period: 5 3.follows steps in "how reproducible" Actual results: the file was appended Expected results: it should not be possible to append files in immutable undeletable state Additional info:
Created attachment 1320841 [details] sosreport client
Created attachment 1320842 [details] sosreport server
It is not appending any content to the worm-retained file. The problem here is when we do an append write we do not print the EROFS error. If you check the actual contents of the file after the append write it won't be changed. Try appending some new contents instead of doing echo "testfile" >> testfile which is same as the original content of the file. If you see the brick logs it will show the EROFS error message for the append writes. If you can see the new contents appended to the worm-retained/worm file, please let me know.
Karthik, See my results: [vagrant@client1 share]$ date && echo "test1" >> testfile Thu Sep 28 11:38:57 CEST 2017 [vagrant@client1 share]$ date && echo "test2" >> testfile Thu Sep 28 11:39:10 CEST 2017 [vagrant@client1 share]$ cat testfile test1 test2
Hi Jurgen Reij, Current code does not have the state transition mechanism in the write code path. This is a bug and we have a dependency on some other thing for this. Once that is fixed we will do transition in the write path as well, so the next writes will be blocked. Let me try to explain the scenario in your test. First you created the testfile. After 13 seconds you are trying to do append write, and expect it to be blocked since the auto-commit-period is 10secs. Since it is an append write, and not link, unlink, rename, or truncate (the only 4 fops which does the state transition in the current code), it won't check for the state transition and does the next write. So the content gets updated. Instead of checking only the date, check the stat of the file. The atime will point to a future value after state transition to worm-retained state which will then be equal to the "time at which transition happened + the retention period". In normal state it will allow append write. We will fix the behaviour so write fops will also do the state transition.
REVIEW: https://review.gluster.org/18560 (write once read many: file appendable in worm state) posted (#1) for review on master by Vishal Pandey (vpandey)
REVIEW: https://review.gluster.org/18560 (write once read many: file appendable in worm state) posted (#2) for review on master by Vishal Pandey (vpandey)
This issue is fixed in mainline by https://review.gluster.org/#/c/18560/ and will be available in the next release. Since version 3.11 is EOL closing this bug.