[gpfsug-discuss] LROC Express

[Sven Oehme]

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: oehmes at us.ibm.com
Phone: +1 (408) 824-8904
IBM Almaden Research Lab
------------------------------------------



From:	"Sanchez, Paul" <Paul.Sanchez at deshaw.com>
To:	gpfsug main discussion list <gpfsug-discuss at gpfsug.org>
Date:	06/22/2015 03:57 PM
Subject:	Re: [gpfsug-discuss] LROC Express
Sent by:	gpfsug-discuss-bounces at gpfsug.org



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: gpfsug-discuss-bounces at gpfsug.org [
mailto:gpfsug-discuss-bounces at gpfsug.org] 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 <bevans at pixitmedia.com>
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/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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150622/9e1bbe14/attachment-0003.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/20150622/9e1bbe14/attachment-0003.gif>