Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread J. Eric Wonderley
Placement policy only applies to writes and I had thought that gpfs did
enough writing to memory "pagepool" to figure out the size before
committing the write to pool.

I also admit I don't know all of the innards of gpfs.  Pehaps being a copy
on write type filesystem prevents this for occurring.

On Mon, Oct 31, 2016 at 1:29 PM, Chris Scott  wrote:

> Hi Brian
>
> This is exactly what I do with a SSD tier on top of 10K and 7.2K tiers.
>
> HAWC is another recent option that might address Eric's requirement but
> needs further consideration of the read requirements you want from the
> small files.
>
> Cheers
> Chris
>
> On 31 October 2016 at 17:23, Brian Marshall  wrote:
>
>> When creating a "fast tier" storage pool in a filesystem is the normal
>> case to create a placement policy that places all files in the fast tier
>> and migrates out old and large files?
>>
>>
>> Brian Marshall
>>
>> On Mon, Oct 31, 2016 at 1:20 PM, Jez Tucker 
>> wrote:
>>
>>> Hey Bryan
>>>
>>>   There was a previous RFE for path placement from the UG, but Yuri told
>>> me this was not techically possible as an inode has no knowledge about the
>>> parent dentry.  (IIRC).You can see this in effect in the C API.  It is
>>> possible to work this out at kernel level, but it's so costly that it
>>> becomes non-viable at scale / performance.
>>>
>>> IBMers please chip in and expand if you will.
>>>
>>> Jez
>>>
>>>
>>> On 31/10/16 17:09, Bryan Banister wrote:
>>>
>>> The File Placement Policy that you are trying to set cannot use the size
>>> of the file to determine the placement of the file in a GPFS Storage Pool.
>>> This is because GPFS has no idea what the file size will be when the file
>>> is open()’d for writing.
>>>
>>>
>>>
>>> Hope that helps!
>>>
>>> -Bryan
>>>
>>>
>>>
>>> PS. I really wish that we could use a path for specifying data placement
>>> in a GPFS Pool, and not just the file name, owner, etc.  I’ll submit a RFE
>>> for this.
>>>
>>>
>>>
>>> *From:* gpfsug-discuss-boun...@spectrumscale.org [
>>> mailto:gpfsug-discuss-boun...@spectrumscale.org
>>> ] *On Behalf Of *J. Eric
>>> Wonderley
>>> *Sent:* Monday, October 31, 2016 11:53 AM
>>> *To:* gpfsug main discussion list
>>> *Subject:* [gpfsug-discuss] wanted...gpfs policy that places larger
>>> files onto a pool based on size
>>>
>>>
>>>
>>> I wanted to do something like this...
>>>
>>>
>>> [root@cl001 ~]# cat /opt/gpfs/home.ply
>>> /*Failsafe migration of old small files back to spinning media
>>> pool(fc_8T) */
>>> RULE 'theshold' MIGRATE FROM POOL 'system' THRESHOLD(90,70)
>>> WEIGHT(ACCESS_TIME) TO POOL 'fc_8T'
>>> /*Write files larger than 16MB to pool called "fc_8T" */
>>> RULE 'bigfiles' SET POOL 'fc_8T' WHERE FILE_SIZE>16777216
>>> /*Move anything else to system pool */
>>> RULE 'default' SET POOL 'system'
>>>
>>> Apparently there is no happiness using FILE_SIZE in a placement policy:
>>> [root@cl001 ~]# mmchpolicy home /opt/gpfs/home.ply
>>> Error while validating policy `home.ply': rc=22:
>>> PCSQLERR: 'FILE_SIZE' is an unsupported or unknown attribute or variable
>>> name in this context.
>>> PCSQLCTX: at line 4 of 6: RULE 'bigfiles' SET POOL 'fc_8T' WHERE
>>> {{{FILE_SIZE}}}>16777216
>>> runRemoteCommand_v2: cl002.cl.arc.internal: tschpolicy /dev/home
>>> /var/mmfs/tmp/tspolicyFile.mmchpolicy.113372 -t home.ply   failed.
>>> mmchpolicy: Command failed. Examine previous error messages to determine
>>> cause.
>>>
>>> Can anyone suggest a way to accomplish this using policy?
>>>
>>> --
>>>
>>> Note: This email is for the confidential use of the named addressee(s)
>>> only and may contain proprietary, confidential or privileged information.
>>> If you are not the intended recipient, you are hereby notified that any
>>> review, dissemination or copying of this email is strictly prohibited, and
>>> to please notify the sender immediately and destroy this email and any
>>> attachments. Email transmission cannot be guaranteed to be secure or
>>> error-free. The Company, therefore, does not make any guarantees as to the
>>> completeness or accuracy of this email or any attachments. This email is
>>> for informational purposes only and does not constitute a recommendation,
>>> offer, request or solicitation of any kind to buy, sell, subscribe, redeem
>>> or perform any type of transaction of a financial product.
>>>
>>>
>>> ___
>>> gpfsug-discuss mailing list
>>> gpfsug-discuss at 
>>> spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>>
>>>
>>> ___
>>> gpfsug-discuss mailing list
>>> gpfsug-discuss at spectrumscale.org
>>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>>
>>>
>>
>> ___
>> gpfsug-discuss mailing list
>> gpfsug-discuss at spectrumscale.org
>> 

Re: [gpfsug-discuss] Recent Whitepapers from Yuri Volobuev

2016-10-31 Thread Chris Scott
Hear, hear. My appreciation to Yuri for his great contribution to the user
community of important details.

On 31 October 2016 at 16:19, Aaron Knister  wrote:

> Wow! That's a real shame. His ability to articulate his immense knowledge
> of GPFS was truly impressive.
>
> Sent from my iPhone
>
> On Oct 31, 2016, at 5:53 AM, Oesterlin, Robert <
> robert.oester...@nuance.com> wrote:
>
> For those of you who may not know, Yuri Volobuev has left IBM to pursue
> new challenges. Myself along with many others received so much help and
> keen insight from Yuri on all things GPFS.
>
>
>
> He will be missed.
>
>
>
>
>
> Bob Oesterlin
> Sr Principal Storage Engineer, Nuance
>
>
>
> ___
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
> ___
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread Brian Marshall
When creating a "fast tier" storage pool in a filesystem is the normal case
to create a placement policy that places all files in the fast tier and
migrates out old and large files?


Brian Marshall

On Mon, Oct 31, 2016 at 1:20 PM, Jez Tucker  wrote:

> Hey Bryan
>
>   There was a previous RFE for path placement from the UG, but Yuri told
> me this was not techically possible as an inode has no knowledge about the
> parent dentry.  (IIRC).You can see this in effect in the C API.  It is
> possible to work this out at kernel level, but it's so costly that it
> becomes non-viable at scale / performance.
>
> IBMers please chip in and expand if you will.
>
> Jez
>
>
> On 31/10/16 17:09, Bryan Banister wrote:
>
> The File Placement Policy that you are trying to set cannot use the size
> of the file to determine the placement of the file in a GPFS Storage Pool.
> This is because GPFS has no idea what the file size will be when the file
> is open()’d for writing.
>
>
>
> Hope that helps!
>
> -Bryan
>
>
>
> PS. I really wish that we could use a path for specifying data placement
> in a GPFS Pool, and not just the file name, owner, etc.  I’ll submit a RFE
> for this.
>
>
>
> *From:* gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-
> boun...@spectrumscale.org ] *On
> Behalf Of *J. Eric Wonderley
> *Sent:* Monday, October 31, 2016 11:53 AM
> *To:* gpfsug main discussion list
> *Subject:* [gpfsug-discuss] wanted...gpfs policy that places larger files
> onto a pool based on size
>
>
>
> I wanted to do something like this...
>
>
> [root@cl001 ~]# cat /opt/gpfs/home.ply
> /*Failsafe migration of old small files back to spinning media pool(fc_8T)
> */
> RULE 'theshold' MIGRATE FROM POOL 'system' THRESHOLD(90,70)
> WEIGHT(ACCESS_TIME) TO POOL 'fc_8T'
> /*Write files larger than 16MB to pool called "fc_8T" */
> RULE 'bigfiles' SET POOL 'fc_8T' WHERE FILE_SIZE>16777216
> /*Move anything else to system pool */
> RULE 'default' SET POOL 'system'
>
> Apparently there is no happiness using FILE_SIZE in a placement policy:
> [root@cl001 ~]# mmchpolicy home /opt/gpfs/home.ply
> Error while validating policy `home.ply': rc=22:
> PCSQLERR: 'FILE_SIZE' is an unsupported or unknown attribute or variable
> name in this context.
> PCSQLCTX: at line 4 of 6: RULE 'bigfiles' SET POOL 'fc_8T' WHERE
> {{{FILE_SIZE}}}>16777216
> runRemoteCommand_v2: cl002.cl.arc.internal: tschpolicy /dev/home
> /var/mmfs/tmp/tspolicyFile.mmchpolicy.113372 -t home.ply   failed.
> mmchpolicy: Command failed. Examine previous error messages to determine
> cause.
>
> Can anyone suggest a way to accomplish this using policy?
>
> --
>
> Note: This email is for the confidential use of the named addressee(s)
> only and may contain proprietary, confidential or privileged information.
> If you are not the intended recipient, you are hereby notified that any
> review, dissemination or copying of this email is strictly prohibited, and
> to please notify the sender immediately and destroy this email and any
> attachments. Email transmission cannot be guaranteed to be secure or
> error-free. The Company, therefore, does not make any guarantees as to the
> completeness or accuracy of this email or any attachments. This email is
> for informational purposes only and does not constitute a recommendation,
> offer, request or solicitation of any kind to buy, sell, subscribe, redeem
> or perform any type of transaction of a financial product.
>
>
> ___
> gpfsug-discuss mailing list
> gpfsug-discuss at 
> spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
> ___
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread Chris Scott
Hi Brian

