Hey Yan,
On 12-09-13 03:58, Yan, Zheng wrote:
> On Thu, Sep 12, 2013 at 3:26 AM, Oliver Daudey <[email protected]
> <mailto:[email protected]>> wrote:
>> Hey Yan,
>>
>> Just confirming that creating fresh pools and doing the newfs on those
>> fixed the problem, while restarting the OSDs didn't, thanks again! If
>> you come up with a permanent fix, let me know and I'll test it for you.
>>
>>
>
> Here is the patch, thanks for testing.
> ---
> commit e42b371cc83aa0398d2c288d7a25a3e8f3494afb
> Author: Yan, Zheng <[email protected] <mailto:[email protected]>>
> Date: Thu Sep 12 09:50:51 2013 +0800
>
> mon/MDSMonitor: don't reset incarnation when creating newfs
>
> Signed-off-by: Yan, Zheng <[email protected]
> <mailto:[email protected]>>
>
> diff --git a/src/mon/MDSMonitor.cc b/src/mon/MDSMonitor.cc
> index 9988d8c..b227327 100644
> --- a/src/mon/MDSMonitor.cc
> +++ b/src/mon/MDSMonitor.cc
> @@ -947,6 +947,7 @@ bool MDSMonitor::prepare_command(MMonCommand *m)
> ss << "this is DANGEROUS and will wipe out the mdsmap's fs, and
> may clobber data in the new pools you specify. add
> --yes-i-really-mean-it if you do.";
> r = -EPERM;
> } else {
> + newmap.inc = pending_mdsmap.inc;
> pending_mdsmap = newmap;
> pending_mdsmap.epoch = mdsmap.epoch + 1;
> create_new_fs(pending_mdsmap, metadata, data);
I can confirm that your one-line patch fixed the problem where the
objects in "metadata" are not recreated after stopping the MDSs,
cleaning "data" and "metadata", running a newfs and restarting the MDSs.
I haven't thoroughly tested if your patch breaks anything else, though.
Thanks for your help in finding this tricky one!
Regards,
Oliver
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
