Feature #630
closedrelease caps on inodes unlinked by other clients
0%
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.
Updated by Sage Weil over 13 years ago
- Translation missing: en.field_position set to 1
Updated by Sage Weil over 13 years ago
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..
Updated by Sage Weil about 13 years ago
- 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.
Updated by Sage Weil about 13 years ago
- Assignee changed from Yehuda Sadeh to Greg Farnum
Updated by Greg Farnum about 13 years ago
- Assignee deleted (
Greg Farnum)
Putting this back in the queue since we've pushed it back past 1.0.
Updated by Sage Weil over 12 years ago
- Translation missing: en.field_position deleted (
185) - Translation missing: en.field_position set to 738
Updated by Zheng Yan over 9 years ago
dup of #5039. already fixed by commit f8a947d92 client: trim deleted inode