<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body dir="auto">
<div>Lustre currently only uses RAM for client side cache. This is kept coherent across all clients by the LDLM, but is not persistent across reboots. </div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">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. <br>
<br>
Cheers, Andreas</div>
<div><br>
On Jul 25, 2017, at 20:10, Joakim Ziegler <<a href="mailto:joakim@terminalmx.com">joakim@terminalmx.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Hello, I'm pretty new to Lustre, we're looking at setting up a Lustre cluster for storage of media assets (something in the 0.5-1PB range to start with, maybe 6 OSSes (in HA pairs), running on our existing FDR IB network). It looks like a good
match for our needs, however, there's an area I've been unable to find details about. Note that I'm just investigating for now, I have no running Lustre setup.
<div><br>
</div>
<div>There are plenty of references to Lustre using client side caching, and how the Distributed Lock Manager makes this work. However, I can't find almost any information about how the client side cache actually works. When I first heard it mentioned, I imagined
something like the ZFS L2ARC, where you can add a device (say, a couple of SSDs) to the client and point Lustre at it to use it for caching. But some references I come across just talk about the normal kernel page cache, which is probably smaller and less
persistent than what I'd like for our usage.</div>
<div><br>
</div>
<div>Could anyone enlighten me? I have a large dataset, but clients typically use a small part of it at any given time, and uses it quite intensively, so a client-side cache (either a read cache or ideally a writeback cache) would likely reduce network traffic
and server load quite a bit. We've been using NFS over RDMA and fscache to get a read cache that does roughly this so far on our existing file servers, and it's been quite effective, so I imagine we could also benefit from something similar as we move to Lustre.<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>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>lustre-discuss mailing list</span><br>
<span><a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a></span><br>
<span><a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org">http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</a></span><br>
</div>
</blockquote>
</body>
</html>