This is exactly what I do with a SSD tier on top of 10K and 7.2K tiers.

HAWC is another recent option that might address Eric's requirement but
needs further consideration of the read requirements you want from the
small files.

Cheers
Chris

On 31 October 2016 at 17:23, Brian Marshall  wrote:

> When creating a "fast tier" storage pool in a filesystem is the normal
> case to create a placement policy that places all files in the fast tier
> and migrates out old and large files?
>
>
> Brian Marshall
>
> On Mon, Oct 31, 2016 at 1:20 PM, Jez Tucker  wrote:
>
>> Hey Bryan
>>
>>   There was a previous RFE for path placement from the UG, but Yuri told
>> me this was not techically possible as an inode has no knowledge about the
>> parent dentry.  (IIRC).You can see this in effect in the C API.  It is
>> possible to work this out at kernel level, but it's so costly that it
>> becomes non-viable at scale / performance.
>>
>> IBMers please chip in and expand if you will.
>>
>> Jez
>>
>>
>> On 31/10/16 17:09, Bryan Banister wrote:
>>
>> The File Placement Policy that you are trying to set cannot use the size
>> of the file to determine the placement of the file in a GPFS Storage Pool.
>> This is because GPFS has no idea what the file size will be when the file
>> is open()’d for writing.
>>
>>
>>
>> Hope that helps!
>>
>> -Bryan
>>
>>
>>
>> PS. I really wish that we could use a path for specifying data placement
>> in a GPFS Pool, and not just the file name, owner, etc.  I’ll submit a RFE
>> for this.
>>
>>
>>
>> *From:* gpfsug-discuss-boun...@spectrumscale.org [
>> mailto:gpfsug-discuss-boun...@spectrumscale.org
>> ] *On Behalf Of *J. Eric
>> Wonderley
>> *Sent:* Monday, October 31, 2016 11:53 AM
>> *To:* gpfsug main discussion list
>> *Subject:* [gpfsug-discuss] wanted...gpfs policy that places larger
>> files onto a pool based on size
>>
>>
>>
>> I wanted to do something like this...
>>
>>
>> [root@cl001 ~]# cat /opt/gpfs/home.ply
>> /*Failsafe migration of old small files back to spinning media
>> pool(fc_8T) */
>> RULE 'theshold' MIGRATE FROM POOL 'system' THRESHOLD(90,70)
>> WEIGHT(ACCESS_TIME) TO POOL 'fc_8T'
>> /*Write files larger than 16MB to pool called "fc_8T" */
>> RULE 'bigfiles' SET POOL 'fc_8T' WHERE FILE_SIZE>16777216
>> /*Move anything else to system pool */
>> RULE 'default' SET POOL 'system'
>>
>> Apparently there is no happiness using FILE_SIZE in a placement policy:
>> [root@cl001 ~]# mmchpolicy home /opt/gpfs/home.ply
>> Error while validating policy `home.ply': rc=22:
>> PCSQLERR: 'FILE_SIZE' is an unsupported or unknown attribute or variable
>> name in this context.
>> PCSQLCTX: at line 4 of 6: RULE 'bigfiles' SET POOL 'fc_8T' WHERE
>> {{{FILE_SIZE}}}>16777216
>> runRemoteCommand_v2: cl002.cl.arc.internal: tschpolicy /dev/home
>> /var/mmfs/tmp/tspolicyFile.mmchpolicy.113372 -t home.ply   failed.
>> mmchpolicy: Command failed. Examine previous error messages to determine
>> cause.
>>
>> Can anyone suggest a way to accomplish this using policy?
>>
>> --
>>
>> Note: This email is for the confidential use of the named addressee(s)
>> only and may contain proprietary, confidential or privileged information.
>> If you are not the intended recipient, you are hereby notified that any
>> review, dissemination or copying of this email is strictly prohibited, and
>> to please notify the sender immediately and destroy this email and any
>> attachments. Email transmission cannot be guaranteed to be secure or
>> error-free. The Company, therefore, does not make any guarantees as to the
>> completeness or accuracy of this email or any attachments. This email is
>> for informational purposes only and does not constitute a recommendation,
>> offer, request or solicitation of any kind to buy, sell, subscribe, redeem
>> or perform any type of transaction of a financial product.
>>
>>
>> ___
>> gpfsug-discuss mailing list
>> gpfsug-discuss at 
>> spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>>
>> ___
>> gpfsug-discuss mailing list
>> gpfsug-discuss at spectrumscale.org
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>>
>
> ___
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread Bryan Banister
Thanks for that suggestion, which is something we already do, but as you say is 
not as flexible.  I think Jez is correct about the overhead being too high to 
support directory path for data placement,
-B

-Original Message-
From: Edward Wahl [mailto:ew...@osc.edu]
Sent: Monday, October 31, 2016 12:26 PM
To: Bryan Banister
Cc: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] wanted...gpfs policy that places larger files 
onto a pool based on size

On Mon, 31 Oct 2016 17:09:55 +
Bryan Banister  wrote:

> -Bryan
>
> PS. I really wish that we could use a path for specifying data
> placement in a GPFS Pool, and not just the file name, owner, etc.
> I’ll submit a RFE for this.

So... use a fileset with a linked directory and a fileset placement policy to a 
pool?  Might be a bit more rigid for what you really want, and it would be 
messy, but it would work just fine.

--

Ed Wahl
Ohio Supercomputer Center
614-292-9302



Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments. Email 
transmission cannot be guaranteed to be secure or error-free. The Company, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments. This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread Edward Wahl
On Mon, 31 Oct 2016 17:09:55 +
Bryan Banister  wrote:

> -Bryan
>  
> PS. I really wish that we could use a path for specifying data
> placement in a GPFS Pool, and not just the file name, owner, etc.
> I’ll submit a RFE for this.

So... use a fileset with a linked directory and a fileset placement
policy to a pool?  Might be a bit more rigid for what you really want,
and it would be messy, but it would work just fine.

-- 

Ed Wahl
Ohio Supercomputer Center
614-292-9302
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread Jez Tucker

Hey Bryan

  There was a previous RFE for path placement from the UG, but Yuri 
told me this was not techically possible as an inode has no knowledge 
about the parent dentry.  (IIRC).You can see this in effect in the C 
API.  It is possible to work this out at kernel level, but it's so 
costly that it becomes non-viable at scale / performance.


IBMers please chip in and expand if you will.

Jez

On 31/10/16 17:09, Bryan Banister wrote:


The File Placement Policy that you are trying to set cannot use the 
size of the file to determine the placement of the file in a GPFS 
Storage Pool.  This is because GPFS has no idea what the file size 
will be when the file is open()’d for writing.


Hope that helps!

-Bryan

PS. I really wish that we could use a path for specifying data 
placement in a GPFS Pool, and not just the file name, owner, etc.  
I’ll submit a RFE for this.


*From:*gpfsug-discuss-boun...@spectrumscale.org 
[mailto:gpfsug-discuss-boun...@spectrumscale.org] *On Behalf Of *J. 
Eric Wonderley

*Sent:* Monday, October 31, 2016 11:53 AM
*To:* gpfsug main discussion list
*Subject:* [gpfsug-discuss] wanted...gpfs policy that places larger 
files onto a pool based on size


I wanted to do something like this...


[root@cl001 ~]# cat /opt/gpfs/home.ply
/*Failsafe migration of old small files back to spinning media 
pool(fc_8T) */
RULE 'theshold' MIGRATE FROM POOL 'system' THRESHOLD(90,70) 
WEIGHT(ACCESS_TIME) TO POOL 'fc_8T'

/*Write files larger than 16MB to pool called "fc_8T" */
RULE 'bigfiles' SET POOL 'fc_8T' WHERE FILE_SIZE>16777216
/*Move anything else to system pool */
RULE 'default' SET POOL 'system'

Apparently there is no happiness using FILE_SIZE in a placement policy:
[root@cl001 ~]# mmchpolicy home /opt/gpfs/home.ply
Error while validating policy `home.ply': rc=22:
PCSQLERR: 'FILE_SIZE' is an unsupported or unknown attribute or 
variable name in this context.
PCSQLCTX: at line 4 of 6: RULE 'bigfiles' SET POOL 'fc_8T' WHERE 
{{{FILE_SIZE}}}>16777216
runRemoteCommand_v2: cl002.cl.arc.internal: tschpolicy /dev/home 
/var/mmfs/tmp/tspolicyFile.mmchpolicy.113372 -t home.ply   failed.
mmchpolicy: Command failed. Examine previous error messages to 
determine cause.


