[gpfsug-discuss] Disabling individual Storage Pools by themselves?

Wahl, Edward ewahl at osc.edu
Thu Jun 18 21:36:48 BST 2015


I'm not sure it's so uncommon, but yes.  (and your line looks suspiciously like mine did)   I've had other situations where it would have been nice to do maintenance on a single storage pool.  Maybe this is a "scale" issue when you get too large and should maybe have multiple file systems instead?  Single name space is nice for users though.
Plus I was curious what others had done in similar situations.

I guess I could do what IBM does and just write the stupid script, name it "ts-something" and put a happy wrapper up front with a mm-something name. ;)   

Just FYI:  'suspend' does NOT stop I/O.  Only stops new block creation,so 'stop' was  what I did.
>From the man page: "...Existing data on a suspended disk may still be read or updated."

Ed Wahl
OSC

________________________________________
From: gpfsug-discuss-bounces at gpfsug.org [gpfsug-discuss-bounces at gpfsug.org] on behalf of Alex Chekholko [chekh at stanford.edu]
Sent: Thursday, June 18, 2015 4:26 PM
To: gpfsug-discuss at gpfsug.org
Subject: Re: [gpfsug-discuss] Disabling individual Storage Pools by     themselves?

mmlsdisk fs | grep pool | awk '{print $1} | tr '\n' ';'| xargs mmchdisk
suspend
# seems pretty simple to me

Then I guess you also have to modify your policy rules which relate to
that pool.

You're asking for a convenience wrapper script for a super-uncommon
situation?

On 06/18/2015 09:02 AM, Zachary Giles wrote:
>   I could "turn down" an entire Storage Pool that did not have metadata for other pools on it, in a simpler manner.

--
Alex Chekholko chekh at stanford.edu

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss



More information about the gpfsug-discuss mailing list