|
Description
|
Bfu to MarkM's bugs:2007-08-26,
if rename a filesystem, then do some read I/O overit,
then it cannot rename and return busy at the first time.
The second time will works ok. (That's not depend on async, I've wait enough time before the 1st rename)
I suspect this defect should has been integrated into onnv:2007-08-27,
since Mark has putback this workspace today.
I'll changed the category if verified.
Force save a crashdump before the 1st rename,
rename testpool.104719/testfs1.104719-new & testpool.104719/testctr104719/testfs1.104719-new will fail at the moment.
The force dump is copied to:
/net/zion.eng/export/dumps/robin/<bug id>/*.22
<stf>:# $STF_GOSU zfs_rename_001_pos
03:12:09 ASSERTION: 'zfs rename' should successfully rename valid datasets
03:12:10 SUCCESS: /usr/sbin/zfs rename testpool.104719/testfs1.104719 testpool.104719/testfs1.104719-new
03:12:10 SUCCESS: datasetexists testpool.104719/testfs1.104719 exited 1
03:12:10 SUCCESS: datasetexists testpool.104719/testfs1.104719-new
03:12:11 SUCCESS: /usr/sbin/zfs rename testpool.104719/testctr104719/testfs1.104719 testpool.104719/testctr104719/testfs1.104719-new
03:12:11 SUCCESS: datasetexists testpool.104719/testctr104719/testfs1.104719 exited 1
03:12:11 SUCCESS: datasetexists testpool.104719/testctr104719/testfs1.104719-new
03:12:11 SUCCESS: /usr/sbin/zfs rename testpool.104719/testctr1104719 testpool.104719/testctr1104719-new
03:12:11 SUCCESS: datasetexists testpool.104719/testctr1104719 exited 1
03:12:11 SUCCESS: datasetexists testpool.104719/testctr1104719-new
03:12:11 NOTE: Verify mountable datasets are mounted in their new namespace.
03:12:11 SUCCESS: mounted testpool.104719/testfs1.104719-new
03:12:12 SUCCESS: mounted testpool.104719/testctr104719/testfs1.104719-new
03:12:12 'zfs rename' successfully renamed each dataset type.
<stf>:# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool.104719 156M 16.3G 24K /testpool.104719
testpool.104719/datafs104719 2.02M 16.3G 2.02M /testdir2104719
testpool.104719/testctr104719 1.04M 16.3G 18K /testpool.104719/testctr104719
testpool.104719/testctr104719/testfs1.104719-new 1.02M 16.3G 1.02M /testdir1104719
testpool.104719/testctr1104719-new 1.02M 16.3G 1.02M /testpool.104719/testctr1104719-new
testpool.104719/testfs.104719 1.02M 16.3G 1.02M /testdir104719
testpool.104719/testfs1.104719-new 1.02M 16.3G 1.02M /testpool.104719/testfs1.104719-new
testpool.104719/testvol104719 1.03M 16.5G 1.03M -
ts-auto-pool 132K 27.4M 19K /ts-auto-pool
ts-auto-pool/fs 18K 27.4M 18K /ts-auto-pool/fs
<stf>:# $STF_GOSU zfs rename testpool.104719/testfs1.104719-new testpool.104719/testfs1.104719
cannot rename to 'testpool.104719/testfs1.104719-new': dataset is busy
<stf>:# $STF_GOSU zfs rename testpool.104719/testfs1.104719-new testpool.104719/testfs1.104719
<stf>:# $STF_GOSU zfs rename testpool.104719/testctr104719/testfs1.104719-new testpool.104719/testctr104719/testfs1.104719
cannot rename to 'testpool.104719/testctr104719/testfs1.104719-new': dataset is busy
<stf>:# echo $?
1
<stf>:# $STF_GOSU zfs rename testpool.104719/testctr104719/testfs1.104719-new testpool.104719/testctr104719/testfs1.104719
It now exist in onnv nightly after MarkM's putback
i think i'm seeing this bug while trying to rename workspace on
my desktop. here's what i'm doing:
---8<---
edp@mcescher$ pfexec zfs rename export/builds/onnv-cons-intel export/builds/intel/onnv-cons
cannot rename to 'export/builds/onnv-cons-intel': dataset is busy
edp@mcescher$ fuser -c /export/builds/onnv-cons-intel
/export/builds/onnv-cons-intel:
edp@mcescher$ pfexec zfs umount export/builds/onnv-cons-intel
edp@mcescher$ pfexec zfs rename export/builds/onnv-cons-intel export/builds/intel/onnv-cons
edp@mcescher$ pfexec zfs mount -a
edp@mcescher$
---8<---
This bug also manifests itself in other ways. For example, doing zfs
unmount -a with shared filesystems can result in random filesystems
returning ebusy (since all of the cached data isn't evicted). The
only solution is to reboot the machine.
|
