Message-ID: <87hbo37ay3.fsf@openvz.org>
Date:	Fri, 26 Mar 2010 11:18:28 +0300
From:	Dmitry Monakhov <dmonakhov@...nvz.org>
To:	Andreas Dilger <andreas.dilger@...cle.com>
Cc:	tytso@....edu, Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

Andreas Dilger <andreas.dilger@...cle.com> writes:

> On 2010-03-25, at 21:38, 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...
>
> I totally agree.  Having to run quotacheck when the quota is journaled
> is a major time waster on a large filesystem.  This is doubly true
> since the only time the journal should ever get inconsistent is when
> e2fsck changes it.
>
>> 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.
>
>> 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.
The only reason to not use journalled quota by default is the currently
it is a bit slower than unjournalled variant.
This is because each quota change result in synchronous quotafile 
update in per-sb-page-cache. And this update is protected by i_mutex.
and dqio_mutex. It may be fixed easily. I've sent a RFC patch two
month ago. I'll update it and will submit it this weekend. 
>
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Engineer, Lustre Group
> Oracle Corporation Canada Inc.
>
> --
> 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
--
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