Journal the client's safe tid with new requests. This keeps the client
completed_requests list trimmed, so that we don't build up a ginormous
list of all requests over the entire journal.
Forward rolling mds format change.
Attaching mdsdir to the root hierarchy means that random mds X
can't push replicas of everything needed for mds Y to reach a
stray item, because Y may not have the /.ceph/mds# dentries and
inode. So detach myin from the hierarchy.
This simplifies startup/mkfs somewhat because non-root mds's
don't have to traverse through /.ceph.
We can still make it reachable via /.ceph/mds# with a remote
dentry (although we haven't done that yet).
MDS stopping is currently broken, since we can't export the stray
dir any more (it's auth mds fixed).
We use OPENING state to indicate sessions that are being
imported. Fix get_or_add_open_session() to NOT set the session
state (except to STATE_NEW if new) so that the caller can do
the right thing. Otherwise, the prepare_force_open_sessions()
can't tell if it just forced open a session (and needs it to be
OPENING) or if it was already open. Subsequently cap migrations
weren't working if the client didn't already have a session
open.
There is still a bug: if the import aborts, we have an OPENING
session with no actual open client_session message queued. Maybe
we should have a different state instead of OPENING... IMPORTING?
Handle the case where a new inode ref appears while we are
purging an inode. If so, we just truncate it to 0, so that next
time we go through purge_stray() we don't have to do the work
over again.
This can happen if a client goes snooping in the stray dir (or
who knows what else!).
There is no reason to track client on the per-pg AccessMode, since we only
care about read/write races on a per-object state, and need to track that
per-object anyway due to the new async commit/apply model. (Though this
is semi-broken even without that...)
Currently we will move from delayed to rmw, but there is no rmw->delayed
transition, since the logic for that is a bit more complex.. it'll be
difficult to determine when it is really a win.
In general, though, RMW is probably a better all around policy!
- fixed issue with normal write-behind journal (op_seq wasn't updated
inside the fs transaction)
- reworked journal interface to support write-behind, parallel, write-ahead
(hopefully)
