[gpfsug-discuss] DMAPI - Unmigrate file to Regular state

Dominic Mueller-Wicke01 dominic.mueller at de.ibm.com
Thu Sep 8 06:35:55 BST 2016


Please open a PMR for the not working "recall to resident". Some
investigation is needed here. Thanks.


Greetings, Dominic.




From:	gpfsug-discuss-request at spectrumscale.org
To:	gpfsug-discuss at spectrumscale.org
Date:	07.09.2016 23:23
Subject:	gpfsug-discuss Digest, Vol 56, Issue 14
Sent by:	gpfsug-discuss-bounces at spectrumscale.org



Send gpfsug-discuss mailing list submissions to
		 gpfsug-discuss at spectrumscale.org

To subscribe or unsubscribe via the World Wide Web, visit
		 http://gpfsug.org/mailman/listinfo/gpfsug-discuss
or, via email, send a message with subject or body 'help' to
		 gpfsug-discuss-request at spectrumscale.org

You can reach the person managing the list at
		 gpfsug-discuss-owner at spectrumscale.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gpfsug-discuss digest..."
Today's Topics:

   1. Re: Remote cluster mount failing (Yuri L Volobuev)
   2. Weirdness with 'mmces address add' (Valdis Kletnieks)
   3. Re: DMAPI - Unmigrate file to Regular state (Lukas Hejtmanek)
   4. Weirdness with 'mmces address add' (Michael L Taylor)
   5. Re: Weirdness with 'mmces address add' (Valdis.Kletnieks at vt.edu)

----- Message from "Yuri L Volobuev" <volobuev at us.ibm.com> on Wed, 7 Sep
2016 09:58:07 -0700 -----
                                                            
      To: gpfsug main discussion list                       
          <gpfsug-discuss at spectrumscale.org>                
                                                            
 Subject: Re: [gpfsug-discuss] Remote cluster mount failing 
                                                            

It's unclear what's wrong. I'd have two main suspects: (1) TLS protocol
version confusion, due to a difference in GSKit version and/or
configuration (e.g. NIST SP800 compliance) on two sides (2) firewall. TLS
issues are usually messy and tedious to work though. I'd recommend opening
a PMR to facilitate debug data collection and analysis. A lot of gory
detail may be needed to figure out what's going on.

yuri

Inactive hide details for "Simon Thompson (Research Computing - IT
Services)" ---09/07/2016 05:37:11 AM---Hi All, I'm trying to"Simon Thompson
(Research Computing - IT Services)" ---09/07/2016 05:37:11 AM---Hi All, I'm
trying to get some multi cluster thing working between two of our GPFS

From: "Simon Thompson (Research Computing - IT Services)"
<S.J.Thompson at bham.ac.uk>
To: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>,
Date: 09/07/2016 05:37 AM
Subject: [gpfsug-discuss] Remote cluster mount failing
Sent by: gpfsug-discuss-bounces at spectrumscale.org



Hi All,

I'm trying to get some multi cluster thing working between two of our GPFS
clusters.

In the "client" cluster, when trying to mount the "remote" cluster, I get:

# mmmount gpfs
Wed  7 Sep 13:33:06 BST 2016: mmmount: Mounting file systems ...
mount: mount /dev/gpfs on /gpfs failed: Connection timed out
mmmount: Command failed. Examine previous error messages to determine
cause.


And in the log file:
Wed Sep  7 13:33:07.481 2016: [N] The client side TLS handshake with node
10.0.0.182 was cancelled: connection reset by peer (return code 420).
Wed Sep  7 13:33:07.486 2016: [N] The client side TLS handshake with node
10.0.0.181 was cancelled: connection reset by peer (return code 420).
Wed Sep  7 13:33:07.487 2016: [E] Failed to join remote cluster
GPFS_STORAGE.CLUSTER
Wed Sep  7 13:33:07.488 2016: [W] Command: err 78: mount
GPFS_STORAGE.CLUSTER:gpfs
Wed Sep  7 13:33:07.489 2016: Connection timed out

In the remote cluster, I see:

Wed Sep  7 13:33:07.487 2016: [W] The TLS handshake with node 10.0.0.222
failed with error 447 (server side).
Wed Sep  7 13:33:07.488 2016: [X] Connection from 10.10.0.35 <c0p174>
refused, authentication failed
Wed Sep  7 13:33:07.489 2016: [E] Killing connection from 10.10.0.35, err
703
Wed Sep  7 13:33:07.490 2016: Operation not permitted



Weirdly though on other nodes in the client cluster this succeeds fine and
can mount, so I think I got all the bits in the mmauth and mmremotecluster
configured correctly.

Any suggestions?

Thanks

Simon

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



