https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-7467 Lustre <p>Quota reporting zero inode usage for user.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">root.pfe21 # lfs quota -u mcantiel /nobackupp8 Disk quotas <span class="code-keyword">for</span> user mcantiel (uid 30403): Filesystem kbytes quota limit grace files quota limit grace /nobackupp8 59604412 530000000 1100000000 - 0 100000 150000 </pre> </div></div> <p>But user has &gt;74K files</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">root.pfe21 # find /nobackupp8/yjiang2/StarMidMHD3 -user mcantiel 2&gt;/dev/<span class="code-keyword">null</span> | wc -l 74223 </pre> </div></div> <p>Example file </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">-rw-r--r-- 1 mcantiel s1439 819753 Nov 17 22:20 /nobackupp8/yjiang2/StarMidMHD3/Data/id1569/Star-id1569.0029.vtk </pre> </div></div> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">debugfs: stat Star-id1569.0029.vtk Inode: 189531663 Type: regular Mode: 0644 Flags: 0x0 Generation: 3904475524 Version: 0x000000c0:2479d74b User: 30403 Group: 41439 Size: 0 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0 <span class="code-object">Number</span>: 0 Size: 0 ctime: 0x564c909d:00000000 -- Wed Nov 18 06:52:13 2015 atime: 0x5653822b:00000000 -- Mon Nov 23 13:16:27 2015 mtime: 0x564c18c1:72aae770 -- Tue Nov 17 22:20:49 2015 crtime: 0x564c18c1:72aae770 -- Tue Nov 17 22:20:49 2015 Size of extra inode fields: 28 Extended attributes stored in inode body: lma = <span class="code-quote">"00 00 00 00 00 00 00 00 77 6e 3b 60 03 00 00 00 69 53 00 00 00 00 00 00 "</span> (24) lma: fid=[0x3603b6e77:0x5369:0x0] compat=0 incompat=0 lov = <span class="code-quote">"d0 0b d1 0b 01 00 00 00 69 53 00 00 00 00 00 00 77 6e 3b 60 03 00 00 00 00 00 10 00 01 00 00 00 2c 43 d0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5b 00 00 00 "</span> (56) link = <span class="code-quote">"df f1 ea 11 01 00 00 00 3e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 26 00 00 00 03 60 3b 46 a9 00 01 3a 2f 00 00 00 00 53 74 61 72 2d 69 64 31 35 36 39 2e 30 30 32 39 2e 76 74 6b "</span> (62) BLOCKS: </pre> </div></div> LU-7467

Quota Account wrong

Bug Minor Resolved Cannot Reproduce Niu Yawei Mahmoud Hanafi Mon, 23 Nov 2015 22:22:10 +0000 Thu, 8 Sep 2016 22:24:11 +0000 Thu, 8 Sep 2016 22:24:11 +0000 0 5 <p>It looks similar to <a href="https://jira.whamcloud.com/browse/LU-7459" title="Incorrect file count with lfs quota" class="issue-link" data-issue-key="LU-7459"><del>LU-7459</del></a>, the inode accounting for certain user is suddenly broken somehow.</p> <p>Mahmoud, could provide more details about the problem? What's the Lustre/Kernel version? If the accounting will change when you adding/removing files? Any error messages prompted in dmesg when you adding/removing files (or inquiring quota)?</p> <p>The server is running kernel: 2.6.32-431.29.2.el6 with lustre 2.5.3<br/> The client is running Sles 3.0.101-0.47.67.2 with lustre 2.5.3</p> <p>No errors are seeing when running quota inquire. Adding new file/directory does change usage.<br/> lfs quota -u mcantiel /nobackupp8<br/> Disk quotas for user mcantiel (uid 30403):<br/> Filesystem kbytes quota limit grace files quota limit grace<br/> /nobackupp8 59609128 8589934592 10737418240 - 11 1000000 2000000 -</p> <p>I suspect that this discrepancy may have happened when the MDS crashed a few days ago. We had this happen once before to a number of users when the MDS crash due to power outage. </p> <p>In that case, we need to run quotacheck (by disable then re-enable quota feature on MDT device, MDT needs be offline) to fix the inconsistent data.</p> <p>This method of fixing these discrepancies is not preferred. We are not able to take downtime every time the quotes are inconsistent. </p> <p>Yes, I totally understood your concern, but it's the only way to fix a already corrupted accounting file so far (it's part of e2fsck functionality actually, so it must be done offline)</p> <p>The reason of the corrupted accounting file is unclear now, if there is some kind of evidence or clue indicating the corruption is caused by certain operation or race, I think we need to trace it down and try to to find out the bug (probably in kernel or e2fsprogs).</p> <p>Did you ever run e2fsck when the MDT recovered from the power outage? What's the version of e2fsprogs on server?</p> <p>Close.</p> <p>ok Mahmoud</p> Related LU-7459 Development End date Wed, 2 Dec 2015 22:22:10 +0000 Rank 1|hzxu3b: Rank (Obsolete) 9223372036854775807 Severity Start date Mon, 23 Nov 2015 22:22:10 +0000