3.10.10: quota problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux