----- 原始邮件 ----- > 发件人: "Dave Chinner" <david@xxxxxxxxxxxxx> > 收件人: "Zirong Lang" <zlang@xxxxxxxxxx> > 抄送: fstests@xxxxxxxxxxxxxxx, eguan@xxxxxxxxxx > 发送时间: 星期一, 2015年 8 月 17日 下午 1:06:12 > 主题: Re: [PATCH] generic/084: check inotify limit before tail many files > > On Sun, Aug 16, 2015 at 09:05:19PM -0400, Zirong Lang wrote: > > Hi Dave, > > > > Thanks for your reply. > > > > ----- 原始邮件 ----- > > > 发件人: "Dave Chinner" <david@xxxxxxxxxxxxx> > > > 收件人: "Zorro Lang" <zlang@xxxxxxxxxx> > > > 抄送: fstests@xxxxxxxxxxxxxxx, eguan@xxxxxxxxxx > > > 发送时间: 星期一, 2015年 8 月 17日 上午 8:03:36 > > > 主题: Re: [PATCH] generic/084: check inotify limit before tail many files > > > > > > On Fri, Aug 14, 2015 at 12:16:32AM +0800, Zorro Lang wrote: > > > > generic/084 try to run 'tail' command, tail will use > > > > inotify, and there're some limit about inotify. I think > > > > the most important is fs.inotify.max_user_instances, then > > > > fs.inotify.max_user_watches is importand too. > > > > > > > > When I test on a machine with 154 cpu cores, this case > > > > run failed, and hit many warning likes: > > > > > > > > tail: inotify cannot be used, reverting to polling: Too many > > > > open files > > > > > > > > Because the fs.inotify.max_user_instances is 128, so if > > > > we try to tail 154 files, it will be failed. > > > > > > We use 'tail' all over the place in xfstests, so why is only > > > generic/084 affected? > > > > Because generic/084 use try to create $nr_cpu tail processes: > > for i in `seq 1 $nr_cpu`; do > > ... > > tail -f $testfile & > > ... > > done > > > > And nr_cpu=`$here/src/feature -o`. > > > > Generally fs.inotify.max_user_instances is 128, when a machine > > have more than(or nearly the same) this number, this test will > > failed. > > This information should have been in the patch description - it's > concurrently run tail commands that are the problem, not a single > execution of tail... > > > Maybe other cases don't try to create so many tail processes, so > > they passed. > > Exactly. The answer is obvious when you explain it fully :) > > So, we have other tests that use hundreds of open unlinked files and > they don't have this problem. That means the issue is how > generic/084 is creating the unlinked files, not an issue with > inotify config. > > Go look at src/multi_open_unlink.c and tests/xfs/1[28]1, and then > rewrite generic/084 to use multi_open_unlink to create and hold > open unlinked files for a specified amount of time. You're Great! This's a good idea to fix this problem. Thanks very much. I have sent the V3 patch, and tested on an old kernel to sure the bug still can be reproduced after I changed. Thanks, Zorro Lang > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
