lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Oct 2013 20:25:41 -0300
From:	Carlos Carvalho <carlos@...ica.ufpr.br>
To:	linux-ext4@...r.kernel.org
Subject: 3.10.10: quota problems

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists