scoutfs_item_set_batch() first tries to populate the item cache with the
range of keys it's going to be modifying. It does this by walking
the input key range and trying to read any missing regions.
It made a bad assumption that reading from the final present key of a
cached range would read more items into the cache. That was often the
case when the last present key landed in a segment that contained more
keys. But if the last present key was at the end of a segment the read
wouldn't make any difference. It'd keep trying to read that final
present key indefinitely.
The fix is to try and populate the item cache starting with the first
key that's missing from the cache by incrementing the last key that we
found in the cache.
This stopped scoutfs/507 from reliably getting stuck trying to modify an
xattr whose single item happened to land at the end of a segment.
Signed-off-by: Zach Brown <zab@versity.com>