<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:14:01 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-1153] Client Unresponsive</title>
                <link>https://jira.whamcloud.com/browse/LU-1153</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;It is possible that I am seeing multiple bugs.  So, you may want to split this one bug into several bugs.&lt;/p&gt;

&lt;p&gt;Let me emphasize that this problem occurs only on one system, and that is the system built withhttp://review.whamcloud.com/#change,2170, which is code specifically for the 2.6.38.2 kernel.&lt;/p&gt;

&lt;p&gt;This bug is preventing us from shipping the code to this customer.&lt;/p&gt;


&lt;p&gt;PROBLEM 1&lt;br/&gt;
---------&lt;br/&gt;
My testing of the client on kernel 2.6.38.2 was going well overnight.  The performance I am getting is the line-rate of the 10G NICs while running IOZone.  Then, I switched to xdd.linux, which uses direct IO; xdd.linux also got line-rate.&lt;/p&gt;

&lt;p&gt;Then, I noticed that I may have hit a minor bug.&lt;/p&gt;

&lt;p&gt;After the iozone tests, I removed all of the files.  Then, I did an lfs df -h, and I saw that some OSTs had 20G used still.  After I unmounted all of the clients then remounted them, the problem went away (that is, all the OSTs had the same amount of used space).  Here is some session output:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@compute-01-32 lustre&amp;#93;&lt;/span&gt;# cd /mnt/lustre&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@compute-01-32 lustre&amp;#93;&lt;/span&gt;# find . -type f &lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@compute-01-32 lustre&amp;#93;&lt;/span&gt;# # Note that there are no files; I removed them a while ago.&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@compute-01-32 lustre&amp;#93;&lt;/span&gt;# lfs df -h&lt;br/&gt;
UUID                       bytes        Used   Available Use% Mounted on&lt;br/&gt;
denver-MDT0000_UUID        73.2M        4.6M       68.6M   6% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;MDT:0&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0000_UUID       190.0G      459.5M      189.6G   0% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:0&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0001_UUID       190.0G      459.5M      189.6G   0% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:1&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0002_UUID       190.0G      459.5M      189.6G   0% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:2&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0003_UUID       190.0G      459.5M      189.6G   0% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:3&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0004_UUID       190.0G      459.5M      189.6G   0% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:4&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0005_UUID       190.0G       20.4G      169.6G  11% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:5&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0006_UUID       190.0G      459.5M      189.6G   0% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:6&amp;#93;&lt;/span&gt;&lt;br/&gt;
denver-OST0007_UUID       190.0G       20.4G      169.6G  11% /mnt/lustre&lt;span class=&quot;error&quot;&gt;&amp;#91;OST:7&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;filesystem summary:         1.5T       43.6G        1.4T   3% /mnt/lustre&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@compute-01-32 lustre&amp;#93;&lt;/span&gt;# # Note that two OSTs have used 20.4G, even though no files !&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@compute-01-32 lustre&amp;#93;&lt;/span&gt;# df&lt;br/&gt;
Filesystem           1K-blocks      Used Available Use% Mounted on&lt;br/&gt;
/dev/mapper/vg_compute0132-lv_root&lt;br/&gt;
                      51606140  12008608  36976092  25% /&lt;br/&gt;
tmpfs                  1924356        88   1924268   1% /dev/shm&lt;br/&gt;
/dev/sda2               495844     59594    410650  13% /boot&lt;br/&gt;
/dev/mapper/vg_compute0132-lv_home&lt;br/&gt;
                     413557824  26856608 365693664   7% /home&lt;br/&gt;
172.20.0.1:/depot/shared&lt;br/&gt;
                      12095040  12094688         0 100% /shared&lt;br/&gt;
172.20.0.1:/home     413557824  26856608 365693664   7% /home&lt;br/&gt;
10.7.200.111@tcp0:10.7.200.112@tcp0:/denver&lt;br/&gt;
                     1594036256  45706984 1548328760   3% /mnt/lustre&lt;/p&gt;


&lt;p&gt;PROBLEM 2&lt;br/&gt;
---------&lt;/p&gt;

