Zach Brown 77f25a71d5 scoutfs: stop overlapping inode index lock ranges ...

Lock names don't have minor.  They're a unique position in
type.major.ino with ino masked to groups.  Any index item is mapped to a
single lock.

But then each lock has a range of items that it covers.  The index item
key still has a minor from the bad old days of indexing time.  When
setting the range of keys covered by the lock name we set it to 0/~0 for
the range.

This is dead wrong because the minor is a higher priority than the inode
in the key space.  By setting the minor to 0/~0 we are saying that each
lock name covers *all the minors and inodes for that major*.  This is
wrong because there are multiple lock names for different inode groups
for each major.  We're in effect having the different lock names
associated with ranges that all overlap.

And this is very bad because it means that a lock can cache keys that
are covered by other locks.  An index item lock for a small inode can
accidentally create a negative item cache region for later inodes
covered by an entirely different lock.

We saw failures in scoutfs/500 because of this.  A node trying to
read an existing item would get enoent because it had a false negative
cached region from an unrelated lock that overlapped with the lock
that it just acquired from a writer and was trying to read the contents
from.

The fix is to just set the minor to 0.  We're not using it.  This stops
the lock names with fixed majors and inode ranges from accidentally
overlapping with each other.

Signed-off-by: Zach Brown <zab@versity.com>

2017-11-21 13:11:43 -08:00

kmod

scoutfs: stop overlapping inode index lock ranges

2017-11-21 13:11:43 -08:00

Description

No description provided

8 MiB

Languages

C 87%

Shell 9.3%

Roff 2.5%

TeX 0.8%

Makefile 0.4%