[Top] [All Lists]

Re: quotacheck speed

To: Arkadiusz Miśkiewicz <arekm@xxxxxxxx>
Subject: Re: quotacheck speed
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 13 Feb 2012 09:21:59 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <201202122201.07649.arekm@xxxxxxxx>
References: <201202122201.07649.arekm@xxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Feb 12, 2012 at 10:01:07PM +0100, Arkadiusz Miśkiewicz wrote:
> Hi,
> When mounting 800GB filesystem (after repair for example) here quotacheck 
> takes 10 minutes. Quite long time that adds to whole time of filesystem 
> downtime (repair + quotacheck).

How long does a repair vs quotacheck of that same filesystem take?
repair has to iterate the inodes 2-3 times, so if that is faster
than quotacheck, then that is really important to know....

> I wonder if quotacheck can be somehow improved or done differently like doing 
> it in parallel with normal fs usage (so there will be no downtime) ?

quotacheck makes the assumption that it is run on an otherwise idle
filesystem that nobody is accessing. Well, what it requires is that
nobody is modifying it. What we could do is bring the filesystem up
in a frozen state so that read-only access could be made but
modifications are blocked until the quotacheck is completed.

Also, quotacheck uses the bulkstat code to iterate all the inodes
quickly. Improvements in bulkstat speed will translate directly
into faster quotachecks. quotacheck could probably drive bulkstat in
a parallel manner to do the quotacheck faster, but that assumes that
the underlying storage is not already seek bound. What is the
utilisation of the underlying storage and CPU while quotacheck is

Otherwise, bulkstat inode prefetching could be improved like
xfs_repair was to look at inode chunk density and change IO patterns
and to slice and dice large IO buffers into smaller inode buffers.
We can actually do that efficiently now that we don't use the page
cache for metadata caching. If repair is iterating inodes faster
than bulkstat, then this optimisation will be the reason and having
that data point is very important....


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>