linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).