In arla's xfs we do the following:
> a) ->d_count becoming atomic.
We check for d_count to decide if we are the sole owner of a dentry
and if it's available to throw away. How are we supposed to throw
away a dentry? Today we do:
if (dentry->d_count == 0) {
dget(dentry);
d_drop(dentry);
dput(dentry);
/* ... */
}
> b) ->d_delete() becoming non-blocking.
Safe on that (we do not do anything in d_delete).
> c) unsafe dget() calls being protected by spinlock (unsafe == ones where
> we don't keep at least one reference to the thing).
Sure, will pass that one too.
> d) same spinlock covering the beginning of dput() - up to the point where
> dentry is excluded from the lists or left alone.
It's not really clear to us what you mean. Should we grab the
spinlock (that we assume will appear in `struct dentry') around the
call to dput?
> e) code that walks ->d_alias/->i_dentry or ->d_subdirs/->d_child moves to
> VFS proper. Each of these pieces should go under the spinlock and end
> with
> dget(). This code should skip unhashed dentries.
We do walking of the lists to invalidate all lower (d_subdirs)
dentries when a directory is invalidated.
> f) _all_ places that check for ->d_count should be either exterminated or
> get an attempt to unhash in front of them. The only valid checks being
> "are we the sole owners of dentry".
This is not really clear either. Do you mean that code that checks
dentries (and isn't sole owner test) should unhash, check d_count and
then rehash ?
> g) manipulation with lists (see above + d_lru/d_hash) are protected by
> the
> same spinlock.
>
> Potential problems:
> 1) 3rd-party code using the lists. Folks, if your code does that - TELL
> ABOUT THAT HERE.
We walk the lists when a node is invalidated (above case). We also
walk d_alias to find if this name in the dentry tree is already
installed, or if we should install a new dentry.
> The bottom line: if you are maintaining an out-of-tree filesystem
> that uses dcache in non-trivial way - either post on fsdevel or get in
> touch with me in any other way ASAP. If you don't - well, you have
> yourself to blame when your code will break. This change is _really_
> needed; it had been requested many times; 2.3 is an unstable branch;
> you are warned.
We are sure that our code will break, and we're happy that you tell us
what the plan was before doing it. Thanks.
Love
arla-hacker
