[Bugme-janitors] [Bug 9520] New: Quotas modification on a loaded system takes up to several minutes to complete

bugme-daemon at bugzilla.kernel.org bugme-daemon at bugzilla.kernel.org
Fri Dec 7 10:26:20 PST 2007


http://bugzilla.kernel.org/show_bug.cgi?id=9520

           Summary: Quotas modification on a loaded system takes up to
                    several minutes to complete
           Product: File System
           Version: 2.5
     KernelVersion: 2.6.23.x and current up to 2.6.24-rc4-git5
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: Other
        AssignedTo: fs_other at kernel-bugs.osdl.org
        ReportedBy: gentuu at gmail.com
                CC: oleg at tv-sign.ru


Most recent kernel where this bug did not occur: not tested
Distribution: GNU
Hardware Environment: i386
Software Environment: GNU
Problem Description:
"quotaon" process hangs for several minutes on a loaded system to complete.
Sometimes it takes 10 minutes...
The process hangs in near-to-deadlock function fs/dquot.c:add_dquot_ref()
for so long.
The problem is in the function's weak algorithm.

Steps to reproduce:
Quota modification with edquota can bring quotaon process in the first top
position for 2-3 seconds even on a low loaded system.

Not fully sure how to reproduce  problem to hang quotaon for several minutes
(just big disk load?)

The problem algorithm (at fs/dquot.c:add_dquot_ref()) theoretically may
loop infinitely. It is a deadlock possible!!

It goes through super block's inodes list and inits some inodes. But after the
init call - it starts the loop over!! Is that necessary?
In the worst _static_ (none else updates the FS) case (when all the inodes
require init) the loop can be run (N^2)/2 times !!
But just anything updates every time an inode in the start of the list - the
loop will always start over and over...
It looks like the logic is broken...

It's much better to create a loop against running whole list
and continue until a loop updates 0 inodes.
In this case the worst static situation takes just 2 loops:
first one updates all the inodes, and the next one - just see that it's nothing
to do.
Obviously, any FS updates during such updated logic can't delay function finish
for so long as it's now.

The attached patch implements the new algorithm.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the Bugme-janitors mailing list