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>
- send_push_op() does a push, nothing else
- push_start() starts a primary->replica push, tracks state
- push_to_replica() ensures we push head first, calculates cloning, etc.
This will slow down writes to degraded objects because we will wait for it
to recover before applying the write. OTOH it will be robust in the case
of large objects. We can optimize the small object update (and overwrite)
cases later.
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>
