[Bug 236710] zfs: clone + resize = dataset is busy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236710
Bug ID: 236710
Summary: zfs: clone + resize = dataset is busy
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: olev...@olevole.ru
( copy of the problem published in freebsd-fs@ )
I see the following problem on FreeBSD 13.0-CURRENT
r345087M amd64, zpool version 28, zfs version 5
If you create a ZVOL, fill in specific data, take a snapshot, clone
and resize, you will get a blocked pool (device busy for : export -f,
destroy -f ..)---
what i found:
a) the problem only appears on clone/snapshot, there is no problem on
a simple zvol resize;
b) the nature of the data affects the problem:
- when zvol no data, problem is missing
- If you try to fill zvol with random data, for example: dd
if=/dev/random of= there are also no problems. But problem exist
if I try to fill in with cloud images data (
http://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/12.0-RELEASE/amd64/Latest/
, http://cloud-images.ubuntu.com/xenial/current/
) - in fact, these are raw images of the installed OS.
c) The problem only occurs when creating zvol + resizing (in two
commands). If you try to do atomically and simultaneously:
/sbin/zfs clone -o volsize= ...
there is no problem, but with this:
/sbin/zfs clone ..
/sbin/zfs set volsize=
problem exist.
Maybe this is not a ZFS problem and GEOM-related ?
Step-by-step how to reproduce (where z01 - active ZFS pool):
---
% wget
http://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/12.0-RELEASE/amd64/Latest/FreeBSD-12.0-RELEASE-amd64.raw.xz
% xz -d FreeBSD-12.0-RELEASE-amd64.raw.xz
> ( /usr/bin/stat -f "%z" FreeBSD-12.0-RELEASE-amd64.raw -- get size)
> 33286062080
% /sbin/zfs create -sV 33286062080 -o volmode=dev z01/test1
% dd bs=1m if=FreeBSD-12.0-RELEASE-amd64.raw of=/dev/zvol/z01/test1
> 31744+1 records in
> 31744+1 records out
> 33286062080 bytes transferred in 127.530635 secs (261004441 bytes/sec)
% /sbin/zfs snapshot z01/test1 at snap
% /sbin/zfs clone z01/test1 at snap
> ( resizing. For example, double up )
> bc -e '33286062080 * 2'
> 66572124160
% /sbin/zfs set volsize=66572124160 z01/test2
% /sbin/zfs destroy z01/test2
> cannot destroy 'z01/test2': dataset is busy
% zpool export -f z01
> cannot export 'z01': pool is busy
---
with truss i can see:
..
ioctl(3,0xc0185a15 { IORW 0x5a('Z'), 21, 24 },0x7fffcd78) ERR#3
'No such process'
ioctl(3,0xc0185a15 { IORW 0x5a('Z'), 21, 24 },0x7fffcd78) ERR#3
'No such process'
ioctl(6,0xc0185a18 { IORW 0x5a('Z'), 24, 24 },0x7fffcdb8) ERR#16
'Device busy'
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236710] zfs: clone + resize = dataset is busy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236710 --- Comment #1 from Andriy Gapon --- This could be a ZFS<->GEOM interaction indeed. Maybe related to bug 228384, maybe not. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236475] [ZFS] Invalid VOP_FSYNC options in vdev_file_io_start
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236475 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: avg Date: Fri Mar 22 09:11:46 UTC 2019 New revision: 345410 URL: https://svnweb.freebsd.org/changeset/base/345410 Log: ZFS vdev_file: use correct value for waitfor parameter of VOP_FSYNC PR: 236475 Reported by: asomers MFC after:2 weeks Changes: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236714] Clang problem with rctl(8)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236714
Bug ID: 236714
Summary: Clang problem with rctl(8)
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: tr...@freebsd.org
I've stumbled upon something that seems to me to be a miscompilation issue in
rctl(8). Basically, this code in usr.bin/rctl/rctl.c:
racct_enable_len = sizeof(racct_enable);
error = sysctlbyname("kern.racct.enable",
&racct_enable, &racct_enable_len, NULL, 0);
if (error != 0) {
if (errno == ENOENT)
errx(1, "RACCT/RCTL support not present in kernel; see
rctl(8) for details");
err(1, "sysctlbyname");
}
if (racct_enable == 0)
errx(1, "RACCT/RCTL present, but disabled; enable using
kern.racct.enable=1 tunable");
Doesn't work as expected unless the racct_enable is initialized before calling
sysctlbyname(3). Without this change:
% doas rctl
rctl: failed to show rules for '::': Function not implemented
With the change:
% doas rctl
rctl: RACCT/RCTL present, but disabled; enable using kern.racct.enable=1
tunable
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236559] Error in the pwd man page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236559 --- Comment #2 from verma...@interia.pl --- (In reply to Mark Johnston from comment #1) So shell builtin (ZSH) behaves correctly with POSIX standards. IMHO FreeBSD should also be correct with POSIX standards so option -L should be assumed in FreeBSD's pwd. I am not gonna 'fight' for this - you will do what you want - but that is my opinion. Regards, vermaden -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236714] Clang problem with rctl(8)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236714 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236710] zfs: clone + resize = dataset is busy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236710 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|f...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236559] Error in the pwd man page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236559 --- Comment #3 from Mark Johnston --- (In reply to vermaden from comment #2) It's mostly a question of whether changing the default will break existing scripts. sh, bash and zsh use a builtin implementation for pwd, but tcsh in the base system does not, so I expect that such a change would cause a fair amount of pain. We should update the pwd(1) man page to note that we are not compliant with the standard. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236475] [ZFS] Invalid VOP_FSYNC options in vdev_file_io_start
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236475 Andriy Gapon changed: What|Removed |Added Assignee|b...@freebsd.org|a...@freebsd.org Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236718] system panics with message: vm_fault_hold: fault on nofault entry, addr: 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236718 Bug ID: 236718 Summary: system panics with message: vm_fault_hold: fault on nofault entry, addr: 0 Product: Base System Version: 12.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: lenzi.ser...@gmail.com the sysem panics when using several ppp (tunx) tunnels using ppp over tcp. the crash files are on http://www.k1.com.br/crash the trace can be found on: http://www.k1.com.br/crash/core.txt.8 seems that a problem on detach the ppp interface... if I stop all the ppp process, the system does not panics This machine is a pppoi server that holds serveral ppp connections -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236718] system panics with message: vm_fault_hold: fault on nofault entry, addr: 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236718 lenzi.ser...@gmail.com changed: What|Removed |Added Hardware|Any |i386 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236718] system panics with message: vm_fault_hold: fault on nofault entry, addr: 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236718 Mark Linimon changed: What|Removed |Added Keywords||panic -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 235944] jedec_dimm(4) does not attach to KFA2 (aka Galax) Hall of Fame DDR4 sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235944 --- Comment #29 from Ravi Pokala --- > Thanks Greg! I'll massage it as needed and commit it for you sometime in the > next few days. For some very large definitions of "few"... :-/ I've finally circled back around to this, and have a patch in Phabricator: https://reviews.freebsd.org/D19681 Greg, could you apply that patch and confirm that it works for you? Thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] Different power states (C1/C2/...) per CPU core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #5 from stockhau...@collogia.de --- Finally I got time to retest everything with 12.0-RELEASE. Situation is the same. Only the first CPU can go to C2 state. All other cores only show up with cx_lowest = C1. Only difference this time: It is the successor CPU AMD RX-427BB. Btw. The hardware in my tests is: First Time: HP Thin client T620 PLUS Second Time: HP Thin client T730 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] Different power states (C1/C2/...) per CPU core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #6 from stockhau...@collogia.de --- Created attachment 203049 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203049&action=edit Screenshot dmesg -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] Different power states (C1/C2/...) per CPU core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #7 from stockhau...@collogia.de --- Just fired up a Fedora 29 on the HP T730. Running a cpu intensive task and looking at the powertop output I would say that C2 states are core independent. Conclusion: Linux kernel detects C2 states per core. So at least BIOS should not be broken. Screenshot attached. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] Different power states (C1/C2/...) per CPU core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #8 from stockhau...@collogia.de --- Created attachment 203050 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203050&action=edit Fedora powertop -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] Different power states (C1/C2/...) per CPU core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #9 from stockhau...@collogia.de --- Bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189267 shows other occurences of CPUs where c states for the first core is C1+C2 while all other cores are C1 only. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236724] igbX interfaces fail to switch active to inactive state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724 Bug ID: 236724 Summary: igbX interfaces fail to switch active to inactive state Product: Base System Version: 12.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ncrog...@gmail.com Since upgrading to 12.0-RELEASE / iflib I've noticed that my igbX interfaces no longer go from status "active" to "inactive" (as reported by ifconfig) when the Ethernet port is unplugged and loses link. The status lights on the physical interface go out but ifconfig still reports active + autoselect/1000baseT. An "ifconfig down" followed by "up", while its unplugged, forces the link to recognize the "inactive" state. After the down/up dance plugging the cable in again returns it to "active". I have replicated this problem with a clean install of the latest 12-STABLE snapshot as of today. The only configuration I've made was the usual timezone, root password, etc. during install. The interfaces in this test case have no IP address configurations. This is possibly a duplicate of bug #228556, however I am unsure because the description is confusing and I am not using a virtualization layer. I've noticed this on multiple systems with the following Intel devices (as reported by pciconf "device"): I210 Gigabit Network Connection I211 Gigabit Network Connection Ethernet Connection I354 uname -a: FreeBSD test.local 12.0-STABLE FreeBSD 12.0-STABLE r345358 GENERIC amd64 ifconfig when igb2 is actually connected and active: igb2: flags=8843 metric 0 mtu 1500 options=e507bb ether 00:90:0b:78:13:5a media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 ifconfig when igb2 is disconnected (identical to above): igb2: flags=8843 metric 0 mtu 1500 options=e507bb ether 00:90:0b:78:13:5a media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 Relevant pciconf -lcv: igb2@pci0:0:20:0: class=0x02 card=0x1f418086 chip=0x1f418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I354' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x2000] cap 10[a0] = PCI-Express 2 root endpoint max data 512(512) FLR NS ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 00900b78135a ecap 0017[1a0] = TPH Requester 1 ecap 000d[1d0] = ACS 1 igb3@pci0:0:20:1: class=0x02 card=0x1f418086 chip=0x1f418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I354' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x2000] cap 10[a0] = PCI-Express 2 root endpoint max data 512(512) FLR NS ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 00900b78135a ecap 0017[1a0] = TPH Requester 1 ecap 000d[1d0] = ACS 1 igb4@pci0:0:20:2: class=0x02 card=0x1f418086 chip=0x1f418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I354' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x2000] cap 10[a0] = PCI-Express 2 root endpoint max data 512(512) FLR NS ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 00900b78135a ecap 0017[1a0] = TPH Requester 1 ecap 000d[1d0] = ACS 1 igb5@pci0:0:20:3: class=0x02 card=0x1f418086 chip=0x1f418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I354' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x2000] cap 10[a0] = PCI-Express 2 root endpoint max data 512(512) FLR NS ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 00900b78135a ecap 0017[1a0] = TPH Requester 1 ecap 000d[1d0] = ACS 1 ehci0@pci0:0:22:0: class
[Bug 236724] igbX interfaces fail to switch active to inactive state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724 Mark Linimon changed: What|Removed |Added Keywords||IntelNetworking, regression Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 199934] [FUSEFS] kernel module fails with filesystems without .create support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199934 --- Comment #4 from commit-h...@freebsd.org --- A commit references this bug: Author: asomers Date: Sat Mar 23 00:22:30 UTC 2019 New revision: 345429 URL: https://svnweb.freebsd.org/changeset/base/345429 Log: fusefs: fallback to MKNOD/OPEN if a filesystem doesn't support CREATE If a FUSE filesystem returns ENOSYS for FUSE_CREATE, then fallback to FUSE_MKNOD/FUSE_OPEN. Also, fix a memory leak in the error path of fuse_vnop_create. And do a little cleanup in fuse_vnop_open. PR: 199934 Reported by: s...@os2.kiev.ua Sponsored by: The FreeBSD Foundation Changes: projects/fuse2/sys/fs/fuse/fuse_vnops.c projects/fuse2/tests/sys/fs/fusefs/create.cc projects/fuse2/tests/sys/fs/fusefs/mockfs.cc -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 199934] [FUSEFS] kernel module fails with filesystems without .create support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199934 Alan Somers changed: What|Removed |Added Status|New |In Progress --- Comment #5 from Alan Somers --- Ok, this bug should be fixed now (though it's not yet merged to head). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236718] system panics with message: vm_fault_hold: fault on nofault entry, addr: 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236718 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable11?, ||mfc-stable12? Status|New |Open Keywords|panic |crash, needs-qa Severity|Affects Many People |Affects Some People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236718] system panics with message: vm_fault_hold: fault on nofault entry, addr: 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236718 --- Comment #1 from Kubilay Kocak --- Created attachment 203059 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203059&action=edit backtrace -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
