Provide open and close callbacks to virtual filesystem implementation…#91
Provide open and close callbacks to virtual filesystem implementation…#91dkocher wants to merge 1 commit intodCache:masterfrom
Conversation
|
Can one of the admins verify this patch? |
|
ok to test |
…s as described in dCache#38. Signed-off-by: David Kocher <dkocher@iterate.ch>
kofemann
left a comment
kofemann
left a comment
There was a problem hiding this comment.
I was trying to do something similar, but at the end decided against it. It's not symmetric, e.q. the some calls accept stateid and have a undefined behavior. Have a look at https://github.com/dCache/nfs4j/blob/master/core/src/main/java/org/dcache/nfs/v4/FileTracker.java. I think it's quite close to what you want to achieve.
| Inode inode = context.currentInode(); | ||
|
|
||
| stateid4 stateid = Stateids.getCurrentStateidIfNeeded(context, _args.opclose.open_stateid); | ||
| context.getFs().close(inode, stateid); |
There was a problem hiding this comment.
This can trigger false evens it client tries to close invalid inode or stateid. I think this should be bound to state disposal
There was a problem hiding this comment.
Makes sense. We have worked around this by tracking the stateid in the virtual filesystem implementation.
| } | ||
|
|
||
| context.currentInode(inode); | ||
| context.getFs().open(inode, this.getAccessMode(_args.opopen.share_access), result.opopen.resok4.stateid); |
There was a problem hiding this comment.
you will mess all opens by file handle, which is quite common, when client already got hanlde by previous readdir, lookup or open.
|
|
3 participants
…s as described in #38.
Signed-off-by: David Kocher dkocher@iterate.ch