>> 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
the scan. To prevent this, quotacheck tries to remount the filesystem
before starting the scan. After the scan is done it remounts the
write. You can disable this with option -m. You can also make quotacheck
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'...
[ ... ]