&lt;p&gt;I then unmounted Lustre on all clients, rebooted all the clients,&lt;br/&gt;
then remounted Lustre on all clients.&lt;br/&gt;
The problem described above seemed to have been resolved.&lt;/p&gt;

&lt;p&gt;I decided to try and reproduce this bug.  So, I started up IOZone again.  Keep in mind that this is after a client reboot.&lt;/p&gt;

&lt;p&gt;IOZone ran for a few seconds, then hung.  I could ping the node with 2.6.38.8 kernel, but I could not ssh to it.  The video console was locked up.  Pressing Caps Lock and NumLock on the keyboard did not light up any LEDs on the keyboard.  So, I power cycled.  &lt;/p&gt;

&lt;p&gt;This is all that I saw in /var/log/messages:&lt;/p&gt;

&lt;p&gt;Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Joining mDNS multicast group on interface eth2.IPv4 with address 10.7.1.32.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: New relevant interface eth2.IPv4 for mDNS.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Registering new address record for 10.7.1.32 on eth2.IPv4.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Withdrawing address record for 10.7.1.32 on eth2.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Leaving mDNS multicast group on interface eth2.IPv4 with address 10.7.1.32.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Interface eth2.IPv4 no longer relevant for mDNS.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Joining mDNS multicast group on interface eth2.IPv4 with address 10.7.1.32.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: New relevant interface eth2.IPv4 for mDNS.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 avahi-daemon&lt;span class=&quot;error&quot;&gt;&amp;#91;1508&amp;#93;&lt;/span&gt;: Registering new address record for 10.7.1.32 on eth2.IPv4.&lt;br/&gt;
Feb 28 09:33:53 compute-01-32 kernel: device eth2 entered promiscuous mode&lt;br/&gt;
Feb 28 09:33:54 compute-01-32 kernel: Lustre: Lustre: Build Version: 2.1.56-g17d2c48-CHANGED-../lustre/scripts&lt;br/&gt;
Feb 28 09:33:55 compute-01-32 kernel: Lustre: Added LNI 10.7.1.32@tcp &lt;span class=&quot;error&quot;&gt;&amp;#91;8/256/0/180&amp;#93;&lt;/span&gt;&lt;br/&gt;
Feb 28 09:33:55 compute-01-32 kernel: Lustre: Accept secure, port 988&lt;br/&gt;
Feb 28 09:33:55 compute-01-32 kernel: Lustre: MGC10.7.200.111@tcp: Reactivating import&lt;br/&gt;
Feb 28 09:33:55 compute-01-32 kernel: Lustre: Client denver-client has started&lt;br/&gt;
Feb 28 09:37:28 compute-01-32 kernel: LustreError: 2567:0:(osc_request.c:797:osc_announce_cached()) dirty 2028 - 2028 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:37:40 compute-01-32 kernel: LustreError: 2568:0:(osc_request.c:797:osc_announce_cached()) dirty 2040 - 2040 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:37:46 compute-01-32 kernel: LustreError: 2565:0:(osc_request.c:797:osc_announce_cached()) dirty 1954 - 1954 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:37:47 compute-01-32 kernel: LustreError: 2561:0:(osc_request.c:797:osc_announce_cached()) dirty 1975 - 1976 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:37:50 compute-01-32 kernel: LustreError: 2566:0:(osc_request.c:797:osc_announce_cached()) dirty 2001 - 2002 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:38:09 compute-01-32 kernel: LustreError: 2567:0:(osc_request.c:797:osc_announce_cached()) dirty 1946 - 1946 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:39:20 compute-01-32 kernel: LustreError: 2615:0:(osc_request.c:797:osc_announce_cached()) dirty 2017 - 2017 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:39:47 compute-01-32 kernel: LustreError: 2615:0:(osc_request.c:797:osc_announce_cached()) dirty 1847 - 1848 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:39:47 compute-01-32 kernel: LustreError: 2615:0:(osc_request.c:797:osc_announce_cached()) Skipped 3 previous similar messages&lt;br/&gt;
Feb 28 09:40:23 compute-01-32 kernel: LustreError: 2609:0:(osc_request.c:797:osc_announce_cached()) dirty 1918 - 1919 &amp;gt; system dirty_max 647168&lt;br/&gt;
Feb 28 09:40:23 compute-01-32 kernel: LustreError: 2609:0:(osc_request.c:797:osc_announce_cached()) Skipped 1 previous similar message&lt;/p&gt;

