From: Carlos Carvalho <carlos@fisica.ufpr.br>
To: linux-ext4@vger.kernel.org
Subject: Re: 3.10.10: quota problems
Date: Tue, 15 Oct 2013 23:58:52 -0300 [thread overview]
Message-ID: <21086.236.420841.123331@fisica.ufpr.br> (raw)
In-Reply-To: <20131016022548.GB28823@thunk.org>
Theodore Ts'o (tytso@mit.edu) wrote on 15 October 2013 22:25:
> Support for the quota feature first appeared in e2fsprogs 1.42,
> although it is not enabled by default. It must enabled via a
> compile-time configuration option, --enable-quota. There are bug fixes
> which have been applied in various 1.42.x maintenance branch releases,
> so users who wish to experiment with the quota feature are strongly
> encouraged upgrade to the latest e2fsprogs 1.42.x maintenance
> release. As of this writing the following bugs are still in e2fsprogs
> 1.42.7, which means use of file systems with the quota feature in
> production can not be recommended:
That's why I'm using 1.42.8, the latest version.
> * The e2fsck check of the on-disk quota inodes won't notice if
> there is a missing uid record. (i.e., if some uid, say daemon
> owns a bunch of files, but that uid record is not in the quota
> inode, e2fsck won't say boo.)
>
> * If e2fsck *does* notice a discrepancy between the usage
> information recorded in the hidden quota inodes, and the actual
> number of blocks used by a particular user id or group id, it
> will overwrite the user or group quota inode with all of the
> information it has. Unfortunately, in the process it will zero
> out all of the current quota limits set. This is unfortunate....
Unfortunate indeed but I can work around it. What's really bad is
*wrong usage*:
cyre#~ quota -v user1
Disk quotas for user user1 (uid 634):
Filesystem blocks quota limit grace files quota limit grace
/dev/md3 0 0 0 0 0 0
cyre#~ du -s ~user1
161M /home/users/user1
ls -l ~user1 shows lots of files belonging to user1. For myself:
cyre%~[23:42] quota -v
Disk quotas for user carlos (uid 577):
Filesystem blocks quota limit grace files quota limit grace
/dev/md3 721680 0 0 51064 0 0
cyre%~[23:42] du -s .
13,6G .
How can this be? Looks like a kernel problem.
prev parent reply other threads:[~2013-10-16 2:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 23:25 3.10.10: quota problems Carlos Carvalho
2013-10-15 15:53 ` Jan Kara
2013-10-15 21:55 ` Carlos Carvalho
2013-10-16 2:25 ` Theodore Ts'o
2013-10-16 2:58 ` Carlos Carvalho [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21086.236.420841.123331@fisica.ufpr.br \
--to=carlos@fisica.ufpr.br \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox