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@xxxxxxxxxxx> wrote: > On Thu, Aug 30, 2012 at 3:44 PM, Noah Watkins <jayhawk@xxxxxxxxxxx> wrote: >> On Thu, Aug 30, 2012 at 3:39 PM, Sage Weil <sage@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
