This sounds like a perfect use case for <a href="https://github.com/jdarcy/negative-lookup">https://github.com/jdarcy/negative-lookup</a><div><br></div><div>Jeff Darcy made this as an example of building your own translators. But it basically caches nagative-lookups so repeated asking of the same questions go away.</div>
<div><br></div><div>Hell, might be beneficial to make a translator that just immediately replies &quot;does not exist&quot; for all filenames starting ._*</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 19, 2012 at 8:00 PM, Adam Tygart <span dir="ltr">&lt;<a href="mailto:mozes@k-state.edu" target="_blank">mozes@k-state.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dan,<br>
<br>
Does something like this help for SAMBA?<br>
<a href="http://www.e-rave.nl/disable-creation-of-ds_store-files-on-samba-shares" target="_blank">http://www.e-rave.nl/disable-creation-of-ds_store-files-on-samba-shares</a><br>
<br>
Negative lookups are a particularly expensive operation on distributed<br>
filesystems, GlusterFS in particular. It has to check through each<br>
brick to see that the file *really* doesn&#39;t exist, increasing the<br>
lookup overhead immensely. If samba doesn&#39;t pass these queries to<br>
GlusterFS, it might help a lot.<br>
<br>
--<br>
Adam Tygart<br>
Beocat Sysadmin<br>
<div><div class="h5"><br>
On Wed, Dec 19, 2012 at 8:29 PM, Daniel Mons &lt;<a href="mailto:daemons@kanuka.com.au">daemons@kanuka.com.au</a>&gt; wrote:<br>
&gt; I&#39;m rolling out 4 lots of 6-node GlusterFS setups for my employer.  Each<br>
&gt; node is ~33TB of RAID6 backed storage (16x 3TB SATA disks in RAID6 with a<br>
&gt; hot spare hanging off an LSI controller, with 2x SSDs configured for<br>
&gt; caching), and Gluster is configured in distribute-replicate.  Each cluster<br>
&gt; is 200TB of raw space, 100TB usable after replication.  When complete, there<br>
&gt; will be 4 of these clusters.<br>
&gt;<br>
&gt; Nodes are configured as XFS with 512byte inodes, running a fully patched<br>
&gt; CentOS6 and Gluster 3.3.1.  Each node has a 6 core Xeon processor (with HT<br>
&gt; for 12 threads) with 32GB of RAM.  Each node runs 2x 10Gbps Ethernet over<br>
&gt; fiber in a bonded configuration (single IP address per node) for a full<br>
&gt; 20Gbits per node.<br>
&gt;<br>
&gt; GlusterFS FUSE performance under Linux is great (clients run a mix of Ubuntu<br>
&gt; 12.04 LTS for workstations and CentOS6 for servers).  Samba performance back<br>
&gt; to Windows 7 clients is great.  NFS performance via both Gluster&#39;s userspace<br>
&gt; setup as well as CentOS6&#39;s native NFS4 kernel server are great to most other<br>
&gt; systems where we can&#39;t get the Gluster FUSE client loaded (large<br>
&gt; industry-specific Linux boxes that are provided by vendors as a &quot;black box&quot;<br>
&gt; solution, and only allow limited access via NFS or SMB/CIFS).  All testing<br>
&gt; so far under those conditions proves orders of magnitude faster throughput<br>
&gt; than our existing single NAS solutions.<br>
&gt;<br>
&gt; MacOSX Finder performance is a problem, however.  There&#39;s a huge bug in<br>
&gt; MacOSX itself that prevents using NFS at all (discussions on other mailing<br>
&gt; lists suggest it occurred somewhere around 10.6, and continues through into<br>
&gt; 10.7 and 10.8).<br>
&gt;<br>
&gt; Mounting via SMB under OSX is more stable than NFS, however in folders with<br>
&gt; a large amount of files, Finder goes looking for a corresponding Apple<br>
&gt; Resource Fork file (for every &quot;filename.ext&quot;, it looks for a<br>
&gt; &quot;._filename.ext&quot;).  Running tcpdump and wireshark on the Gluster nodes shows<br>
&gt; that the resulting &quot;FILE_NOT_FOUND&quot; error back to the client takes a very<br>
&gt; long time.  Configuring a single node as a pure NAS with the same software<br>
&gt; (but no Gluster implementation) is lightening fast.   As soon as GlusterFS<br>
&gt; comes in to play, reporting of each &quot;FILE_NOT_FOUND&quot; slows down the process<br>
&gt; dramatically, causing a directory with ~1000 images in it to take well over<br>
&gt; 5 minutes to display the contents in MacOSX finder.<br>
&gt;<br>
&gt; This problem is resolved somewhat by switching to AFP (via Netatalk loaded<br>
&gt; on the GlusterFS nodes), but it has it&#39;s own problems unique to that<br>
&gt; protocol, and I&#39;d rather stick to GlusterFS-FUSE, NFS or SMB in that order<br>
&gt; of preference.<br>
&gt;<br>
&gt; It&#39;s worth noting that through the terminal, these problems don&#39;t exist.<br>
&gt; Mounting via SMB, browsing to the volume in terminal and running &quot;ls&quot; or<br>
&gt; &quot;find&quot; style commands retrieve file listings at a similar speed to Linux and<br>
&gt; Windows.  The problem is limited to clients using Finder to browse<br>
&gt; directories, and again particularly ones with a large number of files that<br>
&gt; don&#39;t have matching Apple Resource Fork files.  (Of note, creating empty<br>
&gt; files of the matching &quot;._filename.ext&quot; format solves the performance<br>
&gt; problem, but litters our filestores with millions of empty files, which we<br>
&gt; don&#39;t want).<br>
&gt;<br>
&gt; I understand the problem is not strictly Gluster&#39;s issue.  Finder is looking<br>
&gt; for a heck of a lot of files that don&#39;t exist (which is a pretty silly<br>
&gt; design), and it tends to occur only with Samba re-exporting GlusterFS<br>
&gt; volumes that we can see.  And likewise Apple&#39;s NFS bug that has now been in<br>
&gt; existence across three releases of their OS is pretty horrible.   But<br>
&gt; hopefully I can at least describe the problem and prompt some testing by<br>
&gt; others.<br>
&gt;<br>
&gt; I haven&#39;t had a chance to test a MacOSX FUSE client due to time constraints,<br>
&gt; but that would at least answer the question if the problem is Gluster&#39;s lag<br>
&gt; in reporting of files not found, or Samba&#39;s.<br>
&gt;<br>
&gt; -Dan<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Gluster-users mailing list<br>
&gt; <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
&gt; <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br></div>