From: Carlos Carvalho <carlos@fisica.ufpr.br>
Subject: 3.10.10: quota problems
Date: Fri, 11 Oct 2013 20:25:41 -0300
Message-ID: <21080.35061.164482.975014@fisica.ufpr.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: linux-ext4@vger.kernel.org
Sender: linux-ext4-owner@vger.kernel.org

There are two problems. First, on a new filesystem with
tune2fs -Q usrquota and grpquota was working fine until a power
failure switched the machine off. On reboot all files seem normal
but quota -v showed no limits neither usage...

I ran fsck and it said the fs was clean. Then I ran fsck -f and

Pass 5: Checking group summary information
[QUOTA WARNING] Usage inconsistent for ID 577:actual (12847804416, 308767) != expected (12868194304, 308543)
[QUOTA WARNING] Usage inconsistent for ID 541:actual (186360393728, 11089) != expected (186340204544, 11085)

... etc until

Update quota info for quota type 0<y>? yes

then some more of

[QUOTA WARNING] Usage inconsistent for ID 500:actual (192918523904, 20725) != expected (192897576960, 20671)

until

Update quota info for quota type 1<y>? yes

/dev/md3: ***** FILE SYSTEM WAS MODIFIED *****

After remounting and running quota on usage for some users were back
but not limits. For other users even usage is lost.

This is with 3.10.10, e2fsprogs 1.42.8 (Debian) and mount options
rw,nosuid,nodev,commit=30,stripe=768,data=ordered,inode_readahead_blks=64

This was the first unclean shutdown of this machine after more than 6
months of usage. The new quota method looks fragile... Is there
something I can do get limits and usage back?

--------------------------------------------------

The second problem is on an old filesystem with the old quota system,
also with kernel 3.10.10 but another machine. Compilation is different
because this one is 32bit, the other is 64bit. mount options are

defaults,strictatime,nobarrier,nosuid,nodev,commit=30,inode_readahead_blks=64,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1

The problem here is that after removing lots of users in a row
repquota -v shows many entries of removed users in numerical form, like

#42       --      32       0       0              1     0     0       

However all files of the removed users have been deleted and their
quota set to zero with setquota, so there should be no such entries.
After umounting and running quotacheck these entries effectively
disappear. This problem has already happened several times years ago
and had been fixed, but has resurfaced...