On Sun, Feb 12, 2012 at 10:01:07PM +0100, Arkadiusz Miśkiewicz wrote: > > Hi, > > 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). How long does a repair vs quotacheck of that same filesystem take? repair has to iterate the inodes 2-3 times, so if that is faster than quotacheck, then that is really important to know.... > 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) ? quotacheck makes the assumption that it is run on an otherwise idle filesystem that nobody is accessing. Well, what it requires is that nobody is modifying it. What we could do is bring the filesystem up in a frozen state so that read-only access could be made but modifications are blocked until the quotacheck is completed. Also, quotacheck uses the bulkstat code to iterate all the inodes quickly. Improvements in bulkstat speed will translate directly into faster quotachecks. quotacheck could probably drive bulkstat in a parallel manner to do the quotacheck faster, but that assumes that the underlying storage is not already seek bound. What is the utilisation of the underlying storage and CPU while quotacheck is running? Otherwise, bulkstat inode prefetching could be improved like xfs_repair was to look at inode chunk density and change IO patterns and to slice and dice large IO buffers into smaller inode buffers. We can actually do that efficiently now that we don't use the page cache for metadata caching. If repair is iterating inodes faster than bulkstat, then this optimisation will be the reason and having that data point is very important.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
