Ted's email about quotacheck made me think:

Is there a reason that journaled quota is not default for ext4?
(or ext3 for that matter, but we're not messing with that now)

IOW - if we do mount -o quota, is there any reason that we should
also need more options to journal that quota?  When would we not
want journaled quota?

(Forgive me if it's a dumb question, I'm not as well versed in
extN quota as I probably should be).

-Eric
--

[ message continues ]

Part of the problem is that these mount options matter to various init
scripts (and possibly to quotatools?).  So for example, the usrquota
and grpquota mount options are complete no-ops as far as the kernel
code is concerned.  But they are there so they show up in
/proc/mounts, just in case /etc/mtab is a symlink to /proc/mounts (as
it is in some setups), because userspace scripts/tools care about
knowing whether the user wanted user or group quotas.  (And I think
the reason for that is because if someone only wants user or group
quotas, it's cheaper/faster if we only do the form of quota that is
required by the sysadmin....)

Worse yet, not all the distributions are standardized using the same
init scripts.

I *think* ditching non-journal quota does simplify things immensely,
but we will need to collect init scripts (and possibly private patches
to quotatools) across multiple distributions in order to be sure.

(I was looking at this, as well as the documentation out there on the
net about how to use quotas, and it's a bit of a mess.  :-/ )

    	      	     	     	      - Ted
--

[ message continues ]

Yes, quota-tools currently use these options as well to detect whether they
should run the command on the filesystem or not. The problem is that at least
"quotaon -a" needs to know on which filesystem it should run and currently it
uses quota mount options to decide. I can change quota tools to just look for
quota files but that's not guaranteed to succeed because for unjournaled
quotas, quota files could be anywhere - even on a different filesystem - and I
really know admins who use such setup. And for journaled quotas, file name
of the quota file is the one given in the {usr,grp}jquota mount option
so without it it's impossible to locate the quota file as well.
  So I think the easiest way out of this is really to make quota files hidden
as we discussed in another thread. Then kernel always knows whether the
filesystem accounts quotas or not and quota tools can ask it with GETFMT
quotactl.

									Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs
--

[ message continues ]

Hmm.... so is this something we need to continue to support?  If we
phase out support for anything other than hidden journal files, that

... and sometimes names other than aquota.user and aquota.group are
used?  I was thinking about having e2fsck look for those file names,
maybe check the format, and then offer to auto-convert them to the new
format with hidden quota files.  I suppose I could have e2fsck try to
look for that information in /etc/fstab, but that adds a different
layer of complexity (namely, we need to be confident we can match up a
particular device with an /etc/fstab entry, which usually but doesn't

I agreee, long term that will be the right answer.

I just realized that since ext4 does support a nojournal mode, we will
also need to support a no-journal mode with the hidden quota file, but
that's not a big deal if e2fsck handles checking the file system
consistency as well as rebuilding the quota in-use information for the
hidden quota file.

					- Ted
--

[ message continues ]

Yes, they will be forced to move. Honestly, I never heard a good technical
reason for this so hopefully it won't be a big pain for them. But sure we have
to provide a long enough period where we only warn about deprecation so that we
  Alternatively, you could have an option where admin could provide filenames
of quota files for conversion if e2fsck cannot find them on its own. It
wouldn't be automated but it would still provide a reasonable transition
path.

									Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs
--

[ message continues ]