[gpfsug-discuss] Placement Policy Installation and RDM Considerations

[Luke Raimbach]

Hi Marc,

Thanks for the pointer to the updated syntax. That indeed looks nicer.


(1)    Asynchronous policy propagation sounds good in our scenario. We don’t want to potentially interrupt other running experiments by having to quiesce the filesystem for a new one coming online. It is useful to know that you could quiesce if desired. Presumably this is a secret flag one might pass to mmchpolicy?


(2)    I was concerned about the evaluation time if I tried to set all extended attributes at creation time. That’s why I thought about adding a few ‘system’ defined tags which could later be used to link the files to an asynchronously applied policy on the home cluster. I think I calculated around 4,000 rules (dependent on the size of the attribute names and values), which might limit the number of experiments supported on a single ingest file system. However, I can’t envisage we will ever have 4,000 experiments running at once! I was really interested in why the limitation existed from a file-system architecture point of view.


Thanks for the responses.
Luke.



From: Marc A Kaplan [mailto:makaplan at us.ibm.com]
Sent: 18 June 2015 14:19
To: gpfsug main discussion list; Luke Raimbach
Subject: Re: [gpfsug-discuss] Placement Policy Installation and RDM Considerations

Yes, you can do this.  In release 4.1.1 you can write   SET POOL 'x'  ACTION(setXattr(...))  FOR FILESET(...) WHERE ...
which looks nicer to some people than   WHERE ( ... ) AND setXattr(...)

Answers:

(1) No need to quiesce.  As the new policy propagates, nodes begin using it.   So there can be a transition time when node A may be using the new policy but Node B has not started
using it yet.  If that is undesirable, you can quiesce.

(2) Yes, 1MB is a limit on the total size in bytes of your policy rules.  Do you have a real need for more? Would you please show us such a scenario?  Beware that policy rules take some cpu cycles to evaluate...   So if for example, if you had several thousand SET POOL rules, you might notice some impact to file creation time.

--marc of GPFS



From:        Luke Raimbach <Luke.Raimbach at crick.ac.uk<mailto:Luke.Raimbach at crick.ac.uk>>
   ...
RULE 'RDMTEST'
     SET POOL 'instruments’
     FOR FILESET
('%GPFSRDM%10.01013%RDM%0ab34906-5357-4ca0-9d19-a470943db30a%RDM%8fc2395d-64c0-4ebd-8c71-0d2d34b3c1c0')
     WHERE SetXattr
('user.rdm.parent','0ab34906-5357-4ca0-9d19-a470943db30a')
     AND SetXattr
               ('user.rdm.ingestor','8fc2395d-64c0-4ebd-8c71-0d2d34b3c1c0')
RULE 'DEFAULT' SET POOL 'data'
   ...
(1) When I install a placement policy into the file system, does the file system need to quiesce? My suspicion is yes, because the policy needs to be consistent on all nodes performing I/O, but I may be wrong.
  ...
(2) What is the specific limitation for having a policy placement file no larger than 1MB?
  ...

The Francis Crick Institute Limited is a registered charity in England and Wales no. 1140062 and a company registered in England and Wales no. 06885462, with its registered office at 215 Euston Road, London NW1 2BE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150618/1c15fbdc/attachment.htm>