mds: acquire_locks in callers, not rdlock_path_* helpers

This way we only call acquire_locks from one place, and avoid weird lock
reordering issues.

mds: refactor path_traverse, callers

Mainly, we want path_traverse to do the work of giving us back the inode
the final dentry links to.  Simplify callers to use it.

todo

vstart: behave a bit better when sudoing

kclient: allocate cap releases outside of spinlock

kclient: use FLUSH cap op on cap writeback

This is just to make the message logs easier to read.  The only
real distinction is that a FLUSH won't release caps, only write
dirty ones back.

kclient: only check auth cap for WRBUFFER, max_size checks

kclient: switch check_caps interface to use flags field

kclient: fix setxattr

This was broken ages ago with the mds client interface was switched
up a bit.

kclient: kill ceph_release_caps and check_caps drop arg

kclient: fix up cap/wanted delayed release logic

mds: don't reissue caps on embedded request releases

mds: default to issue_caps in file_eval, _unless_ we are dropping caps

mon: make log messages a bit nicer

mds: journal max_size update as loner, if any

This avoids calling file_excl if the lock is already LOCK_EXCL.

kclient: less chatty

mds: include cap, dentry lease release in request messages

Embed dentry and cap releases inside mds request messages.  This
avoids the overhead of sending additional messages, although it
does limit the release to the mds the request is going to.  That
is normally fine, since updates go to the auth MDS, and that is
usually who we're dealing with.

mds: avoid dup change_max in _do_cap_update

Set a flag to prevent issue_caps from checking the max_size (since
we're about to journal that update anyway).  This avoids some dup
cap messages.

kclient: dequeue cap on non-drop send caps

If we are doing a full update (i.e., not a drop, where wanted is
censored), remove ourselves from the delay queue.

mds: drop 'careful' caps concept

This was originally needed before we were smart about projected
vs non-projected values, and making them visible to only the
xlocking or excl client.  No more.

mds: choose reasonable state after xlock finishes

mds: better max_size lock checks when EXCL

Choose an appropriate lock state to change to when we need to
journal a max_size update (-> 0, usually).

mds: stay in EXCL and keep loner until wrlocks drain

Otherwise we go to MIX and revoke caps from the loner, which is
lame.

mds: clean up can_wrlock() so that it checks of loner

Previously the EXCL state/cap check was outside of can_wrlock,
which is yucky.

mds: replace WANT cap op with DROP

While it's not always clear when we are expanding wanted (bc the
client may have skewed perception of mds_wanted), it IS always
clear when we are explicitly _dropping_ caps and don't want them
reissued to us.  And that's the behavior we're trying to avoid
anyway.

mds: use EXCL instead of LOCK to adjust max_size if loner

mds: don't rdlock_try authlock for path_traverse permission check

We don't actually check anything anyway, just ping the lock.

If the client is trusted with AUTH_EXCL, this is pointless anyway.
It is only really useful with untrusted (e.g., fuse) clients, but
they'll need some sort of special support for that later.

mds: issue caps in file_eval only if needed, indicated by WANTED cap op

We can't always issue_caps in file_eval or cap releases won't work.

Sometimes the client wanted shrink is missed, though, and a wanted
expansion is sent that doesn't actually change wanted.  In those
cases, we DO need to issue caps.  Use a separate cap op WANTED so
the mds knows when the client is asking for caps.

mds: fix file_eval to issue caps from EXCL state

Before it wasn't getting called in some cases.

todo

kclient: only flush caps in write_inode if wait=1

The problem is that on delayed writeback, vm calls write_inode and
THEN writepages.  Which means we still have WRBUFFER caps used,
so sending a cap release then is somewhat counter productive.  If
we don't release wanted, we'll have to again later.  And if we do,
the mds will explicitly revoke our WRBUFFER caps so that it can
journal the max_size to 0.  Yuck.

So.  If wait, then do the cap flush immediately, as before.  If
!wait, queue up the caps at the front of the delay queue so that
it goes the next time we check_delayed_caps.  This catches the
sync() and umount cases (basically the same, really).

