Hi Sven,

Yes, I think that fileset level include/exclude would be sufficient for us.

It also begs the question about the same for write caching.  We haven’t 
experimented with it yet, but are looking forward to employing HAWC for 
scratch-like workloads.  Do you imagine providing the same sort of HAWC bypass 
include/exclude to be part of this?  That might be useful for excluding 
datasets where the write ingest rate isn’t massive and the degree of risk we’re 
comfortable with potential data recovery issues in the face of complex outages 
may be much lower.

Thanks,
Paul

From: [email protected] 
[mailto:[email protected]] On Behalf Of Sven Oehme
Sent: Monday, June 22, 2015 7:14 PM
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] LROC Express


Hi Paul,

just out of curiosity, not that i promise anything, but would it be enough to 
support include/exclude per fileset level or would we need path and/or 
extension or even more things like owner of files as well ?

Sven

------------------------------------------
Sven Oehme
Scalable Storage Research
email: [email protected]<mailto:[email protected]>
Phone: +1 (408) 824-8904
IBM Almaden Research Lab
------------------------------------------

[Inactive hide details for "Sanchez, Paul" ---06/22/2015 03:57:29 PM---I can’t 
confirm whether it works with Express, since we]"Sanchez, Paul" ---06/22/2015 
03:57:29 PM---I can’t confirm whether it works with Express, since we’re also 
running standard. But as a simple t

From: "Sanchez, Paul" <[email protected]<mailto:[email protected]>>
To: gpfsug main discussion list 
<[email protected]<mailto:[email protected]>>
Date: 06/22/2015 03:57 PM
Subject: Re: [gpfsug-discuss] LROC Express
Sent by: 
[email protected]<mailto:[email protected]>

________________________________



I can’t confirm whether it works with Express, since we’re also running 
standard. But as a simple test, I can confirm that deleting the gpfs.ext 
package doesn’t seem to throw any errors w.r.t. LROC in the logs at startup, 
and “mmdiag --lroc” looks normal when running without gpfs.ext (Standard 
Edition package). Since we have other standard edition features enabled, I 
couldn’t get far enough to actually test whether the LROC was still functional 
though.

In the earliest 4.1.0.x releases the use of LROC was confused with “serving 
NSDs” and so the use of the feature required a server license, and it did throw 
errors at startup about that. We’ve confirmed that in recent releases that this 
is no longer a limitation, and that it was indeed erroneous since the goal of 
LROC was pretty clearly to extend the capabilities of client-side pagepool 
caching.

LROC also appears to have some rate-limiting (queue depth mgmt?) so you end up 
in many cases getting partial file-caching after a first read, and a subsequent 
read can have a mix of blocks served from local cache and from NSD. Further 
reads can result in more complete local block caching of the file. One missing 
improvement would be to allow its use on a per-filesystem (or per-pool) basis. 
For instance, when backing a filesystem with a huge array of Flash or even a 
GSS/ESS then the performance benefit of LROC may be negligible or even 
negative, depending on the performance characteristics of the local disk. But 
against filesystems on archival media, LROC will almost always be a win. Since 
we’ve started to see features using tracked I/O access time to individual NSDs 
(e.g. readReplicaPolicy=fastest), there’s potential here to do something 
adaptive based on heuristics as well. Anyone else using this at scale and 
seeing a need for additional knobs?

Thx
Paul

From: 
[email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Barry Evans
Sent: Monday, June 22, 2015 11:40 AM
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] LROC Express

Hi Bob,

Thanks for this, just to confirm does this mean that it *does not* work with 
express?

Cheers,
Barry


Bob Oesterlin wrote:
It works with Standard edition, just make sure you have the right license for 
the nodes using LROC.

Bob Oesterlin
Nuance COmmunications


Bob Oesterlin


On Mon, Jun 22, 2015 at 10:28 AM, Barry Evans 
<[email protected]<mailto:[email protected]>> wrote:
Hi All,

Very quick question for those in the know - does LROC require a standard 
license, or will it work with Express? I can't find anything in the FAQ 
regarding this so I presume Express is ok, but wanted to make sure.

Regards,
Barry Evans
Technical Director
Pixit Media/ArcaStream



--

This email is confidential in that it is intended for the exclusive attention 
of the addressee(s) indicated. If you are not the intended recipient, this 
email should not be read or disclosed to any other person. Please notify the 
sender immediately and delete this email from your computer system. Any 
opinions expressed are not necessarily those of the company from which this 
email was sent and, whilst to the best of our knowledge no viruses or defects 
exist, no responsibility can be accepted for any loss or damage arising from 
its receipt or subsequent use of this email.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org<http://gpfsug.org/>
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

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


This email is confidential in that it is intended for the exclusive attention 
of the addressee(s) indicated. If you are not the intended recipient, this 
email should not be read or disclosed to any other person. Please notify the 
sender immediately and delete this email from your computer system. Any 
opinions expressed are not necessarily those of the company from which this 
email was sent and, whilst to the best of our knowledge no viruses or defects 
exist, no responsibility can be accepted for any loss or damage arising from 
its receipt or subsequent use of this 
email._______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


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

Reply via email to