On 9/28/16 10:56 PM, Theodore Ts'o wrote: >> xfstests is not designed for validating system call API compliance - >> > it's for exercising /filesystem implementations/. xfstests assumes >> > the syscall API is valid and working, and tries to break the >> > underlying storage implementation. To play devil's advocate, I think there are a few tests that find problems pretty high up the callchain, possibly in the vfs or syscall layer... >> As such, your example really >> > isn't something you should be using xfstests for - it doesn't test >> > anything like what is needed to verify that the "VFS emulation" is >> > valid and complete and working exactly as documented in the linux >> > man pages. > Who says there isn't an underlying file system implementation which we > want to test? In fact we *are* using the right tool for the job. > (I'm quite aware of the other testing tools that might be available > including LTP and others, such as the LSB tests.) So you want to test a filesystem without being able to mount/unmount... Is this because you want to test how things behave in a restricted privs environment of some sort, or because the system under test has absolutely no way to mount & unmount a filesystem for any user? So many of the current tests expect to check fs consistency, check data integrity after a shutdown or remount, test recovery, examine on-disk structures of a quiesced, consistent block device, test mount options, etc, I fear that there will be so many special snowflakes scattered around individual tests that this might be very hard to maintain. -Eric -- 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
