Re: Panic in getblkx() booting from disc1.iso in Qemu VM
Thanks Rebecca for the report and Mark for the analysis of the problem.
This should be fixed in -r342290.
Kirk McKusick
=-=-=
From:Kirk McKusick
Date:Fri, 21 Dec 2018 01:09:25 + (UTC)
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Subject: svn commit: r342290 - head/sys/kern
Author: mckusick
Date: Fri Dec 21 01:09:25 2018
New Revision: 342290
URL: https://svnweb.freebsd.org/changeset/base/342290
Log:
Some filesystems (like cd9660 and ext3) require that VFS_STATFS()
be called before VFS_ROOT() is called. Move the call for VFS_STATFS()
so that it is done after VFS_MOUNT(), but before VFS_ROOT().
This change actually improves the robustness of the mount system
call because it returns an error rather than failing silently
when VFS_STATFS() returns failure.
Reported by: Rebecca Cran
Sponsored by: Netflix
Modified:
head/sys/kern/vfs_mount.c
Modified: head/sys/kern/vfs_mount.c
==
--- head/sys/kern/vfs_mount.c Thu Dec 20 22:39:58 2018(r342289)
+++ head/sys/kern/vfs_mount.c Fri Dec 21 01:09:25 2018(r342290)
@@ -895,6 +895,7 @@ vfs_domount_first(
*/
error1 = 0;
if ((error = VFS_MOUNT(mp)) != 0 ||
+ (error1 = VFS_STATFS(mp, >mnt_stat)) != 0 ||
(error1 = VFS_ROOT(mp, LK_EXCLUSIVE, )) != 0) {
if (error1 != 0) {
error = error1;
@@ -916,7 +917,6 @@ vfs_domount_first(
vfs_freeopts(mp->mnt_opt);
mp->mnt_opt = mp->mnt_optnew;
*optlist = NULL;
- (void)VFS_STATFS(mp, >mnt_stat);
/*
* Prevent external consumers of mount options from reading mnt_optnew.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On Thu, Dec 20, 2018 at 03:11 Eugene M. Zheganin wrote: > Hello, > > On 19.12.2018 23:32, Allan Jude wrote: > > The biggest thing to remember is that this is still OpenZFS, and still > > run by the same developers as it has been. We are just commonizing on > > the repo that has the most features integrated into it. > > Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because > there is no such thing in ZoL ? No, but the ZTS will need to have ACL tests re-added. Please help out by aiding in getting this merged: https://github.com/zfsonlinux/zfs/pull/7728 Thanks. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On Thu, Dec 20, 2018 at 06:39 Alexey Dokuchaev wrote: > On Thu, Dec 20, 2018 at 03:49:38PM +0500, Eugene M. Zheganin wrote: > > On 19.12.2018 23:32, Allan Jude wrote: > > > The biggest thing to remember is that this is still OpenZFS, and still > > > run by the same developers as it has been. We are just commonizing on > > > the repo that has the most features integrated into it. > > > > Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because > > there is no such thing in ZoL? > +1. I'm also worried if this would bring more Linuxish bits into our > kernel (cf. LinuxKPI). Also, I thought that ZFS was never really native > to Linux but implemented through SPL (Solaris Porting Layer), and Linux' > VFS is not ARC-aware unlike Solaris and FreeBSD. > There is no LinuxKPI involved here. Please re-read Allan’s comments on directory structuring. No open source OS supporting ZFS has a VM subsystem that is integrated with the ARC. The limited feedback that the ARC has from FreeBSD’s VM will remain unchanged. > It would be quite upsetting to see ZFS as we know it in FreeBSD become > pessimized because of those things. :-( > ZFS will be no more pessimized than it currently is. Talk to mjg some time about ZFS some time, there are ... scaling issues in its locking strategies. Apart from that FreeBSD’s VFS itself has serious scaling. None of this will get better or worse when we change the vendor repo we use for integrating changes. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On Thu, Dec 20, 2018 at 1:49 PM Allan Jude wrote: > I am to give a big thanks to Matt Ahrens for organizing the monthly > OpenZFS Leadership meeting, and the OpenZFS developer summit, and to > Brian Behlendorf for being so helpful, and willing to work to make > OpenZFS better for everyone. > I'd recommend the monthly leadership meetings. They dispelled any doubt that I had that there were overly powerful factions present that would disadvantage FreeBSD. The calls were worthwhile to understand the context of a number of other things being discussed. It seems much healthier in this context than things I've seen in the Illumos context because of a lack of burdensome process that provided no benefit and actually got in the way (which honestly, was my expectations going into the meeting). There's good reason to trust OpenZFS, it's leadership and decision making process. If ZoL is the best upstream source, then I trust their judgement on that, regardless of the hassles it will cause us in the coming months. >From the discussions I've seen, there is no pain-free choice that doesn't relegate FreeBSD to a backwater of what we have today. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On 12/19/2018 13:32, Allan Jude wrote: Today, the OpenZFS repo is just a fork of the illumos-gate repo, but where pull requests are accepted, and where previous Delphix employees This should say 'previously', Prakash Surya and Matt Ahrens still work at Delphix. would deal with the process of trying to upstream patches to illumos. This process has not worked well recently, as things have gotten stuck waiting for 'merge advocates' in illumos. The major stumbling block was the lack of modern test infrastructure. Obviously depending on one or two people to merge stuff was a bottleneck as those people inevitably get busy. Anyway, the point is that this doesn't make FreeBSD any more dependent on Linux. The goal is this project is to continue to make it easier and easier to port OpenZFS and its new features to all platforms (illumos, FreeBSD, Linux, OS X, Windows, NetBSD, etc), and to ensure that new features arrive in a timely fashion in all of the platforms. Unifying on a single CI setup saves duplication of effort, and ensures that changes can easily be tested on all of the platforms. This is a project is a good thing, it ensures that FreeBSD will keep current on OpenZFS going forward, and helps improve the entire OpenZFS ecosystem. I am to give a big thanks to Matt Ahrens for organizing the monthly OpenZFS Leadership meeting, and the OpenZFS developer summit, and to Brian Behlendorf for being so helpful, and willing to work to make OpenZFS better for everyone. -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"
[A amd64->armv7 cross build shows interesting hang-up behavior as well, apparently highly repeatable for my current context.] On 2018-Dec-19, at 16:21, Mark Millard wrote: > [I attached to the hung-up process with gdb and looked around a little.] > > On 2018-Dec-19, at 13:58, Mark Millard wrote: > >> [Looks like a race or some such for devel/qt5-testlib: retry of >> poudreire-devel >> did not hang. The other hang-up seems to be repeating and I give some >> details.] >> >> On 2018-Dec-19, at 12:20, Mark Millard wrote: >> >>> FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . >>> This >>> was a rebuild based on going from perl5.26 to perl5.28 without updating the >>> ports >>> tree and from system clang 6 for the prior FreeBSD-head context used to >>> clang 7 >>> this time. (I'm not attributing causes here.) poudriere was using >>> amd64-native >>> tools for speeding up the cross-build. >>> >>> # grep -r =perl5= /etc/ ~/src.configs/ /usr/local/etc/ >>> /etc/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 >>> /usr/local/etc/poudriere.d/make.conf:DEFAULT_VERSIONS+=perl5=5.28 gcc=8 >>> >>> There was also a "print/texinfo:configure/runaway" but I've not looked into >>> it at all yet and it may be a while before I do. The other ports attempted >>> built fine as far as I can tell so far. >>> >>> >>> The devel/qt5-testlib failure looks like: >>> >>> [00:00:13] Building 123 packages using 28 builders >>> . . . >>> [00:49:30] [10] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 >>> . . . >>> [07:31:31] [10] [06:42:01] Saved devel/qt5-testlib | qt5-testlib-5.11.2 >>> wrkdir to: >>> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailCortexA57-default/default/qt5-testlib-5.11.2.tar >>> [07:31:32] [10] [06:42:02] Finished devel/qt5-testlib | qt5-testlib-5.11.2: >>> Failed: configure/runaway >>> >>> With logs/errors/qt5-testlib-5.11.2.log showing: >>> >>> Checking for POSIX monotonic clock... >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake >>> "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared >>> warn_off console single_arch" >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && MAKEFLAGS= make >>> =>> Killing runaway build after 21600 seconds with no output >>> =>> Cleaning up wrkdir >>> ===> Cleaning for qt5-testlib-5.11.2 >>> Killed >>> build of devel/qt5-testlib | qt5-testlib-5.11.2 ended at Wed Dec 19 >>> 06:45:42 PST 2018 >>> build time: 06:41:46 >>> !!! build failure encountered !!! >>> >>> >>> # less >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.log >>> . . . >>> test config.qtbase_corelib.libraries.librt succeeded >>> executing config test clock-monotonic >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/bin/qmake >>> "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared >>> warn_off console single_arch" >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> + cd >>> /wrkdirs/usr/ports/devel/qt5-testlib/work/qtbase-everywhere-src-5.11.2/config.tests/clock-monotonic >>> && MAKEFLAGS= make >>> >>> >>> Some supporting details of context: >>> >>> # uname -apKU >>> FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 >>> 16:37:42 PST 2018 >>> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG >>> amd64 amd64 135 135 >>> >>> # svnlite info /usr/ports/ | grep "Re[plv]" >>> Relative URL: ^/head >>> Repository Root: svn://svn.freebsd.org/ports >>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >>> Revision: 484783 >>> Last Changed Rev: 484783 >>> >> >> I started poudriere up again with just the 2 needing to be rebuilt (plus >> what depends on the 2). devel/qt5-testlib quickly completed just fine: >> >> [00:02:16] [02] [00:00:00] Building devel/qt5-testlib | qt5-testlib-5.11.2 >> [00:04:54] [02] [00:02:38] Finished devel/qt5-testlib | qt5-testlib-5.11.2: >> Success >> >> >> In the prior build that had the hang-ups I looked and dor print/texinfo : >> >> /wrkdirs/usr/ports/print/texinfo/work/texinfo-6.5/config.log shows for its >> hang-up: >> >> . . . >> configure:6639: checking for alloca >> configure:6676: /nxb-bin/usr/bin/cc -o conftest -O2 -pipe -mcpu=cortex-a57 >> -DLIBICONV_PLUG -g -fno-strict-aliasing -mcpu=cortex-a57 -DLIBICONV_PLUG >> -D_THREAD_SAFE conftest.c >&5 >> configure:6676: $? = 0 >> configure:6684: result: yes >> configure:6794: checking for
Re: The future of ZFS in FreeBSD
On Thu, Dec 20, 2018 at 9:33 AM Warner Losh wrote: > > > Matt, > > This is a fairly comprehensive plan. Kudos for putting it together. > > The big question here is do you have a complete list of FreeBSD-specific > changes that will be lost in the cut-over? We've heard about TRIM support and > maybe NFSv4, but are there others that can be identified? > > Once you have that list, it wouldn't be hard to throw the initial email with > some tweaks from the replies into a FCP so everybody knows the plan, and we > have it ratified in case people come along later and 'forget'. The general intent is that we not lose anything. TRIM is the only piece of code that really needs resolution upstream causing us to lose it temporarily. Failure to upstream FreeBSD's TRIM support has been a recurring source of bugs when integrating new features. As for NFSv4 I've forked the ACL bits in to the OS dependent code - I'll make a note to make sure that nothing regresses there. This is yet another example of why there will be a 3 month period for users to try the port before we cut over. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic in getblkx() booting from disc1.iso in Qemu VM
On Thu, Dec 20, 2018 at 10:33:20AM -0700, Rebecca Cran wrote: > I know booting from the cd/dvd iso worked fairly recently, but today booting > a > new build of -CURRENT in a Qemu VM resulted in a panic: > > FreeBSD 13.0-CURRENT 19a6ceb89db(HEAD) GENERIC amd64 > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT(efifb): resolution 800x600 > CPU: QEMU Virtual CPU version 2.5+ (2994.86-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x663 Family=0x6 Model=0x6 Stepping=3 > > Features=0x783fbfd > Features2=0x80002001 > AMD Features=0x20100800 > AMD Features2=0x5 > SVM: NAsids=16 > Hypervisor: Origin = "TCGTCGTCGTCG" > real memory = 8589934592 (8192 MB) > avail memory = 8227643392 (7846 MB) > > ... > > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from cd9660:/dev/iso9660/13_0_CURRENT_AMD64_DVD [ro]... > panic: bsize == 0, check bo->bo_bsize > cpuid = 0 > time = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0041189270 > vpanic() at vpanic+0x1b4/frame 0xfe00411892d0 > panic() at panic+0x43/frame 0xfe0041189330 > getblkx() at getblkx+0x807/frame 0xfe00411893f0 > breadn_flags() at breadn_flags+0x3d/frame 0xfe0041189460 > cd9660_blkatoff() at cd9660_blkatoff+0x53/frame 0xfe00411894d0 > cd9660_vget_internal() at cd9660_vget_internal+0x26b/frame 0xfe0041189550 > vfs_domount() at vfs_domount+0x7d3/frame 0xfe0041189770 > vfs_donmount() at vfs_donmount+0x7b9/frame 0xfe0041189810 > kernel_mount() at kernel_mount+0x58/frame 0xfe0041189860 > parse_mount() at parse_mount+0x469/frame 0xfe00411899a0 > vfs_mountroot() at vfs_mountroot+0x67f/frame 0xfe0041189b10 > start_init() at start_init+0x28/frame 0xfe0041189bb0 > fork_exit() at fork_exit+0x84/frame 0xfe0041189bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0041189bf0 Peter reported the same problem with ext2. I believe this is a regression from r342135, which moved a VFS_ROOT call before VFS_STATFS. For most filesystems, VFS_STATFS is the place where mp->mnt_stat is initialized, so the problem arises because mnt_stat.f_iosize is still 0 when the root vnode is initialized. UFS initializes mnt_stat.f_iosize in its VFS_MOUNT implementation, so it is immune to this problem. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AESNI, /dev/crypto, and new OpenSSL
On Thu, Dec 20, 2018 at 09:33:41AM -0800, Freddie Cash wrote: > On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev wrote: > > Had something got broken here, or I'm misunderstanding how this machinery > > now works? > > Start reading here: > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html > > That thread covers this issue. :) Along with the "fix" for it. Thanks for the pointer. I've checked both -current and -hackers MLs prior to posting, but didn't expect this would show up on -stable first. :) ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AESNI, /dev/crypto, and new OpenSSL
On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev wrote: > Had something got broken here, or I'm misunderstanding how this machinery > now works? > Start reading here: https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html That thread covers this issue. :) Along with the "fix" for it. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Panic in getblkx() booting from disc1.iso in Qemu VM
I know booting from the cd/dvd iso worked fairly recently, but today booting a new build of -CURRENT in a Qemu VM resulted in a panic: FreeBSD 13.0-CURRENT 19a6ceb89db(HEAD) GENERIC amd64 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 800x600 CPU: QEMU Virtual CPU version 2.5+ (2994.86-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x663 Family=0x6 Model=0x6 Stepping=3 Features=0x783fbfd Features2=0x80002001 AMD Features=0x20100800 AMD Features2=0x5 SVM: NAsids=16 Hypervisor: Origin = "TCGTCGTCGTCG" real memory = 8589934592 (8192 MB) avail memory = 8227643392 (7846 MB) ... WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from cd9660:/dev/iso9660/13_0_CURRENT_AMD64_DVD [ro]... panic: bsize == 0, check bo->bo_bsize cpuid = 0 time = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0041189270 vpanic() at vpanic+0x1b4/frame 0xfe00411892d0 panic() at panic+0x43/frame 0xfe0041189330 getblkx() at getblkx+0x807/frame 0xfe00411893f0 breadn_flags() at breadn_flags+0x3d/frame 0xfe0041189460 cd9660_blkatoff() at cd9660_blkatoff+0x53/frame 0xfe00411894d0 cd9660_vget_internal() at cd9660_vget_internal+0x26b/frame 0xfe0041189550 vfs_domount() at vfs_domount+0x7d3/frame 0xfe0041189770 vfs_donmount() at vfs_donmount+0x7b9/frame 0xfe0041189810 kernel_mount() at kernel_mount+0x58/frame 0xfe0041189860 parse_mount() at parse_mount+0x469/frame 0xfe00411899a0 vfs_mountroot() at vfs_mountroot+0x67f/frame 0xfe0041189b10 start_init() at start_init+0x28/frame 0xfe0041189bb0 fork_exit() at fork_exit+0x84/frame 0xfe0041189bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0041189bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 1 tid 12 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why db> -- Rebecca ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
Matt, This is a fairly comprehensive plan. Kudos for putting it together. The big question here is do you have a complete list of FreeBSD-specific changes that will be lost in the cut-over? We've heard about TRIM support and maybe NFSv4, but are there others that can be identified? Once you have that list, it wouldn't be hard to throw the initial email with some tweaks from the replies into a FCP so everybody knows the plan, and we have it ratified in case people come along later and 'forget'. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On Thu, 2018-12-20 at 08:15 -0800, Cy Schubert wrote: > I also think people will not accept regressions or other POLA > violations. +1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
AESNI, /dev/crypto, and new OpenSSL
Hi there, For many years, OpenSSL was quite vocal about which hw-accelerated algos it can use: $ uname -UK 1200058 1200058 $ openssl version OpenSSL 1.0.2n-freebsd 7 Dec 2017 $ openssl engine -c -t (cryptodev) BSD cryptodev engine [RSA, DSA, DH] <<< word count = 3 [ available ] (dynamic) Dynamic engine loading support [ unavailable ] # kldload aesni <<< loading AESNI(4) $ openssl engine -c -t (cryptodev) BSD cryptodev engine [RSA, DSA, DH, AES-128-CBC, AES-192-CBC, AES-256-CBC] <<< word count = 6 [ available ] (dynamic) Dynamic engine loading support [ unavailable ] Since recently[*], OpenSSL had switched to some new engine. Now, the output is less verbose and seemingly unaffected by the presence of the aesni.ko module (or lack thereof): $ uname -UK 135 135 $ openssl version OpenSSL 1.1.1a-freebsd 20 Nov 2018 $ openssl engine -c -t (devcrypto) /dev/crypto engine [ available ] <<< which ones??? (dynamic) Dynamic engine loading support [ unavailable ] This does not look right. Also, now the popular "openssl speed -elapsed" benchmark apparently does not use kernel AESNI support even when it is loaded, because `system' CPU load is nearly zero (previously, in presence of aesni.ko, user load would drop to zero while system load would show that it's the kernel who's doing the job). Had something got broken here, or I'm misunderstanding how this machinery now works? ./danfe [*] http://freshbsd.org/commit/freebsd/src/342009 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: The future of ZFS in FreeBSD
I suspect the idea is to contribute the FreeBSD bits back to ZoL. My question is, how much of a base does ZoL really have? The enterprise players with any significant market share won't touch it -- Ubuntu has but IMO they're a niche player (who has violated GPL by including CDDL in their kernel. The next step should be throwing up a wiki page with a features todo list. Also, this is a large enough project to have its own project branch, with the goal of having it in head before 13 goes GA. I also think people will not accept regressions or other POLA violations. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Alexey Dokuchaev Sent: 20/12/2018 06:40 To: Eugene M. Zheganin Cc: freebsd-current@freebsd.org Subject: Re: The future of ZFS in FreeBSD On Thu, Dec 20, 2018 at 03:49:38PM +0500, Eugene M. Zheganin wrote: > On 19.12.2018 23:32, Allan Jude wrote: > > The biggest thing to remember is that this is still OpenZFS, and still > > run by the same developers as it has been. We are just commonizing on > > the repo that has the most features integrated into it. > > Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because > there is no such thing in ZoL? +1. I'm also worried if this would bring more Linuxish bits into our kernel (cf. LinuxKPI). Also, I thought that ZFS was never really native to Linux but implemented through SPL (Solaris Porting Layer), and Linux' VFS is not ARC-aware unlike Solaris and FreeBSD. It would be quite upsetting to see ZFS as we know it in FreeBSD become pessimized because of those things. :-( ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: The future of ZFS in FreeBSD
We would port the feature ourselves and push the code upstream. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Eugene M. Zheganin Sent: 20/12/2018 03:12 To: freebsd-current@freebsd.org Subject: Re: The future of ZFS in FreeBSD Hello, On 19.12.2018 23:32, Allan Jude wrote: > The biggest thing to remember is that this is still OpenZFS, and still > run by the same developers as it has been. We are just commonizing on > the repo that has the most features integrated into it. Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because there is no such thing in ZoL ? Eugene. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On Thu, Dec 20, 2018 at 03:49:38PM +0500, Eugene M. Zheganin wrote: > On 19.12.2018 23:32, Allan Jude wrote: > > The biggest thing to remember is that this is still OpenZFS, and still > > run by the same developers as it has been. We are just commonizing on > > the repo that has the most features integrated into it. > > Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because > there is no such thing in ZoL? +1. I'm also worried if this would bring more Linuxish bits into our kernel (cf. LinuxKPI). Also, I thought that ZFS was never really native to Linux but implemented through SPL (Solaris Porting Layer), and Linux' VFS is not ARC-aware unlike Solaris and FreeBSD. It would be quite upsetting to see ZFS as we know it in FreeBSD become pessimized because of those things. :-( ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bind 9.12.3-P1 dies after change of IP on outbound interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lateley I realise some strange behaviour of the recent dns/bind912 port. Running named (9.12.3-P1) on a 12-STABLE gateway/router/firewall with outbound interface tun0 to our privider, named seems to crash since the last port upgrade whenver the ISP is changing the IP (using ppp with some linkup/linkdown scripts due to IPv6, nothing fancy). The last sign of live named provides is shown below: [...] Dec 20 13:22:46 <3.2> gate named[1120]: socket.c:3251: REQUIRE(sock->references == 1) failed, back trace Dec 20 13:22:46 <3.2> gate named[1120]: #0 0x2c8880 in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #1 0x4b111a in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #2 0x4e35fc in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #3 0x4e9e79 in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #4 0x35554d in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #5 0x354a2f in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #6 0x4d49fa in ?? Dec 20 13:22:46 <3.2> gate named[1120]: #7 0x800dc37c6 in ?? Dec 20 13:22:46 <3.2> gate named[1120]: exiting (due to assertion failure) Dec 20 13:46:59 <3.5> gate named[3195]: starting BIND 9.12.3-P1 Prior to the last update of dns/bind912, this router/firewall appliance was running more than a month without having such trouble, even the ISP is randomly changing the IPv4/IPv6 addresses spread over the day. What is wrong? Kind regards, O. Hartmann - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXBuVPgAKCRA4N1ZZPba5 RxB8AQDwXm7hVifhDP841aGckXLCCino95lSAtHNLoOz2nBcowD9F4lUyflB/Imq OvERuSNKeixaDDazKj6KJfNtiE8/0gU= =H6r2 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
> On 20 Dec 2018, at 11:58, Steven Hartland wrote: > > > > On 20/12/2018 11:03, Bob Bishop wrote: >> Hi, >> >>> On 19 Dec 2018, at 23:16, Matthew Macy wrote: >>> >>> On Wed, Dec 19, 2018 at 15:11 Steven Hartland >>> wrote: >>> Sorry been off for a few weeks so must have missed that, please do prod me on again if you don’t see any response to anything not just this. Like many others I get so may emails across so many lists it’s more than likely I just missed it. That said would you say that with the right support we can make progress on the this prior to the port? I have to ask as the alternative version has been on the cusp for many years now so it’s feels more like a distant memory than something that may happen, no disrespect to anyone involved, as I know all too well how hard it can be to get something like this over the line, especially when people have competing priorities. >>> I am hoping that it's sufficiently important to FreeBSD ZFS developers that >>> they'll give the PR the attention it needs so that it can be merged before >>> summer. My understanding is that it's mostly suffered from neglect. TRIM is >>> most important to FreeBSD and it already had its own implementation. >>> >>> https://github.com/zfsonlinux/zfs/pull/5925 >> Please correct me if I’m wrong but this looks a lot less mature than >> FreeBSD’s existing TRIM support for ZFS which we’ve had in production for >> six years. >> >> What is the rationale here? I’m concerned that it looks like an opportunity >> for mighty regressions. >> > This is the case, but overall this solution is thought to be a better > approach. > > With anything like this there is always a risk, so we all need a concerted > effort to get to one solution. Not sure what I can contribute, but I can certainly put a box up for testing when there’s something to test. > Regards > Steve > -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
On 20/12/2018 11:03, Bob Bishop wrote: Hi, On 19 Dec 2018, at 23:16, Matthew Macy wrote: On Wed, Dec 19, 2018 at 15:11 Steven Hartland wrote: Sorry been off for a few weeks so must have missed that, please do prod me on again if you don’t see any response to anything not just this. Like many others I get so may emails across so many lists it’s more than likely I just missed it. That said would you say that with the right support we can make progress on the this prior to the port? I have to ask as the alternative version has been on the cusp for many years now so it’s feels more like a distant memory than something that may happen, no disrespect to anyone involved, as I know all too well how hard it can be to get something like this over the line, especially when people have competing priorities. I am hoping that it's sufficiently important to FreeBSD ZFS developers that they'll give the PR the attention it needs so that it can be merged before summer. My understanding is that it's mostly suffered from neglect. TRIM is most important to FreeBSD and it already had its own implementation. https://github.com/zfsonlinux/zfs/pull/5925 Please correct me if I’m wrong but this looks a lot less mature than FreeBSD’s existing TRIM support for ZFS which we’ve had in production for six years. What is the rationale here? I’m concerned that it looks like an opportunity for mighty regressions. This is the case, but overall this solution is thought to be a better approach. With anything like this there is always a risk, so we all need a concerted effort to get to one solution. Regards Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
Hello, On 19.12.2018 23:32, Allan Jude wrote: The biggest thing to remember is that this is still OpenZFS, and still run by the same developers as it has been. We are just commonizing on the repo that has the most features integrated into it. Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because there is no such thing in ZoL ? Eugene. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Andriy Gapon changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
--- Comment #21 from commit-h...@freebsd.org ---
A commit references this bug:
Author: avg
Date: Thu Dec 20 08:45:41 UTC 2018
New revision: 342278
URL: https://svnweb.freebsd.org/changeset/base/342278
Log:
MFC r341632: acpi_{Device,Battery}IsPresent: restore pre-r330957 behaviour
Specifically, assume that the device is present if evaluation of _STA
method fails.
PR: 227191
Changes:
_U stable/12/
stable/12/sys/dev/acpica/acpi.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
Hi, > On 19 Dec 2018, at 23:16, Matthew Macy wrote: > > On Wed, Dec 19, 2018 at 15:11 Steven Hartland > wrote: > >> Sorry been off for a few weeks so must have missed that, please do prod me >> on again if you don’t see any response to anything not just this. Like many >> others I get so may emails across so many lists it’s more than likely I >> just missed it. >> >> That said would you say that with the right support we can make progress >> on the this prior to the port? I have to ask as the alternative version has >> been on the cusp for many years now so it’s feels more like a distant >> memory than something that may happen, no disrespect to anyone involved, as >> I know all too well how hard it can be to get something like this over the >> line, especially when people have competing priorities. >> > > I am hoping that it's sufficiently important to FreeBSD ZFS developers that > they'll give the PR the attention it needs so that it can be merged before > summer. My understanding is that it's mostly suffered from neglect. TRIM is > most important to FreeBSD and it already had its own implementation. > > https://github.com/zfsonlinux/zfs/pull/5925 Please correct me if I’m wrong but this looks a lot less mature than FreeBSD’s existing TRIM support for ZFS which we’ve had in production for six years. What is the rationale here? I’m concerned that it looks like an opportunity for mighty regressions. > I forwarded you the private communication again as well. > > -M > > >> >> On Wed, 19 Dec 2018 at 22:52, Matthew Macy wrote: >> >>> >>> >>> On Wed, Dec 19, 2018 at 14:47 Steven Hartland >>> wrote: >>> Thanks for the write up most appreciated. One of the more meaty differences is that FreeBSD ZFS still has the only merged and production ready TRIM support so my question would be are their any plans to address this before creating the new port as going back to a world without TRIM support wouldn’t be something I’d look forward to. >>> >>> Well, then please follow up on the request I CC'd you on a week ago >>> asking that you engage on the deadlist based TRIM PR. That's a better >>> forum for discussing these details than lamenting in public lists. >>> >>> Thanks. >>> >>> -M >>> >>> >>> >>> On Wed, 19 Dec 2018 at 06:51, Matthew Macy wrote: > The sources for FreeBSD's ZFS support are currently taken directly > from Illumos with local ifdefs to support the peculiarities of FreeBSD > where the Solaris Portability Layer (SPL) shims fall short. FreeBSD > has regularly pulled changes from Illumos and tried to push back any > bug fixes and new features done in the context of FreeBSD. In the past > few years the vast majority of new development in ZFS has taken place > in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced > that they will be moving to ZoL > https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means > that there will be little to no net new development of Illumos. While > working through the git history of ZoL I have also discovered that > many races and locking bugs have been fixed in ZoL and never made it > back to Illumos and thus FreeBSD. This state of affairs has led to a > general agreement among the stakeholders that I have spoken to that it > makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf > has graciously encouraged me to add FreeBSD support directly to ZoL > https://github.com/zfsonfreebsd/ZoF so that we might all have a single > shared code base. > > A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port > Before it can be committed some additional functionality needs to be > added to the FreeBSD opencrypto framework. These can be found at > https://reviews.freebsd.org/D18520 > > This port will provide FreeBSD users with multi modifier protection, > project quotas, encrypted datasets, allocation classes, vectorized > raidz, vectorized checksums, and various command line improvements. > > Before ZoF can be merged back in to ZoL several steps need to be taken: > - Integrate FreeBSD support into ZoL CI > - Have most of the ZFS test suite passing > - Complete additional QA testing at iX > > We at iX Systems need to port ZoL's EC2 CI scripts to work with > FreeBSD and make sure that most of the ZFS Test Suite (ZTS) passes. > Being integrated in to their CI will mean that, among other things, > most integration issues will be caught before a PR is merged upstream > rather than many months later when it is MFVed into FreeBSD. I’m > hoping to submit the PR to ZoL some time in January. > > This port will make it easy for end users on a range of releases to > run the latest version of ZFS. Nonetheless, transitioning away from an > Illumos based ZFS is not likely to be entirely seamless. The >
