The client has a follows of 0 initially, which is correct (it does follow
0, and there are no prior snaps). But the inode has ->first of 2, which
is also fine. The follows here needs to be at least higher than the
inode first, though, or the caps cloning gets off...
In 551a12f52e36 we fixed a bug with cow_inode() where the
cap->client_follows didn't match last precisely. Instead, we compare
to first. But the == is too strict.. cap follows that is equal _or_older_
than the clone's first should be copied to the clone inode.
This fixes the simple test case
$ echo asdf > bar ; mkdir .snap/bar ; rm bar ; cat .snap/bar/bar
asdf
(Previously we would get nothing unless we waited for the cap to flush on
its own.)
This fixes pretty core behavior when doing recursion down the tree. I
suspect it was broken when changing the retry behavior.
Signed-off-by: Sage Weil <sage@newdream.net>
We may not want to recursively call crush_choose() if we start out with a
leaf. If that happens, we need to fill out the out2[] vector with
our result immediately.
Signed-off-by: Sage Weil <sage@newdream.net>
Fill in the out2 choose_leaf vector if it's defined. This is necessary
because we may not recursively call choose on out2 if the item we're on is
not a bucket (e.g., when chooseleaf is given the leaf type 0).
Signed-off-by: Sage Weil <sage@newdream.net>
[ The following text is in the "UTF-8" character set. ]
[ Your display is set for the "iso-8859-1" character set. ]
[ Some characters may be displayed incorrectly. ]
inspired by the addition to
http://ceph.newdream.net/wiki/Snapshots about the snapdirname
option i've created a patch for the mount.ceph manpage
- Thomas
Signed-off-by: Sage Weil <sage@newdream.net>
This should avoid
#0 0x00007f41b1a18a75 in raise () from /lib/libc.so.6
#1 0x00007f41b1a1c5c0 in abort () from /lib/libc.so.6
#2 0x00007f41b22cd8e5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#3 0x00007f41b22cbd16 in ?? () from /usr/lib/libstdc++.so.6
#4 0x00007f41b22cbd43 in std::terminate() () from /usr/lib/libstdc++.so.6
#5 0x00007f41b22cbe3e in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x00000000005b39f8 in ceph::__ceph_assert_fail (assertion=0x5ec3b2 "seq >= last_committed_seq", file=<value optimized out>, line=711, func=<value optimized out>) at common/assert.cc:30
#7 0x00000000005649e1 in FileJournal::committed_thru (this=0x1116310, seq=0) at os/FileJournal.cc:711
#8 0x000000000055d265 in JournalingObjectStore::commit_finish (this=0x1125740) at os/JournalingObjectStore.cc:186
#9 0x00000000005543f3 in FileStore::sync_entry (this=0x1125740) at os/FileStore.cc:1714
#10 0x00000000004ef93d in FileStore::SyncThread::entry() ()
#11 0x0000000000469a4a in Thread::_entry_func (arg=0x6315) at ./common/Thread.h:39
#12 0x00007f41b28ab9ca in start_thread () from /lib/libpthread.so.0
#13 0x00007f41b1acb6cd in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()
Signed-off-by: Sage Weil <sage@newdream.net>
- only need to do it once, by connecting to a random monitor, not for
each monitor
- not sure we should try it every time we start the monitor for all time,
as opposed to once after mkfs, or whenever the admin chooses to load
new classes
We need the store in a consistent state on commit, which means flushing
transactions such that we have all ops <= a given seq applied. That is
handled by the commit_start()/commit_started() pair, but will only include
ops in the FileStore queue if we op_start when it is initially queued.
Which is exactly what we want, because the queue can reorder things, so
stopping just currently-being-applied updates will only keep transactions
atomic but not ordered.
Yup!
