-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zfs commands return EINVAL #46
Comments
I want to add some additional bits about zpool behavior. I have zfs and pulled yesterday from github: [seriv@gauntlet zfs]$ git log | head commit 8c3ab23f4be92a4e55f07f8c1bb467b851ed3e54 Author: Brian Behlendorf Date: Fri Nov 5 12:29:58 2010 -0700 Add lustre zpios-test workload ... [seriv@gauntlet zfs]$ cd ../spl [seriv@gauntlet spl]$ git log | head commit 1e18307b6109a5b2491cd519a312b870b2e7522b Author: Brian Behlendorf Date: Mon Nov 8 21:32:47 2010 -0800 Fix incorrect krw_type_t type ... I have destroyed/exported all zpools I have. [seriv@gauntlet ~]$ sudo zpool list no pools available [seriv@gauntlet ~]$ sudo dd if=/dev/zero of=/dev/sda3 bs=8192 count=8192 8192+0 records in 8192+0 records out 67108864 bytes (67 MB) copied, 1.25259 s, 53.6 MB/s Then created new zpool and have the same problems: [seriv@gauntlet ~]$ sudo zpool create newtest /dev/sda3 [seriv@gauntlet ~]$ sudo zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT - - - - - - - - [seriv@gauntlet ~]$ sudo zpool status pool: newtest state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM newtest ONLINE 0 0 0 sda3 ONLINE 0 0 0 errors: No known data errors And strace zpool status gave me the same ioctl EINVAL. |
Interesting, what distribution are you using? Also is it 32-bit or 64-bit? I haven't seen anything like this in my testing, but I could image it might come up if say your using a 32-bit user space and 64-bit kernel and the ioctl numbers aren't mapped the same. |
It's Fedora 14 64-bit, I think I have some 32-bit libs and applications like acroread, but most are 64-bit: [seriv@gauntlet ~]$ cat /etc/redhat-release Fedora release 14 (Laughlin) [seriv@gauntlet ~]$ uname -a Linux gauntlet.localdomain 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux [seriv@gauntlet ~]$ file `which zpool` /usr/sbin/zpool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped [seriv@gauntlet ~]$ rpm -qf `which zpool` zfs-0.5.2-1.x86_64 |
Thanks for the info, when I get a little time I'll setup FC14 in a new VM and see if I can reproduce this. Although, since this is an older bug presumably you saw this with FC13 too? |
I have not tried it on Fedora-13 because it is already upgraded to Fedora-14. But tested on Fedora-12 and have the same problems. One additional thing was with 'sudo make check'. It reported problem: [seriv@parkheights zfs]$ sudo make check Making check in etc make[1]: Entering directory `/home/seriv/work/zfs/etc' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/seriv/work/zfs/etc' Making check in man make[1]: Entering directory `/home/seriv/work/zfs/man' Making check in man8 make[2]: Entering directory `/home/seriv/work/zfs/man/man8' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/seriv/work/zfs/man/man8' make[2]: Entering directory `/home/seriv/work/zfs/man' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/home/seriv/work/zfs/man' make[1]: Leaving directory `/home/seriv/work/zfs/man' Making check in scripts make[1]: Entering directory `/home/seriv/work/zfs/scripts' Making check in zpool-config make[2]: Entering directory `/home/seriv/work/zfs/scripts/zpool-config' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/seriv/work/zfs/scripts/zpool-config' Making check in zpool-layout make[2]: Entering directory `/home/seriv/work/zfs/scripts/zpool-layout' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/seriv/work/zfs/scripts/zpool-layout' Making check in zpios-test make[2]: Entering directory `/home/seriv/work/zfs/scripts/zpios-test' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/seriv/work/zfs/scripts/zpios-test' Making check in zpios-profile make[2]: Entering directory `/home/seriv/work/zfs/scripts/zpios-profile' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/seriv/work/zfs/scripts/zpios-profile' make[2]: Entering directory `/home/seriv/work/zfs/scripts' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/home/seriv/work/zfs/scripts' ==================================== ZTEST ==================================== 5 vdevs, 7 datasets, 23 threads, 300 seconds... props: autoreplace: 1 Setting dataset ztest/ds_3 to sync always Setting dataset ztest/ds_4 to sync always Setting dataset ztest/temp_0 to sync always Setting dataset ztest/ds_5 to sync always Setting dataset ztest/temp_19 to sync always Setting dataset ztest/temp_10 to sync always Pass 1, SIGKILL, 0 ENOSPC, 6.5% of 238M used, 8% done, 4m37s to go Pass 2, SIGKILL, 0 ENOSPC, 6.2% of 238M used, 9% done, 4m32s to go Setting dataset ztest/temp_19 to sync always Setting dataset ztest/temp_7 to sync always Setting dataset ztest/temp_2 to sync always Pass 3, Complete, 0 ENOSPC, 5.9% of 508M used, 41% done, 2m57s to go Pass 4, Complete, 0 ENOSPC, 4.4% of 814M used, 85% done, 44s to go Pass 5, SIGKILL, 0 ENOSPC, 4.4% of 814M used, 87% done, 38s to go Pass 6, Complete, 0 ENOSPC, 4.4% of 850M used, 100% done, 0s to go 3 killed, 3 completed, 50% kill rate =================================== ZCONFIG =================================== Skipping test 10 which requires the scsi_debug module and the /usr/bin/lsscsi utility 1 persistent zpool.cache Pass 2 scan disks for pools to import Pass 3 zpool import/export device Pass 4 zpool insmod/rmmod device Pass 5 zvol+ext3 volume Pass 6 zvol+ext2 snapshot cannot create snapshot 'tank/fish@pristine': out of space Fail (8) [seriv@parkheights zfs]$ df -h | grep tank/fish /dev/tank/fish1 388M 2.3M 365M 1% /tmp/fish1 [seriv@parkheights zfs]$ sudo cmd/zfs/zfs list NAME USED AVAIL REFER MOUNTPOINT tank 413M 52.8M 31.4K /tank tank/fish 413M 452M 13.9M - [seriv@parkheights zfs]$ sudo cmd/zfs/zfs list -t snapshot no datasets available But this problem was not "stable", when I have run "sudo strace -f cmd/zfs/zfs snapshot tank/fish@pristine", it worked without reproducing the problem. And zpool list still can't get zpool names, [seriv@parkheights zfs]$ sudo dd if=/dev/zero bs=8192 of=/dev/sdd3 count=8192 8192+0 records in 8192+0 records out 67108864 bytes (67 MB) copied, 1.00835 s, 66.6 MB/s [seriv@parkheights zfs]$ sudo zpool list no pools available [seriv@parkheights zfs]$ sudo zpool create test /dev/sdd3 [seriv@parkheights zfs]$ sudo zpool status pool: test state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 sdd3 ONLINE 0 0 0 errors: No known data errors [seriv@parkheights zfs]$ sudo zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT - - - - - - - - [seriv@parkheights zfs]$ sudo zfs create test/mytest cannot create 'test/mytest': no such parent 'test' [seriv@parkheights zfs]$ uname -a Linux parkheights.dyndns.org 2.6.32.23-170.fc12.x86_64 #1 SMP Mon Sep 27 17:23:59 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux [seriv@parkheights zfs]$ cat /etc/redhat-release Fedora release 12 (Constantine) |
It seems to work fine for me on FC12 and FC14, there must be something slightly different about your setup. OK, let's focus on the 'zpool list' problem which your originally reported. The other issues are likely transient false positives in the test cases. Your original bug report shows the that 'zpool list' command was failing because ioctl 0x5a28 was failing with EINVAL. Can you please verify that it's now failing on 0x5a0a, the numbering was changed slightly in newer releases. This is ZFS_IOC_POOL_GET_PROPS which is what 'zpool list' calls to populate that table. It should look something like this in the strace. ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a2a, 0x7fff8dc15a60) = -1 EINVAL (Invalid argument) write(1, "- - - - -"..., 51- - - - - - - - ) = 51 If that's true then the issue is somewhere in the zfs_ioc_pool_get_props() call path. Unfortunately, EINVAL is a fairly common error code which is returned in multiple locations, we need to determine exactly which check is failing and why. |
Strange, on Fedora-14 I have [seriv@gauntlet zfs]$ sudo strace zpool list 2>&1 | grep -C5 EINVAL open("/dev/zfs", O_RDWR) = 3 open("/proc/mounts", O_RDONLY) = 4 open("/etc/dfs/sharetab", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(3, 0x5a04, 0x7fff7e55ed80) = 0 ioctl(3, 0x5a05, 0x7fff7e55ed40) = 0 ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc0b57ee000 ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7e55dd00) = -1 EINVAL (Invalid argument) close(3) = 0 close(4) = 0 write(1, "NAME SIZE ALLOC FREE CAP"..., 108NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT - - - - - - - - ) = 108 [seriv@gauntlet zfs]$ rpm -qV zfs [seriv@gauntlet zfs]$ which zpool /usr/sbin/zpool [seriv@gauntlet zfs]$ rpm -qf `which zpool` zfs-0.5.2-1.x86_64 [seriv@gauntlet zfs]$ rpm -qV zfs-0.5.2-1.x86_64 Zfs there is fresh git clone of commit 8c3ab23. And on Fedora-12: [seriv@parkheights ~]$ sudo strace zpool list 2>&1 | grep -C5 EINVAL open("/dev/zfs", O_RDWR) = 3 open("/proc/mounts", O_RDONLY) = 4 open("/etc/dfs/sharetab", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(3, 0x5a04, 0x7fff7d0cc6c0) = 0 ioctl(3, 0x5a05, 0x7fff7d0cc680) = 0 ioctl(3, 0x5a28, 0x7fff7d0cb640) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb640) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb640) = -1 EINVAL (Invalid argument) fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb895918000 ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) ioctl(3, 0x5a28, 0x7fff7d0cb630) = -1 EINVAL (Invalid argument) close(3) = 0 close(4) = 0 write(1, "NAME SIZE ALLOC FREE CAP"..., 108NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT - - - - - - - - ) = 108 and there zfs is clone of commit b04cffc |
Are you absolutely sure your not accidentally using an old version of zpool which was installed on your system? That would cause exactly this issue and explain why your seeing this issue and I'm not. For the updated code ZFS_IOC_OBJ_TO_PATH is 0x5a28 and ZFS_IOC_POOL_GET_PROPS is 0x5a2a (include/sys/zfs/zfs.h:719), I would absolutely expect it to return EINVAL is your using an old version of zpool. That would also explain why things like 'zpool status' still work, those ioctl number did not shift. I've tried hard to ensure these numbers don't change but it couldn't be helped. |
You are right. when I run zpool in zfs checkout directory, I do not have the problem, and I think the problem may be closed. [seriv@gauntlet zfs]$ sudo ./cmd/zpool/zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT newtest 56.5G 82.5K 56.5G 0% 1.00x ONLINE - Now I need to understand how can "rpm -qV zfs' to show nothing, "rpm -qa zfs" show version 0.5.2-1 and I have old versions of zpool in the rpm packages. |
Ahh good, I'm glad that was it. I'm closing this bug. |
# This is the 1st commit message: Merge branch 'master' of https://github.com/zfsonlinux/zfs * 'master' of https://github.com/zfsonlinux/zfs: Enable QAT support in zfs-dkms RPM # This is the commit message openzfs#2: Import 0.6.5.7-0ubuntu3 # This is the commit message openzfs#3: gbp changes # This is the commit message openzfs#4: Bump ver # This is the commit message openzfs#5: -j9 baby # This is the commit message openzfs#6: Up # This is the commit message openzfs#7: Yup # This is the commit message openzfs#8: Add new module # This is the commit message openzfs#9: Up # This is the commit message openzfs#10: Up # This is the commit message openzfs#11: Bump # This is the commit message openzfs#12: Grr # This is the commit message openzfs#13: Yay # This is the commit message openzfs#14: Yay # This is the commit message openzfs#15: Yay # This is the commit message openzfs#16: Yay # This is the commit message openzfs#17: Yay # This is the commit message openzfs#18: Yay # This is the commit message openzfs#19: yay # This is the commit message openzfs#20: yay # This is the commit message openzfs#21: yay # This is the commit message openzfs#22: Update ppa script # This is the commit message openzfs#23: Update gbp conf with br changes # This is the commit message openzfs#24: Update gbp conf with br changes # This is the commit message openzfs#25: Bump # This is the commit message openzfs#26: No pristine # This is the commit message openzfs#27: Bump # This is the commit message openzfs#28: Lol whoops # This is the commit message openzfs#29: Fix name # This is the commit message openzfs#30: Fix name # This is the commit message openzfs#31: rebase # This is the commit message openzfs#32: Bump # This is the commit message openzfs#33: Bump # This is the commit message openzfs#34: Bump # This is the commit message openzfs#35: Bump # This is the commit message openzfs#36: ntrim # This is the commit message openzfs#37: Bump # This is the commit message openzfs#38: 9 # This is the commit message openzfs#39: Bump # This is the commit message openzfs#40: Bump # This is the commit message openzfs#41: Bump # This is the commit message openzfs#42: Revert "9" This reverts commit de488f1. # This is the commit message openzfs#43: Bump # This is the commit message openzfs#44: Account for zconfig.sh being removed # This is the commit message openzfs#45: Bump # This is the commit message openzfs#46: Add artful # This is the commit message openzfs#47: Add in zed.d and zpool.d scripts # This is the commit message openzfs#48: Bump # This is the commit message openzfs#49: Bump # This is the commit message openzfs#50: Bump # This is the commit message openzfs#51: Bump # This is the commit message openzfs#52: ugh # This is the commit message openzfs#53: fix zed upgrade # This is the commit message openzfs#54: Bump # This is the commit message openzfs#55: conf file zed.d # This is the commit message #56: Bump
* fix python3 compat in zfs_clone_010 * Fix broken diff test on FreeBSD * Fix test script setup on FreeBSD * fix multipath disk detection in tests on FreeBSD * Skip MMP testfail callbacks on FreeBSD, for now * Add gpart and mdconfig commands to test sandbox * Fix delete_partitions in libtest * Skip ext2 test on FreeBSD and ufs test on Linux * Just use the ksh print built-in, it works Fixes "\n" appearing in log messages instead of newlines on FreeBSD. * Fix erroneous assertion * Fix zfs_diff_types test on FreeBSD On FreeBSD, mknod can't be used to create named pipes. Use mkfifo instead. ZoF Issue: openzfs#46 * s/\[ is_freebsd \]/is_freebsd/ in tests Calling a function in a test expression doesn't work like that. This only appeared to work on FreeBSD because `[ is_freebsd ]` is always true and `[ ! is_freebsd ]` is always false. * Use `mount -p` to check mount options on FreeBSD * Merge FreeBSD and Linux cases in some tests
This was causing failure in functional/cli_user/misc/zpool_001_neg.ksh
libzfs sendrecv/mount bug fixes
Opening as a new bug remaining issue in bug #32.
Here they are:
and
.Interesting that zpool list shows nothing while zpool status works:
The text was updated successfully, but these errors were encountered: