Closed gsparrow closed 6 years ago
I have a fix in the commit above. Needs integration testing.
resolved by e510acb21
Using master now this test fails again. It actually breaks all of the items in the pack so that none of them work. I rewrote a file with pftool and it did not cause this issue so it is not a production critical bug as far as I can tell.
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$ cat hello.1
goodbye
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$ cat hello.100
goodbye
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$ echo nuget > hello.100
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$ cat hello.1
cat: hello.1: Input/output error
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$ cat hello.101
cat: hello.101: Input/output error
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$ cat hello.100
cat: hello.100: Input/output error
dejager@stb-fta05:/marfs.dejager/mc/dejager/mHellos$
I can't reproduce this in the current rdma branch (i.e. rdma branches of erasureUtils, marfs, and pftool).
I suspect this was fixed somewhere between d1b718a5 and 53cecca26 in the marfs rdma lineage.
In conversation, I had mentioned concern about whether renames could also have problems, in whatever branch of code was being used to reproduce the problem. That was because of issue #200.
So, I've also tested renames of packed files (in the rdma branches), in the context of #171, and they seem problem-free, as well. A renamed packed file retains its identity in the packed file. If it is subsequently overwritten through fuse, the correct thing happens, acquiring new contents in a distinct object, and corresponding updates to MD.
Renaming does not cause the issue fortunately.
Can't reproduce the problem in marfs 1.10.
Can't reproduce this in 1.10
When creating packed files with PFTool, if after the initial creation, you then use a MarFS FUSE mount to overwrite one of the files that were packed, it fails to update the offset of the user.marfs_post extended attribute. This affects files whose offset were not 0 when in the packed object. The issue does not occur when the file is overwritten with PFTool, as evidenced by the test MarFS_issue_171_PFTool in Jenkins.
Below is a small reproducer, Named "MarFS_issue_171_FUSE" in Jenkins