additional reason move on from illumos KSH93.

I  have found issue with zfs tests 'zvol_swap' whare we try to read 2G volsize 
in bytes.

try to do simple test:

#!/bin/ksh -p
typeset -i var=2147483648
echo $var

and i can see:
# ksh93 v.ksh
-2147483648

it is incorrect - it should not to be less 0

best regards,
-Igor

> On Jun 24, 2018, at 10:20 PM, Igor Kozhukhov <[email protected]> wrote:
> 
> Hello All,
> 
> I’d like to start thread about zfs tests.
> 
> We have ideas for: to use zfs tests on DilOS and Debian based platform.
> 
> Debian - it is not just Linux - it is thechnology.
> 
> They can build varios of architectures - such as: Intel, MIPS, ARM, SPARC, 
> etc - on one build env.
> also, they can use Lnux and FreeBSD kernels with the same userland code base 
> with rebuilds on corresponded platform, etc.
> 
> Debian is providing interest idea for splitting of packages to: with bins - 
> platform depend and need rebuild on another platform/archivecture;
> text modules - for all platform/architectures - what can be reused as is 
> without rebuilds.
> 
> With these ideas on DilOS - we can reuse a big list of package with Perl, 
> Python, Ruby, NodeJS, Java, JS, etc - just download and upload to DilOS repo.
> But Debian based platfroms are use it a long time.
> 
> I’d like propose to split zfs tests to 2 parts:
> 1 - zfs hellper binaries - what can be built on platform like Linux, FreeBSD, 
> Linux, OSX - and used for zfs tests
> 2 - scripting part - can be used as is on all platforms.
> 
> about srcipts.
> current zfs tests based on KSH and it is outdated on illumos.
> I’d like propose to move on to more portable/usable scrupts based on BASH or 
> ZSH.
> 
> we can add ability to use based shell by additional environment variable and 
> use screnps with extensions like:
> export SHELL_EXEC=ksh
> ${SHELL_EXEC} <zfs test script>.${SHELL_EXEC}
> 
> and for transition period to another shell - we can still to use KSH and 
> working on another implementaions.
> 
> additional problems with tests framework - some executions are failed if 
> primary system shell is not as /bin/ksh
> 
> on DilOS platform we are using DASH as primary sysytem shell - /bin/sh = 
> /usr/bin/dash
> 
> based on logs we can see FAILED tests where we do executions with SU and they 
> are failed - it related to tests design and this issue can be fixed with idea 
> to use ${SHELL_EXEC} too.
> 
> Next problem: it is SUDO problem.
> current idea to use PATH to temporary directory with links to tools - failed, 
> if /etc/sudoers contain full security set with definitions:
> Defaults      env_reset
> Defaults      
> secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
> 
> yes - they ara changes are recommended with securoty needs and on DilOS we 
> are using Debian proposed configs with security needs.
> 
> for zfs tests - we need a hack local /etc/sudoers file and disable these 
> optinos - they are not described in README file because probably others 
> platforms are using another /etc/sudoers files.
> with these security options we can’t use PATH with sudo -E.
> 
> for reduce this issue with hacks of local /etc/sudoers file i’d like propose 
> try to change logic with tools: probably will be much more better to use 
> 'alias zpool=/sbin/zpool' - and use 'zpool' with correct pach where we need 
> it ?
> 
> it will be applicable to others platforms(Linux, FreeBSD, OSX, etc) too - 
> where we can remap some tools to another locations, becuase only illumos 
> based platforms are using /usr/gnu/bin, etc.
> 
> next proposal: to go to use universal tools for zfs tests - not illumos 
> specific.
> for some tests - like ACL - we need specific tools based on platform - and 
> every platform can remap and use own tools, but for some cases will be better 
> to use DF, FILE, DD, etc - what are using on all platforms.
> 
> Also - will be better to provide ability to define a platform where we run 
> zfs tests - and use ${ztest_platform} variable where we need for 
> enable/disable platform specific tests.
> 
> Also, tests are failed with 4k drives with UFS (newfs) becasue:
> root@con6-vm-64:~# newfs /dev/dsk/c0t600144F07ADEAD1800005B2E7C150001d0s0
> newfs: construct a new file system 
> /dev/rdsk/c0t600144F07ADEAD1800005B2E7C150001d0s0: (y/n)? y
> The device sector size 4096 is not supported by ufs!
> 
> Have to reduce dependencies to newfs and probably change to use 'zfs' type.
> or - identify tests drives - are they 512b or 4k - and change some tests 
> logic.
> 
> What do you think about changes in zfs design to me used on others platforms ?
> 
> best regards,
> -Igor
> 

------------------------------------------
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/T42f8147492666f65-M1f7a11340219534c5310de22
Delivery options: https://openzfs.topicbox.com/groups

Reply via email to