&lt;p&gt;I did not have a serial cable plugged into get the crash dump.  I have set this up now, so if the problem occurs again, we should get more data.  I will try to reproduce this bug.&lt;/p&gt;



&lt;p&gt;PROBLEM 3&lt;br/&gt;
---------&lt;/p&gt;

&lt;p&gt;I set up the serial cable, and I verified that SysRq-T worked and sent its output over the serial cable to another node that was capturing the data.&lt;/p&gt;

&lt;p&gt;After many hours of testing, the 2.6.38.2 client became unresponsive again.  I see some Out of memory messages.  I will keep an eye on the slab usage next time.&lt;/p&gt;

&lt;p&gt;Below following is the output over ttyS0.  After the problem occurred, I plugged in a monitor and keyboard, and SysRq-T did not work.  Perhaps I need to have the keyboard in prior to the problem occurring &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/help_16.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.&lt;/p&gt;


&lt;p&gt;LustreError: 19819:0:(ldlm_request.c:1171:ldlm_cli_cancel_req()) Got rc -108 from cancel RPC: canceling anyway&lt;br/&gt;
LustreError: 19819:0:(ldlm_request.c:1797:ldlm_cli_cancel_list()) ldlm_cli_cancel_list: -108&lt;br/&gt;
LustreError: 19819:0:(ldlm_request.c:1171:ldlm_cli_cancel_req()) Got rc -108 from cancel RPC: canceling anyway&lt;br/&gt;
LustreError: 19819:0:(ldlm_request.c:1797:ldlm_cli_cancel_list()) ldlm_cli_cancel_list: -108&lt;br/&gt;
Out of memory: Kill process 1421 (rsyslogd) score 1 or sacrifice child&lt;br/&gt;
Killed process 1421 (rsyslogd) total-vm:242652kB, anon-rss:0kB, file-rss:784kB&lt;br/&gt;
Out of memory: Kill process 1452 (irqbalance) score 1 or sacrifice child&lt;br/&gt;
Killed process 1452 (irqbalance) total-vm:9252kB, anon-rss:0kB, file-rss:416kB&lt;br/&gt;
INFO: task irqbalance:1452 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task irqbalance:1452 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task automount:1823 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task ksmtuned:1975 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task irqbalance:1452 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task automount:1823 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task ksmtuned:1975 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task irqbalance:1452 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task automount:1823 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;br/&gt;
INFO: task ksmtuned:1975 blocked for more than 120 seconds.&lt;br/&gt;
&quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.&lt;/p&gt;</description>
                <environment>Lustre servers are running 2.6.32-220.el6, with Lustre 2.1.1.rc4.  &lt;br/&gt;
Most Lustre clients are running 2.6.18-194.el5, with Lustre 1.8.4&lt;br/&gt;
One Lustre client is running 2.6.38.2, with special code created for this release, with &lt;a href=&quot;http://review.whamcloud.com/#change,2170&quot;&gt;http://review.whamcloud.com/#change,2170&lt;/a&gt;. &lt;br/&gt;
The problems are occurring only on this one client.</environment>
        <key id="13378">LU-1153</key>
            <summary>Client Unresponsive</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</priority>
                        <status id="5" iconUrl="https://jira.whamcloud.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="laisiyao">Lai Siyao</assignee>
                                    <reporter username="rspellman">Roger Spellman</reporter>
                        <labels>
                            <label>paj</label>
                    </labels>
                <created>Wed, 29 Feb 2012 14:57:16 +0000</created>
                <updated>Fri, 15 Jun 2012 18:05:48 +0000</updated>
                            <resolved>Fri, 15 Jun 2012 18:05:48 +0000</resolved>
                                    <version>Lustre 2.2.0</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>7</watches>
                                                                            <comments>
                            <comment id="29986" author="pjones" created="Wed, 29 Feb 2012 15:06:23 +0000"  >&lt;p&gt;Lai&lt;/p&gt;

