diff options
author | Nick Piggin <npiggin@kernel.dk> | 2011-01-07 17:49:23 +1100 |
---|---|---|
committer | Nick Piggin <npiggin@kernel.dk> | 2011-01-07 17:50:18 +1100 |
commit | fe15ce446beb3a33583af81ffe6c9d01a75314ed (patch) | |
tree | bc8af66b6dd2d0f21a2a3f48a19975ae2cdbae4e /Documentation/filesystems/porting | |
parent | 5eef7fa905c814826f518aca2d414ca77508ce30 (diff) |
fs: change d_delete semantics
Change d_delete from a dentry deletion notification to a dentry caching
advise, more like ->drop_inode. Require it to be constant and idempotent,
and not take d_lock. This is how all existing filesystems use the callback
anyway.
This makes fine grained dentry locking of dput and dentry lru scanning
much simpler.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Diffstat (limited to 'Documentation/filesystems/porting')
-rw-r--r-- | Documentation/filesystems/porting | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index b12c8953868..9e71c9ad310 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -318,3 +318,11 @@ if it's zero is not *and* *never* *had* *been* enough. Final unlink() and iput( may happen while the inode is in the middle of ->write_inode(); e.g. if you blindly free the on-disk inode, you may end up doing that while ->write_inode() is writing to it. + +--- +[mandatory] + + .d_delete() now only advises the dcache as to whether or not to cache +unreferenced dentries, and is now only called when the dentry refcount goes to +0. Even on 0 refcount transition, it must be able to tolerate being called 0, +1, or more times (eg. constant, idempotent). |