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-4530 Lustre <p>Hello,</p> <p>'lfs quota -u $(whoami)...' reports "Permission denied' for regular users. It works if the same user queries the quota for <b>another</b> user:</p> <p>$ whoami<br/> cdufour</p> <p>$ lfs quota -u $(whoami) /idiap/temp/$(whoami)<br/> Permission denied.</p> <p>$ lfs quota -u formaz /idiap/temp/formaz<br/> Disk quotas for user formaz (uid 1005):<br/> Filesystem kbytes quota limit grace files quota limit grace<br/> /idiap/temp/formaz<br/> 113371820 1072693248 1073741824 - 452499 9999900 10000000 -</p> <p>(patch follows as soon as I have the LU-&lt;ID&gt; for this bug)</p> <p>Best,</p> <p>Cédric</p> LU-4530

Mainline kernel client (3.12-3.14): lfs quota -u ... -> Permission denied

Bug Minor Resolved Fixed Oleg Drokin Cédric Dufour patch Thu, 23 Jan 2014 10:18:42 +0000 Wed, 1 Jul 2015 16:29:11 +0000 Wed, 1 Jul 2015 16:29:11 +0000 0 6 <p>Hello again,</p> <p>Problem was introduced by changes made in <a href="https://lkml.org/lkml/2013/7/15/218" class="external-link" target="_blank" rel="nofollow noopener">https://lkml.org/lkml/2013/7/15/218</a>, which got the "uid_eq" check the wrong way around.</p> <p>Attached patch solves the issue:</p> <p>$ whoami<br/> cdufour</p> <p>$ lfs quota -u $(whoami) /idiap/temp/$(whoami)<br/> Disk quotas for user cdufour (uid 1224):<br/> Filesystem kbytes quota limit grace files quota limit grace<br/> /idiap/temp/cdufour<br/> 20 1072693248 1073741824 - 5 9999900 10000000 -</p> <p>$ lfs quota -u formaz /idiap/temp/formaz<br/> Permission denied.</p> <p>Best,</p> <p>Cédric</p> <p>PS: what is the recommended GIT source to work on the mainline kernel client of Lustre ?<br/> (I'm currently working with git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git)</p> <p>Yes, the upstream kernel patches you just send to Greg &amp; general Linux mailing lists (and CC us too, of course), as we have no commit right to staging tree ourselves.</p> <p>Thanks!</p> <p>Couple of additional questions/comments concerning this:</p> <ul class="alternate" type="square"> <li>Is there no internal GIT repo for this at Intel (if yes, please make it available publicly)?</li> <li>How do you manage the flow from the master Lustre branch to the in-kernel code? It seems<br/> a lot of fixes don't make it to the in-kernel code.</li> <li>Is there any QA/testing on the in-kernel code (the 3.12 stuff crashes as soon as you load the modules)?</li> <li>I think, if the in-kernel stuff is supposed to attract any serious users, there should be a much<br/> better workflow and clear policy regarding its management.</li> </ul> <ul class="alternate" type="square"> <li>The mainline-tracking repo is currently being setup (so, no, there is not one yet).<br/> For now the best you could do is send patches to Greg KH directly, and CC us, so we can pick those up once (either immediately, or once we actually add support for such modern kernels).</li> </ul> <ul class="alternate" type="square"> <li>The flow from master to mainline kernel is not currently working all that well, we are currently thinking how to overcome this. The present state is such that the upstream kernel lustre code is quite a bit behind in some respects and ahead in others.</li> </ul> <ul class="alternate" type="square"> <li>The official QA/testing will be happening in the repo from item #1 once it's ready, we are working on it. Until then, it's just a few developers have their own testbeds. I set up mine just this week and the state is quite sorry, I am feeding important bugfixes upstream to Greg now to make the client at least work in most cases (I guess see my patches from yesterday in lkml as a startign point, also do not use 3.12, for best results the staging tree is what has the most uptodate client).<br/> Also, do not enable the additional lustre debug checks, those don't work at present and crash needlessly, this will be fixed eventually.</li> </ul> <p>I agree currently in-kernel stuff is in a somewhat strange state now (for a variety of reasons, not all of which are actually under our control), we are thinking on how to better turn it around.</p> <p>Hello Oleg,</p> <p>Thank you for those precisions.</p> <p>Thanks to Roland - who originally set up our Lustre cluster server-wise - we have been using Lustre for 5 years now, as a general purpose temp space for our users and our computation grid. We're quite happy with it, especially after evaluating several commercial solutions and finding none up to Lustre so far. Lately, we grew plagued by the requirement to stick with the 2.6.32 kernel (supporting new hardware and new distributions was becoming a nightmare). As we migrated from Lustre 1.8 to 2.4 - thanks to Roland again - we decided to use the in-kernel client (actually, using the in-kernel client was the pre-requisite for this migration). We're happy to see that it works. There are few bugs of course, but fortunately none blocking. Thanks to a very few patches added to 3.13/14 kernel - namely those addressing <a href="https://jira.whamcloud.com/browse/LU-4209" title="O_LOV_DELAY_CREATE conflict with __O_TMPFILE" class="issue-link" data-issue-key="LU-4209"><del>LU-4209</del></a>, 4231, 4400, 4530 and hopefully soon 4520 - our Lustre cluster is functional production-wise.</p> <p>We believe that proper in-kernel support can bring a lot of momentum to Lustre. We hope that Lustre in-kernel client may one day be as notorious as other Intel's contributions to the kernel. Let us know if we can help in some ways.</p> <p>Best,</p> <p>Cédric</p> <p>Thanks for this info. I am glad to hear you find lustre useful and that even vanilla kernel client works for you.</p> <p>I uploaded a stream of patches I plan to push upstream to <a href="https://github.com/verygreen/linux/tree/lustre-next" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/verygreen/linux/tree/lustre-next</a><br/> With it and updated <a href="https://jira.whamcloud.com/browse/LU-4209" title="O_LOV_DELAY_CREATE conflict with __O_TMPFILE" class="issue-link" data-issue-key="LU-4209"><del>LU-4209</del></a> patch for the tools sanity testing almost completely succeeds, and more importantly, nothing crashes anymore.</p> <p>I know Peng Tao has his tree at <a href="https://github.com/bergwolf/linux/compare/master-sync-round-5" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/bergwolf/linux/compare/master-sync-round-5</a> that has some more patches, though not as critical for normal operations.</p> <p>BTW, do you happen to use jobstats feature?</p> <p>Thanks for the GIT pointers. Having some "insider's" insights on which patch to "backport" in priority (before they make it to the kernel) will definitely help (and provide opportunities for feedback from us users before it does).</p> <p>Will/should patches always be linked to Jira IDs and should Jira be the place to provide feedback (in case issues remain) ?<br/> Will a notice be given in Jira when a patch is submitted to mainline ?</p> <p>Also, are you the one to link new mainline kernel issues with <a href="https://jira.whamcloud.com/browse/LU-4416" title="support for 3.12 linux kernel" class="issue-link" data-issue-key="LU-4416"><del>LU-4416</del></a> or can/should we reporter do it ?<br/> (note: actually haven't found how to link one issue to another in Jira).</p> <p>As for jobstats: I hadn't heard of them until your mention but I will look into it; it seems it would allow us to address some questions we have with some load patterns we experience with our (SGE) grid.</p> <p>Best,</p> <p>Cédric</p> <p>Thanks for your detailed answer to my questions. I am glad to see you are putting further<br/> effort into the vanilla kernel client. Looking forward to the days, when the server code will<br/> compile against recent vanilla kernels as well <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p><a href="https://jira.whamcloud.com/browse/LU-4416" title="support for 3.12 linux kernel" class="issue-link" data-issue-key="LU-4416"><del>LU-4416</del></a> is not related to in-kernel client, instead it's for our efforts to make our lustre version to compile against mainline kernel.<br/> There's certainly some overlap, but please file in-kernel client bugreports separately ad marked as such</p> <p>This patch landed upstream. We can now close this ticket.</p> <p>Peter you can close this ticket as well since the patch has landed upstream.</p> <p>The fix </p> <p>commit 8b9e418c013e8b671fc10108ab14243f0657bffd<br/> Author: Cédric Dufour - Idiap Research Institute &lt;cedric.dufour@idiap.ch&gt;<br/> Date: Fri Jan 24 20:57:05 2014 +0100</p> <p> staging: lustre: fix quotactl permission denied (<a href="https://jira.whamcloud.com/browse/LU-4530" title="Mainline kernel client (3.12-3.14): lfs quota -u ... -&gt; Permission denied" class="issue-link" data-issue-key="LU-4530"><del>LU-4530</del></a>)</p> <p> The changes introduced in commit 4b1a25f06b30b203 ("fix build when<br/> CONFIG_UIDGID_STRICT_TYPE_CHECKS is on") got the UID check the wrong way<br/> around, leading to "Permission denied" when a regular user attempts to<br/> retrieve his quota (lfs quota -u ...) but allowing him to retrieve other<br/> users quota.</p> <p> Full details at: <a href="https://jira.hpdd.intel.com/browse/LU-4530" class="external-link" target="_blank" rel="nofollow noopener">https://jira.hpdd.intel.com/browse/LU-4530</a></p> <p> Cc: Peng Tao &lt;tao.peng@emc.com&gt;<br/> Cc: &lt;stable@vger.kernel.org&gt; # 3.12.x<br/> Cc: &lt;stable@vger.kernel.org&gt; # 3.13.x<br/> Signed-off-by: Cédric Dufour &lt;cedric.dufour@idiap.ch&gt;<br/> Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;</p> <p>was landed upstream. This ticket can be closed.</p> <p>Close as James's comment.</p> Related LU-6215 LU-4011 LU-4416 Development Rank 1|hzwdgn: Rank (Obsolete) 12388 Severity