Zach Brown 829126790b scoutfs: retry stale btree and segment reads ...

We don't have strict consistency protocols protecting the "physical"
caches that hold btree blocks and segments.  We have metadata that tells
a reader that it's hit a stale cached entry and needs to invalidate and
read a the current version from the media.

This implements the retrying.  If we get stale sequence numbers in
segments or btree blocks we invalidate them from the cache and return
-ESTALE.

This can only happen when reading structures that could have been
modified remotely.  This means btree reads in the clients and segment
reads for everyone.  btree reads on the server are always consistent
because it is the only writer.

Adding retrying to item reading and compaction catches all of these
cases.

Stale reads are triggered by inconsistency.  But that could also be
persistent corruption in persistent media.  Callers need to be careful
to turn their retries into hard errors if they're persistent.  Item
reading can do this because it knows the btree root seq that anchored
the walk.  Compaction doesn't do this today.  That gets addressed in a
big sweep of error handling at some point in the not too distant future.

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

2017-12-20 12:21:13 -08:00

kmod

scoutfs: retry stale btree and segment reads

2017-12-20 12:21:13 -08:00

Description

No description provided

8 MiB

Languages

C 87%

Shell 9.3%

Roff 2.5%

TeX 0.8%

Makefile 0.4%