On Tuesday 14 of February 2012, Dave Chinner wrote: > On Mon, Feb 13, 2012 at 07:09:50PM +0100, Arkadiusz Miśkiewicz wrote: > > On Monday 13 of February 2012, Christoph Hellwig wrote: > > > 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). > > > > > > > > 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) ? > > > > > > I think the best idea to improve the performance in case you did a > > > repair is to integrate the quotacheck code into repair. It's fairly > > > simple given that quotacheck simply walks all inodes and adds their > > > space usage to the correct user/group/project, and given that repair > > > already walks all inodes, and checks their block maps it does most of > > > that work already. > > > > That would be interesting and probably make > > > > > The only downside would be that the memory usage > > > of repair increases a bit by keeping the dquots in memoryb, but even > > > for your 130000 dquot setup that would add about 100 bytes * 130000 > > > please a bit of in-memory metadata (less than 20MB total) of memory > > > usage, so it probably is a good tradeoff. > > > > > > > > > In what cases do you regularly run quotacheck when you did not do > > > a repair first? > > > > I don't initiate quotacheck manually. AFAIK internal xfs quotacheck > > happens in two cases here: > > 1) repair->mount > > 2) filesystem has quotacheck done properly some time ago -> umount -> > > mount- > > > > >oops/reset/something like that happens while mounting -> new mount > > So you'd like both quotacheck to be sped up and repair > to do it as well? ;) Well, 1) is happening much more often than 2) :-) -- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
