>> 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
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'...
[ ... ]
|