Actually we're a bit conservative in a few places since the wanted check
is a bit more expensive. We always do a full check in try_to_expire, so
much of the time we can do the quick check only.
If they're unwanted, it's no biggie to fail to reconnect the cap. And
Locker::adjust_cap_wanted() already adjusts the open_file logseg lists in
this way, so let's just totally consistent.
We can get a capless inode here if we replay an open file, the client
fails to reconnect it, but does REPLAY an open request (that adds it
to the logseg). AFAICS it's ok for the client to replay an open on a
file it doesn't have in it's cache anymore.
If there are waiters for a later version of the dir to hit
disk, then we need to recommit as soon as the prior commit
completes. We auth_pin on adding the first waiter, and do
not unpin until removing the last waiter, so this doesn't
break auth_pin rules.
Previously we could stall because we didn't finish the
waiter (on the later version) but also never started the
commit. Sometimes we would get lucky and someone else would
ask for a commit, but sometimes not. We would then see old
LogSegments that would never get fully expired.
When the client has an excl lock on an inode, and it's
stating a snapped version of it, we can't expect it to
put 2 and 2 together and look at it's head metadata. If
the cap does not follow the snapid we're trying to stat, do
the full rdlock to force the snapped values back to the
mds so we can do the cow.
If there is nothing cow, the cap will get reissued with an
accurate follows value, and we won't have to do this again.
We may load a dir version off disk that is older than the
in-core version (because we got newer data from the
journal, say). When marking underwater items clean, do
so based on the _loaded_ version, not out in-core version.
finish_recovery needs to set up a callback for when the current set of
changes commit to disk (to kickstart cleanup of strya replicas etc). We
can't call apply_transaction this deep inside the call chain without
causing problems. So, pass a list of completion contexts all the way down
so that we can set up the completion callback.
This is more helpful than assert(0). It's still bad (it means the client
and osd calculated different pg mappings) though, but this makes it easier
to identify and fix.
The old hash (from linux dcache) was very weak, such that
least sig bits may not change and you could get lots of
consecutive objects on the same osds (because lsbits of the
pg weren't changing).
This is Robert Jenkin's hash and is quite strong. Public
domain.
Rev osd disk format, protocol, since we're totally changing
object placement here.
