Jan Kara <jack@suse.cz> writes:

quoted text
>   Hi Ted,
>
> On Thu 25-03-10 20:20:18, Theodore Ts'o wrote:
>> This is something I whipped up last night to speed up quotacheck by
>> doing the data collection in e2fsck.  If e2fsck runs and does a full
>> check, it's likely that quotacheck needs to be run as well --- and it's
>> faster if e2fsck does the dirty work of fetching the information since
>> (1) it needs to paw through all of the inodes anyway, and (2) quotacheck
>> has to go through the file system and iterate over the files in an
>> non-optimal order.
>> 
>> What do folks think?  Obviously changes in quotacheck would be required
>> before it could take advantage of these output files, but hopefully that
>> shouldn't be hard...
>> 
>> To use, either use:
>> 
>>    e2fsck -E usrquota_check=/tmp/quota.user,grpquota_check=/tmp/quota.group
>> 
>> or you can edit /etc/e2fsck.conf and add:
>> 
>> [quota]
>> 	directory = /var/e2fsck/quota
>> 
>> I still need to write documentation, update the man pages, and do some
>> polishing, so this is still in a pretty rough state, but I'd appreciate
>> comments.
This is definitely right idea.
quoted text
>   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
Please excuse my naive question, but is it easy enough to allocate
space during fsck?  If we allow to do this then each fsck will result
in sb-changes because of new tmp quota-file creation/rename/deletion
even if sb and quota is ok.
quoted text
> 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...
>
> 								Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html