<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >Just a note on Marc's "mmcrfs -i" suggestion in (y) below.</div>
<div dir="ltr" > </div>
<div dir="ltr" >FSes created at GPFS 4.1 or later automatically use inode size 4K unless a smaller size is explicitly specified with -i.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Jamie</div>
<div dir="ltr" > </div>
<div dir="ltr" >Jamie Davis<br>GPFS Functional Verification Test (FVT)<br>jamiedavis@us.ibm.com
<div> </div>
<div> </div>
<blockquote data-history-content-modified="1" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr" >----- Original message -----<br>From: Marc A Kaplan/Watson/IBM@IBMUS<br>Sent by: gpfsug-discuss-bounces@gpfsug.org<br>To: Luke Raimbach <Luke.Raimbach@crick.ac.uk><br>Cc: gpfsug main discussion list <gpfsug-discuss@gpfsug.org><br>Subject: Re: [gpfsug-discuss] Placement Policy Installation and RDM Considerations<br>Date: Thu, Jun 18, 2015 11:37 AM<br> <br><font face="sans-serif" size="2" >(1) There is no secret flag. I assume that the existing policy is okay but the new one is better. So start using the better one ASAP, but why stop the system if you don't have to?</font><br><font face="sans-serif" size="2" >The not secret way to quiesce/resume a filesystem without unmounting is fsctl <fsname> {suspend | suspend-write | resume}; </font><br><br><font face="sans-serif" size="2" >(2) The policy rules text is passed as a string through a GPFS rpc protocol (not a standard RPC) and the designer/coder chose 1MB as a safety-limit. I think it could be increased, but suppose you did have 4000 rules, each 200 bytes - you'd be at 800KB, still short of the 1MB limit. </font><br><br><font face="sans-serif" size="2" >(x) Personally, I wouldn't worry much about setting, say 10 extended attribute values in each rule. I'd worry more about the impact of having 100s of rules.</font><br><font face="sans-serif" size="2" >(y) When designing/deploying a new GPFS filesystem, consider explicitly setting the inode size so that all anticipated extended attributes will be stored in the inode, rather than spilling into other disk blocks. See mmcrfs ... -i InodeSize. You can build a test filesystem with just one NSD/LUN and test your anticipated usage. Use tsdbfs ... xattr ... to see how EAs are stored. Caution: tsdbfs display commands are harmless, BUT there are some patch and patch-like subcommands that could foul up your filesystem.</font><br><br><br><font color="#5f5f5f" face="sans-serif" size="1" >From: </font><font face="sans-serif" size="1" >Luke Raimbach <Luke.Raimbach@crick.ac.uk></font><br><br><br><br><font color="#004080" face="Calibri" size="2" >Hi Marc,</font><br><font color="#004080" face="Calibri" size="2" > </font><br><font color="#004080" face="Calibri" size="2" >Thanks for the pointer to the updated syntax. That indeed looks nicer.</font><br><font color="#004080" face="Calibri" size="2" > </font><br><font color="#004080" face="Calibri" size="2" >(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?</font><br><a name="_MailEndCompose" target="_blank" ></a><font color="#004080" face="Calibri" size="2" > </font><br><font color="#004080" face="Calibri" size="2" >(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.</font><br><font color="#004080" face="Calibri" size="2" > </font><br><font color="#004080" face="Calibri" size="2" >Thanks for the responses.</font><br><font color="#004080" face="Calibri" size="2" >Luke.</font><br><font color="#004080" face="Calibri" size="2" > </font><br><font color="#004080" face="Calibri" size="2" > </font>
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at gpfsug.org<br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank" >http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></div></blockquote></div></div><BR>