Re: crash zfs_clone_range()

Hi Ronald, hitting the panic with a DEBUG kernel would be great and it would be very nice if I could somehow reproduce the panic. I have the option to rent an cheap arm64 virtual host at Hetzner so I could test that at an environment close to yours. Please try compiling a GENERIC-DEBUG kernel

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

I vote for enabling block cloning on main :-) mm On 16. 9. 2023 19:14, Alexander Motin wrote: On 16.09.2023 01:25, Graham Perrin wrote: On 16/09/2023 01:28, Glen Barber wrote: o A fix for the ZFS block_cloning feature has been implemented. Thanks I see

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

Hi Alexander, I can confirm that the patch fixes the panic caused by the provided script on my test systems. Mark, would it be possible to try poudriere on your system with a patched kernel? Thanks mm On 9. 9. 2023 0:09, Alexander Motin wrote: On 08.09.2023 09:52, Martin Matuska wrote: I

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

I digged a little and was able to reproduce the panic without poudriere with a shell script. You may want to increase "repeats". The script causes the panic in dmu_buf_hold_array_by_dnode() on my VirtualBox with the cat command on 9th iteration. Here is the script: #!/bin/sh nl=' ' sed_scrip

Re: ZFS deadlock in 14

Hi Alexander, as 15107 is a prerequisite for 15122, would it be possible to have https://github.com/openzfs/zfs/pull/15107 merged into the OpenZFS zfs-2.2-release branch (and of course later 15122)? If the patches help I can cherry-pick them into main. Cheers, mm Alexander Motin wrote:

Re: panic(s) in ZFS on CURRENT

I will wait with my prepared merge until #14954 gets merged. On 9. 6. 2023 15:59, Alexander Motin wrote: Hi Gleb, There are two probably related PRs upstream: https://github.com/openzfs/zfs/pull/14939 https://github.com/openzfs/zfs/pull/14954 On 09.06.2023 00:57, Gleb Smirnoff wrote: On Thu,

Re: another crash and going forward with zfs

Btw. I am open for setting up a pre-merge stress testing I will check out if I can use the hourly-billed amd64 and arm64 cloud boxes at Hetzner with FreeBSD. Otherwise there are monthly-billed as well. Cheers, mm On 17. 4. 2023 22:14, Mateusz Guzik wrote: On 4/17/23, Pawel Jakub Dawidek wro

Re: another crash and going forward with zfs

On 18. 4. 2023 3:16, Warner Losh wrote: Related question: what zfs branch is stable/14 going to track? With 13 it was whatever the next stable branch was. Warner FreeBSD 14.0 is about to track soon-to-be-branched OpenZFS 2.2

Tachyum Prodigy processors

Hi everybody, does anyone have any information regarding the new Tachyum Prodigy processors? They have announced FreeBSD support as well as a porting kit of their instruction set architecture for FreeBSD: https://www.tachyum.com/en-eu/media/press-releases/2022/04/05/tachyum-successfully-runs

Re: zpool upgrade can't enable new features

I have submitted a pull request to fix this in OpenZFS: https://github.com/openzfs/zfs/pull/11653 On 25. 2. 2021 17:20, John Kennedy wrote: On Thu, Feb 25, 2021 at 11:09:17AM -0300, Renato Botelho wrote: I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and zpool status shows:

Re: zpool upgrade can't enable new features

Looks like Ryan didn't think it all the way through in: https://github.com/openzfs/zfs/commit/35ec51796f0aa8d4fe322b48e7d1d5a65e38a4ce I am preparing a patch for OpenZFS. On 25. 2. 2021 17:20, John Kennedy wrote: On Thu, Feb 25, 2021 at 11:09:17AM -0300, Renato Botelho wrote: I recently upgrad

Re: libarchive update SVN r299529 breaks "ezjail update"

That switch is "--insecure" and is supported in all libarchive versions freebsd ever used. On 15.05.2016 01:36, Ngie Cooper (yaneurabeya) wrote: >> On May 14, 2016, at 16:29, Martin Matuska wrote: >> >> Ian, we are here talking about cpio, not libarchive. The flag in

Re: libarchive update SVN r299529 breaks "ezjail update"

>>>> On May 14, 2016, at 12:17 PM, Tim Kientzle >>>> wrote: >>>> >>>> Many people consider the traditional behavior to be a security >>>> risk, which is why this was changed. >>>> >>>> FreeBSD is welcome to make --insecure th

Re: libarchive update SVN r299529 breaks "ezjail update"

Looks like we have to remove line #174 from cpio/cpio.c: cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS; This breaks traditional cpio behavior. Quoting Martin Matuska : Hi Michael, I have looked at the source and this is an intended change in 3.2.0. An absolute p

Re: libarchive update SVN r299529 breaks "ezjail update"

local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is absolute: Unknown error: -1 [ .. etc. .. ] -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinf

Re: Prompt Live-CD/DVD with support for ZFS v.5000

I have updated the amd64 images with rsync without iconv linking. Please re-download. On 2013-10-10 23:12, Vladislav V. Prodan wrote: > 04.10.2013 16:56, Ollivier Robert wrote: >> According to Vladislav V. Prodan on Fri, Oct 04, 2013 at 01:48:16AM +0300: >>> You want to add such a liveCD for autom

Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?

have disabled logging for these calls. Please test the patch from current in r252380. http://svnweb.freebsd.org/base?view=revision&revision=252380 On 29.6.2013 17:00, Alexander Leidinger wrote: > On Sat, 29 Jun 2013 14:02:35 +0200 > Martin Matuska wrote: > >> some input would be

Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?

On 2013-06-29 12:01, Alexander Leidinger wrote: > On Thu, 27 Jun 2013 23:58:33 +0200 > Kristof Provost wrote: > >> On 2013-06-24 22:08:01 (+0200), Alexander Leidinger >> wrote: >>> On Mon, 24 Jun 2013 12:15:18 +0200 >>> Kristof Provost wrote: >>> For what it's worth, I'm running into exactl

Re: [CRASH] ZFS recv (fwd)/CURRENT

This is a patch against -CURRENT, so the receiving side in your case. On 5.4.2013 18:31, Larry Rosenman wrote: > On 2013-04-05 11:29, Martin Matuska wrote: >> You can use the attached patch, it should fix the problem. >> We are still waiting for code review and a final solu

Re: [CRASH] ZFS recv (fwd)/CURRENT

You can use the attached patch, it should fix the problem. We are still waiting for code review and a final solution by illumos, maybe I will commit this preliminary (or final) fix to head. mm On 5.4.2013 16:49, Larry Rosenman wrote: > On 2013-04-02 16:26, Martin Matuska wrote: >> On 1

Re: [CRASH] ZFS recv (fwd)/CURRENT

On 1. 4. 2013 22:33, Martin Matuska wrote: > This error seems to be limited to sending deduplicated streams. Does > sending without "-D" work ok? This might be a vendor error as well. > > On 1.4.2013 20:05, Larry Rosenman wrote: >> Re-Sending. Any ideas, guys/gals?

Re: [CRASH] ZFS recv (fwd)/CURRENT

This error seems to be limited to sending deduplicated streams. Does sending without "-D" work ok? This might be a vendor error as well. On 1.4.2013 20:05, Larry Rosenman wrote: > Re-Sending. Any ideas, guys/gals? > > This really gets in my way. > -- Martin Matuska

Re: ZFS problems

zpool). The kernel module is loaded and visible by kldstat. > Any ideas? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsu

Re: r238860: bsdtar: eating up 100% CPU, hanging

Please check with CURRENT r238909. I have backported the NFSv4 ACL fix for now. It will be reverted and re-merged when fixed in libarchive's release branch. On 30.7.2012 0:17, O. Hartmann wrote: > Am 07/29/12 19:19, schrieb Martin Matuska: >> Do you still have this problem after r23

Re: r238860: bsdtar: eating up 100% CPU, hanging

Do you still have this problem after r238882? Dňa 28. 7. 2012 19:21 O. Hartmann wrote / napísal(a): > When updating ports (like databases/sqlite3 or graphics/png via > portmaster graphics/png), the installation process comes to a point > where a backup of the old port is created with bsdtar. The

Re: r238860: bsdtar: eating up 100% CPU, hanging

I am also looking into it: 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) 2. It happens only if archiving files located on ZFS (UFS works fine) 3. Backtrace: #0 setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000, archive_entry_acl_type=256) at /base/head/lib

Re: binutils-2.22: ld and --copy-dt-needed-entries