&lt;p&gt;Could you please look into this one?&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="30314" author="rspellman" created="Fri, 2 Mar 2012 13:07:27 +0000"  >&lt;p&gt;I am able to reproduce the bug at will.&lt;br/&gt;
The code that I have opens a file, writes to it, closes the file, then reopens the same file (truncating it), and writes it again, then closes it. &lt;br/&gt;
This is repeated for many, many files, until I stop the test or the test fails.&lt;/p&gt;

&lt;p&gt;The test fails every time.  I believe that the cause is out-of-memory.&lt;/p&gt;

&lt;p&gt;I see the following in the logs quite frequently:&lt;/p&gt;

&lt;p&gt;Mar  1 11:01:01 compute-01-32 kernel: cannot allocate a tage (7)&lt;br/&gt;
Mar  1 11:08:25 compute-01-32 kernel: cannot allocate a tage (13)&lt;br/&gt;
Mar  1 11:36:32 compute-01-32 kernel: cannot allocate a tage (13)&lt;br/&gt;
Mar  1 12:03:50 compute-01-32 kernel: cannot allocate a tage (9)&lt;br/&gt;
Mar  1 12:07:40 compute-01-32 kernel: cannot allocate a tage (13)&lt;/p&gt;

&lt;p&gt;I have also seen:&lt;/p&gt;

&lt;p&gt;Mar  1 10:52:35 compute-01-32 kernel: -----------&lt;del&gt;[ cut here ]&lt;/del&gt;-----------&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: WARNING: at fs/libfs.c:363 simple_setattr+0x99/0xb0()&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: Hardware name: PowerEdge R210&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: Modules linked in: lmv mgc lustre lquota lov osc mdc fid fld ksocklnd ptlrpc obdclass lnet lvfs libcfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 nfs lockd fscache nfs_acl auth_rpcgss sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 vhost_net macvtap macvlan tun kvm uinput power_meter sg dcdbas microcode pcspkr iTCO_wdt iTCO_vendor_support bnx2 ixgbe dca mdio ext4 mbcache jbd2 sd_mod crc_t10dif ahci libahci dm_mirror dm_region_hash dm_log dm_mod &lt;span class=&quot;error&quot;&gt;&amp;#91;last unloaded: speedstep_lib&amp;#93;&lt;/span&gt;&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: Pid: 14596, comm: bash Not tainted 2.6.38.2 #2&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: Call Trace:&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff810619ff&amp;gt;&amp;#93;&lt;/span&gt; ? warn_slowpath_common+0x7f/0xc0&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81061a5a&amp;gt;&amp;#93;&lt;/span&gt; ? warn_slowpath_null+0x1a/0x20&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811760f9&amp;gt;&amp;#93;&lt;/span&gt; ? simple_setattr+0x99/0xb0&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0926f20&amp;gt;&amp;#93;&lt;/span&gt; ? ll_md_setattr+0x4b0/0xb20 &lt;span class=&quot;error&quot;&gt;&amp;#91;lustre&amp;#93;&lt;/span&gt;&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811e0fc1&amp;gt;&amp;#93;&lt;/span&gt; ? inode_has_perm+0x51/0xa0&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa09277f3&amp;gt;&amp;#93;&lt;/span&gt; ? ll_setattr_raw+0x263/0x1040 &lt;span class=&quot;error&quot;&gt;&amp;#91;lustre&amp;#93;&lt;/span&gt;&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811e14fb&amp;gt;&amp;#93;&lt;/span&gt; ? dentry_has_perm+0x5b/0x80&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0928627&amp;gt;&amp;#93;&lt;/span&gt; ? ll_setattr+0x57/0xf0 &lt;span class=&quot;error&quot;&gt;&amp;#91;lustre&amp;#93;&lt;/span&gt;&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8116d671&amp;gt;&amp;#93;&lt;/span&gt; ? notify_change+0x161/0x2c0&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81153191&amp;gt;&amp;#93;&lt;/span&gt; ? do_truncate+0x61/0x90&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8115f094&amp;gt;&amp;#93;&lt;/span&gt; ? finish_open+0x154/0x1d0&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81160cd6&amp;gt;&amp;#93;&lt;/span&gt; ? do_last+0x86/0x370&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81163028&amp;gt;&amp;#93;&lt;/span&gt; ? do_filp_open+0x3a8/0x760&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8111e0e5&amp;gt;&amp;#93;&lt;/span&gt; ? handle_mm_fault+0x1e5/0x340&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8116fc7f&amp;gt;&amp;#93;&lt;/span&gt; ? vfsmount_lock_global_unlock_online+0x4f/0x60&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811704bc&amp;gt;&amp;#93;&lt;/span&gt; ? mntput_no_expire+0x19c/0x1c0&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8116e7c5&amp;gt;&amp;#93;&lt;/span&gt; ? alloc_fd+0x95/0x160&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81151fb9&amp;gt;&amp;#93;&lt;/span&gt; ? do_sys_open+0x69/0x110&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811520a0&amp;gt;&amp;#93;&lt;/span&gt; ? sys_open+0x20/0x30&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100bf82&amp;gt;&amp;#93;&lt;/span&gt; ? system_call_fastpath+0x16/0x1b&lt;br/&gt;
Mar  1 10:52:35 compute-01-32 kernel: --&lt;del&gt;[ end trace 69e4427ab9bdd594 ]&lt;/del&gt;--&lt;/p&gt;
</comment>
                            <comment id="30346" author="rspellman" created="Fri, 2 Mar 2012 14:13:42 +0000"  >&lt;p&gt;Lai, Can you please give an update to this bug? Thanks.&lt;br/&gt;
-Roger&lt;/p&gt;</comment>
                            <comment id="30419" author="pjones" created="Sat, 3 Mar 2012 11:20:58 +0000"  >&lt;p&gt;Roger&lt;/p&gt;

&lt;p&gt;I did chat with Lai about this ticket. There is a lot of information to sift through but he expects to post something in the near future. He is based in China so this may well occur before you are in the office on Monday&lt;/p&gt;

&lt;p&gt;Regards&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="30506" author="laisiyao" created="Mon, 5 Mar 2012 04:34:25 +0000"  >&lt;p&gt;Roger,&lt;/p&gt;

&lt;p&gt;The warning message for simple_setattr() is not an issue, kernel exports this function, but it&apos;s too cautious that if a somewhat complicated filesystem uses this function (which has it&apos;s -&amp;gt;truncate implementation), it will complain. But Lustre just uses it to update times, so it&apos;s absolutely okay.&lt;/p&gt;

&lt;p&gt;As for messages like &quot;kernel: cannot allocate a tage&quot;, this is normal too. By default, Lustre debug is enabled, and it&apos;s printed to allocated kernel pages, but sometimes when system memory is tight, it can&apos;t allocate pages, it will print such warnings, and skip output debug logs.&lt;/p&gt;

&lt;p&gt;I&apos;m trying to reproduce this failure, and after that I&apos;ll update you. If you can run some scripts to output /proc/slabinfo periodically (eg. `watch sort -k2rn /proc/slabinfo`), and if OOM happens again, could you collect it from the serial console and put here?&lt;/p&gt;</comment>
                            <comment id="30524" author="laisiyao" created="Mon, 5 Mar 2012 06:20:52 +0000"  >&lt;p&gt;Roger, I can&apos;t reproduce here, could you upload the test script or program?&lt;/p&gt;</comment>
                            <comment id="30530" author="rspellman" created="Mon, 5 Mar 2012 10:45:12 +0000"  >&lt;p&gt;While running my test, I also ran the script get-slab-loop.  This script gets slab info, vmstat, and other stuff, and puts it into new file every 30 seconds.  The script and the files are in the tarball.&lt;br/&gt;
So, mem.3 was taken 30 seconds after mem.2, which was taken 30 seconds after mem.1.&lt;/p&gt;

&lt;p&gt;I believe that my test started running before mem.4 was created.&lt;/p&gt;

