Whamcloud Community JIRA

Whamcloud Community JIRA https://jira.whamcloud.com This file is an XML representation of an issue en-us

9.4.14

940014

05-12-2023

[LU-2963] fail to create large stripe count file with -ENOSPC error https://jira.whamcloud.com/browse/LU-2963 Lustre LU-2963

fail to create large stripe count file with -ENOSPC error

Bug Major Resolved Duplicate Jian Yu James A Simmons Thu, 14 Mar 2013 10:27:40 +0000 Tue, 6 May 2014 13:51:13 +0000 Tue, 6 May 2014 13:48:28 +0000 Lustre 2.4.0 0 8 Durning testing we did some runs creating directories of increasing stripe count. What was discovered was that around 128 stripes that the files being created would fail with a -ENOSPC no matter what size the file was. This test was also done with 1.8 clients and we saw no such problems. Also durning the runs with the 2.4 clients attempts to do a lfs getstripe on the large stripe count directory would lock up. He is a log from the MDS whne I attempted to use lfs getstripe and it hung. Mar 8 21:12:54 widow-mds1 kernel: [27048.704079] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 379s: evicting client at 3167@gni ns: mdt-ffff880e55b20000 lock: ffff880c3f748600/0x4453d516b35bd568 lrc: 3/0,0 mode: CR/CR res: 8589939214/48084 bits 0x9 rrc: 14 type: IBT flags: 0x200000000020 nid: 3167@gni remote: 0x1f865dc509f72511 expref: 11 pid: 28552 timeout: 4321715043 lvb_type: 0 Mar 8 21:12:54 widow-mds1 kernel: [27048.807514] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 379s: evicting client at 3160@gni ns: mdt-ffff880e55b20000 lock: ffff880c91423800/0x4453d516b35bd481 lrc: 3/0,0 mode: CR/CR res: 8589939214/48084 bits 0x9 rrc: 14 type: IBT flags: 0x200000000020 nid: 3160@gni remote: 0x13f59fd0192bc693 expref: 9 pid: 28131 timeout: 4321715043 lvb_type: 0 Mar 8 21:19:15 widow-mds1 kernel: [27429.704085] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 379s: evicting client at 4524@gni ns: mdt-ffff880e55b20000 lock: ffff880cecfe8800/0x4453d516b35c5e97 lrc: 3/0,0 mode: CR/CR res: 8589937079/12 bits 0x9 rrc: 36 type: IBT flags: 0x200000000020 nid: 4524@gni remote: 0x3f5d4900776bce4c expref: 16 pid: 28093 timeout: 4322096096 lvb_type: 0 Mar 8 21:19:15 widow-mds1 kernel: [27429.808017] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) Skipped 11 previous similar messages Mar 8 21:25:39 widow-mds1 kernel: [27813.704166] LustreError: 49:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 384s: evicting client at 3158@gni ns: mdt-ffff880e55b20000 lock: ffff880b58904000/0x4453d516b35ca546 lrc: 3/0,0 mode: CR/CR res: 8589936085/14 bits 0x9 rrc: 5 type: IBT flags: 0x200000000020 nid: 3158@gni remote: 0x72cd27e494baa553 expref: 16 pid: 28882 timeout: 4322480792 lvb_type: 0 Mar 8 21:25:39 widow-mds1 kernel: [27813.808394] LustreError: 49:0:(ldlm_lockd.c:391:waiting_locks_callback()) Skipped 34 previous similar messages Mar 8 21:31:39 widow-mds1 kernel: [28173.189536] Lustre: routed1-MDT0000: haven't heard from client 61445347-9977-82cd-59dd-430903b6625f (at 10.36.227.198@o2ib) in 1366 seconds. I think it's dead, and I am evicting it. exp ffff880d79545c00, cur 1362796299 expire 1362795399 last 1362794933 Mar 8 21:31:39 widow-mds1 kernel: [28173.251441] Lustre: Skipped 4 previous similar messages Mar 8 21:47:52 widow-mds1 kernel: [29146.704092] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 379s: evicting client at 1626@gni ns: mdt-ffff880e55b20000 lock: ffff880d2c019600/0x4453d516b365e418 lrc: 3/0,0 mode: CR/CR res: 8589939214/48110 bits 0x9 rrc: 14 type: IBT flags: 0x200000000020 nid: 1626@gni remote: 0xdbdb318b1cc3700e expref: 10 pid: 29051 timeout: 4323813395 lvb_type: 0 Mar 8 21:47:52 widow-mds1 kernel: [29146.809942] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) Skipped 3 previous similar messages Mar 8 21:54:13 widow-mds1 kernel: [29527.704103] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 379s: evicting client at 4582@gni ns: mdt-ffff880e55b20000 lock: ffff880b80052400/0x4453d516b3666b48 lrc: 3/0,0 mode: CR/CR res: 8589937079/16 bits 0x9 rrc: 37 type: IBT flags: 0x200000000020 nid: 4582@gni remote: 0xbe8a1154e07f5e4f expref: 14 pid: 28963 timeout: 4324194184 lvb_type: 0 Mar 8 21:54:13 widow-mds1 kernel: [29527.810409] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) Skipped 12 previous similar messages Mar 8 22:01:07 widow-mds1 kernel: [29941.704087] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) ### lock callback timer expired after 414s: evicting client at 4581@gni ns: mdt-ffff880e55b20000 lock: ffff880c3f697400/0x4453d516b366b0bc lrc: 3/0,0 mode: CR/CR res: 8589944660/2 bits 0x9 rrc: 11 type: IBT flags: 0x200000000020 nid: 4581@gni remote: 0x5cd35be174c032ea expref: 9 pid: 28346 timeout: 4324608334 lvb_type: 0 Mar 8 22:01:07 widow-mds1 kernel: [29941.810653] LustreError: 0:0:(ldlm_lockd.c:391:waiting_locks_callback()) Skipped 35 previous similar messages Minh Could you please see whether you are able to reproduce this? Thanks Peter Hi James, You said you ran create directory with increasing stripe count. Then you said at around 128 strips, "files" create failed. Did you try to create files under those directories after the directories created? Due to <a href="https://jira.whamcloud.com/browse/LU-2845" title="NULL pointer deref in osp_precreate_thread()" class="issue-link" data-issue-key="LU-2845"><del>LU-2845</del></a> I haven't been able to setup wide-striping cluster with 200 osts from 2 oss Hi James, I have setup 2 oss with 300 ost each but could not reproduce the problem you are seeing. Could you please try the latest build on lustre-master since there have been many fixes went in lately. Thanks Setting up a smaller scale test system to reproduce. While attempting to setup a system to reproduce this I ran into <a href="https://jira.whamcloud.com/browse/LU-3004" title="MGS llog choke on to much parameter data" class="issue-link" data-issue-key="LU-3004"><del>LU-3004</del></a> which is blocking me. Managed to get a 224 stripe count system up. So far I haven't been able to reproduce the problem. Please don't close the ticket until our next test shot in the latter part of April when we can make sure that this is fixed. James, just curious, what is the memory size on your oss? I am hitting OOM when I tried to mount 300 OSTs, stopping at around 241 I originally tried 448 OSTs but I also hit a OOM as well. I reduced my to 224 and that worked for me. The OSS I'm working with has 16GB of ram. Dropping in priority as unable to reproduce this issue on the latest master. Will raise it in priority again if it reoccurs. Good news and bad news. I can now duplicate this problem with the latest 2.3.63. What is the best debug settings to track down this problem? James, could you provide lustre debug log with debug=-1? how long does it take to produce this? With my IOR job less than a minute to reproduce. I'm going to setup the debug script now. Uploaded one clients log to ftp.whamcloud.com/uploads/<a href="https://jira.whamcloud.com/browse/LU-2963" title="fail to create large stripe count file with -ENOSPC error" class="issue-link" data-issue-key="LU-2963"><del>LU-2963</del></a>/lustre-log.c0-0c0s7n0.txt I have more client logs if you need them. how many oss and ost? how many client did you use for IOR? I'd like to try to reproduce this in the lab Here are my scripts to create a file system with the config (testfs-barry-224.conf). new-build formats the file system and new-lustre-start mounts it. Hostlist is used to handle the pdsh format listing of the devices and servers. I also attached my ior job scripts I used to run my IOR job with. 4 OSS each with 56 OST to give a total of 224 OSTs. This is a LVM setup were each OSS has 7 real OSTs. The client side I ran IOR across 18 cray computes. I attached all my setup scripts and the job script I ran with. You will need to adapt for your system. Any updates? Sorry, no. I hit <a href="https://jira.whamcloud.com/browse/LU-3102" title="kernel BUG at fs/jbd2/transaction.c:1033" class="issue-link" data-issue-key="LU-3102"><del>LU-3102</del></a> when I tried to reproduce. If it's easy for you to reproduce, could you upload servers and clients debug log (with debug=-1)? I have a client log uploaded already at ftp.whamcloud.com/uploads/<a href="https://jira.whamcloud.com/browse/LU-2963" title="fail to create large stripe count file with -ENOSPC error" class="issue-link" data-issue-key="LU-2963"><del>LU-2963</del></a>/lustre-log.c0-0c0s7n0.txt. I can get the server logs as well. yes, please upload the server logs too. thanks I need to build a new large stripe count file system for other test so I will get you new logs. I rebased to the latest master and now I can't reproduce this bug. I have a feeling some of the layout patches that were merged the 8th fixed this issue. Please leave this ticket open until after our test shot which will take place tomorrow. During the last test shot we encountered this bug again. This time we got logs from the clients and servers. I uploaded all the logs to ftp.whamcloud.com/uploads/<a href="https://jira.whamcloud.com/browse/LU-2963" title="fail to create large stripe count file with -ENOSPC error" class="issue-link" data-issue-key="LU-2963"><del>LU-2963</del></a>/testshot-4-12-2013 Yu, Jian Could you please review this latest information from ORNL? Thanks Peter Sorry, haven't looked at the logs yet. My gut feeling is that the -ENOSPC is being returned from the server, and either from the journal layer or from the xattrs, since these are the few places that are affected by growing stripe count. James, first question - is the "large_xattr" feature enabled on your MDS? This is still not being enabled by default (see <a href="http://review.whamcloud.com/4315" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4315</a>), since the patch has not been accepted upstream yet, and it makes sense to limit the feature exposure to sites that actually need it. This can be set any time during formatting (via mkfsoptions) or after (via tune2fs) with "-O large_xattr". James: I just checked the debug log, I did not find mds log there? Just want to confirm, the bug you hit in the last test is still "-NOSPC when you try to create a file with 224 stripes? Lustre Branch: master Lustre Build: <a href="http://build.whamcloud.com/job/lustre-master/1441/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-master/1441/</a> Distro/Arch: RHEL6.4/x86_64 (kernel version: 2.6.32-358.2.1.el6) Network: TCP (1GigE) OSSCOUNT=4 OSTCOUNT=224 (with 56 OSTs per OSS) MDSOPT="--mkfsoptions='-O large_xattr'" The parallel-scale test iorssf passed with 224 OSTs: <a href="https://maloo.whamcloud.com/test_sessions/ce2253de-af21-11e2-8f8e-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sessions/ce2253de-af21-11e2-8f8e-52540035b04c</a> As per run_ior() in lustre/tests/functions.sh, "$LFS setstripe $testdir -c -1" was performed before running the IOR command. Another test run with MDSOPT="--mkfsoptions='-O large_xattr -J size=1024'" also passed: <a href="https://maloo.whamcloud.com/test_sessions/94998110-af57-11e2-8f8e-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sessions/94998110-af57-11e2-8f8e-52540035b04c</a> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>+ /usr/bin/lfs setstripe /mnt/lustre/d0.ior.ssf -c -1 + /usr/bin/lfs getstripe -d /mnt/lustre/d0.ior.ssf stripe_count: -1 stripe_size: 1048576 stripe_offset: -1 + /usr/bin/IOR -a POSIX -C -g -b 1g -o /mnt/lustre/d0.ior.ssf/iorData -t 4m -v -e -w -r -i 5 -k </pre> </div></div> More tests passed: <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># ls -l /mnt/lustre/ total 0 # lfs setstripe -c 224 /mnt/lustre/file # lfs getstripe -i -c -s /mnt/lustre/file lmm_stripe_count: 224 lmm_stripe_size: 1048576 lmm_stripe_offset: 133 # yes | dd bs=1024 count=1048576 of=/mnt/lustre/file 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 1288.4 s, 833 kB/s # lfs getstripe -i -c -s /mnt/lustre/file lmm_stripe_count: 224 lmm_stripe_size: 1048576 lmm_stripe_offset: 133 # mkdir /mnt/lustre/dir # lfs getstripe -d /mnt/lustre/dir stripe_count: 1 stripe_size: 1048576 stripe_offset: -1 # lfs setstripe -c 224 /mnt/lustre/dir # lfs getstripe -d /mnt/lustre/dir stripe_count: 224 stripe_size: 1048576 stripe_offset: -1 # touch /mnt/lustre/dir/file # lfs getstripe -i -c -s /mnt/lustre/dir/file lmm_stripe_count: 224 lmm_stripe_size: 1048576 lmm_stripe_offset: 189 # yes | dd bs=1024 count=1048576 of=/mnt/lustre/dir/file 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 1359.48 s, 790 kB/s # lfs getstripe -i -c -s /mnt/lustre/dir/file lmm_stripe_count: 224 lmm_stripe_size: 1048576 lmm_stripe_offset: 189 # lfs getstripe -d /mnt/lustre/dir stripe_count: 224 stripe_size: 1048576 stripe_offset: -1 </pre> </div></div> Sorry about the confusion with this ticket. When I created this ticket for our first test shot this problem was only observed during our hero wide stripe test with 367 ost at the time. After that test shot I opened this ticket and prepared a scaling job that would create directories with powers of two stripe count. So for the second test shot we ran this scaling job to discover that the failure happened around 128 stripes which is below the old 160 stripe limit. For this last test shot run we again saw this problem not only at larger stripe count (128 stripes again) but also for single shared file that was stripe across 4 OSTs. This shared file was being written to by 18K number of nodes. So I don't think it is a general wide stripe problem we are seeing but some other issue. We thought it might of been a grant issues since the OSTs are only 250 GB in size but Oleg told me during LUG this is unlikely the case. P.S I can't seem to find the MDS ldump <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> Will talk to the admin tomorrow. James, this ENOSPC problem may only be related to your test configuration, if there are individual OSTs that are out of space for some reason. Creating a file with specific striping will fail if it can't allocate at least 3/4 of the requested stripes (some margin is allowed so that applications don't get failures when a small number of OSTs are offline). Is it possible that earlier in your testing that some OSTs were filled up? For the last test shot we had to reformat the file system due to the changes in the fid format. After mounting the file system I always run the large stripe job first. James, Have you run this large stripe job recently and, if so, are you still seeing this problem? Thanks, James The problem was large_xattr was not set on the MDS. That was resolved. What is not resolved is that when large stripe count is not set then the default LOV_MAX_STRIPE is not 160 but something less due to changes in the data being sent over wire. James, The patch for <a href="https://jira.whamcloud.com/browse/LU-4791" title="lod_ah_init() ASSERTION( lc->ldo_stripenr == 0 ) failed:" class="issue-link" data-issue-key="LU-4791"><del>LU-4791</del></a> has landed to master and there is a b2_4 patch available that has not landed yet. If you are able, please test with the <a href="https://jira.whamcloud.com/browse/LU-4791" title="lod_ah_init() ASSERTION( lc->ldo_stripenr == 0 ) failed:" class="issue-link" data-issue-key="LU-4791"><del>LU-4791</del></a> patch and see if it fixes this issue. Thank you. Excellent news. The patch from <a href="https://jira.whamcloud.com/browse/LU-4791" title="lod_ah_init() ASSERTION( lc->ldo_stripenr == 0 ) failed:" class="issue-link" data-issue-key="LU-4791"><del>LU-4791</del></a> fixes this issue. You can close this ticket. That is excellent news - thanks James! Related LU-4791 Development Rank 1|hzvldb: Rank (Obsolete) 7227 Severity