to resolve symbols. What do we do with this? We can go back, patch to behave as before or to continue. Are there any serious complaints? -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.

Re: zfs i/o hangs on 9-PRERELEASE

ave posted this seems to be a pf problem. Could you try the same situation with with pf(4) disabled? If you are not able to reproduce this hang with pf(4) disabled, it would be very nice to have a PR submitted. -- Martin Matuska FreeBSD committer http://blog.vx.sk ___

[PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features)

il/jail_etc.v2.nowhitespace.patch On 31. 7. 2011 0:32, Jamie Gritton wrote: > Yes, that looks good. It keeps what I'd call expected behavior for > persist (at least on the startup side). > > - Jamie > > > On 07/29/11 14:53, Martin Matuska wrote: >> So what do you thin

Re: makefs(8) & broken iso9660 images

nd: /media/usr/include/c++/4.2/ext/pb_ds/detail/trie_policy: Input/output > error > find: /media/usr/include/c++/4.2/ext/pb_ds/detail/unordered_iterator: > Input/output error > > Am I alone in seeing this? > To resolve problems as quickly as possible, libarchive er

Re: bsdtar(1) can't extract new ISO images

#x27;s also reproducable on daily snapshots from allbsd.org > /stable/8 vs. /head. So, does this count as regression? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscri

Re: panic: share -> excl @r224632

Patch updated. On 05.08.2011 10:26, Kostik Belousov wrote: > On Fri, Aug 05, 2011 at 10:18:49AM +0200, Martin Matuska wrote: >> I agree to Kostik's approach, but I suggest implementing it in a >> separate function and also use for the unmount() part. >> >> Pleas

Re: panic: share -> excl @r224632

> + NDFREE(&nd, NDF_ONLY_PNBUF); > + vp1 = nd.ni_vp; > + vrele(vp); > + if (vp1 != vp) { > + vput(vp1); > + free(fbuf, M_TEMP); > + return (ENOENT); > + } > >

Re: [PATCH] updated /etc/rc.d/jail and added ZFS support

Dňa 30. 7. 2011 17:29, Alexander Leidinger wrote / napísal(a): > On Thu, 28 Jul 2011 16:11:37 +0200 Martin Matuska > wrote: > > >> The attached patch allows better fine-tuning of jails started via >> /etc/rc.d, uses the new jail(8) flags (-c -m), the persist parameter

Re: [PATCH] updated /etc/rc.d/jail and added ZFS support

nd then clears it at a later > stage unless the user specifies to keep it set. It looks like I might > want to add some ZFS support to the new jail(8). > > I would prefer to keep things simpler regarding create/start and > remove/stop, and keep them tied together. > > - Jamie &

[PATCH] Updated jail mount/unmount patch

After implementing a suggestion from pjd@, a new version of the patch is attached, now using a more universal solution - vn_fullpath_global() in the mount part. Dňa 28. 7. 2011 16:59, Martin Matuska wrote / napísal(a): > Please review my attached patch. > > The patch fixes f_mntonname w

Re: [PATCH] jail mount/unmount patch

;m not sure about enforce_statfs!=2 in the privilege check. It seems a > reasonable response to a contradictory set of permissions, but then so > does the strange case if being able to mount a filesystem and then not > being able to see it in statfs. > > - Jamie > > > On 0

Re: [PATCH] updated /etc/rc.d/jail and added ZFS support

used. > > Also, why the specific inclusion of the security-related parameters? > They could just be folded into ${_params}, and if left unspecified then > jail(8) should by default do the right thing. > > - Jamie > > > On 07/28/11 08:11, Martin Matuska wrote: >> T

[PATCH] jail mount/unmount patch

devices may work correctly with this patch, too (e.g. nfs). With jailed nullfs we can run tinderbox in a jail ;) Please review, comment and/or test my attached patch. Cheers, mm -- Martin Matuska FreeBSD committer http://blog.vx.sk Index: src/sys/kern/kern_jail.c

[PATCH] updated /etc/rc.d/jail and added ZFS support

The attached patch allows better fine-tuning of jails started via /etc/rc.d, uses the new jail(8) flags (-c -m), the persist parameter and adds ZFS support. Patch is fully backward compatible. Please review, comment and/or test my attached patch. Cheers, mm -- Martin Matuska FreeBSD committer

Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

