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-7984 Lustre <ol> <li>du -hs --apparent-size .<br/> 15T .</li> <li>du -hs .<br/> 9,5T .</li> <li>lfs find . ! -G rcaguess</li> <li>lfs quota -g rcaguess /rfs18<br/> Disk quotas for group rcaguess (gid 771):<br/> Filesystem kbytes quota limit grace files quota limit grace<br/> /rfs18<br/> 375111456* 0 1048576 - 340878 0 0 -</li> </ol> <p>(Filesystem name edited to protect the guilty, but other than that<br/> it's a cut'n'paste.)</p> <p>There is such a huge difference between usage measured by the quota<br/> system and reality that it's a real operation issue.</p> <p>Is this resolvable without downtime? Getting to within 10% of real usage is workable, it doesn't need to be perfect.</p> <p>If not, what is the procedure to do an off-line fsck of the quota in 2.4?</p> CentOS 6.5, Linux 2.6.32-431.20.3.el6.x86_64<br/> <br/> Everything running on ZFS, llnl&#39;s patches to make ZFS usable (13chaos)<br/> <br/> lz4 compression enable<br/> <br/> Site is Linkoping University LU-7984

Group quota does not reflect actual usage

Bug Major Resolved Won't Fix Niu Yawei Peter Bortas Tue, 5 Apr 2016 12:32:29 +0000 Fri, 21 Jul 2017 12:44:43 +0000 Fri, 21 Jul 2017 12:44:43 +0000 Lustre 2.4.2 0 6 <p>Jira decided to auto-convert the root prompts to a numbered list. Imagine hashes instead of the list numbers...</p> <p>Niu</p> <p>Could you please advise?</p> <p>Thanks</p> <p>Peter</p> <p>I don't think there is any way to do offline fsck for zfs.</p> <p>Given the huge difference of quota output and du output, I suspect some OST objects got wrong ownership, and there were three known bugs which could lead to the inconsistent ownership on OST objects:</p> <ul class="alternate" type="square"> <li><a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a>. If you are running 2.4.2-llnl, I believe the fix has already been included. (Could you verify if your Lustre is the latest 2.4.2-llnl?)</li> <li><a href="https://jira.whamcloud.com/browse/LU-5006" title="chown/chgrp doesn&#39;t work for files created by lfs setstripe" class="issue-link" data-issue-key="LU-5006"><del>LU-5006</del></a>. If Application creates file by mknod (or by 'lfs setstripe') then changes the file's ownership, the ownership won't be set properly on OST objects.</li> <li><a href="https://jira.whamcloud.com/browse/LU-7205" title="OSP sync RPC could be out of order" class="issue-link" data-issue-key="LU-7205"><del>LU-7205</del></a>. This is a rare race and very unlikely to happen.</li> </ul> <p>The way to fix the inconsistent ownership is: find out all the files belong to group 'xxx', then explicitly change files's group to 'xxx' again (by chown or chgrp command from client), it can be done online. (The prerequisite is <a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a> is included)</p> <p>Thanks Niu, that gives me some threads to start pulling in.</p> <p>Re: "I don't think there is any way to do offline fsck for zfs"</p> <p>What I meant was a way to verify and update the combined quota counter against the objects in the OST. There is as you say no fsck for zfs outside of online scrub. </p> <p>Is there a way to map Lustre file/objid -&gt; zfs object/attribute to verify with zdb that wrong ownership of the object really is the problem?</p> <blockquote> <p>What I meant was a way to verify and update the combined quota counter against the objects in the OST.</p></blockquote> <p>I don't think zfs has that kind of tool neither.</p> <blockquote> <p>Is there a way to map Lustre file/objid -&gt; zfs object/attribute to verify with zdb that wrong ownership of the object really is the problem?</p></blockquote> <p>With zfs, I think you have to mount the OST as zfs then verify the objects' owner, that requires OST offline.</p> <p>Any updates on this? Can we close this one? Thanks.</p> <p>Seems like there are no further questions on this for the time being</p> Development End date Thu, 7 Apr 2016 12:32:29 +0000 Rank 1|hzy6s7: Rank (Obsolete) 9223372036854775807 Severity Start date Tue, 5 Apr 2016 12:32:29 +0000