On Fri, Feb 16, 2018 at 10:52:20AM +0100, Jan Kara wrote: > On Fri 16-02-18 08:38:23, Xiong Zhou wrote: > > On Thu, Feb 15, 2018 at 10:23:43AM +0100, Jan Kara wrote: > > > On Thu 15-02-18 08:49:40, Xiong Zhou wrote: > > > > On Wed, Feb 14, 2018 at 12:03:31PM +0100, Jan Kara wrote: > > > > > On Mon 12-02-18 13:46:48, Xiong Zhou wrote: > > > > > > Stress test for fanotify and inotify. Exercise fanotify and > > > > > > inotify user interfaces in loop while other stress tests going > > > > > > on in the watched test directory. > > > > > > > > > > > > Watching slab object inotify_inode_mark size, report fail > > > > > > it increases too fast. This may lead to a crash if OOM killer > > > > > > invoked. > > > > > > > > > > > > kernel commit related to the fixes in v4.15-rc1: > > > > > > 0d6ec07 fsnotify: pin both inode and vfsmount mark > > > > > > > > > > > > Signed-off-by: Xiong Zhou <xzhou@xxxxxxxxxx> > > > > > > > > > > I'm sorry for chiming in so late but I was on vacation. Just one question: > > > > > Currently, all inotify and fanotify tests are part of LTP. Is there any > > > > > good reason for putting this particular test to fstests and not LTP? > > > > > > > > It's handy to test with bash and c. fstests is more convenient to do that. > > > > > > Hum, I don't understand. You can just run the executables created by LTP. > > > > Like *_files functions and run fsstress in this patch. It's doable by c, > > just with more code. > > I see thanks for explanation. That's a fair point but LTP also has support > for testcases in shell. So you could do basically what you did for fstests > in LTP as well. See e.g. how testcases/network/nfs/nfs_stress/nfs06 uses > fsstress. Thanks for the direction! Xiong > > Honza > -- > Jan Kara <jack@xxxxxxxx> > SUSE Labs, CR -- 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