After my recent patches to HEAD not anymore. I have also a SSSE3 patch and a general gcc 4.2 update patch pending. Dňa 12.03.2011 09:42, Jakub Lach wrote / napísal(a): > > "Core i7 based procesors run slower with -march=core2 (new option) on the > system > compiler than with -march=nocona" > >

Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

42cc.8020...@freebsd.org>, Martin Matuska writes: > >> But what I can say, e.g. for the Intel Atom processor, if there are >> performance gains in all but one test (that falls 2% behind), generic >> perl code (the routines benchmarked) on this processor is very likely to >

Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

sts, I can say it is very likely that it will run slower. But again, I am benchmarking just a subset of generic perl functions. Cheers, mm Dňa 11.03.2011 15:01, Poul-Henning Kamp wrote / napísal(a): > In message <4d7943b1.1030...@freebsd.org>, Martin Matuska writes: > >> More

FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

Hi everyone, we have performed a benchmark of the perl binary compiled with base gcc, ports gcc and ports clang using the perlbench benchmark suite. Our benchmark was performed solely on amd64 with 10 different processors and we have tried different -march= flags to compare binary performance of t

[TESTING] base gcc update to latest GPLv2 version

Here is a base gcc upgrade to the latest GPLv2 version (rev. 127959). http://people.freebsd.org/~mm/patches/head-gcc-422-prerelease.patch Open questions: Do we want the "4.2.2 prerelase 20070831" version tag or stick to "4.2.1 20070831"? Testing and comments are welcome. Originally suggested by

[TESTING] ssse3 backport from gcc 4.3

I have prepared a patch that finishes the "core2" support part and backports from gcc-4.3 the SSSE3 instruction set (-mssse3, -mno-ssse3). It is enabled for -march=core2 by default. Testing and comments are welcome. Patch: http://people.freebsd.org/~mm/patches/head-gcc-ssse3.patch The backport c

Re: r219385 build error.

