quoted

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.

quoted

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  filesys-
  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 read-only
  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'...

[ ... ]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs