<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Our code knows exactly what files it needs and what directories they are in. So, that’s not the problem. I’m interested more for administrative functions like
the ability to pull file lists to report things like, “we have x articles in storage with x images,” cleaning out files older than X, and etc…
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Michael<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Bryan Whitehead [mailto:driver@megahappy.net]
<br>
<b>Sent:</b> Tuesday, December 04, 2012 5:36 PM<br>
<b>To:</b> Kushnir, Michael (NIH/NLM/LHC) [C]<br>
<b>Cc:</b> Andrew Holway; gluster-users@gluster.org<br>
<b>Subject:</b> Re: [Gluster-users] Does brick fs play a large role on listing files client side?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I think performance.cache-refresh-timeout *might* cache directory listings, so you can try bumping that value up. But probably someone else on the list needs to clarify if that will actually cache a directory (might only cache a file).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If not, you can write a translator to cache directory listings. A good place to start is the code Jeff Darcy wrote: <a href="https://github.com/jdarcy/negative-lookup">https://github.com/jdarcy/negative-lookup</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The best solution would be to directly use the API in your own code - but I don't think that is really going to be available until gluster 3.4? Basically fuse directory lookups are expensive so it is best to use it as little as possible.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Dec 4, 2012 at 2:30 PM, Kushnir, Michael (NIH/NLM/LHC) [C] <<a href="mailto:michael.kushnir@nih.gov" target="_blank">michael.kushnir@nih.gov</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Thanks for the reply,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
> Are you just using a single brick? Gluster is a scale-out NAS file system so is usually used when you want to want to aggregate the disk performance and disk space of many machines into a singe Global Name Space.<o:p></o:p></p>
</div>
<p class="MsoNormal">I currently have one server with 8 bricks. Once I get through evaluation, we will expand to multiple servers with 24 bricks each. We are looking to have a replica count of 2 for each brick eventually.<br>
<br>
On my gluster server, I can run an ls against /export/*/imgs and get file listings from each brick in seconds. However, on my client, I run ls against the /imgs/ directory on the gluster volume and wait days. Even if I mount the gluster volume on the storage
server itself, ls takes a long long time.<br>
<br>
So, what are my options for improving the speed of directory listing on gluster clients? Would changing brick FS to ext4 make a difference in the time it takes to list on the client? Should I try mounting the volume over NFS? Something else?<br>
<br>
Thanks,<br>
Michael<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
-----Original Message-----<br>
From: Andrew Holway [mailto:<a href="mailto:a.holway@syseleven.de">a.holway@syseleven.de</a>]<br>
Sent: Tuesday, December 04, 2012 4:47 PM<br>
To: Kushnir, Michael (NIH/NLM/LHC) [C]<br>
Cc: <a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a><br>
Subject: Re: [Gluster-users] Does brick fs play a large role on listing files client side?<br>
<br>
<br>
On Dec 4, 2012, at 5:30 PM, Kushnir, Michael (NIH/NLM/LHC) [C] wrote:<br>
<br>
> My GlusterFS deployment right now is 8 x 512GB OCZ Vertex 4 (no RAID) connected to Dell PERC H710, formatted as XFS and put together into a distributed volume.<br>
<br>
Hi,<br>
<br>
Are you just using a single brick? Gluster is a scale-out NAS file system so is usually used when you want to want to aggregate the disk performance and disk space of many machines into a singe Global Name Space.<br>
<br>
ocfs (cluster filesystem) is more for when you have a single disk volume attached via SCSI to many machines. More than one machine cannot for instance access the same ext4 filesystem concurrently. ocfs provides a locking mechanism allowing many systems to access
the same SCSI device at the same time.<br>
<br>
Gluster is to NFS as OCFS is to EXT4 (kinda).<br>
<br>
The lag your getting might be due to FUSE (Filesystem in Userspace). FUSE allows weird and wonderful filesystems to be mounted in userspace meaning kernel support is not required. This is typically much slower than kernel enabled filesystems.<br>
<br>
Cheers,<br>
<br>
Andrew<br>
<br>
<br>
<br>
<br>
<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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>