[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-devel
Subject:    Re: CephFS mount delay
From:       Noah Watkins <jayhawk () cs ! ucsc ! edu>
Date:       2012-08-30 22:55:54
Message-ID: CAPrxi59g8bQj9FZh32GMrg17H6ggN+5FYSaZDwnZz3ds_RwEeA () mail ! gmail ! com
[Download RAW message or body]

The delay is indefinite (I was killing it after >3 minutes).
Interestingly, this "first mount" hang issue is not present after a
restart of a fresh file system (./vstart.sh -n), but always occurs if
I restart with an existing file system untouched (./stop.sh &&
./vstart).

- Noah

On Thu, Aug 30, 2012 at 3:47 PM, Gregory Farnum <greg@inktank.com> wrote:
> On Thu, Aug 30, 2012 at 3:44 PM, Noah Watkins <jayhawk@cs.ucsc.edu> wrote:
>> On Thu, Aug 30, 2012 at 3:39 PM, Sage Weil <sage@inktank.com> wrote:
>>> On Thu, 30 Aug 2012, Noah Watkins wrote:
>>>
>>> I think this is just the mds reconnect delay; it's complete normal when
>>> the mds restarts and some of the clients also crashed that it has to wait
>>> for the full reconnect window to pass.
>>
>> Are you talking about the clients running during the restart? In the
>> case I'm describing I bring down all daemons and the client, before
>> starting the cluster and re-running the test.
>
> How long a hang have you observed? Since you brought down a client,
> the MDS needs to wait through a full time-out period before letting
> other people do things (it's giving the previous client a chance to
> claim some state). The default looks to be 45 seconds right now.
>
> But the patch shouldn't have changed that behavior in any way; so if
> it's actually different behavior in testing then we just
> broke...something else, somehow...
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]