On Tue, Feb 09, 2016 at 08:49:59PM -0500, Theodore Ts'o wrote: > The generic/027 test creates a large number of 1k files until the file > creation fails. On other file systems there will be a large number > zero length files because the block allocation has failed, but there > are still inodes available, and so the file creation loop runs until > the file system runs out of inodes. > > With tmpfs, we can limit the size of the file system, which limits the > block allocation, but there is no limit to the number of inodes that > can be created until kmalloc() fails --- or the OOM killer kills the > test. So this causes this test to run for a long, long time, and in > some cases the test or the test runner will get OOM killed instead. > We have other ENOSPC tests, so given that tmpfs is just so different > from all other file systems, it's simpler just to disable this test > for tmpfs than to try to make it work. This sounds like a bug in tmpfs and a potential user level DOS vector, too. Hence I dont think not running the test is the right thing to do here - tmpfs should be handling this gracefully by applying sane resource limits. 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
