{"action":"created","issue":{"url":"https://api.github.com/repos/mar-file-system/marfs/issues/207","repository_url":"https://api.github.com/repos/mar-file-system/marfs","labels_url":"https://api.github.com/repos/mar-file-system/marfs/issues/207/labels{/name}","comments_url":"https://api.github.com/repos/mar-file-system/marfs/issues/207/comments","events_url":"https://api.github.com/repos/mar-file-system/marfs/issues/207/events","html_url":"https://github.com/mar-file-system/marfs/issues/207","id":363363159,"node_id":"MDU6SXNzdWUzNjMzNjMxNTk=","number":207,"title":"marfs_rename() should do trash_truncate on the destination","user":{"login":"jti-lanl","id":8238841,"node_id":"MDQ6VXNlcjgyMzg4NDE=","avatar_url":"https://avatars2.githubusercontent.com/u/8238841?v=4","gravatar_id":"","url":"https://api.github.com/users/jti-lanl","html_url":"https://github.com/jti-lanl","followers_url":"https://api.github.com/users/jti-lanl/followers","following_url":"https://api.github.com/users/jti-lanl/following{/other_user}","gists_url":"https://api.github.com/users/jti-lanl/gists{/gist_id}","starred_url":"https://api.github.com/users/jti-lanl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jti-lanl/subscriptions","organizations_url":"https://api.github.com/users/jti-lanl/orgs","repos_url":"https://api.github.com/users/jti-lanl/repos","events_url":"https://api.github.com/users/jti-lanl/events{/privacy}","received_events_url":"https://api.github.com/users/jti-lanl/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-09-25T00:02:45Z","updated_at":"2018-09-25T19:27:27Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"... otherwise, the storage for the destination is orphaned.\r\n\r\n`trash_truncate() `would preserve the MD xattrs in the trashed file, so GC could potentially find and reclaim the storage.\r\n\r\nThis comes up both for rename through fuse, and for the new rename-temp-file approach of pftool."},"comment":{"url":"https://api.github.com/repos/mar-file-system/marfs/issues/comments/424470750","html_url":"https://github.com/mar-file-system/marfs/issues/207#issuecomment-424470750","issue_url":"https://api.github.com/repos/mar-file-system/marfs/issues/207","id":424470750,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNDQ3MDc1MA==","user":{"login":"gransom","id":10716953,"node_id":"MDQ6VXNlcjEwNzE2OTUz","avatar_url":"https://avatars2.githubusercontent.com/u/10716953?v=4","gravatar_id":"","url":"https://api.github.com/users/gransom","html_url":"https://github.com/gransom","followers_url":"https://api.github.com/users/gransom/followers","following_url":"https://api.github.com/users/gransom/following{/other_user}","gists_url":"https://api.github.com/users/gransom/gists{/gist_id}","starred_url":"https://api.github.com/users/gransom/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gransom/subscriptions","organizations_url":"https://api.github.com/users/gransom/orgs","repos_url":"https://api.github.com/users/gransom/repos","events_url":"https://api.github.com/users/gransom/events{/privacy}","received_events_url":"https://api.github.com/users/gransom/received_events","type":"User","site_admin":false},"created_at":"2018-09-25T19:27:27Z","updated_at":"2018-09-25T19:27:27Z","author_association":"CONTRIBUTOR","body":"See Jeff was first, but I'll post this whole thing anyhow since I've already bothered to type it up.\r\n\r\nIf I'm understanding Jeff correctly, this refers to the fact that MarFS can't just do a simple rename of its metadata info.  Each MarFS metadata file exists on GPFS, but contains a reference to MarFS objects in its xattrs.  If MarFS blindly performs a metadata rename (rename of the GPFS metadata file), then the destination file will get overwritten and those xattrs will simply be lost.  As those xattrs contain our only reference to the corresponding data object(s), those objects will now be orphaned.  Instead, we need to have MarFS first perform a 'trash' of the destination, marking its data objects for deletion, before then doing the rename of the source (as normal) which would overwrite the metadata file of the dest.\r\nHope this helps.\r\n\r\nThere is more to be discussed here regarding the safest way to do this.  We want to avoid race conditions in which a destination file can be trashed (marked for deletion) but not actually be overwritten by the rename and thus still be user accessible until a GC run.  I suspect we may want to consider slapping a restart xattr on the dest before doing anything else, indicating to both the user and the system that the rename has rendered that destination unreadable (maybe trashed, maybe not).  If it hasn't, and the operation aborts, no worries because the next op that tries to overwrite will trash it properly.  If it has, and the operation aborts, maybe we end up with duplicate info in the trash.  That shouldn't be a problem though.  I think the GC may handle double deletions without issue.  Definitely better in principle than orphaned objs."}}
{"actor":{"display_login":"gransom"}}