Are negative dentries the right abstraction in the first place?

A bloom filter is a probabilistic data structure with two operations: insert and query. You insert keys (usually strings), and can later query for whether a given key was inserted. The filter will return either "maybe" or "no." This isn't useful as a direct substitute for negative dentries, because (assuming the keys represent non-existing dentries) both answers require us to take the slow path. We would need a data structure that returns "maybe" or "yes" (so that we can skip the slow path on a "yes").

Unfortunately, all of the materials I found on the web suggest that the closest equivalent to such an "inverse Bloom filter" is some kind of cache, which is exactly what negative dentries already are.

So then the question is whether we're allowed to make more substantial refactors. For example, we might give each directory a lazily-initialized bloom filter. Initially, the directory would use negative dentries as in the current design. If the directory is ever fully scanned, however, we would take the opportunity to initialize the bloom filter with all of the *positive* dentries we find on disk, then delete all of its negative dentries and consult the bloom filter instead of looking for negative dentries. We would then need to keep the bloom filter up to date by inserting newly created dentries as we go. If the filter gets too full, we would erase it and go back to using negative dentries until it can be re-initialized. As a bonus, newly-created directories are initially empty, and can be initialized with an empty bloom filter immediately.

Obviously, there are serious concurrency hazards to this approach. My assumption is that the filesystem is capable of guarding against those hazards without a serious performance penalty (because it already must do so for regular read-write conflicts anyway). But I might be wrong about that.