1

I wanted to validate/test/benchmark set of features I have added to the ext4 kernel_tree/fs.

I came across Spruce Linux file system driver verification. Especially for filesystem.

The project is hosted @https://code.google.com/p/spruce/wiki/GettingStarted. and this is for x86.

I work on arm target, and I have few questions before starting off.

  1. Has anybody worked on Spruce earlier.

  2. how to use Spruce project for ARM, Do we need to port for ARM?

  3. Is cross compilation straight forward or any changes need to be done.

I have gone through this paper: http://syrcose.ispras.ru/2012/files/submissions/25_syrcose2012_submission_21.pdf

there is no information on ARM and its support.

Please someone explain/help who has any work experience/knowledge on Spruce project.

kzs
  • 1,793
  • 3
  • 24
  • 44

2 Answers2

2

  1. Spruce was intended to work as follows. It provides a set of tests that make the kernel module for a given file system execute as many paths in the code as possible. It allows to use some external analyzers (such as the tools from KEDR framework) to detect different kinds of errors: memory leaks, etc.

    All that was primarily intended for x86.

    While it might be possible to port the tests themselves to ARM, one will need to choose the analyzers that work on that platform too. KEDR tools are currently for x86 only but one may try Kmemleak, Fault injection facilities and other tools on ARM instead.

  2. Spruce seems to be a work in progress still. I see, you opened a ticket concerning ARM support in their issue tracker, I think, it is the right thing to do.

  3. I would also suggest to take a look at Phoronix Test Suite. It is currently widely used for testing and benchmarking, including the analysis of file system kernel modules. See this article for example. It seems to work on ARM although I haven't tried it there myself.

Eugene
  • 5,977
  • 2
  • 29
  • 46
  • As I see the getting started document, it requires dependency libs. which seems uncertain for ARM. As you have mentioned, you have not used it. Do you know someone who is using for ARM.? so that it will help me get idea about getting dependency libs. – kzs Nov 18 '13 at 06:47
  • I have posted the same question in phoronix forum too.! http://phoronix.com/forums/showthread.php?88585-How-to-use-phoronix-test-suite-for-ARM&p=373199#post373199 – kzs Nov 18 '13 at 07:04
  • @kzs: No, I currently do not know if anyone tried it on ARM. The project was started by my former colleagues and they used KEDR tools that I maintain, that's why I know a bit about the project. – Eugene Nov 18 '13 at 07:15
  • @kzs: The original idea of Spruce was to collect existing tests for a number of file systems and to add more tests only where it is required to improve code coverage. But they seem to try to implement all the tests themselves instead. Well, it is their decision. – Eugene Nov 18 '13 at 07:19
  • @kzs: While waiting for reply on Phoronix forums, you may try to build some benchmarks internally used by Phoronix to test file systems: dbench, ffsb, FS-Mark, AIO-Stress, IOzone. They are available as standalone tools. There is a variety of ARM-based systems, so this way you can see if these tools can be built and run for yours. – Eugene Nov 18 '13 at 07:23
1

The best tool for testing/validating a file system is xfstests. I have written tools to make it easy to validate xfstests for ext4. See: http://thunk.org/gce-xfstests for more details.

There is also an alpha-test level support for using this on ARM directly: http://thread.gmane.org/gmane.comp.file-systems.ext4/53649/focus=53659

This has been used successfully to test ext4 on an Android device, although to be honest, most of the time what I do is to bludgeon an Android kernel until it will build on x86, and then use kvm-xfstests gce-xfstests, since it's much more convenient. In particular with gce-xfstests, I can just do a "fire and forget", and then when the test completes I get a test report in my e-mail. Where as with the Android arm xfstests tarball, the automation isn't done yet, so you have to manually set up an external USB-attached USB device, hook it up via some kind of USB C hub, or if you are going to use an OTG usb adapter, you need to make sure the Android device can receive power while it is also driving the OTG usb port --- and you have to manually set up the chroot. Unless the BSP kernel has been badly abused so you can't figure out how to make it build on x86 (getting the MSM kernel to work on x86 wasn't easy) testing on gce-xfstests may be much simpler at the end of the day.

Theodore Ts'o
  • 556
  • 2
  • 8