<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-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;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.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">I am looking for more details on the “-n size=65536” option in mkfs.xfs.  The question is the memory allocation this option generates.  The system is Redhat EL 7.0 (3.10.0-229.1.2.el7.x86_64).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We have been getting this memory allocation deadlock message in the /var/log/messages file.  The file system is used for ceph OSD and it has about 531894 files.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Oct  6 07:11:09 abc-ceph1-xyz kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x8250)<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Reading this post, <a href="https://access.redhat.com/solutions/532663">
https://access.redhat.com/solutions/532663</a> it discussed the “memory allocation deadlock” message.  It looks like the root cause is a very fragmented file.  Is setting the “-n size=65536” option on the file system causes (directly or indirectly) the “memory
 allocation deadlock” error?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here is a note on the “-n size=65536”.  The FAQ note is more on the CPU and IO performance. 
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="http://xfs.org/index.php/XFS_FAQ">http://xfs.org/index.php/XFS_FAQ</a><o:p></o:p></p>
<p class="MsoNormal">“<o:p></o:p></p>
<p class="MsoNormal">Q: Performance: mkfs.xfs -n size=64k option<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Asking the implications of that mkfs option on the XFS mailing list,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Dave Chinner explained it this way:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Inodes are not stored in the directory structure, only the directory entry name<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">and the inode number.  Hence the amount of space used by a directory entry is<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">determined by the length of the name.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">There is extra overhead to allocate large directory blocks (16 pages instead of<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">one, to begin with, then there's the vmap overhead, etc), so for small<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">directories smaller block sizes are faster for create and unlink operations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">For empty directories, operations on 4k block sized directories consume roughly<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">50% less CPU that 64k block size directories. The 4k block size directories<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">consume less CPU out to roughly 1.5 million entries where the two are roughly<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">equal. At directory sizes of 10 million entries, 64k directory block operations<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">are consuming about 15% of the CPU that 4k directory block operations consume.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">In terms of lookups, the 64k block directory will take less IO but consume more<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">CPU for a given lookup.  Hence it depends on your IO latency and whether<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">directory readahead can hide that latency as to which will be faster. e.g. For<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">SSDs, CPU usage might be the limiting factor, not the IO.  Right now I don't<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">have any numbers on what the difference might be - I'm getting 1 billion inode<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">population issues worked out first before I start on measuring cold cache<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">lookup times on 1 billion files....</span><o:p></o:p></p>
<p class="MsoNormal">“<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Al Lau<o:p></o:p></p>
</div>
</body>
</html>