<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 26, 2017 at 7:02 AM, Michael Di Domenico <span dir="ltr"><<a href="mailto:mdidomenico4@gmail.com" target="_blank">mdidomenico4@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jul 26, 2017 at 2:19 AM, Dilger, Andreas<br>
<<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>> wrote:<br>
> We have discussed integration of fscache with the Lustre client to allow<br>
> persistent cache on NVMe/Optane/NVRAM or other fast local storage. IMHO,<br>
> there is little benefit to cache on slower local devices (e.g. HDD) since<br>
> Lustre can read over the network (assuming IB and decent servers) at a large<br>
> fraction of the PCI bandwidth. That would only be a win over WAN or other<br>
> slow networks.<br>
<br>
</span>i might disagree slightly with this.  i certainly have a use case<br>
where the aggregate performance of the individual cluster nodes<br>
reading from local disk (even using sata) outstrips the aggregate<br>
lustre bandwidth.  the size of our clusters far out strip the<br>
aggregate speed compared to the filesystem.  being able to cache a<br>
file locally and re-read it a number of times would be beneficial in<br>
some of our use cases.  and since we share our filesystems between<br>
multiple clusters, this would also prevent one cluster from hammering<br>
the filesystem making less usable in another<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.<wbr>org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/<wbr>listinfo.cgi/lustre-discuss-<wbr>lustre.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span></span>Joakim Ziegler  -  Supervisor de postproducción  -  Terminal
<br><a href="mailto:joakim@terminalmx.com" target="_blank">joakim@terminalmx.com</a>   -   044 55 2971 8514   -   5264 0864
</div></div>
</div>