There was some weird thing where dirty items were added to the front of
the list in the EMetaBlob, dating from 2007. I have no idea why. But it
was breaking rename, which dirties the same inode twice in some cases
(same src and dst dir). Since it would replay in reverse, the inode would
end up with an older state. If that happened to be the last time the inode
was modified in the journal prior to an mds restart+replay, we'd get bad
dirstat/rstat metadata.
Signed-off-by: Sage Weil <sage@newdream.net>
I suspect the intent was to exclude snaps from parents from before we
existed. However, get_snap_info() already does that intelligently. And
get_oldest_snap() was wrong: this dirs snaps have little to do with
the nested snaprealms, old_inodes isn't a good indicator of birth time,
etc.
This fixes a bug where we couldn't see a snap in .snaps, but after the mds
restart could (because old_inodes included more old versions after
replay).
Signed-off-by: Sage Weil <sage@newdream.net>
I'm receving log output on every rados_initialize (... found mon0).
Since this makes the qemu-iotests fail, I'd suggest to lower the loglevel.
Christian
The pool snap mode determines where the snapc should come from. In
particular, if the client specifies no snap seq, but the pool is in
unmanaged snap mode, then use the client (empty) snapc, and do not generate
one from the pool.
The pool might have a snap seq that is > 0, leading to and totally
invalid(!) snapc like 2=[], e.g., because the pool seq was bumped to create
an unmanaged snapc by another client.
Signed-off-by: Sage Weil <sage@newdream.net>
We want to acquire_locks exactly once per path through the function.
Don't look at mdr->* yet if we haven't locked yet.
Signed-off-by: Sage Weil <sage@newdream.net>
For snap_caps, who cares if the live inode has a cap for this client. We
always want to issue the maximum set of caps the inode locks allow for
a live inode or snapped inode with caps, or the max caps ever for a snapped
inode without caps.
Signed-off-by: Sage Weil <sage@newdream.net>
configure is building radosgw as soon as libfcgi is installed, even
if --without-radosgw is given. Here is a fix for configure.in and the
specfile.
Regards,
Christian
Signed-off-by: Sage Weil <sage@newdream.net>
We need to close out client sessions, and caps, to empty the open_files
lists, so that we can properly trim the EOpen events from the log.
This fixes a crash like so:
mds/journal.cc: In function 'C_Gather* LogSegment::try_to_expire(MDS*)':
mds/journal.cc:160: FAILED assert(ls != this)
1: (LogSegment::try_to_expire(MDS*)+0x11c1) [0x90a1df]
2: (MDLog::try_expire(LogSegment*)+0x2d) [0x902c25]
3: (MDLog::trim(int)+0x55b) [0x902b0b]
4: (MDCache::shutdown_pass()+0xeb) [0x7d6aab]
5: (MDS::_dispatch(Message*)+0x2dc1) [0x71597f]
6: (MDS::ms_dispatch(Message*)+0x38) [0x712a44]
7: (Messenger::ms_deliver_dispatch(Message*)+0x63) [0x6fe07b]
8: (SimpleMessenger::dispatch_entry()+0x5fd) [0x6ef7e7]
9: (SimpleMessenger::DispatchThread::entry()+0x2c) [0x6e44b8]
10: (Thread::_entry_func(void*)+0x23) [0x6fd075]
11: /lib64/libpthread.so.0() [0x3552e06a3a]
12: (clone()+0x6d) [0x35526ddf3d]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is
needed to interpret this.
Reported-by: Henry C Chang <henry_c_chang@tcloudcomputing.com>
Signed-off-by: Sage Weil <sage@newdream.net>
This needs to be longer than the monclient hunt rate (currently 10s) so
that we succeed if we initially pick a down monitor.
Signed-off-by: Sage Weil <sage@newdream.net>
