[lustre-discuss] client showing "inactive device" at mount time

[Ben Evans]

I’m just going to guess, but you’ve got active/active OSTs, and some are running on the standby node.

A lustre client will contact the MGS on mount and get the list of MDTs and OSTs, along with their primary and secondary (etc.) locations.  The client then starts contacting the targets.  The thing is, that for any target, the client tries querying the primary location for the target, and has to wait for a timeout value before continuing on.  It then tries the secondary location, etc.  Combine that with targets not responding right away due to being busy, and you get the behavior you describe.

Try it on a quiescent system, where all targets are mounted on the primary server, and it will all happen pretty much instantaneously.

-Ben Evans

From: lustre-discuss <lustre-discuss-bounces at lists.lustre.org<mailto:lustre-discuss-bounces at lists.lustre.org>> on behalf of "Andrus, Brian Contractor" <bdandrus at nps.edu<mailto:bdandrus at nps.edu>>
Date: Tuesday, September 22, 2015 at 12:39 PM
To: "lustre-discuss at lists.lustre.org<mailto:lustre-discuss at lists.lustre.org>" <lustre-discuss at lists.lustre.org<mailto:lustre-discuss at lists.lustre.org>>
Subject: [lustre-discuss] client showing "inactive device" at mount time

All,

I have been seeing this pretty regularly.
I reboot a system and mount a lustre filesystem.
It mounts, but when I do ‘lfs df’, I see numerous OSTs that are listed as ‘inactive device’
If I wait, they all eventually mount. Odd thing is that I always get some that mount fine and others that wait that are both served by the same OSS.

Any insight as to why OSTs can take several minutes to mount on a client? There doesn’t seem to be any network issues or congestion.

Brian Andrus
ITACS/Research Computing
Naval Postgraduate School
Monterey, California
voice: 831-656-6238

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20150922/d5332b02/attachment.htm>