On fsync, queue the caps for write, but don't wait, since the mds
can recover the size/mtime anyway.

kclient: maintain min and max cap hold delays

Set a minimum amount of time we keep caps wanted bits even after
the file is closed.  Before that time, even if we are sending a
cap message, we tell the mds we still want the caps.  After the min
but before the max, we will tell the mds we no longer need them
IF we are sending a cap message for some other reason.

The caps_delay queue works as before based on the max timeout. When
that timer goes off, send a new message to release the wanted bits.

In most cases, this now releases wanted bits when we write back the
file size to the mds after writepages, which means only a single
message after we write and close a file.  Yay!

kclient: drop FILE_RD if !wanted and max_size non-zero

If we are dropping wanted and max_size is non-zero, the mds will
want to journal the update, which will mean syncing the lock and
recalling FILE_RD anyway.

mds: adjust mds client request format to include optional releases

The goal is to release caps and/or dentry leases in the same
message as the request we are dropping them for.  We will already
get caps/leases reissued with the response, in most cases.

Kill the mds replication hack while we're at it.  That should be
cleaned up if/when it is reincarnated.

mds: separate CREATE vs OPEN handling

These are now distinct ops.

mds: allow full dir lease (FILE_RDCACHE) on root ino

Now that root changes are persistent, and client looks at
rdcache_gen and not i_version anyway, this will work.

kclient: drop root ino special cases

Now that root ino changes are persistent on the mds, we can remove
various special cases that disallow I_CONTENT checks.

kclient: mark dentries with dir rdcache_gen, not i_version

The i_version may change if we are doing dir updates with an excl
lock on the dir, but our dcache should remain consistent over those
operations (unless we lack a trace, and fill_trace clears
I_COMPLETE in that case).  Instead, we want to effectively
invalidate prior dentries when we are _newly_ issued RDCACHE and
don't know what has changed... which is exactly what rdcache_gen is
for.

kclient: don't clear I_COMPLETE on dentry revalidate failure

I_COMPLETE + FILE_RDCACHE means we have the full set of dentries.
If a revalidating dentry is part of the current set, then it will
successfully revalidate.  The only reason revalidate would fail is
if the dentry is not part of the current set, or we don't hold
FILE_RDCACHE.. and in those cases clearing I_COMPLETE is either
wrong or unnecessary.  Revalidate will already fail when we lose
FILE_RDCACHE, or when a dentry is released, or when a new RDCACHE
is issued and our rdcache_gen changes.

kclient: reverse logic of O_CREAT create vs open check

todo

config: remove INSTALL_PREFIX

On a 'norma' install, it's /usr, which isn't helpful.  If anything, we
need sysconfdir, etc. individually.  Blech.

uclient: fix up caps some.  make dentry leases work

uclient: set fsid in statfs request

kclient: fix ino returned in fstat for 32 bit arch

kclient: don't alter mds_wanted caps if dropping caps

vstart: kill bashisms

kclient: remove alignment restrictions on O_DIRECT reads and writes

These aren't needed, since we aren't restricted by DMA to a hardware disk
device or any such thing.  (And even if they were, it'd probably be
sector alignment, not page alignment.)

mds: fix compilation error

mds: bump mds protocol

mds: add CEPH_CAP_OP_REVOKE

kclient: clear di->lease_session when dropping session

mds: flush log when expanding caps and filelock is unstable

mds, kclient: add CEPH_MDS_OP_CREATE operation

kclient: implement permission iop

The permission iop verfies we have a valid uid/gid/mode by checking for
the AUTH cap.  Then calls the generic helper.

This is 100% consistent because we don't carry a cap ref over the
permission checkout.  OTOH, if we don't hold the cap and the mds doesn't
actually issue it, we never will anyway.  Maybe fix this eventually.

kclient: make do_getattr take inode, not dentry

kclient: d_alloc_anon on older kernels

mds: make sure kick wasn't immediatley fruitful in rdlock_try

mds: simplify EMetaBlob interface - don't pass explicit inode_t pointer

It is always in->get_projected_inode().

