>> 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'... [ ... ] _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
