From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
stable@vger.kernel.org, adityakali@google.com, adilger@dilger.ca
Subject: Re: [PATCH 2/2] quota: autoload the quota_v2 module for QFMT_VFS_V1 quota format
Date: Mon, 21 Jan 2013 10:50:20 -0500 [thread overview]
Message-ID: <20130121155020.GD5618@thunk.org> (raw)
In-Reply-To: <20130121151008.GM5588@quack.suse.cz>
On Mon, Jan 21, 2013 at 04:10:08PM +0100, Jan Kara wrote:
> Exactly. There shouldn't be any conflicts so just keep it in your tree.
> You can add to the patch:
> Acked-by: Jan Kara <jack@suse.cz>
Great, thanks.
BTW, do you have any plans to work on getting repquota support for
ocfs2 and ext4 with the internal quota support into quotactl(2) and
quotatools? It's missing functionality that I think users who want to
switch to the internal quota support will very much care about.
The work list that I have currently for ext4 w/ internal quota support
are:
1) Debugfs support for manipulating the quota inode directly. (So we
can introduce fs corruptions and make sure e2fsck deals
appropriately).
2) Make sure e2fsck preserves the quota limits information when it
repairs the quota information, and that it notices a missing quota
record in the quota inode.
3) Make sure e2fsck notices repairs a quota inode which is corrupted
in some way (and not just contains missing or incorrect usage
information).
4) More regression tests in e2fsprogs.
5) Add some kind of functional replacement for repquota. If
quotactl(2) support is not forthcoming in the near future, at the very
least debugfs should have a way of dumping out the repquota
information for an unmounted ext4 file system with internal quotas
enabled.
Can anyone think of other things which might be missing?
- Ted
next prev parent reply other threads:[~2013-01-21 15:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-19 2:40 how to quotacheck with the new quota implementation (hidden inode)? Carlos Carvalho
2013-01-21 5:47 ` Theodore Ts'o
2013-01-21 6:46 ` [PATCH 1/2] ext4: release sysfs kobject when failing to enable quotas on mount Theodore Ts'o
2013-01-21 6:46 ` [PATCH 2/2] quota: autoload the quota_v2 module for QFMT_VFS_V1 quota format Theodore Ts'o
2013-01-21 10:40 ` Jan Kara
2013-01-21 15:01 ` Theodore Ts'o
2013-01-21 15:10 ` Jan Kara
2013-01-21 15:50 ` Theodore Ts'o [this message]
2013-01-21 19:08 ` Jan Kara
2013-01-21 12:16 ` Carlos Maiolino
2013-01-21 12:12 ` [PATCH 1/2] ext4: release sysfs kobject when failing to enable quotas on mount Carlos Maiolino
2013-01-21 17:26 ` how to quotacheck with the new quota implementation (hidden inode)? Carlos Carvalho
2013-01-21 19:34 ` Aditya Kali
2013-01-31 19:01 ` Carlos Carvalho
2013-01-31 19:04 ` Aditya Kali
2013-01-31 19:13 ` Carlos Carvalho
2013-01-31 22:03 ` Theodore Ts'o
2013-01-31 22:28 ` Jan Kara
2013-01-31 22:44 ` Carlos Carvalho
2013-01-31 23:03 ` Theodore Ts'o
2013-02-04 9:42 ` Jan Kara
2013-01-31 22:41 ` Carlos Carvalho
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=20130121155020.GD5618@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=adityakali@google.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@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;
as well as URLs for NNTP newsgroup(s).