Need to initialize created and current_parent_since on new snaprealms
when they are created, or else we get incorrect results from the likes of
SnapRealm::get_snap_info() (e.g., parent snaps from before we were
created).
This prevents bleed through of failures (due to not getting hearbeats, due
to us being marked down) so they don't get sent after we are marked back
up again.
This fixes one possible source of up/down flapping...
Make sure the pool exists before calling OSDMap::raw_pg_to_pg(). Fixes
crash on operations shortly after pg pools are created.
Signed-off-by: Sage Weil <sage@newdream.net>
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>
Sage Weil
Yehuda Sadeh
Greg Farnum
Christian Brunner