[lustre-discuss] How does Lustre client side caching work?

[Joakim Ziegler]

Yes, our use case would also likely benefit from client-side caching, it
wouldn't need to be persistent between reboots, but definitely bigger than
what would fit in RAM.

For instance, our data set is in the hundreds of terabytes, but a single
client at a time accesses maybe 5-10 terabytes, and does so quite
intensively, reading the same data repeatedly many times over a period of a
week or so. The data does not chance during this time. However, the client
only needs read speeds in the range of maybe a GB per second. I could
stripe together a few SSDs on the client as a cache, and avoid load on the
cluster, which would save capacity for other clients who need high speed
reads and/or writes of fresh data. This is especially relevant where each
client reads the same data multiple times, but each client reads different
data, in other words, would thrash the cache on the cluster nodes.

On Wed, Jul 26, 2017 at 7:02 AM, Michael Di Domenico <mdidomenico4 at gmail.com
> wrote:

> On Wed, Jul 26, 2017 at 2:19 AM, Dilger, Andreas
> <andreas.dilger at intel.com> wrote:
> > We have discussed integration of fscache with the Lustre client to allow
> > persistent cache on NVMe/Optane/NVRAM or other fast local storage. IMHO,
> > there is little benefit to cache on slower local devices (e.g. HDD) since
> > Lustre can read over the network (assuming IB and decent servers) at a
> large
> > fraction of the PCI bandwidth. That would only be a win over WAN or other
> > slow networks.
>
> i might disagree slightly with this.  i certainly have a use case
> where the aggregate performance of the individual cluster nodes
> reading from local disk (even using sata) outstrips the aggregate
> lustre bandwidth.  the size of our clusters far out strip the
> aggregate speed compared to the filesystem.  being able to cache a
> file locally and re-read it a number of times would be beneficial in
> some of our use cases.  and since we share our filesystems between
> multiple clusters, this would also prevent one cluster from hammering
> the filesystem making less usable in another
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>



-- 
Joakim Ziegler  -  Supervisor de postproducción  -  Terminal
joakim at terminalmx.com   -   044 55 2971 8514   -   5264 0864
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20170726/bc2791f6/attachment.htm>