lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100326104205.GA3055@quack.suse.cz>
Date:	Fri, 26 Mar 2010 11:42:05 +0100
From:	Jan Kara <jack@...e.cz>
To:	tytso@....edu
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

On Thu 25-03-10 23:38:24, tytso@....edu wrote:
> On Fri, Mar 26, 2010 at 01:47:38AM +0100, Jan Kara wrote:
> >   This is definitely a move in the right direction. I'd be even happier
> > if e2fsck would write quota file directly - then we could just make
> > quota files hidden inodes, start doing quota accounting immediately
> > on mount and always do quota journaling. That would save us quite some
> > trouble in kernel. The only problem with this is that we'd need to pull
> > knowledge about quota formats in e2fsck...
> 
> 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.
  Well, init scripts can be fixed and if we provide some grace time for
distros to catch up I believe this isn't that hard.

> 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....
  Yeah, this is possible, although I'm not aware of any such program -
except for repquota and warnquota from quota-tools but I'll take care about
those. What some programs do is that they change quota files via kernel
(quotactl) or call programs from quota-tools but that is fine (and ultimately
the only way I'd like to leave to userspace when the filesystem is mounted).

> 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.
  Actually, XFS and OCFS2 already use hidden quota files. So it won't be
completely new thing.

> 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.
  Yeah, I believe that support for the oldest quota format can be phased
out - the new format is around for something like 10 years and it had
it's problems at that time already. I guess I'll add a warning to the
next release of quota-tools to the people still using it.
  About quota journaling - it has some performance penalty (changed quota
structures have to be written on every transaction commit instead of just
once on quotaoff time / sync) but I belive that if someone is running
journaled filesystem, he also should use journaled quotas because it's
essentially filesystem metadata.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