From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <andreas.dilger@oracle.com>
Cc: tytso@mit.edu, Jan Kara <jack@suse.cz>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck
Date: Fri, 26 Mar 2010 11:54:41 +0100 [thread overview]
Message-ID: <20100326105441.GB3055@quack.suse.cz> (raw)
In-Reply-To: <9E7C0FF6-B02F-4470-B70A-4DBF5D5D6E0E@oracle.com>
On Fri 26-03-10 01:01:35, Andreas Dilger wrote:
> >Yes, quite possibly. How quota is currently is set up is quite
> >kludgy, with magic options that do nothing but display magic options
> >in /proc/mounts, just in case that's a hard link to /etc/mtab. It
> >also looks like that some of the magic is in various distribution's
> >init.d scripts, and so while I very much want to clean things up, it
> >wasn't clear to me how much flexibility we would have without worrying
> >about breaking the init scripts for Debian, Ubuntu, RHEL, SLES,
> >Fedora, Open SuSE, etc.
> >
> >There may also be other programs that depend on the existence of
> >aquota.user, and may be reading and writing them in various random
> >ways, and there is the question of how do we provide compatibility
> >with these other programs, some of which may not be within quotatools,
> >but in various magic virtualization or container or cluster management
> >systems....
>
> If the quota file is already present as a regular file, I don't
> think it would be terrible to leave it in place, but to create new
> quota files as hidden files.
> It also would be nice to always enable quota journaing in ext4,
> since I don't think this does any harm, and if quotacheck isn't run
> then at least there a good chance the quotas are still correct.
Yes, this should be a good option. I imagine we would create RO_COMPAT
features USRQUOTA and GRPQUOTA meaning that the filesystem maintains
quotas in hidden files. And mkfs would directly create these files if
it was asked to.
> >So maintaining compatibility between older kernels, newer kernels,
> >older init scripts, new init scripts, etc. may make changing the quota
> >system quite difficult. I would like to do as much cleanup as we can,
> >though.
> >
> >One question I have --- do we really have to support the 2 or 3
> >different quota variants? How many people/distributions are still
> >using the original old quota system? One thing that worries me is
> >that it looks like the old (non-journaled) quota system may be the
> >primary system still being used by Canonical and Debian... I really
> >do hope I'm wrong, but there are a bunch of HOWTO's that still people
> >to use usrquota and grpquota in /etc/fstab, and not the newer
> >usrjquota and grpjquota mount options.
>
> If there isn't a reason to continue using unjournaled quota (i.e. it
> doesn't break to just move to journaled quota everywhere), then
> these could just become aliases for the journaled quota
> implementation. The other alternative is to deprecate these options
> in the next kernel and have it print out a warning on the console to
> tell the user to switch over to the journaled version.
If we make quota files hidden and teach quota-tools to not depend on
usr[j]quota options, then we don't need any quota options at all. And I'd
leave usrjquota / grpjquota as they are. Maybe we could issue a warning
when usrquota / grpquota is used but quotacheck already prints the warning
that you should use journaled quotas if it's run on ext3 / ext4. So
we already have this to some extent.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2010-03-26 10:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 0:20 [PATCH,RFC] Adding quotacheck functionality to e2fsck Theodore Ts'o
2010-03-26 0:47 ` Jan Kara
2010-03-26 3:38 ` tytso
2010-03-26 7:01 ` Andreas Dilger
2010-03-26 8:18 ` Dmitry Monakhov
2010-03-26 10:57 ` Jan Kara
2010-03-26 11:15 ` Dmitry Monakhov
2010-03-26 16:27 ` Dmitry Monakhov
2010-03-29 7:35 ` Jan Kara
2010-03-29 7:50 ` dmonakhov
2010-03-26 10:54 ` Jan Kara [this message]
2010-03-26 13:51 ` tytso
2010-03-30 0:43 ` Jan Kara
2010-03-26 10:42 ` Jan Kara
2010-03-26 13:38 ` tytso
2010-03-30 0:55 ` Jan Kara
2010-03-30 5:26 ` Dmitry Monakhov
2010-03-30 12:42 ` Jan Kara
2010-03-26 8:09 ` Dmitry Monakhov
2010-03-26 11:00 ` Jan Kara
2010-03-26 13:55 ` tytso
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=20100326105441.GB3055@quack.suse.cz \
--to=jack@suse.cz \
--cc=andreas.dilger@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).