[Top] [All Lists]

Re: quotacheck speed

To: Linux fs XFS <xfs@xxxxxxxxxxx>
Subject: Re: quotacheck speed
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Mon, 13 Feb 2012 00:17:55 +0000
In-reply-to: <20120212234425.GA23625@xxxxxxxxxxxxx>
References: <201202122201.07649.arekm@xxxxxxxx> <20120212234425.GA23625@xxxxxxxxxxxxx>
>> 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).

For tight downtime minimization requirements wishful thinking is
not a strategy: whole filetree metadata scans are not cheap. If
you require fast scan of metadata of the whole filetree, ensure
filetrees don't have a lot of metadata (or fund the development
of a parallel whole tree metadata scanner).

Also 10 minutes is not that long; file system checks/repairs can
take days or weeks.

>> 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) ?

>From 'man 8 quotacheck':

 "It is strongly recommended to run quotacheck with quotas turned off for  the  
  tem.  Otherwise, possible damage or loss to data in the quota files can 
result.  It is
  also unwise to run quotacheck on a live filesystem as actual usage may  
change  during
  the  scan.   To  prevent  this,  quotacheck  tries to remount the filesystem 
  before starting the scan.  After the scan is done it  remounts  the  
filesystem  read-
  write.  You  can disable this with option -m.  You can also make quotacheck 
ignore the
  failure to remount the filesystem read-only with option -M."

Accoridng to this the only consequence of parallel running of
'quotacheck' is a somewhat inaccurate accounting of quotas.

> I think the best idea to improve the performance in case you
> did a repair is to integrate the quotacheck code into repair.

Probably this should be 'xfs_check' more than 'xfs_repair'...

[ ... ]

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