Announcing: ZFS-fuse 0.7.0
#23 — zfs status command failure
| State | Resolved |
|---|---|
| Version: | 0.6.0 |
| Area | Functionality |
| Issue type | Bug |
| Severity | Low |
| Submitted by | (anonymous) |
| Submitted on | Jan 29, 2010 |
| Responsible | Seth Heeren |
| Target release: |
Last modified on
May 22, 2010
by
Seth Heeren
Hi there,
I have just built a backblaze box with 35 drives in it; and I am having problems displaying the status of the ZFS partition in 0.6. The array seems to be working correctly;
zpool iostat storage01
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
storage01 10.5G 47.6T 0 11 2.94K 1.23M
When I do a zpool status, I am getting the following error message:
[root@backblaze01 tvtuser]# zpool status storage01
pool: storage01
state: ONLINE
zpool: cmd/zpool/zpool_main.c:3208: status_callback: Assertion `reason == ZPOOL_STATUS_OK' failed.
Aborted
I have just built a backblaze box with 35 drives in it; and I am having problems displaying the status of the ZFS partition in 0.6. The array seems to be working correctly;
zpool iostat storage01
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
storage01 10.5G 47.6T 0 11 2.94K 1.23M
When I do a zpool status, I am getting the following error message:
[root@backblaze01 tvtuser]# zpool status storage01
pool: storage01
state: ONLINE
zpool: cmd/zpool/zpool_main.c:3208: status_callback: Assertion `reason == ZPOOL_STATUS_OK' failed.
Aborted
- Steps to reproduce:
- EDIT: to reproduce/test fix I used this script:
http://downloads.sehe.nl/zfs-fuse/dorky_issue23.sh
Beware, read the script first. Have /mnt on something that supports sparse files. Shutdown zfs-fuse before commencing the script.
Build a system with 35 drives in it [Drives sdb to sdz and sdaa to sdaj], and create a single drive partition.
mount the array using the zfs mountpoint=/dev/mountpoint drivearray
now do a zpool status drivearray - this displays the error.
dorky.sh
—
text/x-sh,
2Kb
Added by
Seth Heeren
on
Jan 29, 2010 01:59 PM
Issue state:
unconfirmed → open
Responsible manager:
(UNASSIGNED) → sgheeren
Trying it now
Is this vanilla 0.6.0? You could build from source in the 'critical' branch
# git clone http://git.zfs-fuse.net/official
# cd official/
# git checkout origin/critical
and build according to the INSTALL file (or zfs-fuse.net)
Is this vanilla 0.6.0? You could build from source in the 'critical' branch
# git clone http://git.zfs-fuse.net/official
# cd official/
# git checkout origin/critical
and build according to the INSTALL file (or zfs-fuse.net)
Added by
Seth Heeren
on
Jan 29, 2010 02:06 PM
Severity:
Medium → Low
Definitely not a problem on:
official/critical
Linux karmic 2.6.31-17-generic-pae #54-Ubuntu SMP Thu Dec 10 17:23:29 UTC 2009 i686 GNU/Linux
fusermount version: 2.8.1
See attached file (status with 5 pools of 2 x raidz(34)).
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dorky1 68.3T 174K 68.3T 0% ONLINE -
dorky2 68.3T 174K 68.3T 0% ONLINE -
dorky3 68.3T 174K 68.3T 0% ONLINE -
dorky4 68.3T 174K 68.3T 0% ONLINE -
dorky5 68.3T 174K 68.3T 0% ONLINE -
official/critical
Linux karmic 2.6.31-17-generic-pae #54-Ubuntu SMP Thu Dec 10 17:23:29 UTC 2009 i686 GNU/Linux
fusermount version: 2.8.1
See attached file (status with 5 pools of 2 x raidz(34)).
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dorky1 68.3T 174K 68.3T 0% ONLINE -
dorky2 68.3T 174K 68.3T 0% ONLINE -
dorky3 68.3T 174K 68.3T 0% ONLINE -
dorky4 68.3T 174K 68.3T 0% ONLINE -
dorky5 68.3T 174K 68.3T 0% ONLINE -
status.log
—
application log,
38Kb
Added by
Seth Heeren
on
Jan 29, 2010 02:14 PM
Target release:
None → 0.6.1
Also not a problem on rainemu.../master or zfs-fuse.net/master (equivalent besides changes in ztest and zdb).
Excuse the typo in previous response: 34 should be 35 (see log)
[For the record: 0.5.0 would hang during creation of the 4th pool. The prior ones were not a problem :)]
Excuse the typo in previous response: 34 should be 35 (see log)
[For the record: 0.5.0 would hang during creation of the 4th pool. The prior ones were not a problem :)]
Added by
Seth Heeren
on
Jan 29, 2010 03:38 PM
Just for kicks, installed an ubuntu karmic 64:
Linux karmic64 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
fusermount version: 2.7.4
branch: official/critical
Attached a log
NAME USED AVAIL REFER MOUNTPOINT
dorky1 93K 51.4T 21K /tmp/dorky1
dorky2 93K 51.4T 21K /tmp/dorky2
dorky3 93K 51.4T 21K /tmp/dorky3
dorky4 93K 51.4T 21K /tmp/dorky4
dorky5 93K 51.4T 21K /tmp/dorky5
Linux karmic64 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
fusermount version: 2.7.4
branch: official/critical
Attached a log
NAME USED AVAIL REFER MOUNTPOINT
dorky1 93K 51.4T 21K /tmp/dorky1
dorky2 93K 51.4T 21K /tmp/dorky2
dorky3 93K 51.4T 21K /tmp/dorky3
dorky4 93K 51.4T 21K /tmp/dorky4
dorky5 93K 51.4T 21K /tmp/dorky5
status.log
—
application log,
10Kb
Added by
(anonymous)
on
Jan 29, 2010 04:19 PM
Yes, forgot to say I was running Centos 5.4 x86_64 with a 2.6.18.164-1 kernel [latest]
Added by
(anonymous)
on
Jan 29, 2010 04:20 PM
The version I am using is an RPM from rpmfind.net
http://rpmfind.net/[…]/zfs-fuse-0.6.0-6.el5.x86_64.html
http://rpmfind.net/[…]/zfs-fuse-0.6.0-6.el5.x86_64.html
Added by
Seth Heeren
on
Jan 29, 2010 05:26 PM
Well colour me silly... I went and installed a system just to reproduce that. System details, see below. (8Gb, dual core)
I can confirm problems with 0.6.0 (packaged:). I cannot even create the pool like that, it will just hang immediately.
My test shows it is fixed with the critical branch works ok: see attached log. 5x240TB pools. Nifty eh!
Compiling it is dead easy (even I could do it, just copy and paste from the zfs-fuse.net homepage). Erm, if you don't have git, you will want to 'yum install git' too :)
I'll edit the steps to reproduce with my test script.
==================================== DETAILS
Linux domU-12-31-39-03-41-72 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.4 (Final)
Release: 5.4
Codename: Final
zfs-fuse x86_64 0.6.0-6.el5 epel 1.4 M
fuse x86_64 2.7.4-8.el5 base 83 k
fuse-libs x86_64 2.7.4-8.el5 base 71 k
NAME USED AVAIL REFER MOUNTPOINT
dorky1 232K 240T 59.1K /tmp/dorky1
dorky2 232K 240T 59.1K /tmp/dorky2
dorky3 232K 240T 59.1K /tmp/dorky3
dorky4 232K 240T 59.1K /tmp/dorky4
dorky5 232K 240T 59.1K /tmp/dorky5
I can confirm problems with 0.6.0 (packaged:). I cannot even create the pool like that, it will just hang immediately.
My test shows it is fixed with the critical branch works ok: see attached log. 5x240TB pools. Nifty eh!
Compiling it is dead easy (even I could do it, just copy and paste from the zfs-fuse.net homepage). Erm, if you don't have git, you will want to 'yum install git' too :)
I'll edit the steps to reproduce with my test script.
==================================== DETAILS
Linux domU-12-31-39-03-41-72 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.4 (Final)
Release: 5.4
Codename: Final
zfs-fuse x86_64 0.6.0-6.el5 epel 1.4 M
fuse x86_64 2.7.4-8.el5 base 83 k
fuse-libs x86_64 2.7.4-8.el5 base 71 k
NAME USED AVAIL REFER MOUNTPOINT
dorky1 232K 240T 59.1K /tmp/dorky1
dorky2 232K 240T 59.1K /tmp/dorky2
dorky3 232K 240T 59.1K /tmp/dorky3
dorky4 232K 240T 59.1K /tmp/dorky4
dorky5 232K 240T 59.1K /tmp/dorky5
status.log
—
application log,
48Kb
Added by
Seth Heeren
on
Jan 29, 2010 05:36 PM
PS. rereading your steps to reproduce I spotted some confusion
> "mount the array using the zfs mountpoint=/dev/mountpoint drivearray"
Firstly, no need to mount a new pool (unless you created it with '-o canmount=noauto' or '-o mountpoint=none|legacy'). A new pool 'poola" will be automounted at /poola :)
Secondly, You probably mean "zfs set mountpoint...."
Thirdly, using a /dev/ path for mountpoints is funny. Block/char devices go there.
> "mount the array using the zfs mountpoint=/dev/mountpoint drivearray"
Firstly, no need to mount a new pool (unless you created it with '-o canmount=noauto' or '-o mountpoint=none|legacy'). A new pool 'poola" will be automounted at /poola :)
Secondly, You probably mean "zfs set mountpoint...."
Thirdly, using a /dev/ path for mountpoints is funny. Block/char devices go there.
Added by
(anonymous)
on
Jan 29, 2010 06:54 PM
PS. rereading your steps to reproduce I spotted some confusion
> "mount the array using the zfs mountpoint=/dev/mountpoint drivearray"
Firstly, no need to mount a new pool (unless you created it with '-o canmount=noauto' or '-o mountpoint=none|legacy'). A new pool 'poola" will be automounted at /poola :)
Yes - correct - I'm tired...long day
Secondly, You probably mean "zfs set mountpoint...."
Yup - again long day
Thirdly, using a /dev/ path for mountpoints is funny. Block/char devices go there.
Typo - opps
Thanks for confirming my sanity!
> "mount the array using the zfs mountpoint=/dev/mountpoint drivearray"
Firstly, no need to mount a new pool (unless you created it with '-o canmount=noauto' or '-o mountpoint=none|legacy'). A new pool 'poola" will be automounted at /poola :)
Yes - correct - I'm tired...long day
Secondly, You probably mean "zfs set mountpoint...."
Yup - again long day
Thirdly, using a /dev/ path for mountpoints is funny. Block/char devices go there.
Typo - opps
Thanks for confirming my sanity!
Added by
Seth Heeren
on
May 22, 2010 01:23 PM
Issue state:
open → resolved
assuming fixed (no report back)