This change did NOT add SSSE3 or any other new instruction sets to our base compiler. The only change of using -march=core2 vs -march=nocona is actually different instruction costs that may result in binaries more optimized for your core2 and later CPUs (and less optimized for nocona and earlier C

Re: r219385 build error.

This actually does not happen at the bootstrap stage, but when building 32-bit compat libs under amd64. It looks like the system compiler is used here instead (should it be this way, isn't it a bug somewhere around Makefile.inc1?). Yes, building + installing world without this optimization makes i

Re: Next ZFSv28 patchset ready for testing.

Thanks for the notice. I have found the cause of this error (wrong constants), tested the code in both directions again (v15->v28 and v28->v15) + fixed it in perforce. Bugfix patch (apply after pjd's patch): http://people.freebsd.org/~mm/patches/zfs/v28/head-zfs_ioctl_compat.c.patch Dňa 14.12.20

Re: ZFS v28 is ready for wider testing.

written on this list. Thanks for understanding! Dňa 6. 9. 2010 13:50, Martin Matuska wrote / napísal(a): > Hi everyone, > I have put together a slightly improved patch of Pawel's that compiles > correctly and supports booting from ZFS v19 pools. > > You can d

Re: ZFS v28 is ready for wider testing.

Hi everyone, I have put together a slightly improved patch of Pawel's that compiles correctly and supports booting from ZFS v19 pools. You can download the patch here: http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch For users who don't want to compile I have created a mfsBS

[CFT] ZFS ACL and rrwlock speedup

Dear FreeBSD community, in my last CFT I presented a patch that improves ZFS write speed. There have been easily portable improvements on the read side in OpenSolaris, too. Of course, the improvement here is by far not that dramatic as in the zfs_metaslab.patch, but OpenSolaris developers claim th

Re: [CFT] Improved ZFS metaslab code (faster write speed)

Thank you, I have updated the v15 patch for 8-STABLE. Dňa 22. 8. 2010 17:44, Olivier Smedts wrote / napísal(a): > 2010/8/22 Martin Matuska : >> Dear FreeBSD community, >> >> many of our [2] (and Solaris [3]) users today are complaining about slow >> ZFS writes. One of

[CFT] Improved ZFS metaslab code (faster write speed)

Dear FreeBSD community, many of our [2] (and Solaris [3]) users today are complaining about slow ZFS writes. One of the causes for these writes is the selection of the proper allocation method for allocation of new blocks [3] [4]. Another issue a write slowdown during TXG sync times. Solaris 10 (

Re: [CFT] ZFS v15 patch (version 3)

Dňa 14. 7. 2010 10:23, Peter Jeremy wrote / napísal(a): > On 2010-Jul-14 09:16:09 +0200, Martin Matuska wrote: >> Without head-12636.patch you are unable to reproduce the deadlock? > The deadlock occurs with either stock 8-stable or with head-12636.patch. > > I have also been

Re: [CFT] ZFS v15 patch (version 3)

What about the OpenSolaris revision 9701 for starters? Could that help your case? 9701:cc5b64682e64 6803605 should be able to offline log devices http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6803605 6726045 vdev_deflate_ratio is not set when offlining a log device http://bugs.open

Re: [CFT] ZFS v15 patch (version 3)

Without head-12636.patch you are unable to reproduce the deadlock? Dňa 14. 7. 2010 2:14, Peter Jeremy wrote / napísal(a): > On 2010-Jul-08 23:30:33 +0200, Martin Matuska wrote: >> On 8. 7. 2010 22:04, Peter Jeremy wrote / napísal(a): >>> Without patching arc_memory_th

[HEADSUP] ZFS version 15 committed to head

Dear community, as you may have noticed, ZFS v15 support with many bugfixes was committed to head in revision 209962. The commit was tagged for MFC, so if there are no stopper issues I am going to commit it to stable/8 in 2 months from today. Here is a short summary of what we gained with this u

Re: [CFT] ZFS v15 patch (version 3)

Upgrading your pool to version 15, compared to version 14, you get only these additional features: - user and group quotas - getting rid of the old version message in zpool status (-x) and these disadvantages: - not importable and/or operable with pre-v15 kernel module and updated boot loader code

Re: [CFT] ZFS v15 patch (version 3)

On 8. 7. 2010 22:04, Peter Jeremy wrote / napísal(a): > On 2010-Jul-05 13:50:52 +0200, Martin Matuska wrote: > >> As ZFS v15 is already being used in the Solaris 10 enterprise world, we >> can consider it well-tested. >> > So we know if the ZFS in Solaris

Re: [CFT] ZFS v15 patch (version 3)

example > here of the stability of OSol bits...they use the SXCE distro recently > discontinued. > > v19 also includes a number of performance fixes for DB workloads. > > -J > > Sent via iPhone > > Is your e-mail Premiere? > > On Jul 8, 2010, at 1:32, Martin M

Re: [CFT] ZFS v15 patch (version 3)

User and group quotas is no important enhancement? We have to see the whole thing from a stability perspective as well - OpenSolaris has by far less testing than Solaris 10. Oracle cannot afford to feed his enterprise customers (and these are not few) with untested code. Dňa 7. 7. 2010 20:30, Sam

Re: [CFT] ZFS v15 patch (version 3)

> using head from 3 hours ago, this patch does not apply cleanly > > http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3-extension.patch > The patch you are trying is just for experimental testing and can be applied only on top of head-v15-v3.patch (so you need to apply head-v15-v3.patch

Re: [CFT] ZFS v15 patch (version 3)

Dňa 7. 7. 2010 18:04, jhell wrote / napísal(a): > On 07/05/2010 07:50, Martin Matuska wrote: > >> Direct link to the patch: >> http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch >> >> For full operation (commands zfs allow, unallow, userspace, gr

[CFT] ZFS v15 patch (version 3)

Dear FreeBSD community, there has been a ZFS-related discussion at the meetBSD conference in Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to -CURRENT. An upgrade to version 16 gives us no valuable features (to be true, no features at all besides ability to import v16 pools). A

[CFT] ZFS v16 with stat() speedup

As I have imported some more improvements to the ZFS v15 patch that also target speed, I am now calling for testing of v16 with mainly the following important (post-v16) enhancement (and some related bugfixes): OpenSolaris Bug ID: 6775100 stat() performance on files on zfs should be improved This

CFT: ZFS v15 patch

Dear developers, I would like to do a call for testing for my ZFS v15 patch. As the user/group quotas feature is too much attractive for my needs, I couldn't resist and have created (and debugged + tested) a ZFS v15 patch for head (applies cleanly against stable/8 as well). It is a backport of s