mds: fix journal replay

Load root inode before replaying journal.  Kill root special case in
journal replay.  Replay root inode if it is journaled.

mds: journal projected inode values by default

There was a bug in here that was journaling _old_ inode values.  Doh!

vstart: run valgrind properly

todo

mds: make mds restart work

Root mds needs to load root inode, .ceph directories.

mon: fix mds stopping and restart

Remove stopped mds from last_beacon (monitoring) set.  Fix mdsmap dump
output to include stopping set.  Remove mds from stopped set on start.

mds: fix permissions checks on root, system inodes

mds: journal root inode changes

Journal root inode changes, and flush them when trimming the log segment.

mds: inode fetch/store

objecter: only send one ping per laggy osd

objecter: add support for compound read ops (ObjectRead)

osd: implement GETXATTR read op

kclient: better readdir debug output

mds: make rdlock_try kick the lock if it blocks

We were strangely getting by even though it wasn't changing the lock
state.  Weird.

mds: issue AUTH_EXCL on mkdir

Client is clearly an exclusive user, and will often chmod.

kclient: drop LINK_RDCACHE cap on rename source inode

This is only needed because the mds locks the srci linklock.  It has to
lock _some_ field on the source inode in order to make and propagate the
ctime change; the linklock is generally the least contended.  So humor
the mds...

kclient: update cap->mds_wanted on revocation reply

Make sure our local mds_wanted reflects the value sent off to the mds
during a revocation.

mds: do not want LINK caps for any open file; no non-FILE caps when readonly

When readonly, we don't want anything other than FILE caps.  (The mds
will of course give us more when it can.)

For WR and RDWR, we still want AUTH and XATTR caps, for now, since there
is some possibility that the client will want to change them.

kclient: drop any unwanted caps when unlinking a file

Since we can't reopen an unlinked file, there's no reason to hold on to
them.  And the MDS will often want to lock to update max_size, which could
mean spurious revocations.  At the very least, make sure we drop the LINK
caps.

Do the same for the rename target, if it exists.

kclient: send messages with default priority (to match mds)

Make our default priority match the mds.  This is only important because
we occasionally resend and incoming message out again without fixing the
priority to match our default, which means out-of-order processing on
the other end.

msgr: show seq # of incoming messages

mds: alloc wrlock by EXCL client

Not sure why this was off.  It is allowed in EXCL_MIX...

mds: don't issue new caps with a revocation

This is a really just a heuristic...

kclient: queue inode for cap check if mds_wanted mismatch

If mds_wanted in add_cap is more than we actually want (for
example, on a getattr that races with a cap wanted release),
requeue a cap check.  We don't want to release immediately if we
can help it because something like readdir would prematurely (?)
release caps we're holding on to for good measure...

mds: fix wanted updates

Check issue_seq, not seq, for wanted updates.  We're primarily
worried about racing against a lookup+open, which means we only
need to worry about an _issue_ (not a cap grant or revocation).

Allow wanted _expansion_ even if seq mismatch, though!

mds: clean up issue_new_caps interface

kclient: fix session leak

kclient: grab inode before queue_cap_snap; cleanup

kclient: fix some log messages

uclient: mksnap/rmsnap via mkdir/rmdir

uclient: remove some dead code

kclient: protect realm->inodes_with_caps_lock

kclient: protect session->s_caps list with s_cap_lock

kclient: adjust caps accounting a bit

Keep track of caps avail (size of caps reserve list).

kclient: link snap dentry for MKSNAP as well as LOOKUPSNAP

Also, set is_dentry = 1 to prevent the notrace handler(s) from doing
another lookup.

mds: include target inode in mksnap result

kclient: fix readdir dup requests

We want to request a new frag if the offset is _before_ the one we
have cached (i.e., we need to back up or start over).  Not after.

This was making a final readdir at the end of the directory do
an extra mds request.  Der.

uclient: fix up snapped path generation

uclient: fix reply trace

uclient: fix root inode open on mount; fix readdir

uclient: use new mds protocol for replies

A 'walk' now works.