OpenZFS 6404 - zvol_swap_006_pos can occasionally fail due to swaplen…

[gmelikov]

… being < 16

Authored by: Matthew Ahrens mahrens@delphix.com
Reviewed by: George Wilson george.wilson@delphix.com
Reviewed by: John Kennedy john.kennedy@delphix.com
Reviewed by: Will Andrews will@freebsd.org
Approved by: Dan McDonald danmcd@omniti.com
Ported-by: George Melikov mail@gmelikov.ru

OpenZFS-issue: https://www.illumos.org/issues/6404
OpenZFS-commit: openzfs/openzfs@24e268f

[mention-bot]

@gmelikov, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf and @ikozhukhov to be potential reviewers.

[gmelikov]

I modified zfs to $ZFS and occasionally recreated most of openzfs/openzfs@258c9c7 . I'll port rest of it after this PR merge.

[behlendorf]

So Illumos 7290 openzfs/openzfs@1d32ba6 is the big change to be aware. OpenZFS decided to change the scheme they're using to locate the binaries to run and updated all of their test cases for the following reasons:

1. It doesn't constrain the set of allowable commands. New tests can always introduce a utility directly, bypassing the current mechanism.
2. It leads to errors where $COMMAND is used, but not defined.
3. A variable referring to a command can be overridden (think export FILE=/tmp/foo)

We're going to need to decide if we're going to pick up this patch and adopt the PATH method. I can't remember any of the concerns above being major pain points for us and it will be fair bit of work to port. But if we don't pull it in all of our test cases will diverge from the OpenZFS versions making it difficult to share tests.

[gmelikov]

My opinion is to make ZoL code as seamless with OpenZFS as we can. I'm ready to work on it.

[behlendorf]

@gmelikov reluctantly I concur. We can't be running such different versions of the test suite. We're going to need to pull it in. We'll want to focus on pulling in the changes made to OpenZFS prior to this commit first to minimize conflicts and then tackle this one.

[ikozhukhov]

hi Brain, i did some update on DilOS for more universal tools/env to use with zfs tests, but with latest updates on OpenZFS tree - they killed my env - i mean: i can’t use my updates now after merges to my separate tree and need time for restore it. my idea was - replace tools PATH by env var like: export SUDO=/usr/bin/sudo or export SUDO=/usr/local/bin/sudo - related to smartos env with DilOS i have GNU coreutils tools in primary location - at /usr/bin and for ACL tests i’m using tools like chown, chmod, etc - from /system/bin and it was more easy to me - replace PATH for some tools by env vars in shell script where i start zfs tests by Jenkins job. if you are interest - i can provide more details. i think - if we are using zf code on different platforms - will be better to move to use more universal tools and provide solution how to replace tools without tests modifications. i have added OpenZFS maillist to this thread because this problem now visible on ZoL and try to discuss solutions - will be better for adoptation of zfs tests to another platforms. first proposal: move/update zfs tests to use BASH instead of KSH - and yes, it will be big deal, but it will be more universal because more platforms have BASH , but need install KSH as additional shell. I have tested/updated tests for GNU TOOLS: - dd - file - find/grep/sed - and some others if we can find some agreements - we can start to work together with others, wo are interested in run zfs tests on another platfrom. if you are interested in details in DilOS env - let me know. i have no published new ISO and can provide latest snapshot by request. i have more upades with transition to use more flexible build env for ports of userland apps from Debian upstream, but this work still in progress. best regards, -Igor

…

On Feb 15, 2017, at 1:25 AM, Brian Behlendorf ***@***.***> wrote: So Illumos 7290 <https://www.illumos.org/issues/7290> ***@***.*** <openzfs/openzfs@1d32ba6> is the big change to be aware. OpenZFS decided to change the scheme they're using to locate the binaries to run and updated all of their test cases for the following reasons: It doesn't constrain the set of allowable commands. New tests can always introduce a utility directly, bypassing the current mechanism. It leads to errors where $COMMAND is used, but not defined. A variable referring to a command can be overridden (think export FILE=/tmp/foo) We're going to need to decide if we're going to pick up this patch and adopt the PATH method. I can't remember any of the concerns above being major pain points for us and it will be fair bit of work to port. But if we don't pull it in all of our test cases will diverge from the OpenZFS versions making it difficult to share tests. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5792 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5Gk-nOViwpPfasGW547zt00a2HBxA_ks5rcinSgaJpZM4MA4gP>.