Can anyone suggest a way to accomplish this using policy?




Note: This email is for the confidential use of the named addressee(s) 
only and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you are hereby 
notified that any review, dissemination or copying of this email is 
strictly prohibited, and to please notify the sender immediately and 
destroy this email and any attachments. Email transmission cannot be 
guaranteed to be secure or error-free. The Company, therefore, does 
not make any guarantees as to the completeness or accuracy of this 
email or any attachments. This email is for informational purposes 
only and does not constitute a recommendation, offer, request or 
solicitation of any kind to buy, sell, subscribe, redeem or perform 
any type of transaction of a financial product.



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


Re: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread Bryan Banister
The File Placement Policy that you are trying to set cannot use the size of the 
file to determine the placement of the file in a GPFS Storage Pool.  This is 
because GPFS has no idea what the file size will be when the file is open()’d 
for writing.

Hope that helps!
-Bryan

PS. I really wish that we could use a path for specifying data placement in a 
GPFS Pool, and not just the file name, owner, etc.  I’ll submit a RFE for this.

From: gpfsug-discuss-boun...@spectrumscale.org 
[mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of J. Eric Wonderley
Sent: Monday, October 31, 2016 11:53 AM
To: gpfsug main discussion list
Subject: [gpfsug-discuss] wanted...gpfs policy that places larger files onto a 
pool based on size

I wanted to do something like this...

[root@cl001 ~]# cat /opt/gpfs/home.ply
/*Failsafe migration of old small files back to spinning media pool(fc_8T) */
RULE 'theshold' MIGRATE FROM POOL 'system' THRESHOLD(90,70) WEIGHT(ACCESS_TIME) 
TO POOL 'fc_8T'
/*Write files larger than 16MB to pool called "fc_8T" */
RULE 'bigfiles' SET POOL 'fc_8T' WHERE FILE_SIZE>16777216
/*Move anything else to system pool */
RULE 'default' SET POOL 'system'
Apparently there is no happiness using FILE_SIZE in a placement policy:
[root@cl001 ~]# mmchpolicy home /opt/gpfs/home.ply
Error while validating policy `home.ply': rc=22:
PCSQLERR: 'FILE_SIZE' is an unsupported or unknown attribute or variable name 
in this context.
PCSQLCTX: at line 4 of 6: RULE 'bigfiles' SET POOL 'fc_8T' WHERE 
{{{FILE_SIZE}}}>16777216
runRemoteCommand_v2: cl002.cl.arc.internal: tschpolicy /dev/home 
/var/mmfs/tmp/tspolicyFile.mmchpolicy.113372 -t home.ply   failed.
mmchpolicy: Command failed. Examine previous error messages to determine cause.
Can anyone suggest a way to accomplish this using policy?



Note: This email is for the confidential use of the named addressee(s) only and 
may contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you are hereby notified that any review, dissemination 
or copying of this email is strictly prohibited, and to please notify the 
sender immediately and destroy this email and any attachments. Email 
transmission cannot be guaranteed to be secure or error-free. The Company, 
therefore, does not make any guarantees as to the completeness or accuracy of 
this email or any attachments. This email is for informational purposes only 
and does not constitute a recommendation, offer, request or solicitation of any 
kind to buy, sell, subscribe, redeem or perform any type of transaction of a 
financial product.
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


[gpfsug-discuss] wanted...gpfs policy that places larger files onto a pool based on size

2016-10-31 Thread J. Eric Wonderley
I wanted to do something like this...

[root@cl001 ~]# cat /opt/gpfs/home.ply
/*Failsafe migration of old small files back to spinning media pool(fc_8T)
*/
RULE 'theshold' MIGRATE FROM POOL 'system' THRESHOLD(90,70)
WEIGHT(ACCESS_TIME) TO POOL 'fc_8T'
/*Write files larger than 16MB to pool called "fc_8T" */
RULE 'bigfiles' SET POOL 'fc_8T' WHERE FILE_SIZE>16777216
/*Move anything else to system pool */
RULE 'default' SET POOL 'system'

Apparently there is no happiness using FILE_SIZE in a placement policy:
[root@cl001 ~]# mmchpolicy home /opt/gpfs/home.ply
Error while validating policy `home.ply': rc=22:
PCSQLERR: 'FILE_SIZE' is an unsupported or unknown attribute or variable
name in this context.
PCSQLCTX: at line 4 of 6: RULE 'bigfiles' SET POOL 'fc_8T' WHERE
{{{FILE_SIZE}}}>16777216
runRemoteCommand_v2: cl002.cl.arc.internal: tschpolicy /dev/home
/var/mmfs/tmp/tspolicyFile.mmchpolicy.113372 -t home.ply   failed.
mmchpolicy: Command failed. Examine previous error messages to determine
cause.

Can anyone suggest a way to accomplish this using policy?
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


[gpfsug-discuss] Recent Whitepapers from Yuri Volobuev

2016-10-31 Thread Oesterlin, Robert
For those of you who may not know, Yuri Volobuev has left IBM to pursue new 
challenges. Myself along with many others received so much help and keen 
insight from Yuri on all things GPFS.

He will be missed.


Bob Oesterlin
Sr Principal Storage Engineer, Nuance


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


Re: [gpfsug-discuss] Two new whitepapers published

2016-10-31 Thread Greg.Lehmann
Thanks Yuri. These were great. I'm not trying to be impertinent, but I have one 
suggestion - If you can find the time, add some diagrams to help readers 
visualise the various data structures and layouts. I am thinking along the 
lines of what was in "The Magic Garden Explained" and "The Design and 
Implementation of the 4.3BSD UNIX Operating System" where they talked about 
their filesystems.

Cheers,

Greg

From: gpfsug-discuss-boun...@spectrumscale.org 
[mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Yuri L Volobuev
Sent: Friday, 21 October 2016 11:59 AM
To: gpfsug-discuss@spectrumscale.org
Subject: [gpfsug-discuss] Two new whitepapers published


Esteemed GPFS and Spectrum Scale users,

For your reading enjoyment, two new whitepapers have been posted to the 
Spectrum Scale Wiki:

Spectrum Scale: Replication in 
GPFS
Spectrum Scale: GPFS 
Metadata

The URL for the parent page is 
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel%20File%20System%20(GPFS)/page/White%20Papers%20%26%20Media

The two .pdf documents are accessible through the Attachment section at the 
bottom of the page.  Unfortunately, dW "spam prevention engine" does a very 
good job preventing me from "spamming" the page to actually add links.

Best regards,

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