Hi Folks, We have a user report about skip quota check on first mount/boot several monthes ago, the original discussion thread can be found at: http://oss.sgi.com/archives/xfs/2013-06/msg00170.html. As per Dave's suggestion, it would be possible to perform quota check in parallel, this patch series is just trying to follow up that idea. Sorry for the too long day as I have to spent most of time dealing with personl things in the last few monthes, I was afraid I can not quickly follow up the review procedure. Now the nightmare is over, it's time to revive this task. Also, my previous test results on my laptop and a poor desktop can not convience me that performs parallism quota check can really get benefits compare to the current single thread as both machines are shipped with slow disks, I even observed a little performance regression with millions of small files(e.g, 100 bytes) as quota check is IO bound, additionaly, it could affected by the seek time differences. Now with a Mackbook Air I bought recently, it can show significant difference. tests: - create files via fs_mark (empty file/100 byte small file) fs_mark -k -S 0 -n 100000 -D 100 -N 1000 -d /xfs -t [10|20|30|50] -s [0|100] - mount -ouquota,pquota /dev/sdaX /storage - run each test for 5 times and figure out the average value test environment: - laptop: i5-3320M CPU 4 cores, 8G ram, normal SATA disk results of empty files via time: - # of file(million) default patched 1 real 1m12.0661s real 1m8.328s user 0m0.000s user 0m0.000s sys 0m43.692s sys 0m0.048s 2 real 1m43.907s real 1m16.221s user 0m0.004s user 0m0.000s sys 1m32.968s sys 0m0.065s 3 real 2m36.632s real 1m48.011s user 0m0.000s user 0m0.002s sys 2m23.501s sys 0m0.094s 5 real 4m20.266s real 3m0.145s user 0m0.000s user 0m0.002s sys 3m56.264s sys 0m0.092s results of 100 bytes files via time: - # of file(million) default patched 1 real 1m34.492 real 1m51.268s user 0m0.008s user 0m0.008.s sys 0m54.432s sys 0m0.236s 3 real 3m26.687s real 3m16.152s user 0m0.000s user 0m0.000s sys 2m23.144s sys 0m0.088s So with emtpy files, the performance still looks good but with small files, this change introduced a little regression on very slow storage. I guess this is caused by disk seek as data blocks allocated and spreads over the disk. In order to get some more reasonable results, I ask a friend helping run this test on a server which were shown as following. test environment - 16core, 25G ram, normal SATA disk, but the XFS is resides on a loop dev. result of 100 bytes files via time: - # of file(million) default patched 1 real 0m19.015s real 0m16.238s user 0m0.004s user 0m0.002s sys 0m4.358s sys 0m0.030s 2 real 0m34.106s real 0m28.300s user 0m0.012s user 0m0.002s sys 0m8.820s sys 0m0.035s 3 real 0m53.716s real 46.390s user 0m0.002s user 0m0.005s sys 0m13.396s sys 0m0.023s 5 real 2m26.361s real 2m17.415s user 0m0.004s user 0m0.004s sys 0m22.188s sys 0m0.023s In this case, there is no regression although there is no noticeable improvements. :( test environment - Macbook Air i7-4650U with SSD, 8G ram - # of file(million) default patched 1 real 0m6.367s real 0m1.972s user 0m0.008s user 0m0.000s sys 0m2.614s sys 0m0.008s 2 real 0m3.772s real 0m15.221s user 0m0.000s user 0m0.000s sys 0m0.007s sys 0m6.269s 5 real 0m36.036s real 0m8.902s user 0m0.000s user 0m0.002s sys 0m14.025s sys 0m0.006s Btw, The current implementation has a defeat considering the duplicated code at [patch 0/4] xfs: implement parallism quota check at mount time. Maybe it's better to introduce a new function xfs_bulkstat_ag() which can be used to bulkstat inodes per ag, hence it could shared at above patch while adjusting dquota usage per ag, i.e, xfs_qm_dqusage_adjust_perag(). As usual, critism and comments are both welcome! Thanks, -Jeff _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
