Date: Sat, 20 Jun 2020 19:07:35 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 247445] ZFS - memory leak in dsl_scan_visitbp() Message-ID: <bug-247445-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247445 Bug ID: 247445 Summary: ZFS - memory leak in dsl_scan_visitbp() Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: jdolecek@NetBSD.org Created attachment 215825 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215825&action=edit Memory leak fix File: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c dsl_scan_visitbp() doesn't free allocated memory when dsl_scan_recurse() fails. This is probably very rare, seems it's only possible on I/O errors. I've attached what I believe is the fix, but it's not tested. Memory leak was introduced with this change (git checkout): commit a73aecd5f1b3afb968ba2977945b1a62d47d0353 Author: sef <sef@FreeBSD.org> Date: Fri Jun 8 17:38:28 2018 +0000 This originated from ZFS On Linux, as https://github.com/zfsonlinux/zfs/commit/d4a72f23863382bdf6d0ae33196f5b5decbc48fd During scans (scrubs or resilvers), it sorts the blocks in each transaction group by block offset; the result can be a significant improvement. (On my test system just now, which I put some effort to introduce fragmentation into the pool since I set it up yesterday, a scrub went from 1h2m to 33.5m with the changes.) I've seen similar rations on production systems. Approved by: Alexander Motin Obtained from: ZFS On Linux Relnotes: Yes (improved scrub performance, with tunables) Differential Revision: https://reviews.freebsd.org/D15562 -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247445-227>