Feature #630
closed
release caps on inodes unlinked by other clients
Added by Sage Weil over 13 years ago.
Updated over 9 years ago.
Description
If client A writes a file, and client B unlinks it, client A needs to drop the inode sooner rather than later.
Or, the MDS needs to delete file data as soon as a stray's wanted drops to 0.
- Translation missing: en.field_position set to 1
Sage Weil wrote:
Or, the MDS needs to delete file data as soon as a stray's wanted drops to 0.
That won't work, as the client is allowed to reopen a file and add to wanted if it holds the caps.
I think we need an additional cap message that's a hint to the client to drop the inode asap. Or, just a normal cap message that update's the client's nlink to 0 so that it knows it should drop it..
- Assignee set to Yehuda Sadeh
I think sending a client_caps to (other) clients with caps notifying them of nlink==0 is the way to do this without changing the protocol. Then the client can try to drop the inode('s dentry) immediately if that happens.
- Assignee changed from Yehuda Sadeh to Greg Farnum
- Target version changed from v0.25 to 19
- Assignee deleted (
Greg Farnum)
Putting this back in the queue since we've pushed it back past 1.0.
- Target version deleted (
19)
- Translation missing: en.field_position deleted (
185)
- Translation missing: en.field_position set to 738
- Tracker changed from Bug to Feature
- Project changed from Ceph to CephFS
dup of #5039. already fixed by commit f8a947d92 client: trim deleted inode
- Status changed from New to Resolved
Also available in: Atom
PDF