test suite for whole filesystem

[camuel]

No description provided.

[YaroslavLitvinov]

We needed test suite to test folowing cases:
case 1. Whole file system;
case 2. File system loaded via channel:
Need to be tested integrity of data loaded via channel and was saved into fs;

For case1 I suggest to use (http://www.tuxera.com/community/posix-test-suite/, "pjd fstests") that supports UFS, ZFS, ext3, XFS and the NTFS-3G file systems. That test suite has been writen in c language and can be easily ported into project.
Since Native Client doesn't support folowing syscalls: create, mkdir, unlink, rmdir, fsync; we can modify pjd tests that will skip unsupported functions during tests of our own filesystem .

For case2 any recommendations are welcome.
As for me: It can be just self-test of all files loaded from channel were added to filesystem, and at the next step were read again and performs bitwise compare for every loaded file;

[camuel]

On Sun, Sep 30, 2012 at 6:53 PM, Yaroslav Litvinov <[email protected]

wrote:

We needed test suite to test folowing cases:
case 1. Whole file system;
case 2. File system loaded via channel:
Need to be tested integrity of data loaded via channel and was saved into
fs;

For case1 I suggest to use (
http://www.tuxera.com/community/posix-test-suite/, "pjd fstests") that
supports UFS, ZFS, ext3, XFS and the NTFS-3G file systems. That test suite
has been writen in c language and can be easily ported into project.
Since Native Client doesn't support folowing syscalls: create, mkdir,
unlink, rmdir, fsync; we can modify pjd tests that will skip unsupported
functions during tests of our own filesystem .

we should support it! If we don't support it then a lot of ported program
will choke on them. Why we cannot support them?

For case2 any recommendations are welcome.
As for me: It can be just self-test of all files loaded from channel were
added to filesystem, and at the next step were read again and performs
bitwise compare for every loaded file;

what do you mean by files loaded from channels?

—
Reply to this email directly or view it on GitHubhttps://github.com/Dazo-org/zrt/issues/12#issuecomment-9015412.

[YaroslavLitvinov]

1. nacl_sdk glibc toolchain we using does not support syscalls list specified here (create, mkdir, unlink, rmdir, fsync) therefore trusted code didn't receiving any of that syscalls and not translate their into untrasted code. In terms of ZRT project it's can not be done without changing of toolchain.
2. If user application starts, it has only preloaded channels wrapped into fs mounted into "/dev" and empty filesystem in memory mounted into root "/". If user has filesystem copy on storage it can use it. ZRT gives ability to read archive via i/o channel defined in manifest and extracts it into root folder where fs in memory mounted.

In order to use second storage archive, it's should be added into manifest file, where "/tarimage.tar" full path to archive:
Channel = /tarimage.tar, /dev/tarimage, 1, 9999999, 9999999, 0, 0

[pkit]

I've found out that nacl glibc functions use weak_alias macro to alias their functions, which means that we can overwrite their implementation in zrt just by using same symbols and nothing else.
Yaroslav tested it and it seems to work.

[YaroslavLitvinov]

• The main requirement to filesystem test suite it's distinct test for every single session.
• pjd fstests not applicable for testing filesystem on top of zerovm, because it launching related tests by bash scripts, but currently we can't share filesystem state between separated launches of zerovm, most amount of tests will fail.

[pkit]

Ok, I see that it's executing fstest binary and using sh and expect to test the results.
It cannot be run in zerovm, but we can rewrite the tests as a C program.
It doesn't look too complicated.
For example:

expect 0 create ${n0} 0644
expect none stat ${n0} flags

Can be rewritten as something along the lines of:

assert_errno(creat(n0, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH), 0);
assert(stat(n0, flags));

[YaroslavLitvinov]

Currently pjd-fstests can't be launched on last zerovm version, because any zerovm channel contents can't be altered after zerovm started. That is all due to zerovm determinism;
To solve this problem in non-deterministic way and get filesystem test suite working, it's required:

• zerovm channel support for PIPEs (FIFO channels)
  or
• create "non zerovm" executable that will work as generic linux application and will act as zerovm node, and would be able to send any data into channel of zerovm node, and data will be handled properly by zerovm as data from network channel;
  It's problem should be discussed.

[YaroslavLitvinov]

pipes support now is available in zerovm, so filesystem test suite should become working, make changes if that needs.

[YaroslavLitvinov]

waiting support from zerovm, changes related to issue in commit:
03e1af6