[Lustre-discuss] file system shrinking and OST failure

Andreas Dilger adilger at sun.com
Mon Jul 13 13:47:15 PDT 2009


On Jul 13, 2009  14:02 -0500, Carlos Santana wrote:
> The manual has a note in failover chapter 8-4 for stopping client
> process which waits indefinitely saying - "the OST is explicitly
> marked "inactive" on the clients: lctl --device <failed OSC device on
> the client> deactivate". But, a note in chapter 4-18 says "Do not
> deactivate the OST on the clients. Do so causes errors (EIOs), and the
> copy out to fail.". This is a bit confusing. So what should we do when
> an OST fails? and when should we deactivate OST (or to be precide
> OSC?) on client?

These are for two different situations.  If the OST is unavailable, and
you want clients to return -EIO if they access files located on that
OST, then deactivate the OSC on the client.  If the OST is just marked
administratively down on the MDS in order to manually balance space
usage, then the OSC should NOT be deactivated on the client, so that
the clients can read/write/unlink files on that OST.

> Could you please elaborate more on configuring failover while making a
> new filesystem? The mkfs.lustre command does not have --failover
> switch, but rather has --failnode switch. So we just need to specify
> '--failnode=<ip.addr.of.another.OST at interface>'  or anything else?
> What is the correct method?
> 
> And do we need to configure this (spare) OST for the file system and
> be it active/mounted while running above mkfs.lustre command?

You are mixing up "OST" and "OSS".  For failover you are moving the
OST (disk/filesystem) from a primary OSS (server) to a backup OSS.
The backup OSS can also be active serving its own OSTs, and then also
take over the failed OSS's OSTs, so long as it has enough RAM and is
of course cabled to the shared disk that holds the failed-over OSTs.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.




More information about the lustre-discuss mailing list