&lt;p&gt;I will upload the test shortly.&lt;/p&gt;</comment>
                            <comment id="30532" author="rspellman" created="Mon, 5 Mar 2012 11:04:24 +0000"  >&lt;p&gt;This tarball contains the test that causes this bug.  The test uses IOZone. The binary is in this directory.  It should be moved to a place that all clients can access.  Then, the client_list should be modified with the location of that binary.&lt;/p&gt;

&lt;p&gt;The format of the cilent_list is:&lt;/p&gt;

&lt;p&gt;hostname mountPoint binaryLocation fileToCreate&lt;/p&gt;

&lt;p&gt;The client list currently has 22 entries.  You can modify this for the number of clients that you have.&lt;/p&gt;

&lt;p&gt;Before running any tests, I run:&lt;/p&gt;

&lt;p&gt;./setup_directories /mnt/lustre&lt;/p&gt;

&lt;p&gt;That creates the following directories on my system with 8 OSTS:&lt;/p&gt;

&lt;p&gt;/mnt/lustre/&lt;br/&gt;
/mnt/lustre/stripe-1M&lt;br/&gt;
/mnt/lustre/stripe-256M&lt;br/&gt;
/mnt/lustre/stripe-32M&lt;br/&gt;
/mnt/lustre/stripe-4M&lt;br/&gt;
/mnt/lustre/ost/ost-00&lt;br/&gt;
/mnt/lustre/ost/ost-01&lt;br/&gt;
/mnt/lustre/ost/ost-02&lt;br/&gt;
/mnt/lustre/ost/ost-03&lt;br/&gt;
/mnt/lustre/ost/ost-04&lt;br/&gt;
/mnt/lustre/ost/ost-05&lt;br/&gt;
/mnt/lustre/ost/ost-06&lt;br/&gt;
/mnt/lustre/ost/ost-07&lt;/p&gt;


&lt;p&gt;The last 8 are striped to each OST.  The client_list writes files to these directories.  Feel free to change the client list to match the number of OSTs that you have.&lt;/p&gt;

&lt;p&gt;The script that is run is called &apos;run-test&apos;.  This script includes the line:&lt;/p&gt;

&lt;p&gt;for threads in  22&lt;/p&gt;

&lt;p&gt;&apos;22&apos; is the number of entries in the client_list.  If you change the number of entries in client_list, then you should change the number 22 to match that.&lt;/p&gt;

&lt;p&gt;Please let me know if you need any help setting up the tests.  It usually hangs within an hour or two.&lt;/p&gt;</comment>
                            <comment id="30600" author="laisiyao" created="Tue, 6 Mar 2012 06:18:50 +0000"  >&lt;p&gt;Yes, I can reproduce in your way, thanks! I&apos;ll update you when I have some clue.&lt;/p&gt;</comment>
                            <comment id="30609" author="laisiyao" created="Tue, 6 Mar 2012 09:38:29 +0000"  >&lt;p&gt;Hi Roger,&lt;/p&gt;

&lt;p&gt;I&apos;m wondering whether this issue is introduced by FC15 support code, do you have any client with supported kernels (eg. RHEL5/6) to verify this won&apos;t happen on them?&lt;/p&gt;</comment>
                            <comment id="30614" author="rspellman" created="Tue, 6 Mar 2012 12:26:32 +0000"  >&lt;p&gt;Lai,&lt;br/&gt;
