On Thu, Jul 31, 2014 at 07:45:37AM -0400, Brian Foster wrote: > On Thu, Jul 31, 2014 at 11:32:38AM +0800, Eryu Guan wrote: > > On Thu, Jul 24, 2014 at 09:06:47AM -0400, Brian Foster wrote: > > > On Thu, Jul 24, 2014 at 06:36:58PM +0800, Eryu Guan wrote: > > > > On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote: > > > > > On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote: [snip] > > > > Hi Brian, > > > > > > > > Thanks for the review, and sorry for the late response.. > > > > > > > > > You could probably even make this smaller and make the test quicker. > > > > > E.g., I can create an fs down to 20M or so without any problems. Also, > > > > > setting imaxpct=0 might be a good idea so you don't hit that artificial > > > > > limit. > > > > > > > > Yes, a smaller fs could make the test much more quicker. I tested with > > > > 16M fs and the test time reduced from 70s to ~10s on my test host. > > > > > > > > > > That sounds great. > > > > > > > But setting imaxpct=0 could increase the total available inode number > > > > which could make test run longer. So I tend to use default mkfs > > > > options here. > > > > > > > > > > True... I don't really want to make a big deal out of imaxpct. I think > > > the consensus now is that it's a useless relic and will probably be > > > removed. That does mean this test will eventually use the full fs space > > > by default and we should make sure it runs in a reasonable amount of > > > time. FWIW, it seems to in my tests, running in under 2 minutes on a > > > single spindle. > > > > > > The other issue is that if I set imaxpct=1 in my mkfs options, the test > > > passes. Should it? Is it actually testing what it should be in that > > > scenario? ;) Note that when imaxpct is set, the 'df -i' information will > > > be based on the cap that imaxpct sets. E.g., it will show 100% usage > > > even though we've only used a few MB for inodes. > > > > Yes, I can pass the test too with imaxpct=1 set. But I'm not really > > sure about imaxpct impact on the test result. > > > > Eric, do you have any suggestions here? Because I saw you send out the > > kernel patch to fix this problem :) > > > > (I think Eric might be away.) > > To be clear, I'm just suggesting we verify whether the test is as > focused as possible. Put another way, have we verified whether this test > detects the problem with this potential configuration? E.g., run a > kernel without Eric's growfs fix, run the test and verify it fails. > Repeat with '-i imaxpct=1' in MKFS_OPTIONS and verify the test still > fails. If it does, then it's probably fine. If it passes, that's a hole > in the test case we should close up. > > Brian Thanks Brian, I'll look into it and try to work it out. (Note that with my v2 patch, the maxpct number in question is 5 instead of 1) Thanks, Eryu _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
