Project

General

Profile

Bug #5570

panic in dmu_objset_userspace_upgrade

Added by Alex Reece almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2015-01-29
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

<tt>dmu_objset_userspace_upgrade</tt> panics when running under debug bits because the pool is held while a txg is executed.

delphix@oi-151:~$ sudo zpool create test c3t1d0
delphix@oi-151:~$ sudo zpool destroy test
delphix@oi-151:~$ sudo zpool create -o version=1 test c3t1d0
delphix@oi-151:~$ sudo zfs create test/fs
delphix@oi-151:~$ sudo zfs set mountpoint=none test/fs
delphix@oi-151:~$ sudo zpool upgrade test
This system supports ZFS pool feature flags.

Successfully upgraded 'test' from version 1 to feature flags.
Enabled the following features on 'test':
  async_destroy
  empty_bpobj
  lz4_compress
  multi_vdev_crash_dump
  spacemap_histogram
  enabled_txg
  hole_birth
  extensible_dataset
  embedded_data
  bookmarks
  filesystem_limits
  large_blocks

delphix@oi-151:~$ sudo /usr/lib/zfs/pyzfs.py userspace test/fs
Initializing accounting information on old filesystem, please wait...
Write failed: Broken pipe
> ::status
debugging crash dump /var/crash//vmcore.0 (64-bit) from oi-151
operating system: 5.11 os-build-build-3128 (i86pc)
image uuid: f5b84e33-da8c-421d-fc1a-d39dad0c6701
panic message: 
assertion failed: txg_how != TXG_WAIT || !dsl_pool_config_held(tx->tx_pool), file: .
./../common/fs/zfs/dmu_tx.c, line: 1283
dump content: kernel pages only
> ::stack
vpanic()
0xfffffffffbe0bae8()
dmu_tx_assign+0x152(ffffff01ddbd5800, 1)
dmu_objset_userspace_upgrade+0xfa(ffffff0207722b40)
zfs_ioc_userspace_upgrade+0x78(ffffff020eb4b000)
zfsdev_ioctl+0x4ff(b300000000, 5a2f, 8046460, 102302, ffffff01ef4d6df8, 
ffffff0007dcee58)
cdev_ioctl+0x39(b300000000, 5a2f, 8046460, 102302, ffffff01ef4d6df8, 
ffffff0007dcee58)
spec_ioctl+0x60(ffffff01dd4be700, 5a2f, 8046460, 102302, ffffff01ef4d6df8, 
ffffff0007dcee58)
fop_ioctl+0x55(ffffff01dd4be700, 5a2f, 8046460, 102302, ffffff01ef4d6df8, 
ffffff0007dcee58)
ioctl+0x9b(4, 5a2f, 8046460)
_sys_sysenter_post_swapgs+0x237()

It looks like a long hold would be appropriate here, so that we do not have to hold the pool while performing transactions.

Also available in: Atom PDF