I have 10 clients running Lustre 1.8.4 on RHEL 5.5.  I have one client with the new code.  Only that one client is having this problem.&lt;/p&gt;</comment>
                            <comment id="30800" author="laisiyao" created="Sun, 11 Mar 2012 23:47:41 +0000"  >&lt;p&gt;I tested the same code on RHEL5/6 and FC15, OOM only happens on FC15. The log and memory stats doesn&apos;t show anything special, just too many cached pages, and the slab usage is a bit high. I talked to Jinshan, he said that iozone test consuming a lot memory is a known issue (but he never met OOM before), and it&apos;s because CLIO depends on kernel to release cached pages, but kernel tends to cache more pages. I doubt that FC15 kernel is more aggressive on this, therefore it will OOM. Jinshan is working on iozone memory use problem, I&apos;ll update here if he has any progress.&lt;/p&gt;</comment>
                            <comment id="30812" author="laisiyao" created="Mon, 12 Mar 2012 11:10:32 +0000"  >&lt;p&gt;I tried tuning kernel vm dirty_ratio and dirty_background_ratio to 5, but it still OOM. There may not exist a simple workaround for this excessive memory usage issue. &lt;/p&gt;</comment>
                            <comment id="30826" author="rspellman" created="Mon, 12 Mar 2012 12:28:56 +0000"  >&lt;p&gt;&amp;gt; I talked to Jinshan, he said that iozone test consuming a lot &lt;br/&gt;
&amp;gt; memory is a known issue (but he never met OOM before), &lt;/p&gt;

&lt;p&gt;This bug DOES NOT require IOZone.  I am able to reproduce it with dd, with the following script:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;cat write-twice-loop&lt;br/&gt;
(( COUNT = 0 ))&lt;br/&gt;
size=2048&lt;br/&gt;
&amp;gt; /root/keep_going&lt;br/&gt;
cd /mnt/lustre/ost&lt;br/&gt;
while [ -f /root/keep_going ];&lt;br/&gt;
do&lt;br/&gt;
        index=`printf &apos;%04d&apos; $COUNT`&lt;br/&gt;
        file=file.$index&lt;br/&gt;
        echo -n &quot;writing $file+ &quot;&lt;br/&gt;
        (cd ost-01 &amp;amp;&amp;amp; dd if=/dev/zero of=$file bs=1024k count=$size &amp;gt; ~/tmp.1a 2&amp;gt;&amp;amp;1 ) &amp;amp;&lt;br/&gt;
        (cd ost-07 &amp;amp;&amp;amp; dd if=/dev/zero of=$file bs=1024k count=$size &amp;gt; ~/tmp.2a 2&amp;gt;&amp;amp;1 ) &amp;amp;&lt;br/&gt;
        wait&lt;br/&gt;
        echo -n &quot;+ &quot;&lt;br/&gt;
        (cd ost-01 &amp;amp;&amp;amp; dd if=/dev/zero of=$file bs=1024k count=$size &amp;gt; ~/tmp.1b 2&amp;gt;&amp;amp;1 ) &amp;amp;&lt;br/&gt;
        (cd ost-07 &amp;amp;&amp;amp; dd if=/dev/zero of=$file bs=1024k count=$size &amp;gt; ~/tmp.2b 2&amp;gt;&amp;amp;1 ) &amp;amp;&lt;br/&gt;
        wait&lt;br/&gt;
        echo&lt;br/&gt;
        (( COUNT = $COUNT + 1 ))&lt;br/&gt;
        sleep 0.5&lt;br/&gt;
done&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;echo&lt;br/&gt;
echo Cannot find /root/keep_going&lt;/p&gt;</comment>
                            <comment id="31036" author="pjones" created="Tue, 13 Mar 2012 09:22:35 +0000"  >&lt;p&gt;Roger&lt;/p&gt;

&lt;p&gt;To clarify, Jinshan is referring to the conditions that can be simulated by running a tool like IOZONE. He is not suggesting that IOZONE itself is the key factor here&lt;/p&gt;

&lt;p&gt;Peter &lt;/p&gt;</comment>
                            <comment id="31039" author="rspellman" created="Tue, 13 Mar 2012 09:58:26 +0000"  >&lt;p&gt;Peter,&lt;br/&gt;
Thanks for the clarification.  &lt;/p&gt;

&lt;p&gt;Jinshan, I believe that the problem has to do with writing then over-writing the same file.  IOZone does this by default, and the loop that I submitted does that too.  When I just write a file once, I am not seeing this problem (in the time frame that I&apos;m testing).  You can do that in IOZone with the -+n option.&lt;/p&gt;

&lt;p&gt;Roger&lt;/p&gt;</comment>
                            <comment id="31247" author="jay" created="Wed, 14 Mar 2012 18:27:03 +0000"  >&lt;p&gt;I&apos;ll look into this issue. For the warning of simple_setattr(), it means we shouldn&apos;t use simple_setattr() if we have truncate method implemented. We used to call inode_setattr() for old kernels, we really need to fix that.&lt;/p&gt;</comment>
                            <comment id="31254" author="laisiyao" created="Wed, 14 Mar 2012 21:42:29 +0000"  >&lt;p&gt;Jinshan, please check &lt;a href=&quot;http://review.whamcloud.com/#change,1863&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#change,1863&lt;/a&gt; and &lt;a href=&quot;http://review.whamcloud.com/#change,2145&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#change,2145&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="33035" author="jay" created="Sat, 31 Mar 2012 00:15:23 +0000"  >&lt;p&gt;I&apos;m trying to compile lustre-master with fc15 but it doesn&apos;t work. Can you please tell me which distribution you;re using for your client?&lt;/p&gt;</comment>
                            <comment id="33163" author="laisiyao" created="Sat, 31 Mar 2012 22:20:06 +0000"  >&lt;p&gt;Hmm, if you use kernel-devel package to build kernel module, lustre configure will fail on LB_LINUX_COMPILE_IFELSE in build/autoconf/lustre-build-linux.m4, I tried to tweak it a bit, but didn&apos;t succeed. In my setup, I build lustre patchless client against kernel source, and you need update kernel source Makefile &apos;EXTRAVERSION&apos; to be in accordance with your kernel version(my setup is &apos;.6-26.rc1.fc15.x86_64&apos;).&lt;/p&gt;</comment>
                            <comment id="33316" author="rspellman" created="Mon, 2 Apr 2012 14:51:09 +0000"  >&lt;p&gt;I had no trouble building against 2.6.38.2.&lt;/p&gt;

&lt;p&gt;I don&apos;t see LB_LINUX_COMPILE_IFELSE in .config in this release.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;root@RS_vm-2_6_38_2 linux-2.6.38.2&amp;#93;&lt;/span&gt;# pwd&lt;br/&gt;
/usr/src/kernels/linux-2.6.38.2&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@RS_vm-2_6_38_2 linux-2.6.38.2&amp;#93;&lt;/span&gt;# grep LB_LINUX_COMPILE_IFELSE .config &lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@RS_vm-2_6_38_2 linux-2.6.38.2&amp;#93;&lt;/span&gt;#&lt;/p&gt;

&lt;p&gt;-Roger&lt;/p&gt;</comment>
                            <comment id="33321" author="rspellman" created="Mon, 2 Apr 2012 15:55:57 +0000"  >&lt;p&gt;I updated to the 5th patch on:&lt;br/&gt;
&lt;a href=&quot;http://review.whamcloud.com/#change,2170&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#change,2170&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;This bug is still present there.&lt;/p&gt;</comment>
                            <comment id="34345" author="pjones" created="Mon, 9 Apr 2012 20:51:43 +0000"  >&lt;p&gt;Roger&lt;/p&gt;

&lt;p&gt;Peter said today that he thought that this issue was independent of using the 2.6.38 client. Are you able to reproduce this same behaviour when running vanilla 2.1.x and RHEL6 clients, say?&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="34415" author="rspellman" created="Tue, 10 Apr 2012 11:51:33 +0000"  >&lt;p&gt;I have a client with kernel:  2.6.32-220.el6.x86_64&lt;/p&gt;


&lt;p&gt;Is that what you want me to try?&lt;/p&gt;

&lt;p&gt;What git tag should I use to get the 2.1.x code?&lt;/p&gt;</comment>
                            <comment id="40690" author="pjones" created="Fri, 15 Jun 2012 18:05:48 +0000"  >&lt;p&gt;As per Terascala ok to close&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="10920" name="ioz-test-bug-1153.tgz" size="144878" author="rspellman" created="Mon, 5 Mar 2012 11:04:24 +0000"/>
                            <attachment id="10919" name="slabinfo-and-mem2.tgz" size="766428" author="rspellman" created="Mon, 5 Mar 2012 10:45:12 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzvh8f:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>6441</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>