----- Message from Valdis Kletnieks <Valdis.Kletnieks at vt.edu> on Wed, 07
Sep 2016 14:45:43 -0400 -----
                                                    
      To: gpfsug-discuss at spectrumscale.org          
                                                    
 Subject: [gpfsug-discuss] Weirdness with 'mmces    
          address add'                              
                                                    

We're in the middle of deploying Spectrum Archive, and I've hit a
snag.  We assigned some floating IP addresses, which now need to
be changed.  So I look at the mmces manpage, and it looks like I need
to add the new addresses, and delete the old ones.

We're on GPFS 4.2.1.0, if that matters...

What 'man mmces' says:

1. To add an address to a specified node, issue this command:

   mmces address add --ces-node node1 --ces-ip 10.1.2.3

(and at least 6 or 8 more uses of an IP address).

What happens when I try it:  (And yes, we have an 'isb' ces-group defined
with
addresses in it already)

# mmces address add --ces-group isb --ces-ip 172.28.45.72
Cannot resolve 172.28.45.72; Name or service not known
mmces address add: Incorrect value for --ces-ip option
Usage:
  mmces address add [--ces-node Node] [--attribute Attribute] [--ces-group
Group]
     {--ces-ip {IP[,IP...]}

Am I missing some special sauce? (My first guess is that it's complaining
because there's no PTR in the DNS for that address yet - but if it was
going
to do DNS lookups, it should be valid to give a hostname rather than an IP
address (and nowhere in the manpage does it even *hint* that --ces-ip can
be anything other than a list of IP addresses).

Or is it time for me to file a PMR?



----- Message from Lukas Hejtmanek <xhejtman at ics.muni.cz> on Wed, 7 Sep
2016 22:11:11 +0200 -----
                                                            
      To: gpfsug main discussion list                       
          <gpfsug-discuss at spectrumscale.org>                
                                                            
 Subject: Re: [gpfsug-discuss] DMAPI - Unmigrate file to    
          Regular state                                     
                                                            

On Tue, Sep 06, 2016 at 02:04:36PM +0200, Dominic Mueller-Wicke01 wrote:
> Hi Miroslav,
>
> please use the command: > dsmrecall -resident -detail <file name>
> or use it with file lists

well, it looks like

 Client Version 7, Release 1, Level 4.4

leaks file descriptors:

09/07/2016 21:03:07 ANS1587W Unable to read extended attributes for object
/exports/tape_tape/VO_metacentrum/home/jfeit/atlases/atlases/novo3/atlases/images/.svn/prop-base

due to errno: 24, reason: Too many open files

after about 15 minutes of run, I can see 88 opened files in /proc/$PID/fd

when using:
dsmrecall -R -RESid -D /path/*

is it something known fixed in newer versions?

--
Lukáš Hejtmánek


----- Message from "Michael L Taylor" <taylorm at us.ibm.com> on Wed, 7 Sep
2016 13:40:13 -0700 -----
                                                    
      To: gpfsug-discuss at spectrumscale.org          
                                                    
 Subject: [gpfsug-discuss] Weirdness with 'mmces    
          address add'                              
                                                    

Can't be for certain this is what you're hitting but reverse DNS lookup is
documented the KC:

http://www.ibm.com/support/knowledgecenter/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1ins_protocolnodeipfurtherconfig.htm

Note: All CES IPs must have an associated hostname and reverse DNS lookup
must be configured for each. For more information, see Adding export IPs in
Deploying protocols.

http://www.ibm.com/support/knowledgecenter/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1ins_deployingprotocolstasks.htm

Note: Export IPs must have an associated hostname and reverse DNS lookup
must be configured for each.

Can you make sure the IPs have reverse DNS lookup and try again?
Will get the mmces man page updated for address add


----- Message from Valdis.Kletnieks at vt.edu on Wed, 07 Sep 2016 17:23:30
-0400 -----
                                                            
      To: gpfsug main discussion list                       
          <gpfsug-discuss at spectrumscale.org>                
                                                            
 Subject: Re: [gpfsug-discuss] Weirdness with 'mmces        
          address add'                                      
                                                            

On Wed, 07 Sep 2016 13:40:13 -0700, "Michael L Taylor" said:

> Can't be for certain this is what you're hitting but reverse DNS lookup
is
> documented the KC:

> Note: All CES IPs must have an associated hostname and reverse DNS lookup
> must be configured for each. For more information, see Adding export IPs
in
> Deploying protocols.

Bingo.  That was it.  Since the DNS will take a while to fix, I fed
the appropriate entries to /etc/hosts and it worked fine.

I got thrown for a loop because if there is enough code to do that
checking,
it should be able to accept a hostname as well (RFE time? :)

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160908/97ae12ea/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160908/97ae12ea/attachment.gif>


More information about the gpfsug-discuss mailing list