From owner-freebsd-fs@freebsd.org Sun Mar 5 09:21:09 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F088BCF85BC for ; Sun, 5 Mar 2017 09:21:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFDBD13C5 for ; Sun, 5 Mar 2017 09:21:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v259L9cc093534 for ; Sun, 5 Mar 2017 09:21:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Sun, 05 Mar 2017 09:21:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: erik@nordstroem.no X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 09:21:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 --- Comment #9 from Erik Nordstr=C3=B8m --- (In reply to Conrad Meyer from comment #8) With # mount_msdosfs -L en_US.UTF-8 /dev/da1s1 /mnt/ I am able to list the files correctly indeed. $ ls -laR /mnt/PS4/SHARE/Screenshots/ total 192 drwxrwxrwx 1 root wheel 32768 Mar 5 11:15 ./ drwxrwxrwx 1 root wheel 32768 Mar 5 11:15 ../ drwxrwxrwx 1 root wheel 32768 Mar 5 11:15 Alien_ Isolation=E2=84=A2/ /mnt/PS4/SHARE/Screenshots/Alien_ Isolation=E2=84=A2: total 640 drwxrwxrwx 1 root wheel 32768 Mar 5 11:15 ./ drwxrwxrwx 1 root wheel 32768 Mar 5 11:15 ../ -rwxrwxrwx 1 root wheel 255197 Mar 5 11:15 Alien_ Isolation=E2=84=A2_20170305101454.jpg* --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Mar 5 09:26:05 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 408A2CF88B2 for ; Sun, 5 Mar 2017 09:26:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8F11654 for ; Sun, 5 Mar 2017 09:26:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v259Q4hO009855 for ; Sun, 5 Mar 2017 09:26:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Sun, 05 Mar 2017 09:26:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: erik@nordstroem.no X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 09:26:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 --- Comment #10 from Erik Nordstr=C3=B8m --- Furthermore I agree with your wondering why it doesn't respect locale setti= ngs. Building on what you said in that and other comments, I think it might be reasonable to try: 1. User defined locale as per the LANG and/or relevant LC_* env variables. 2. en_US.UTF-8 3. win-1252 4. Short names How one would determine if the right or wrong choice had been made I don't know. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Mar 5 11:01:39 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E69D4CFAB23 for ; Sun, 5 Mar 2017 11:01:39 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB1BB1E4F; Sun, 5 Mar 2017 11:01:39 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ckTur-0007mI-EP; Sun, 05 Mar 2017 12:01:29 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?Karli_Sj=C3=B6berg?= , "Gary Palmer" , "Shiva Bhanujan" Cc: "freebsd-fs@freebsd.org" , "Jeremy Faulkner" Subject: Re: FreeBSD restartable send/receive over WAN References: <0719669324a44fe0bfba3e8e08b0ae99@exch2-4.slu.se> <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12619@QLEXC01.Quorum.local> <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12ABA@QLEXC01.Quorum.local> Date: Sun, 05 Mar 2017 12:01:28 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <3A5A10BE32AC9E45B4A22F89FC90EC0701BDB12ABA@QLEXC01.Quorum.local> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: bca631f11fdfe15816789e985206fecc X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 11:01:40 -0000 On Fri, 03 Mar 2017 01:34:57 +0100, Shiva Bhanujan = wrote: > I ran the same set of tests between 2 FreeBSD instances, connected on = a = > 1G LAN. The the comms was setup using mbuffer. Here's the basic = > command. > > time zfs send -v | | mbuffer -O :8099 -b 102= 4 = > -m 128M -P 10 -q -l /tmp/mbuffer.log > mbuffer -4 -I 8099 -b 1024 -m 128M -q -l /tmp/mbuffer.log | = > | zfs recv > > Here are the results that I got. > > no compression: > real 3m18.591s > user 0m0.390s > sys 0m8.177s > > xz -0: > real 7m26.349s > user 7m6.436s > sys 0m8.471s > > pxz -0: > real 2m28.470s > user 6m44.168s > sys 0m12.002s > > gzip: > real 3m12.482s > user 3m8.260s > sys 0m4.974s > > lz4: > real 1m58.363s > user 0m10.000s > sys 0m8.708s > > > > lz4 still comes out best. Is there anything else that I might be = > missing in my tests? don't have a real setup at this time to test WAN= = > connections, but I'd like to think that these results can be = > extrapolated to a WAN link also. Uhm, in your previous test no-compression came out best. I thought you = wanted to test if sending on-disk compressed blocks over a network was a= = gain. Not a plain test of compression algoritms. As your current numbers show: the overhead of mbuffer.log is much higher= = than the overhead of compression+decompression for the lz4 case. real: = 0m29 to 1m58. (All other compressors are actually faster with mbuffer in= = between? Probably because of more efficient buffering by mbuffer.) As the overhead of mbuffer is large it is a question how much gain you g= et = from removing the extra compression step by sending the on-disk compres= sed = blocks. I guess the time would go from 1m58 to about 1m30. NB: By splitting your zfs send/receive command in two, the numbers of ti= me = can be affected. Time prints the output as soon as zfs send ends. Have fun, Ronald. > ________________________________________ > From: Ronald Klop [ronald-lists@klop.ws] > Sent: Tuesday, February 28, 2017 11:44 AM > To: Karli Sj=C3=B6berg; Gary Palmer; Shiva Bhanujan > Cc: freebsd-fs@freebsd.org; Jeremy Faulkner > Subject: Re: FreeBSD restartable send/receive over WAN > > On Tue, 28 Feb 2017 16:04:16 +0100, Shiva Bhanujan > wrote: > >> thanks for all the pointers for the compression algorithms. I ran a = few >> tests to compare compression overhead. These are local zfs >> send/receive, and no network is involved. >> >> time zfs send -v | | | zfs >> receive -s >> >> Here are the performance results that I got. >> >> no compression: >> real 0m20.892s >> user 0m0.000s >> sys 0m5.587s >> >> xz -0: >> real 8m38.569s >> user 10m28.551s >> sys 0m6.866s >> >> pxz -0: >> real 4m38.448s >> user 10m55.863s >> sys 0m13.324s >> >> gzip: >> real 3m51.297s >> user 4m12.035s >> sys 0m4.696s >> >> lz4: >> real 0m29.912s >> user 0m16.543s >> sys 0m10.810s >> >> >> lz4 has the least overhead in terms of time. pxz/xz seem to be >> prohibitive give the above results. Unless, there is something basic= >> I'm missing? >> >> I was really hoping that compressed sends would be available, as that= >> would actively eliminate this overhead, given that we use lz4 as the >> compression algorithm when writing to disks. > > > Why don't you test this with a network in between? That would give muc= h > more valuable numbers to compare for your use case. > The number above say nothing about the gain vs the bottleneck you are > trying to remove. > > Ronald. > > > > >> >> >> ________________________________ >> From: Karli Sj=C3=B6berg [karli.sjoberg@slu.se] >> Sent: Sunday, February 26, 2017 8:41 AM >> To: Gary Palmer >> Cc: Shiva Bhanujan; Jeremy Faulkner; freebsd-fs@freebsd.org >> Subject: Re: FreeBSD restartable send/receive over WAN >> >> >> Den 26 feb. 2017 4:16 em skrev Gary Palmer : >>> >>> On Sun, Feb 26, 2017 at 02:08:59PM +0000, Shiva Bhanujan wrote: >>> > The compression that we use on our ZFS filesystems is lz4. So, if= I >>> have to pipe it through a compression algorithm, that'd be >>> uncompressing and compressing it 4 times. >>> > >>> > disk (lz4) -> zfs send (uncompress) -> compress (gzip) -> (network= ) >>> -> uncompress (gzip) -> zfs recv (compress) -> disk (lz4) >>> > >>> > isn't this quite expensive? We have to transfer multi terabyte fi= les >>> on a WAN link. I'm also of the understanding that gzip by itself is= >>> single-threaded, so that'd peg one of the CPUs to 100%. there might= be >>> other compression algorithms that can be used, but sending the ZFS a= s >>> it is compressed on the filesystem is something that would be optima= l, >>> and would reduce the overhead of the additional [de]compressions tha= t >>> are taking place? >>> >>> Without going into the efficiency part of your message: >>> >>> archivers/pigz: Parallel GZIP >>> archivers/pbzip2: Parallel BZIP2 >>> archivers/pixz: Parallel, indexing version of XZ >>> archivers/pxz: Parallel LZMA compressor using liblzma >> >> Also worth mentioning is, obviously: >> archivers/lz4 >> >> :) >> >> /K >> >>> >>> Regards, >>> >>> Gary >>> >>> > >>> > ________________________________________ >>> > From: owner-freebsd-fs@freebsd.org [owner-freebsd-fs@freebsd.org] = on >>> behalf of Jeremy Faulkner [gldisater@gmail.com] >>> > Sent: Saturday, February 25, 2017 4:03 PM >>> > To: freebsd-fs@freebsd.org >>> > Subject: Re: FreeBSD restartable send/receive over WAN >>> > >>> > Pipe it through a compressor >>> > >>> > On 2017-02-25 2:09 PM, Shiva Bhanujan wrote: >>> > > Hi, >>> > > >>> > > I just tried restartable send/receive in 10.3 and it works like = a >>> charm. I was wondering if compressed send has made its way into >>> FreeBSD? I checked 10.3 and 11.0-RELEASE, and I don't see the >>> -c/--compressed option. Any pointers? >>> > > >>> > > Regards, >>> > > Shiva >>> > > >>> > > >>> > > ________________________________________ >>> > > From: owner-freebsd-fs@freebsd.org [owner-freebsd-fs@freebsd.org= ] >>> on behalf of Adam Nowacki [nowakpl@platinum.linux.pl] >>> > > Sent: Thursday, February 16, 2017 10:41 AM >>> > > To: freebsd-fs@freebsd.org >>> > > Subject: Re: FreeBSD restartable send/receive over WAN >>> > > >>> > > On 2017-02-16 19:22, Shiva Bhanujan wrote: >>> > >> Hello, >>> > >> >>> > >> I was wondering if restartable send/receive is available in >>> FreeBSD? We're running 10.2 and have a requirement of sending and >>> receiving ZFS snapshots over a WAN link. The snapshots could be mor= e >>> than a few terabytes. >>> > >> >>> > >> Can somebody please give me pointers, and if this feature is or= >>> isn't available in FreeBSD? >>> > > >>> > > FreeBSD 10.3 and later. >>> > > >>> > > _______________________________________________ >>> > > freebsd-fs@freebsd.org mailing list >>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> > > To unsubscribe, send any mail to >>> "freebsd-fs-unsubscribe@freebsd.org" >>> > > _______________________________________________ >>> > > freebsd-fs@freebsd.org mailing list >>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> > > To unsubscribe, send any mail to >>> "freebsd-fs-unsubscribe@freebsd.org" >>> > > >>> > _______________________________________________ >>> > freebsd-fs@freebsd.org mailing list >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.o= rg" >>> > _______________________________________________ >>> > freebsd-fs@freebsd.org mailing list >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.o= rg" >>> > >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org= " >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"= From owner-freebsd-fs@freebsd.org Sun Mar 5 18:02:13 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 460EBCFA7DC for ; Sun, 5 Mar 2017 18:02:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 355981F31 for ; Sun, 5 Mar 2017 18:02:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v25I2C9p001004 for ; Sun, 5 Mar 2017 18:02:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Sun, 05 Mar 2017 18:02:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: imp@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 18:02:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 Warner Losh changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imp@FreeBSD.org --- Comment #11 from Warner Losh --- There's no way for the kernel to know the locale. That's purely a userland construct. msdosfs does have a notion of how to decode things, but it has to be done at mount time. And there's likely a bug or two in the translations that's causing the issu= es that you're seeing. These bugs are likely in the MSDOSFS code. I suspect that Conrad's notion of switching to UTF-8 internally is the right way to go, but worry about compatibility. We should ask the folks that set = it to ISO-8859-1 why that specific choice, and if we can shift the interpretat= ion over to UTF-8. Eg, was iso-8859-1 just a placeholder that then got perverted into a format that Windows never produces, or was there a deeper reason... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Mar 5 21:00:37 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF723CFA650 for ; Sun, 5 Mar 2017 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A65301571 for ; Sun, 5 Mar 2017 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v25L01JA038950 for ; Sun, 5 Mar 2017 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201703052100.v25L01JA038950@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 05 Mar 2017 21:00:37 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:00:37 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic New | 217062 | for file systems mounted with -o noexec, exec=off Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 203419 | solaris assert: (dn->dn_phys->dn_nlevels == 0 && Open | 211491 | System hangs after "Uptime" on reboot with ZFS 8 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Mar 5 22:37:31 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23B08CFAF7F for ; Sun, 5 Mar 2017 22:37:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 137F516E8 for ; Sun, 5 Mar 2017 22:37:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v25MbUJh015538 for ; Sun, 5 Mar 2017 22:37:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217560] FAT32 - Time stamp of file is one hour off Date: Sun, 05 Mar 2017 22:37:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 22:37:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217560 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Mar 6 18:11:20 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4187CFB57A for ; Mon, 6 Mar 2017 18:11:20 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8322D199C for ; Mon, 6 Mar 2017 18:11:20 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by mail-it0-x233.google.com with SMTP id 203so55662323ith.0 for ; Mon, 06 Mar 2017 10:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JX/QiiFwubRnM2er4fpZB8gcgvijOOONyCzCsnBq8Pc=; b=aP1mGH94v+sB7BfQY3X3aMM/9MWLEu2SntlsftyMYx4RVnTmY1PEWgI9xLXIbyFMpp LIY/iJwo1TW+WMPBXAjkobmKsj1SkaJHos3VOeqNqkIxCjiXSJmLu3ereNDHI7pTR7Ny VY+rJAyehg5o6ewh6aoyDCBtwnp+s2wBviRic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JX/QiiFwubRnM2er4fpZB8gcgvijOOONyCzCsnBq8Pc=; b=RhY/ow442nxcYo+I1ZYgaIiYJs5IvX3itp2EopUByPkfNWAnrSuOhVkDjxXKOKpKJI wusx3CtLNp6Do9b4fmg+9+bQGZzJ4+ubjAhPfKoDgBFbSDgPTQc0PCnbmfaEQqSjSTQH mweTpvNXuXGpyDYoFF7iXPo+OldvkJsIooz7I2gCcHH8Z1r7e00p6gPFRL6+6CJa4oix NdY7ao0tsmsFQPqBwvlX2XP4ZfneqlLt3Mn5/Eojv1t3K93xyky7zG2UqwCzVulQ0nHg j4Atxm318BEER+M44G+qLAmUmh8G5IpdC8PathX2ZE5H7cIjvJ14XM8Bzs95Nsu3xI8Z jTHg== X-Gm-Message-State: AMke39k4VrVhCBuw2MFP8lKT5co+QJb4TcR9YSWFpw1YskFo2wsBmmZANpNvCvSnxv/jcpK7unX73WMxOpCJPBZT X-Received: by 10.36.59.7 with SMTP id c7mr17108316ita.43.1488823879598; Mon, 06 Mar 2017 10:11:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.27.65 with HTTP; Mon, 6 Mar 2017 10:11:19 -0800 (PST) In-Reply-To: <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> From: Matthew Ahrens Date: Mon, 6 Mar 2017 10:11:19 -0800 Message-ID: Subject: Re: 11-STABLE vs 11.0-RELENG test To: Alexander Motin Cc: freebsd-fs , Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:11:20 -0000 On Wed, Dec 7, 2016 at 5:34 AM, Alexander Motin wrote: > On 06.12.2016 22:26, Alexander Motin wrote: > > I've reproduced this issue with quick test on my lab system configured > > with 12-disk RAIDZ2 pool. I've measured write and read back (with and > > without prefetch) speeds for pool recreated on different FreeBSD head > > revisions: > > r309625 r305456 r305330 r305322 > > write 702 701 1115 1120 > > read w/ pref 232 228 518 512 > > read w/o pref 128 126 242 240 > > > > I suspect we could obtain the problem here: > > > > r305331 | mav | 2016-09-03 13:04:37 +0300 (=D1=81=D0=B1, 03 =D1=81=D0= =B5=D0=BD=D1=82. 2016) | 45 lines > > > > MFV r304155: 7090 zfs should improve allocation order and throttle > > allocations > > Closer look shown me the cause. This code sorts I/Os on time, offset > and memory address. But time on FreeBSD (to reduce overhead) returned > with 1ms resolution, so it does not provide reliable ordering. Offset > sorting used by this patch is broken by design, since io_offset field is > always zero there, since it is used only for physical I/Os, not for > logical. As result, I/Os are "sorted" on memory address, that in fact > means complete randomization of all allocations within one millisecond, > predictably killing read performance. > > Switching gethrtime() emulation from getnanouptime() to nanouptime() > fixes the read performance, resulting: > nanouptime() > write 702 > read w/ pref 845 > read w/o pref 272 > > It would be good to make offset sorting really work there rather then > just switching to high resolution time source, but that maybe quite > invasive. Will look more. FYI - I am changing this sorting to be based on the bookmark (objset, object, level, blkid) instead of timestamp. This normally doesn't change the performance on illumos, but it should fix this on FreeBSD (and it ensures that the multi-threaded spa_sync doesn't degrade performance). Here's the PR; you can pick out the "sort by bookmark" commit if you want: https://github.com/openzfs/openzfs/pull/138 --matt From owner-freebsd-fs@freebsd.org Mon Mar 6 18:52:42 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D72DECFC6B6 for ; Mon, 6 Mar 2017 18:52:42 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1E81818; Mon, 6 Mar 2017 18:52:42 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id g70so12585164lfh.3; Mon, 06 Mar 2017 10:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0fHJLbvLeR5i1dw8OzOFlFz9XzIrrQgGkqvDMLSAtes=; b=QZCIzJdtLvivpi3cRaG+2J9sv0IntiPzjkfCGAn6HE6UUZL/6vQesYi98KePIhPK9B 5zJZAMq77PRfEllPggWJ8p0n3kyLPjCNvtmkAFPfNCNtt1NU7ZJeq54rp3PfXLnlFYi7 b55xLqQ1jAyOorkoF+t8t0VEtmXuyWzJcQyeUVz3xXkkXsAWeoSm3OKrywSaFxMFzJ8S pKD5ar9lVHA9kCNRADYbAhIh9JJGoZbIAQt3n6NKEjLgRZjIKTyvNy9C1h4H7N/MT9rT /qES6o+wJUmUMSpXIhw543ksBN3cIA4OsWUK9HiIwfd4lEQvHqG5DJsD3cW2P7Tl8qoV 0iFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0fHJLbvLeR5i1dw8OzOFlFz9XzIrrQgGkqvDMLSAtes=; b=WBg/Y+H6R1WW679CEUSDK9o1PkUIiuFxAY1j53UdTmDVjOb+5fK5IlpuR4DjUflpjB 2JNszEmGTuSU0Bkijejc6MqBCYEuiRv3L9ian7ERiodL6qaMRILL3ZVHUXTq/qy90S3U XwzLAQwBf6l/8EhBi+0vMmn1186V+g36YuDIz3VYjfTUaJRTDphMt/4K1uhnEUA4EY96 yD4y2ip9tqNpGU93JKnMS2zoA3uN3x3e3d5MkEWQv1WGy26+qoneTA8ADmrSWeLFLxH9 kq7J0UVAMd6bXc7N3NB/GEBdFYnUe52ITk++AKSZBw1csAyaV/4XlyEfw/EPlH903taY PgGA== X-Gm-Message-State: AMke39l8GkmG72rdQYccBr4rrQeHsG34i10j16jaNDuFhivVuRyPxVf6eLIv/tzBX15Ibg== X-Received: by 10.46.20.27 with SMTP id u27mr5853399ljd.103.1488826360606; Mon, 06 Mar 2017 10:52:40 -0800 (PST) Received: from spectre.mavhome.dp.ua ([134.249.139.101]) by smtp.gmail.com with ESMTPSA id p27sm2354409lfg.5.2017.03.06.10.52.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 10:52:39 -0800 (PST) Sender: Alexander Motin Subject: Re: 11-STABLE vs 11.0-RELENG test To: Matthew Ahrens References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> Cc: freebsd-fs , Andriy Gapon From: Alexander Motin Message-ID: Date: Mon, 6 Mar 2017 20:52:38 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:52:42 -0000 On 06.03.2017 20:11, Matthew Ahrens wrote: > FYI - I am changing this sorting to be based on the bookmark (objset, > object, level, blkid) instead of timestamp. This normally doesn't > change the performance on illumos, but it should fix this on FreeBSD > (and it ensures that the multi-threaded spa_sync doesn't degrade > performance). > > Here's the PR; you can pick out the "sort by bookmark" commit if you want: > > https://github.com/openzfs/openzfs/pull/138 Thank you for the notice, but we already have alike patch in a tree for few months to address the mentioned issue: https://svnweb.freebsd.org/base?view=revision&revision=309714 We'll just replace one patch with another when yours comes in to reduce the code divergence. -- Alexander Motin From owner-freebsd-fs@freebsd.org Tue Mar 7 05:26:39 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58950D0139E for ; Tue, 7 Mar 2017 05:26:39 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1F1215A9; Tue, 7 Mar 2017 05:26:38 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 465C87E8FF; Tue, 7 Mar 2017 16:26:28 +1100 (EST) Subject: Re: svn commit: r308089 - in head To: Andriy Gapon References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> Cc: freebsd-fs@freebsd.org, Toomas Soome From: Lawrence Stewart Message-ID: Date: Tue, 7 Mar 2017 16:25:23 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <201610291409.u9TE9WXJ020650@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 05:26:39 -0000 Hi Andriy, On 30/10/2016 01:09, Andriy Gapon wrote: > Author: avg > Date: Sat Oct 29 14:09:32 2016 > New Revision: 308089 > URL: https://svnweb.freebsd.org/changeset/base/308089 > > Log: > zfsbootcfg: a simple tool to set next boot (one time) options for zfsboot > > (gpt)zfsboot will read one-time boot directives from a special ZFS pool > area. The area was previously described as "Boot Block Header", but > currently it is know as Pad2, marked as reserved and is zeroed out on > pool creation. The new code interprets data in this area, if any, using > the same format as boot.config. The area is immediately wiped out. > Failure to parse the directives results in a reboot right after the > cleanup. Otherwise the boot sequence proceeds as usual. > > zfsbootcfg writes zfsboot arguments specified on its command line to the > Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and > vfs.zfs.boot.primary_vdev kenv variables that are set by loader during > boot. Please see the manual page for more. > > Thanks to all who reviewed, contributed and made suggestions! There are > many potential improvements to the feature, please see the review for > details. > > Reviewed by: wblock (docs) > Discussed with: jhb, tsoome > MFC after: 3 weeks > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D7612 > > Added: > head/sbin/zfsbootcfg/ > head/sbin/zfsbootcfg/Makefile (contents, props changed) > head/sbin/zfsbootcfg/zfsbootcfg.8 (contents, props changed) > head/sbin/zfsbootcfg/zfsbootcfg.c (contents, props changed) > Modified: > head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h > head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c > head/sbin/Makefile > head/sys/boot/i386/common/drv.c > head/sys/boot/i386/common/drv.h > head/sys/boot/i386/gptzfsboot/Makefile > head/sys/boot/i386/zfsboot/Makefile > head/sys/boot/i386/zfsboot/zfsboot.c > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h > [snip] > @@ -634,7 +712,39 @@ main(void) > primary_spa = spa; > primary_vdev = spa_get_primary_vdev(spa); > > - if (zfs_spa_init(spa) != 0 || zfs_mount(spa, 0, &zfsmount) != 0) { > + nextboot = 0; > + rc = vdev_read_pad2(primary_vdev, cmd, sizeof(cmd)); > + if (vdev_clear_pad2(primary_vdev)) > + printf("failed to clear pad2 area of primary vdev\n"); > + if (rc == 0) { > + if (*cmd) { > + /* > + * We could find an old-style ZFS Boot Block header here. > + * Simply ignore it. > + */ > + if (*(uint64_t *)cmd != 0x2f5b007b10c) { > + /* > + * Note that parse() is destructive to cmd[] and we also want > + * to honor RBX_QUIET option that could be present in cmd[]. > + */ > + nextboot = 1; > + memcpy(cmddup, cmd, sizeof(cmd)); > + if (parse()) { > + printf("failed to parse pad2 area of primary vdev\n"); > + reboot(); > + } > + if (!OPT_CHECK(RBX_QUIET)) > + printf("zfs nextboot: %s\n", cmddup); > + } > + /* Do not process this command twice */ > + *cmd = 0; > + } > + } else > + printf("failed to read pad2 area of primary vdev\n"); > + I've just taken Allan Jude's & co-conspirators' work for a spin that allows gptzfsboot to boot from a geli + ZFS partition. Everything is working amazingly well, but I see the above "failed to read pad2 area of primary vdev" message on every boot. It doesn't appear to cause any problems per se and the system boots/works fine. I assume that message is printed to signal an unexpected situation though, so figured I'd get in touch to get your thoughts. I installed the KVM-based virtual machine system manually from the live shell of: FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso The partitioning is very simple: gpart create -s gpt /dev/vtbd0 gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 gpart add -t freebsd-zfs -b 2088 vtbd0 root# gpart show => 40 83886000 vtbd0 GPT (40G) 40 1024 1 freebsd-boot (512K) 1064 1024 - free - (512K) 2088 83883952 2 freebsd-zfs (40G) geli was inited/attached to vtbd0p2 and the zpool was created with command: zpool create -o altroot=/tmp/zroot -o cachefile=/tmp/zpool.cache -O checksum=skein -O compression=lz4 vtbd0p2.eli i.e. the entire pool including bootfs is using skein for checksumming and lz4 for compression. I hit another boot bug using skein previously which Toomas (CCed) fixed, and am wondering if this issue might also be related to the skein implementation. I haven't tested if the zfsbootcfg functionality works for fear that the printf is indicating a low level problem with the zpool. I can test potentially destructive things and break the pool though if that would be helpful. Any thoughts? Cheers, Lawrence From owner-freebsd-fs@freebsd.org Tue Mar 7 08:04:41 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0355D01591 for ; Tue, 7 Mar 2017 08:04:41 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E4A61187; Tue, 7 Mar 2017 08:04:41 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OMF00A00NN15X00@st13p35im-asmtp002.me.com>; Tue, 07 Mar 2017 07:04:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1488870273; bh=UWl4GDb6XiYLEWSgjeGhRFsUnb6MDrMU7R1ZdKLrwxY=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=AokUI6kY63JcUOTC4ZgraUy1xdampHbGR1RigHan4/30tOP+mqq9xQqFD/p6AHQCy tj6PgPpTOaeNDH8hH3IinBkD/qJQWWDYSJny4gijCscNsK99dGUnF1Ye2loT64HOaP uFgFkPD0YNq7kxPs2nyjN/c9kRrq9ox6bzQaaoJB2UeL19JuZ003Gmf7lYmXJNSlzC LSUyBo+Up3XGDkiUr6ZbpIce2JuvkH8ei+T1vLfIKAtEHnkpXK7XALjVEn+CbwYW+o xZAr1LSfMvuYL6qOZOg+SufIZje1/jCkALX92Acco87khyUQb2tSn+F1SLkYAcq5E6 0jq/VKoHsgTXg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OMF006FKNNI6300@st13p35im-asmtp002.me.com>; Tue, 07 Mar 2017 07:04:33 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-07_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703070061 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: svn commit: r308089 - in head From: Toomas Soome In-reply-to: Date: Tue, 07 Mar 2017 09:04:29 +0200 Cc: Andriy Gapon , freebsd-fs@freebsd.org, Toomas Soome Content-transfer-encoding: quoted-printable Message-id: References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> To: Lawrence Stewart X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 08:04:41 -0000 > On 7. m=C3=A4rts 2017, at 7:25, Lawrence Stewart = wrote: >=20 > Hi Andriy, >=20 > On 30/10/2016 01:09, Andriy Gapon wrote: >> Author: avg >> Date: Sat Oct 29 14:09:32 2016 >> New Revision: 308089 >> URL: https://svnweb.freebsd.org/changeset/base/308089 >>=20 >> Log: >> zfsbootcfg: a simple tool to set next boot (one time) options for = zfsboot >>=20 >> (gpt)zfsboot will read one-time boot directives from a special ZFS = pool >> area. The area was previously described as "Boot Block Header", but >> currently it is know as Pad2, marked as reserved and is zeroed out = on >> pool creation. The new code interprets data in this area, if any, = using >> the same format as boot.config. The area is immediately wiped out. >> Failure to parse the directives results in a reboot right after the >> cleanup. Otherwise the boot sequence proceeds as usual. >>=20 >> zfsbootcfg writes zfsboot arguments specified on its command line to = the >> Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and >> vfs.zfs.boot.primary_vdev kenv variables that are set by loader = during >> boot. Please see the manual page for more. >>=20 >> Thanks to all who reviewed, contributed and made suggestions! There = are >> many potential improvements to the feature, please see the review = for >> details. >>=20 >> Reviewed by: wblock (docs) >> Discussed with: jhb, tsoome >> MFC after: 3 weeks >> Relnotes: yes >> Differential Revision: https://reviews.freebsd.org/D7612 >>=20 >> Added: >> head/sbin/zfsbootcfg/ >> head/sbin/zfsbootcfg/Makefile (contents, props changed) >> head/sbin/zfsbootcfg/zfsbootcfg.8 (contents, props changed) >> head/sbin/zfsbootcfg/zfsbootcfg.c (contents, props changed) >> Modified: >> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h >> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c >> head/sbin/Makefile >> head/sys/boot/i386/common/drv.c >> head/sys/boot/i386/common/drv.h >> head/sys/boot/i386/gptzfsboot/Makefile >> head/sys/boot/i386/zfsboot/Makefile >> head/sys/boot/i386/zfsboot/zfsboot.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c >> head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h >>=20 > [snip] >> @@ -634,7 +712,39 @@ main(void) >> primary_spa =3D spa; >> primary_vdev =3D spa_get_primary_vdev(spa); >>=20 >> - if (zfs_spa_init(spa) !=3D 0 || zfs_mount(spa, 0, &zfsmount) !=3D = 0) { >> + nextboot =3D 0; >> + rc =3D vdev_read_pad2(primary_vdev, cmd, sizeof(cmd)); >> + if (vdev_clear_pad2(primary_vdev)) >> + printf("failed to clear pad2 area of primary vdev\n"); >> + if (rc =3D=3D 0) { >> + if (*cmd) { >> + /* >> + * We could find an old-style ZFS Boot Block header here. >> + * Simply ignore it. >> + */ >> + if (*(uint64_t *)cmd !=3D 0x2f5b007b10c) { >> + /* >> + * Note that parse() is destructive to cmd[] and we also = want >> + * to honor RBX_QUIET option that could be present in = cmd[]. >> + */ >> + nextboot =3D 1; >> + memcpy(cmddup, cmd, sizeof(cmd)); >> + if (parse()) { >> + printf("failed to parse pad2 area of primary = vdev\n"); >> + reboot(); >> + } >> + if (!OPT_CHECK(RBX_QUIET)) >> + printf("zfs nextboot: %s\n", cmddup); >> + } >> + /* Do not process this command twice */ >> + *cmd =3D 0; >> + } >> + } else >> + printf("failed to read pad2 area of primary vdev\n"); >> + >=20 > I've just taken Allan Jude's & co-conspirators' work for a spin that > allows gptzfsboot to boot from a geli + ZFS partition. Everything is > working amazingly well, but I see the above "failed to read pad2 area = of > primary vdev" message on every boot. >=20 > It doesn't appear to cause any problems per se and the system > boots/works fine. I assume that message is printed to signal an > unexpected situation though, so figured I'd get in touch to get your > thoughts. >=20 >=20 >=20 > I installed the KVM-based virtual machine system manually from the = live > shell of: >=20 > FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso >=20 >=20 >=20 > The partitioning is very simple: >=20 > gpart create -s gpt /dev/vtbd0 > gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 > gpart add -t freebsd-zfs -b 2088 vtbd0 >=20 > root# gpart show > =3D> 40 83886000 vtbd0 GPT (40G) > 40 1024 1 freebsd-boot (512K) > 1064 1024 - free - (512K) > 2088 83883952 2 freebsd-zfs (40G) >=20 >=20 >=20 > geli was inited/attached to vtbd0p2 and the zpool was created with = command: >=20 > zpool create -o altroot=3D/tmp/zroot -o cachefile=3D/tmp/zpool.cache = -O > checksum=3Dskein -O compression=3Dlz4 vtbd0p2.eli >=20 > i.e. the entire pool including bootfs is using skein for checksumming > and lz4 for compression. >=20 >=20 >=20 > I hit another boot bug using skein previously which Toomas (CCed) = fixed, > and am wondering if this issue might also be related to the skein > implementation. >=20 > I haven't tested if the zfsbootcfg functionality works for fear that = the > printf is indicating a low level problem with the zpool. I can test > potentially destructive things and break the pool though if that would > be helpful. >=20 > Any thoughts? >=20 > Cheers, > Lawrence The problem with having pool on geli encrypted partition is that all the = reads done on such partition, gave to go through geli aware read() = function, and the same is true for writes (which is important for = nextboot feature). So what it means for gptzfsboot/zfsboot is that we = would need to have the disk reads/writes go through the geli aware = functions and we can not issue =E2=80=9Cpure=E2=80=9D disk io directly. rgds, toomas From owner-freebsd-fs@freebsd.org Tue Mar 7 08:26:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AF75D01B10 for ; Tue, 7 Mar 2017 08:26:54 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91A531CCF; Tue, 7 Mar 2017 08:26:53 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id C5B687E918; Tue, 7 Mar 2017 19:26:48 +1100 (EST) Subject: Re: svn commit: r308089 - in head To: Toomas Soome References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> Cc: Andriy Gapon , freebsd-fs@freebsd.org, Toomas Soome , allanjude@freebsd.org From: Lawrence Stewart Message-ID: <9f0b2f93-04b8-b90b-3cb5-13b8539b9171@freebsd.org> Date: Tue, 7 Mar 2017 19:25:43 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 08:26:54 -0000 On 07/03/2017 18:04, Toomas Soome wrote: > >> On 7. märts 2017, at 7:25, Lawrence Stewart wrote: >> >> Hi Andriy, >> >> On 30/10/2016 01:09, Andriy Gapon wrote: >>> Author: avg >>> Date: Sat Oct 29 14:09:32 2016 >>> New Revision: 308089 >>> URL: https://svnweb.freebsd.org/changeset/base/308089 >>> >>> Log: >>> zfsbootcfg: a simple tool to set next boot (one time) options for zfsboot >>> >>> (gpt)zfsboot will read one-time boot directives from a special ZFS pool >>> area. The area was previously described as "Boot Block Header", but >>> currently it is know as Pad2, marked as reserved and is zeroed out on >>> pool creation. The new code interprets data in this area, if any, using >>> the same format as boot.config. The area is immediately wiped out. >>> Failure to parse the directives results in a reboot right after the >>> cleanup. Otherwise the boot sequence proceeds as usual. >>> >>> zfsbootcfg writes zfsboot arguments specified on its command line to the >>> Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and >>> vfs.zfs.boot.primary_vdev kenv variables that are set by loader during >>> boot. Please see the manual page for more. >>> >>> Thanks to all who reviewed, contributed and made suggestions! There are >>> many potential improvements to the feature, please see the review for >>> details. >>> >>> Reviewed by: wblock (docs) >>> Discussed with: jhb, tsoome >>> MFC after: 3 weeks >>> Relnotes: yes >>> Differential Revision: https://reviews.freebsd.org/D7612 >>> >>> Added: >>> head/sbin/zfsbootcfg/ >>> head/sbin/zfsbootcfg/Makefile (contents, props changed) >>> head/sbin/zfsbootcfg/zfsbootcfg.8 (contents, props changed) >>> head/sbin/zfsbootcfg/zfsbootcfg.c (contents, props changed) >>> Modified: >>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h >>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c >>> head/sbin/Makefile >>> head/sys/boot/i386/common/drv.c >>> head/sys/boot/i386/common/drv.h >>> head/sys/boot/i386/gptzfsboot/Makefile >>> head/sys/boot/i386/zfsboot/Makefile >>> head/sys/boot/i386/zfsboot/zfsboot.c >>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h >>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c >>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c >>> head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h >>> >> [snip] >>> @@ -634,7 +712,39 @@ main(void) >>> primary_spa = spa; >>> primary_vdev = spa_get_primary_vdev(spa); >>> >>> - if (zfs_spa_init(spa) != 0 || zfs_mount(spa, 0, &zfsmount) != 0) { >>> + nextboot = 0; >>> + rc = vdev_read_pad2(primary_vdev, cmd, sizeof(cmd)); >>> + if (vdev_clear_pad2(primary_vdev)) >>> + printf("failed to clear pad2 area of primary vdev\n"); >>> + if (rc == 0) { >>> + if (*cmd) { >>> + /* >>> + * We could find an old-style ZFS Boot Block header here. >>> + * Simply ignore it. >>> + */ >>> + if (*(uint64_t *)cmd != 0x2f5b007b10c) { >>> + /* >>> + * Note that parse() is destructive to cmd[] and we also want >>> + * to honor RBX_QUIET option that could be present in cmd[]. >>> + */ >>> + nextboot = 1; >>> + memcpy(cmddup, cmd, sizeof(cmd)); >>> + if (parse()) { >>> + printf("failed to parse pad2 area of primary vdev\n"); >>> + reboot(); >>> + } >>> + if (!OPT_CHECK(RBX_QUIET)) >>> + printf("zfs nextboot: %s\n", cmddup); >>> + } >>> + /* Do not process this command twice */ >>> + *cmd = 0; >>> + } >>> + } else >>> + printf("failed to read pad2 area of primary vdev\n"); >>> + >> >> I've just taken Allan Jude's & co-conspirators' work for a spin that >> allows gptzfsboot to boot from a geli + ZFS partition. Everything is >> working amazingly well, but I see the above "failed to read pad2 area of >> primary vdev" message on every boot. >> >> It doesn't appear to cause any problems per se and the system >> boots/works fine. I assume that message is printed to signal an >> unexpected situation though, so figured I'd get in touch to get your >> thoughts. >> >> >> >> I installed the KVM-based virtual machine system manually from the live >> shell of: >> >> FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso >> >> >> >> The partitioning is very simple: >> >> gpart create -s gpt /dev/vtbd0 >> gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 >> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 >> gpart add -t freebsd-zfs -b 2088 vtbd0 >> >> root# gpart show >> => 40 83886000 vtbd0 GPT (40G) >> 40 1024 1 freebsd-boot (512K) >> 1064 1024 - free - (512K) >> 2088 83883952 2 freebsd-zfs (40G) >> >> >> >> geli was inited/attached to vtbd0p2 and the zpool was created with command: >> >> zpool create -o altroot=/tmp/zroot -o cachefile=/tmp/zpool.cache -O >> checksum=skein -O compression=lz4 vtbd0p2.eli >> >> i.e. the entire pool including bootfs is using skein for checksumming >> and lz4 for compression. >> >> >> >> I hit another boot bug using skein previously which Toomas (CCed) fixed, >> and am wondering if this issue might also be related to the skein >> implementation. >> >> I haven't tested if the zfsbootcfg functionality works for fear that the >> printf is indicating a low level problem with the zpool. I can test >> potentially destructive things and break the pool though if that would >> be helpful. >> >> Any thoughts? >> >> Cheers, >> Lawrence > > > The problem with having pool on geli encrypted partition is that all the reads done on such partition, gave to go through geli aware read() function, and the same is true for writes (which is important for nextboot feature). So what it means for gptzfsboot/zfsboot is that we would need to have the disk reads/writes go through the geli aware functions and we can not issue “pure” disk io directly. [+Allan] Presumably that functionality exists given that the geli support Allan added to gptzfsboot is able to read loader and loader is able to read everything in /boot from the geli-encrypted ZFS pool? From owner-freebsd-fs@freebsd.org Tue Mar 7 08:48:22 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49627CFA0A6 for ; Tue, 7 Mar 2017 08:48:22 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C6BC15E3; Tue, 7 Mar 2017 08:48:22 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OMF00A00SGD8D00@st13p35im-asmtp002.me.com>; Tue, 07 Mar 2017 08:48:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1488876500; bh=MGl6ufMZiRlsU6CqLJr1PNRrJe/PNq1ZDWVDDRW6raA=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=OcK/3+ozSiiKfmRus9OiCVbA3JkTUC7EN0cnsdO6U3TEYheVa5W30M9Rz1zUh8D/R tlcfxMlKWd6rhxhET3+ceJIBwZ5PDHNPOYHkPrSFswexoHpAdZbStcnKsJ1jj+UB0T 4yiEnELKmpLX+1gVnT6WxYEFVspV+6QurnPAgKexVGjepsdLGpFA4+HdH1v1XtAdiN PjVT7MOwKs9IPkTdzNL0NEeTS3mIt4+uy472ZPwTS2l+oeCH0Vkfg4cIOS8p7N5Sz+ gMFLdsdOvqTnd/kWkPMhS2z2+e6++v7GZjNfH2FAHC6MqGUKtIolqcfB+J61iYAc0h Q/PSTeNRBoi7w== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OMF00OIWSGHCJ40@st13p35im-asmtp002.me.com>; Tue, 07 Mar 2017 08:48:20 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-07_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703070076 From: Toomas Soome Message-id: <814E1C65-23E3-42A1-8093-8008DF188506@me.com> MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: svn commit: r308089 - in head Date: Tue, 07 Mar 2017 10:48:16 +0200 In-reply-to: <9f0b2f93-04b8-b90b-3cb5-13b8539b9171@freebsd.org> Cc: Andriy Gapon , freebsd-fs@freebsd.org, Toomas Soome , allanjude@freebsd.org To: Lawrence Stewart References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> <9f0b2f93-04b8-b90b-3cb5-13b8539b9171@freebsd.org> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 08:48:22 -0000 > On 7. m=C3=A4rts 2017, at 10:25, Lawrence Stewart = wrote: >=20 > On 07/03/2017 18:04, Toomas Soome wrote: >>=20 >>> On 7. m=C3=A4rts 2017, at 7:25, Lawrence Stewart = wrote: >>>=20 >>> Hi Andriy, >>>=20 >>> On 30/10/2016 01:09, Andriy Gapon wrote: >>>> Author: avg >>>> Date: Sat Oct 29 14:09:32 2016 >>>> New Revision: 308089 >>>> URL: https://svnweb.freebsd.org/changeset/base/308089 >>>>=20 >>>> Log: >>>> zfsbootcfg: a simple tool to set next boot (one time) options for = zfsboot >>>>=20 >>>> (gpt)zfsboot will read one-time boot directives from a special ZFS = pool >>>> area. The area was previously described as "Boot Block Header", = but >>>> currently it is know as Pad2, marked as reserved and is zeroed out = on >>>> pool creation. The new code interprets data in this area, if any, = using >>>> the same format as boot.config. The area is immediately wiped out. >>>> Failure to parse the directives results in a reboot right after the >>>> cleanup. Otherwise the boot sequence proceeds as usual. >>>>=20 >>>> zfsbootcfg writes zfsboot arguments specified on its command line = to the >>>> Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and >>>> vfs.zfs.boot.primary_vdev kenv variables that are set by loader = during >>>> boot. Please see the manual page for more. >>>>=20 >>>> Thanks to all who reviewed, contributed and made suggestions! = There are >>>> many potential improvements to the feature, please see the review = for >>>> details. >>>>=20 >>>> Reviewed by: wblock (docs) >>>> Discussed with: jhb, tsoome >>>> MFC after: 3 weeks >>>> Relnotes: yes >>>> Differential Revision: https://reviews.freebsd.org/D7612 >>>>=20 >>>> Added: >>>> head/sbin/zfsbootcfg/ >>>> head/sbin/zfsbootcfg/Makefile (contents, props changed) >>>> head/sbin/zfsbootcfg/zfsbootcfg.8 (contents, props changed) >>>> head/sbin/zfsbootcfg/zfsbootcfg.c (contents, props changed) >>>> Modified: >>>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h >>>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c >>>> head/sbin/Makefile >>>> head/sys/boot/i386/common/drv.c >>>> head/sys/boot/i386/common/drv.h >>>> head/sys/boot/i386/gptzfsboot/Makefile >>>> head/sys/boot/i386/zfsboot/Makefile >>>> head/sys/boot/i386/zfsboot/zfsboot.c >>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h >>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c >>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c >>>> head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h >>>>=20 >>> [snip] >>>> @@ -634,7 +712,39 @@ main(void) >>>> primary_spa =3D spa; >>>> primary_vdev =3D spa_get_primary_vdev(spa); >>>>=20 >>>> - if (zfs_spa_init(spa) !=3D 0 || zfs_mount(spa, 0, &zfsmount) = !=3D 0) { >>>> + nextboot =3D 0; >>>> + rc =3D vdev_read_pad2(primary_vdev, cmd, sizeof(cmd)); >>>> + if (vdev_clear_pad2(primary_vdev)) >>>> + printf("failed to clear pad2 area of primary vdev\n"); >>>> + if (rc =3D=3D 0) { >>>> + if (*cmd) { >>>> + /* >>>> + * We could find an old-style ZFS Boot Block header here. >>>> + * Simply ignore it. >>>> + */ >>>> + if (*(uint64_t *)cmd !=3D 0x2f5b007b10c) { >>>> + /* >>>> + * Note that parse() is destructive to cmd[] and we also = want >>>> + * to honor RBX_QUIET option that could be present in = cmd[]. >>>> + */ >>>> + nextboot =3D 1; >>>> + memcpy(cmddup, cmd, sizeof(cmd)); >>>> + if (parse()) { >>>> + printf("failed to parse pad2 area of primary = vdev\n"); >>>> + reboot(); >>>> + } >>>> + if (!OPT_CHECK(RBX_QUIET)) >>>> + printf("zfs nextboot: %s\n", cmddup); >>>> + } >>>> + /* Do not process this command twice */ >>>> + *cmd =3D 0; >>>> + } >>>> + } else >>>> + printf("failed to read pad2 area of primary vdev\n"); >>>> + >>>=20 >>> I've just taken Allan Jude's & co-conspirators' work for a spin that >>> allows gptzfsboot to boot from a geli + ZFS partition. Everything is >>> working amazingly well, but I see the above "failed to read pad2 = area of >>> primary vdev" message on every boot. >>>=20 >>> It doesn't appear to cause any problems per se and the system >>> boots/works fine. I assume that message is printed to signal an >>> unexpected situation though, so figured I'd get in touch to get your >>> thoughts. >>>=20 >>>=20 >>>=20 >>> I installed the KVM-based virtual machine system manually from the = live >>> shell of: >>>=20 >>> FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso >>>=20 >>>=20 >>>=20 >>> The partitioning is very simple: >>>=20 >>> gpart create -s gpt /dev/vtbd0 >>> gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 >>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 >>> gpart add -t freebsd-zfs -b 2088 vtbd0 >>>=20 >>> root# gpart show >>> =3D> 40 83886000 vtbd0 GPT (40G) >>> 40 1024 1 freebsd-boot (512K) >>> 1064 1024 - free - (512K) >>> 2088 83883952 2 freebsd-zfs (40G) >>>=20 >>>=20 >>>=20 >>> geli was inited/attached to vtbd0p2 and the zpool was created with = command: >>>=20 >>> zpool create -o altroot=3D/tmp/zroot -o cachefile=3D/tmp/zpool.cache = -O >>> checksum=3Dskein -O compression=3Dlz4 vtbd0p2.eli >>>=20 >>> i.e. the entire pool including bootfs is using skein for = checksumming >>> and lz4 for compression. >>>=20 >>>=20 >>>=20 >>> I hit another boot bug using skein previously which Toomas (CCed) = fixed, >>> and am wondering if this issue might also be related to the skein >>> implementation. >>>=20 >>> I haven't tested if the zfsbootcfg functionality works for fear that = the >>> printf is indicating a low level problem with the zpool. I can test >>> potentially destructive things and break the pool though if that = would >>> be helpful. >>>=20 >>> Any thoughts? >>>=20 >>> Cheers, >>> Lawrence >>=20 >>=20 >> The problem with having pool on geli encrypted partition is that all = the reads done on such partition, gave to go through geli aware read() = function, and the same is true for writes (which is important for = nextboot feature). So what it means for gptzfsboot/zfsboot is that we = would need to have the disk reads/writes go through the geli aware = functions and we can not issue =E2=80=9Cpure=E2=80=9D disk io directly. >=20 > [+Allan] >=20 > Presumably that functionality exists given that the geli support Allan > added to gptzfsboot is able to read loader and loader is able to read > everything in /boot from the geli-encrypted ZFS pool? The problem is deeper, the idea behind the nextboot is that it is = attempting to provide recovery from failed boot, so if you set nextboot = dataset, attempt to boot from it, you need to do 2 things: 1. detect the = nextboot config, so you would actually be able to use it, and 2, you = want to reset it as early as possible, because later you may not have a = chance. So it means the gptzfsboot has to read out the config to know where from = it has to load the zfsloader, and gptzfsboot has to reset the config, so = that if anything will go wrong, on next boot the fallback or = =E2=80=9Cnormal=E2=80=9D boot will be done. Which means that either = gptzfsboot has to know how to deal with geli in context of handling = nextboot, or with geli, you just can not use nextboot config. The similar issue is with using boot block area in zfs pool label - to = be able to store and use gptzfsboot in pool label boot area, the boot1 = either has to know how to read the geli, or geli must be able not to = encrypt the bootblock area, or we just can not use that area [with = geli]. All in all, it is another example of the chicken and the egg = issue:) rgds, toomas= From owner-freebsd-fs@freebsd.org Tue Mar 7 09:01:53 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82AB4CFAAFE for ; Tue, 7 Mar 2017 09:01:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8081191; Tue, 7 Mar 2017 09:01:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA10027; Tue, 07 Mar 2017 11:01:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1clB0A-000FUd-0g; Tue, 07 Mar 2017 11:01:50 +0200 Subject: Re: svn commit: r308089 - in head To: Lawrence Stewart References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> Cc: freebsd-fs@FreeBSD.org, Toomas Soome From: Andriy Gapon Message-ID: Date: Tue, 7 Mar 2017 11:00:54 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:01:53 -0000 On 07/03/2017 07:25, Lawrence Stewart wrote: > I've just taken Allan Jude's & co-conspirators' work for a spin that > allows gptzfsboot to boot from a geli + ZFS partition. Everything is > working amazingly well, but I see the above "failed to read pad2 area of > primary vdev" message on every boot. > > It doesn't appear to cause any problems per se and the system > boots/works fine. I assume that message is printed to signal an > unexpected situation though, so figured I'd get in touch to get your > thoughts. > > > > I installed the KVM-based virtual machine system manually from the live > shell of: > > FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso > > > > The partitioning is very simple: > > gpart create -s gpt /dev/vtbd0 > gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 > gpart add -t freebsd-zfs -b 2088 vtbd0 > > root# gpart show > => 40 83886000 vtbd0 GPT (40G) > 40 1024 1 freebsd-boot (512K) > 1064 1024 - free - (512K) > 2088 83883952 2 freebsd-zfs (40G) > > > > geli was inited/attached to vtbd0p2 and the zpool was created with command: > > zpool create -o altroot=/tmp/zroot -o cachefile=/tmp/zpool.cache -O > checksum=skein -O compression=lz4 vtbd0p2.eli > > i.e. the entire pool including bootfs is using skein for checksumming > and lz4 for compression. > > > > I hit another boot bug using skein previously which Toomas (CCed) fixed, > and am wondering if this issue might also be related to the skein > implementation. > > I haven't tested if the zfsbootcfg functionality works for fear that the > printf is indicating a low level problem with the zpool. I can test > potentially destructive things and break the pool though if that would > be helpful. > > Any thoughts? I think that Toomas explained the situation rather well. vdev_read_pad2() and vdev_clear_pad2() are not aware of GELI as of now, so the former does not even try to decrypt anything and, obviously, gets some garbage as a result. It's that simple. If it's possible to make it understand that it deals with encrypted data, then it would be great. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Tue Mar 7 09:08:21 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B492CFAE29 for ; Tue, 7 Mar 2017 09:08:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6AE2E182F for ; Tue, 7 Mar 2017 09:08:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2798LJA019266 for ; Tue, 7 Mar 2017 09:08:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 216364] ZFS ARC cache is duplicating data? The cache size gets bigger then the pool. Date: Tue, 07 Mar 2017 09:08:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:08:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216364 --- Comment #12 from Andriy Gapon --- (In reply to k_georgiev from comment #11) It's the ratio, not percents. As hard as it is for you to believe that your system uses that much space, = all stats indicate that it actually does. You can use du, df, zfs get space, e= tc to drill down where the space is used. I am closing this bug report now. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Mar 7 09:08:39 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D296CCFAEA7 for ; Tue, 7 Mar 2017 09:08:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1E9B1922 for ; Tue, 7 Mar 2017 09:08:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2798dgI029118 for ; Tue, 7 Mar 2017 09:08:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 216364] ZFS ARC cache is duplicating data? The cache size gets bigger then the pool. Date: Tue, 07 Mar 2017 09:08:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:08:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216364 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |Not A Bug --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Mar 7 12:35:03 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE567CFB903 for ; Tue, 7 Mar 2017 12:35:03 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7323C1231; Tue, 7 Mar 2017 12:35:03 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 41AD67E901; Tue, 7 Mar 2017 23:34:58 +1100 (EST) Subject: Failed to read pad2 area of primary vdev [was: Re: svn commit: r308089 - in head] To: Toomas Soome References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> <9f0b2f93-04b8-b90b-3cb5-13b8539b9171@freebsd.org> <814E1C65-23E3-42A1-8093-8008DF188506@me.com> Cc: Andriy Gapon , freebsd-fs@freebsd.org, Toomas Soome , allanjude@freebsd.org From: Lawrence Stewart Message-ID: <5497b4a0-836a-668c-f18c-f2adb5b93f7a@freebsd.org> Date: Tue, 7 Mar 2017 23:33:52 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <814E1C65-23E3-42A1-8093-8008DF188506@me.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:35:04 -0000 On 07/03/2017 19:48, Toomas Soome wrote: > >> On 7. märts 2017, at 10:25, Lawrence Stewart > > wrote: >> >> On 07/03/2017 18:04, Toomas Soome wrote: >>> >>>> On 7. märts 2017, at 7:25, Lawrence Stewart >>> > wrote: >>>> >>>> Hi Andriy, >>>> >>>> On 30/10/2016 01:09, Andriy Gapon wrote: >>>>> Author: avg >>>>> Date: Sat Oct 29 14:09:32 2016 >>>>> New Revision: 308089 >>>>> URL: https://svnweb.freebsd.org/changeset/base/308089 >>>>> >>>>> Log: >>>>> zfsbootcfg: a simple tool to set next boot (one time) options for >>>>> zfsboot >>>>> >>>>> (gpt)zfsboot will read one-time boot directives from a special ZFS pool >>>>> area. The area was previously described as "Boot Block Header", but >>>>> currently it is know as Pad2, marked as reserved and is zeroed out on >>>>> pool creation. The new code interprets data in this area, if any, >>>>> using >>>>> the same format as boot.config. The area is immediately wiped out. >>>>> Failure to parse the directives results in a reboot right after the >>>>> cleanup. Otherwise the boot sequence proceeds as usual. >>>>> >>>>> zfsbootcfg writes zfsboot arguments specified on its command line >>>>> to the >>>>> Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and >>>>> vfs.zfs.boot.primary_vdev kenv variables that are set by loader during >>>>> boot. Please see the manual page for more. >>>>> >>>>> Thanks to all who reviewed, contributed and made suggestions! >>>>> There are >>>>> many potential improvements to the feature, please see the review for >>>>> details. >>>>> >>>>> Reviewed by:wblock (docs) >>>>> Discussed with:jhb, tsoome >>>>> MFC after:3 weeks >>>>> Relnotes:yes >>>>> Differential Revision: https://reviews.freebsd.org/D7612 >>>>> >>>>> Added: >>>>> head/sbin/zfsbootcfg/ >>>>> head/sbin/zfsbootcfg/Makefile (contents, props changed) >>>>> head/sbin/zfsbootcfg/zfsbootcfg.8 (contents, props changed) >>>>> head/sbin/zfsbootcfg/zfsbootcfg.c (contents, props changed) >>>>> Modified: >>>>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h >>>>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c >>>>> head/sbin/Makefile >>>>> head/sys/boot/i386/common/drv.c >>>>> head/sys/boot/i386/common/drv.h >>>>> head/sys/boot/i386/gptzfsboot/Makefile >>>>> head/sys/boot/i386/zfsboot/Makefile >>>>> head/sys/boot/i386/zfsboot/zfsboot.c >>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h >>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c >>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c >>>>> head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h >>>>> >>>> [snip] >>>>> @@ -634,7 +712,39 @@ main(void) >>>>> primary_spa = spa; >>>>> primary_vdev = spa_get_primary_vdev(spa); >>>>> >>>>> - if (zfs_spa_init(spa) != 0 || zfs_mount(spa, 0, &zfsmount) != 0) { >>>>> + nextboot = 0; >>>>> + rc = vdev_read_pad2(primary_vdev, cmd, sizeof(cmd)); >>>>> + if (vdev_clear_pad2(primary_vdev)) >>>>> +printf("failed to clear pad2 area of primary vdev\n"); >>>>> + if (rc == 0) { >>>>> +if (*cmd) { >>>>> + /* >>>>> + * We could find an old-style ZFS Boot Block header here. >>>>> + * Simply ignore it. >>>>> + */ >>>>> + if (*(uint64_t *)cmd != 0x2f5b007b10c) { >>>>> +/* >>>>> + * Note that parse() is destructive to cmd[] and we also want >>>>> + * to honor RBX_QUIET option that could be present in cmd[]. >>>>> + */ >>>>> +nextboot = 1; >>>>> +memcpy(cmddup, cmd, sizeof(cmd)); >>>>> +if (parse()) { >>>>> + printf("failed to parse pad2 area of primary vdev\n"); >>>>> + reboot(); >>>>> +} >>>>> +if (!OPT_CHECK(RBX_QUIET)) >>>>> + printf("zfs nextboot: %s\n", cmddup); >>>>> + } >>>>> + /* Do not process this command twice */ >>>>> + *cmd = 0; >>>>> +} >>>>> + } else >>>>> +printf("failed to read pad2 area of primary vdev\n"); >>>>> + >>>> >>>> I've just taken Allan Jude's & co-conspirators' work for a spin that >>>> allows gptzfsboot to boot from a geli + ZFS partition. Everything is >>>> working amazingly well, but I see the above "failed to read pad2 area of >>>> primary vdev" message on every boot. >>>> >>>> It doesn't appear to cause any problems per se and the system >>>> boots/works fine. I assume that message is printed to signal an >>>> unexpected situation though, so figured I'd get in touch to get your >>>> thoughts. >>>> >>>> >>>> >>>> I installed the KVM-based virtual machine system manually from the live >>>> shell of: >>>> >>>> FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso >>>> >>>> >>>> >>>> The partitioning is very simple: >>>> >>>> gpart create -s gpt /dev/vtbd0 >>>> gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 >>>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 >>>> gpart add -t freebsd-zfs -b 2088 vtbd0 >>>> >>>> root# gpart show >>>> => 40 83886000 vtbd0 GPT (40G) >>>> 40 1024 1 freebsd-boot (512K) >>>> 1064 1024 - free - (512K) >>>> 2088 83883952 2 freebsd-zfs (40G) >>>> >>>> >>>> >>>> geli was inited/attached to vtbd0p2 and the zpool was created with >>>> command: >>>> >>>> zpool create -o altroot=/tmp/zroot -o cachefile=/tmp/zpool.cache -O >>>> checksum=skein -O compression=lz4 vtbd0p2.eli >>>> >>>> i.e. the entire pool including bootfs is using skein for checksumming >>>> and lz4 for compression. >>>> >>>> >>>> >>>> I hit another boot bug using skein previously which Toomas (CCed) fixed, >>>> and am wondering if this issue might also be related to the skein >>>> implementation. >>>> >>>> I haven't tested if the zfsbootcfg functionality works for fear that the >>>> printf is indicating a low level problem with the zpool. I can test >>>> potentially destructive things and break the pool though if that would >>>> be helpful. >>>> >>>> Any thoughts? >>>> >>>> Cheers, >>>> Lawrence >>> >>> >>> The problem with having pool on geli encrypted partition is that all >>> the reads done on such partition, gave to go through geli aware >>> read() function, and the same is true for writes (which is important >>> for nextboot feature). So what it means for gptzfsboot/zfsboot is >>> that we would need to have the disk reads/writes go through the geli >>> aware functions and we can not issue “pure” disk io directly. >> >> [+Allan] >> >> Presumably that functionality exists given that the geli support Allan >> added to gptzfsboot is able to read loader and loader is able to read >> everything in /boot from the geli-encrypted ZFS pool? > > > The problem is deeper, the idea behind the nextboot is that it is > attempting to provide recovery from failed boot, so if you set nextboot > dataset, attempt to boot from it, you need to do 2 things: 1. detect the > nextboot config, so you would actually be able to use it, and 2, you > want to reset it as early as possible, because later you may not have a > chance. > > So it means the gptzfsboot has to read out the config to know where from > it has to load the zfsloader, and gptzfsboot has to reset the config, so > that if anything will go wrong, on next boot the fallback or “normal” > boot will be done. Which means that either gptzfsboot has to know how to > deal with geli in context of handling nextboot, or with geli, you just > can not use nextboot config. > > The similar issue is with using boot block area in zfs pool label - to > be able to store and use gptzfsboot in pool label boot area, the boot1 > either has to know how to read the geli, or geli must be able not to > encrypt the bootblock area, or we just can not use that area [with > geli]. All in all, it is another example of the chicken and the egg issue:) Thanks to both you and Andriy for the detailed explanation. To clarify the current state of affairs as I understand them: - zfsbootcfg will set parameters correctly in the pool's correct Pad2 location when the system is booted and running i.e. zfsbootcfg is safe to use in this scenario and won't scribble in any places it shouldn't - The support in gptzfsboot for these zfsbootcfg Pad2 parameters does not know to decrypt first, so reads "garbage" and harmlessly gives up i.e. any parameters which have been set by zfsbootcfg are completely ignored. If I've got that right, then I guess the printf is harmless and is safe to ignore, and I just shouldn't expect zfsbootcfg to work as advertised until such time as someone figures out if/how to add the necessary support to gptzfsboot? Cheers, Lawrence From owner-freebsd-fs@freebsd.org Tue Mar 7 14:34:02 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00C81D011FE for ; Tue, 7 Mar 2017 14:34:02 +0000 (UTC) (envelope-from gldisater@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAF511CA9 for ; Tue, 7 Mar 2017 14:34:01 +0000 (UTC) (envelope-from gldisater@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id f84so4630410ioj.0 for ; Tue, 07 Mar 2017 06:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=KdtJezwgoWsW0Lh/OzdxiL9kChuE0r/vE3X3ixYIPeY=; b=SAJEyglmCVRIFs11/eIZdjhBJcenkTAhMrT9YKik/fCurwGe3j1G6vNzo/B1poVQ5T q6KzkMn3pbcmSyI+1p/AyddxghnRtNaJ1JXvcv+DXq22I02fjp0vYuwhbxSl56Zwd+54 RKvh1fU/YqtAV+G3vCcTmqdHBIbCpI3KoHf3s4oOBmLVCB+koUQgbfrVqH3U2qqZU2cH 7TlP8ZwNjq57UqYNSKordb0g+48YWU+Bsgs0JaAcvdDSEambiM+LowLNmg77+ENSjyuV lzw3QG0xXf2ULTAe/yieLjJDdSOse9EpfRB1VDegVo8chIf5DzWF9Ta16dTmIW2rfH8r 9Ing== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KdtJezwgoWsW0Lh/OzdxiL9kChuE0r/vE3X3ixYIPeY=; b=LHfRe+qEOSiYygAj/R7qOfWcs/4HHQGWeuHfIIQUCsY8mK/zY3lx/Bv1zAoWAEcmG1 ETVKp4uKEZce4N8liABXlLNpeiCTtnMIK3WWwNpwKbfEz2Wp0DtP87Emi6lK9mIxuot3 FM/b7t3u3Q8vQ1BVEJZVMFs6n/vPUofdI8MvDbD7XWpQOM9C3XoirFzQiiR0Rs4T4P71 pQlshtBjzmNS9eBHhcwhpUSiRnJFfZns4zeJ06Bnn3DI0slrJPszQ73yCKp58xSRvQTB YjUcT+vM3wGXy0DeYKvrhJCM3Hgq640pyKUxKIhJtpx78HsRtaMLdCZQSGxlUD20pCw3 IwKg== X-Gm-Message-State: AMke39npDM2u5wqGw0Km8yEitEQ6IzRwtwUBqv+S/lzez5KEeRAo9otpY4+lZbtwQ1OoFg== X-Received: by 10.107.147.134 with SMTP id v128mr1054642iod.128.1488897241058; Tue, 07 Mar 2017 06:34:01 -0800 (PST) Received: from [192.168.1.152] (dhcp-108-168-15-83.cable.user.start.ca. [108.168.15.83]) by smtp.gmail.com with ESMTPSA id g77sm192931iog.40.2017.03.07.06.33.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 06:34:00 -0800 (PST) Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@freebsd.org References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> From: Jeremy Faulkner Message-ID: <27722817-5d5f-69f9-385f-57df1a470b9c@gmail.com> Date: Tue, 7 Mar 2017 09:34:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:34:02 -0000 On 2017-03-06 1:52 PM, Alexander Motin wrote: > On 06.03.2017 20:11, Matthew Ahrens wrote: >> FYI - I am changing this sorting to be based on the bookmark (objset, >> object, level, blkid) instead of timestamp. This normally doesn't >> change the performance on illumos, but it should fix this on FreeBSD >> (and it ensures that the multi-threaded spa_sync doesn't degrade >> performance). >> >> Here's the PR; you can pick out the "sort by bookmark" commit if you want: >> >> https://github.com/openzfs/openzfs/pull/138 > > Thank you for the notice, but we already have alike patch in a tree for > few months to address the mentioned issue: > https://svnweb.freebsd.org/base?view=revision&revision=309714 > > We'll just replace one patch with another when yours comes in to reduce > the code divergence. > This has not been MFC'd yet. Jeremy From owner-freebsd-fs@freebsd.org Wed Mar 8 05:50:32 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A42D3D02614 for ; Wed, 8 Mar 2017 05:50:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8917A1BB1; Wed, 8 Mar 2017 05:50:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-109-205.dyn.iinet.net.au [106.68.109.205]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v285oOZn061271 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 7 Mar 2017 21:50:27 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: svn commit: r308089 - in head To: Toomas Soome , Lawrence Stewart References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> <9f0b2f93-04b8-b90b-3cb5-13b8539b9171@freebsd.org> <814E1C65-23E3-42A1-8093-8008DF188506@me.com> Cc: freebsd-fs@freebsd.org, Toomas Soome , allanjude@freebsd.org, Andriy Gapon From: Julian Elischer Message-ID: <4a498b08-7417-e7b1-2e5d-b0dbe5f3c49a@freebsd.org> Date: Wed, 8 Mar 2017 13:50:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <814E1C65-23E3-42A1-8093-8008DF188506@me.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 05:50:32 -0000 On 7/3/17 4:48 pm, Toomas Soome wrote: >> On 7. märts 2017, at 10:25, Lawrence Stewart wrote: >> >> On 07/03/2017 18:04, Toomas Soome wrote: >>>> On 7. märts 2017, at 7:25, Lawrence Stewart wrote: >>>> >>>> Hi Andriy, >>>> >>>> On 30/10/2016 01:09, Andriy Gapon wrote: >>>>> Author: avg >>>>> Date: Sat Oct 29 14:09:32 2016 >>>>> New Revision: 308089 >>>>> URL: https://svnweb.freebsd.org/changeset/base/308089 >>>>> >>>>> Log: >>>>> zfsbootcfg: a simple tool to set next boot (one time) options for zfsboot >>>>> >>>>> (gpt)zfsboot will read one-time boot directives from a special ZFS pool >>>>> area. The area was previously described as "Boot Block Header", but >>>>> currently it is know as Pad2, marked as reserved and is zeroed out on >>>>> pool creation. The new code interprets data in this area, if any, using >>>>> the same format as boot.config. The area is immediately wiped out. >>>>> Failure to parse the directives results in a reboot right after the >>>>> cleanup. Otherwise the boot sequence proceeds as usual. >>>>> >>>>> zfsbootcfg writes zfsboot arguments specified on its command line to the >>>>> Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and >>>>> vfs.zfs.boot.primary_vdev kenv variables that are set by loader during >>>>> boot. Please see the manual page for more. >>>>> >>>>> Thanks to all who reviewed, contributed and made suggestions! There are >>>>> many potential improvements to the feature, please see the review for >>>>> details. >>>>> >>>>> Reviewed by: wblock (docs) >>>>> Discussed with: jhb, tsoome >>>>> MFC after: 3 weeks >>>>> Relnotes: yes >>>>> Differential Revision: https://reviews.freebsd.org/D7612 >>>>> >>>>> Added: >>>>> head/sbin/zfsbootcfg/ >>>>> head/sbin/zfsbootcfg/Makefile (contents, props changed) >>>>> head/sbin/zfsbootcfg/zfsbootcfg.8 (contents, props changed) >>>>> head/sbin/zfsbootcfg/zfsbootcfg.c (contents, props changed) >>>>> Modified: >>>>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h >>>>> head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c >>>>> head/sbin/Makefile >>>>> head/sys/boot/i386/common/drv.c >>>>> head/sys/boot/i386/common/drv.h >>>>> head/sys/boot/i386/gptzfsboot/Makefile >>>>> head/sys/boot/i386/zfsboot/Makefile >>>>> head/sys/boot/i386/zfsboot/zfsboot.c >>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h >>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c >>>>> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c >>>>> head/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h >>>>> >>>> [snip] >>>>> @@ -634,7 +712,39 @@ main(void) >>>>> primary_spa = spa; >>>>> primary_vdev = spa_get_primary_vdev(spa); >>>>> >>>>> - if (zfs_spa_init(spa) != 0 || zfs_mount(spa, 0, &zfsmount) != 0) { >>>>> + nextboot = 0; >>>>> + rc = vdev_read_pad2(primary_vdev, cmd, sizeof(cmd)); >>>>> + if (vdev_clear_pad2(primary_vdev)) >>>>> + printf("failed to clear pad2 area of primary vdev\n"); >>>>> + if (rc == 0) { >>>>> + if (*cmd) { >>>>> + /* >>>>> + * We could find an old-style ZFS Boot Block header here. >>>>> + * Simply ignore it. >>>>> + */ >>>>> + if (*(uint64_t *)cmd != 0x2f5b007b10c) { >>>>> + /* >>>>> + * Note that parse() is destructive to cmd[] and we also want >>>>> + * to honor RBX_QUIET option that could be present in cmd[]. >>>>> + */ >>>>> + nextboot = 1; >>>>> + memcpy(cmddup, cmd, sizeof(cmd)); >>>>> + if (parse()) { >>>>> + printf("failed to parse pad2 area of primary vdev\n"); >>>>> + reboot(); >>>>> + } >>>>> + if (!OPT_CHECK(RBX_QUIET)) >>>>> + printf("zfs nextboot: %s\n", cmddup); >>>>> + } >>>>> + /* Do not process this command twice */ >>>>> + *cmd = 0; >>>>> + } >>>>> + } else >>>>> + printf("failed to read pad2 area of primary vdev\n"); >>>>> + >>>> I've just taken Allan Jude's & co-conspirators' work for a spin that >>>> allows gptzfsboot to boot from a geli + ZFS partition. Everything is >>>> working amazingly well, but I see the above "failed to read pad2 area of >>>> primary vdev" message on every boot. >>>> >>>> It doesn't appear to cause any problems per se and the system >>>> boots/works fine. I assume that message is printed to signal an >>>> unexpected situation though, so figured I'd get in touch to get your >>>> thoughts. >>>> >>>> >>>> >>>> I installed the KVM-based virtual machine system manually from the live >>>> shell of: >>>> >>>> FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso >>>> >>>> >>>> >>>> The partitioning is very simple: >>>> >>>> gpart create -s gpt /dev/vtbd0 >>>> gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 >>>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 >>>> gpart add -t freebsd-zfs -b 2088 vtbd0 >>>> >>>> root# gpart show >>>> => 40 83886000 vtbd0 GPT (40G) >>>> 40 1024 1 freebsd-boot (512K) >>>> 1064 1024 - free - (512K) >>>> 2088 83883952 2 freebsd-zfs (40G) >>>> >>>> >>>> >>>> geli was inited/attached to vtbd0p2 and the zpool was created with command: >>>> >>>> zpool create -o altroot=/tmp/zroot -o cachefile=/tmp/zpool.cache -O >>>> checksum=skein -O compression=lz4 vtbd0p2.eli >>>> >>>> i.e. the entire pool including bootfs is using skein for checksumming >>>> and lz4 for compression. >>>> >>>> >>>> >>>> I hit another boot bug using skein previously which Toomas (CCed) fixed, >>>> and am wondering if this issue might also be related to the skein >>>> implementation. >>>> >>>> I haven't tested if the zfsbootcfg functionality works for fear that the >>>> printf is indicating a low level problem with the zpool. I can test >>>> potentially destructive things and break the pool though if that would >>>> be helpful. >>>> >>>> Any thoughts? >>>> >>>> Cheers, >>>> Lawrence >>> >>> The problem with having pool on geli encrypted partition is that all the reads done on such partition, gave to go through geli aware read() function, and the same is true for writes (which is important for nextboot feature). So what it means for gptzfsboot/zfsboot is that we would need to have the disk reads/writes go through the geli aware functions and we can not issue “pure” disk io directly. >> [+Allan] >> >> Presumably that functionality exists given that the geli support Allan >> added to gptzfsboot is able to read loader and loader is able to read >> everything in /boot from the geli-encrypted ZFS pool? > > The problem is deeper, the idea behind the nextboot is that it is attempting to provide recovery from failed boot, so if you set nextboot dataset, attempt to boot from it, you need to do 2 things: 1. detect the nextboot config, so you would actually be able to use it, and 2, you want to reset it as early as possible, because later you may not have a chance. > > So it means the gptzfsboot has to read out the config to know where from it has to load the zfsloader, and gptzfsboot has to reset the config, so that if anything will go wrong, on next boot the fallback or “normal” boot will be done. Which means that either gptzfsboot has to know how to deal with geli in context of handling nextboot, or with geli, you just can not use nextboot config. > > The similar issue is with using boot block area in zfs pool label - to be able to store and use gptzfsboot in pool label boot area, the boot1 either has to know how to read the geli, or geli must be able not to encrypt the bootblock area, or we just can not use that area [with geli]. All in all, it is another example of the chicken and the egg issue:) this is why the ORIGINAL nextboot in freebsd 3 (+ or -) wrote the data into block 1 of the drive and read it from boot0, and rewrote block 1 after zeroing out teh entry. All using bios calls. 1/ read and remove ASAP, 2 don't depend on the filesystem.. it may be dead, and that is why we are redirecting somewhere else. the current nextboot is not nearly as useful and needs to be replaced as soon as possible as a failed experiment. things we coudl do to improve nextboot functionality: 1/ declare a partition type freebsd-bootinfo tha t is just raw boot info. 2/ store the info in a known place in the freebsd-zfs partition (what andriy is doing I believe) 3/ store it at the end of the freebsd-boot partition. It should be read by gptzfsboot and set into the environment (what comes earlier in a gpt system?) originally I read it using bios calls from boot0. that was of course a UFS system on a dedicated drive. > > rgds, > toomas > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@freebsd.org Wed Mar 8 05:55:41 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6D3FD028CA for ; Wed, 8 Mar 2017 05:55:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 932981F79 for ; Wed, 8 Mar 2017 05:55:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v285teNd028493 for ; Wed, 8 Mar 2017 05:55:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Wed, 08 Mar 2017 05:55:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: erik@nordstroem.no X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 05:55:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 --- Comment #12 from Erik Nordstr=C3=B8m --- (In reply to Warner Losh from comment #11) >We should ask the folks that set it to ISO-8859-1 why that specific choice= , and if we can shift the interpretation over to UTF-8. I agree. I don't know who to ask and probably couldn't contribute much in conversation anyway, could either of you -- Warner or Conrad -- ask them? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 8 06:42:12 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9813D02E29 for ; Wed, 8 Mar 2017 06:42:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8F8D11A4 for ; Wed, 8 Mar 2017 06:42:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v286gC8H057850 for ; Wed, 8 Mar 2017 06:42:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Wed, 08 Mar 2017 06:42:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 06:42:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 --- Comment #13 from Conrad Meyer --- I don't know how to find these people either :-(. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 8 14:24:33 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 531CFD038FF for ; Wed, 8 Mar 2017 14:24:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4298519AA for ; Wed, 8 Mar 2017 14:24:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v28EOWbp041849 for ; Wed, 8 Mar 2017 14:24:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Wed, 08 Mar 2017 14:24:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: imp@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:24:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 --- Comment #14 from Warner Losh --- ache@ is the only one I can think of. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 8 14:27:45 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FC56D039FF for ; Wed, 8 Mar 2017 14:27:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F1FE1BE7 for ; Wed, 8 Mar 2017 14:27:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v28ERjxw045751 for ; Wed, 8 Mar 2017 14:27:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217440] FAT32 formatted USB stick with files written by PS4 - Invalid argument, unable to list directory contents Date: Wed, 08 Mar 2017 14:27:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: imp@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:27:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217440 --- Comment #15 from Warner Losh --- And if we can't contact him, go ahead with the change. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 8 17:44:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39D83D03CEE for ; Wed, 8 Mar 2017 17:44:54 +0000 (UTC) (envelope-from kristen.bell@digitalinfozone.com) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-bo1ind01on0075.outbound.protection.outlook.com [104.47.101.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87FE52D2 for ; Wed, 8 Mar 2017 17:44:53 +0000 (UTC) (envelope-from kristen.bell@digitalinfozone.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2155543.onmicrosoft.com; s=selector1-digitalinfozone-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z3QntVNn+D3EYHTEDj06CA84TLUXsvxZZ+NmNI93rWo=; b=EamgPZNGAmZtd7PhZa00481N2U87XXmjgByeeQh5xQI3FMHP0BwvJvxnb3+24DfvBZD82rKMapZSa6yvEg5y39nz0TI6mPZL/0X1xPp5ZTC2g4KcK1fAsUt8u0SkdmQa2MyUjFXgMRADzDkVa7TSKHfh8HdCWfBPUo4nQ1LVav8= Received: from PN1PR01MB0608.INDPRD01.PROD.OUTLOOK.COM (10.164.142.23) by PN1PR01MB0608.INDPRD01.PROD.OUTLOOK.COM (10.164.142.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 17:44:49 +0000 Received: from PN1PR01MB0608.INDPRD01.PROD.OUTLOOK.COM ([10.164.142.23]) by PN1PR01MB0608.INDPRD01.PROD.OUTLOOK.COM ([10.164.142.23]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 17:44:49 +0000 From: Kristen Bell To: "freebsd-fs@freebsd.org" Subject: Re: HD Expo 2017 Attendees Contact information Thread-Topic: Re: HD Expo 2017 Attendees Contact information Thread-Index: AdKYM6z8v27E8knlQwGOfhz3h0/Gbw== Date: Wed, 8 Mar 2017 17:44:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kristen.bell@digitalinfozone.com; x-originating-ip: [103.57.83.120] x-ms-office365-filtering-correlation-id: 0994a3b8-1fba-4edd-7f71-08d4664ad1c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702085552020)(201702085553020)(201702085551020); SRVR:PN1PR01MB0608; x-microsoft-exchange-diagnostics: 1; PN1PR01MB0608; 7:MLjsXcGv2ew1sh1eMwhe4I5QGJAfK012T9cg5fPsYy3lE2OCjO654sq9UcJvGxvMfVl4z1PCXFElJ5882b7DshT5F2Na1p/FVXBUNGiFTAeEGiCKu3oxlGLvNn/PvLgVDybMVqS9GK7487CeXj86boBzCOECR8QxDbraBLG5VJqa2vT+L5odaCWeBfTLdd01Oqyfl2YQme6fwAEmvPHlYIJl+23x+OkDv+xUn0lhuy0j4KNw4jKde1RP222WWlkuQGSl7uaBdzQyuFw5oBVKR/7DF9wwUcfqOMcUBXlyiWd811y3dY4NWDm/q5nH23G7fmy7gZF4ioLVu9EDyUhLxA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(2016111802025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6043046)(6042181)(6072148); SRVR:PN1PR01MB0608; BCL:0; PCL:0; RULEID:; SRVR:PN1PR01MB0608; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(151974002)(110136004)(38730400002)(5660300001)(6916009)(6246003)(7696004)(5630700001)(2900100001)(6116002)(189998001)(3280700002)(790700001)(6306002)(9686003)(54896002)(6506006)(77096006)(55016002)(8676002)(229853002)(9326002)(53936002)(8936002)(81166006)(86362001)(9476002)(223583001)(2501003)(5640700003)(6436002)(50986999)(102836003)(3846002)(3660700001)(2906002)(54356999)(2351001)(7736002)(74316002)(122556002)(33656002)(66066001)(35810200001); DIR:OUT; SFP:1101; SCL:1; SRVR:PN1PR01MB0608; H:PN1PR01MB0608.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovr; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: digitalinfozone.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: digitalinfozone.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 17:44:49.7096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 61584268-d2c5-44bb-b8df-ba5a962387e5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PN1PR01MB0608 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:44:54 -0000 Hi, I found your company listed as Sponsors and Exhibitors HD expo 2017 and I t= hought you would Be Interested in Attendees Contact information for your RO= I. List Contains: Name, Company's Name, Phone Number, Fax Number, Job Title, E= mail address, Complete Mailing Address, SIC code, Company revenue, size, We= b address etc. We offer: * Complete list with Email address in an Excel Sheet for unlimited usag= e. * Do an email blast endorsing your product/services and providing your = contact information. * Email appending, multiple contacts appending, Data appending which wi= ll append or add the missing information to your existing database. Let me know your thoughts or pass on the message to the right person in you= r company. Thanks & regards, Kristen Bell Demand Generation Executive. If you don't want to receive any message from us then please type "L= eave Out" in the Subject Line. From owner-freebsd-fs@freebsd.org Thu Mar 9 08:29:02 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B17FED04D5A for ; Thu, 9 Mar 2017 08:29:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 5875F81D; Thu, 9 Mar 2017 08:29:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 1D8201049998; Thu, 9 Mar 2017 19:28:59 +1100 (AEDT) Date: Thu, 9 Mar 2017 19:28:58 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer cc: Toomas Soome , Lawrence Stewart , freebsd-fs@freebsd.org, Toomas Soome , Andriy Gapon , allanjude@freebsd.org Subject: Re: svn commit: r308089 - in head In-Reply-To: <4a498b08-7417-e7b1-2e5d-b0dbe5f3c49a@freebsd.org> Message-ID: <20170309175948.R1327@besplex.bde.org> References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> <9f0b2f93-04b8-b90b-3cb5-13b8539b9171@freebsd.org> <814E1C65-23E3-42A1-8093-8008DF188506@me.com> <4a498b08-7417-e7b1-2e5d-b0dbe5f3c49a@freebsd.org> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=XD7vrdztDUKdFc0NCCQA:9 a=_4WE8NwcEVrEyAIe:21 a=2hNUDaqj4LBtHBc0:21 a=45ClL6m2LaAA:10 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 08:29:02 -0000 On Wed, 8 Mar 2017, Julian Elischer wrote: > On 7/3/17 4:48 pm, Toomas Soome wrote: >>> ... >> The problem is deeper, the idea behind the nextboot is that it is=20 >> attempting to provide recovery from failed boot, so if you set nextboot= =20 >> dataset, attempt to boot from it, you need to do 2 things: 1. detect the= =20 >> nextboot config, so you would actually be able to use it, and 2, you wan= t=20 >> to reset it as early as possible, because later you may not have a chanc= e. >>=20 >> So it means the gptzfsboot has to read out the config to know where from= it=20 >> has to load the zfsloader, and gptzfsboot has to reset the config, so th= at=20 >> if anything will go wrong, on next boot the fallback or =E2=80=9Cnormal= =E2=80=9D boot=20 >> will be done. Which means that either gptzfsboot has to know how to deal= =20 >> with geli in context of handling nextboot, or with geli, you just can no= t=20 >> use nextboot config. >>=20 >> The similar issue is with using boot block area in zfs pool label - to b= e=20 >> able to store and use gptzfsboot in pool label boot area, the boot1 eith= er=20 >> has to know how to read the geli, or geli must be able not to encrypt th= e=20 >> bootblock area, or we just can not use that area [with geli]. All in all= ,=20 >> it is another example of the chicken and the egg issue:) > > this is why the ORIGINAL nextboot in freebsd 3 (+ or -) wrote the data in= to=20 > block 1 of the drive and read it from boot0, and rewrote block 1 after=20 > zeroing out teh entry. > All using bios calls. > 1/ read and remove ASAP, > 2 don't depend on the filesystem.. it may be dead, and that is why we ar= e=20 > redirecting somewhere else. I didn't like this method. Anything that writes to the disk increases fragility. Is still use my version of biosboot (updated for elf and EDD) and try not to see the nextboot code in it (I can't delete this code since it would then show up even more in diffs). My method (used mostly only interactively) is to depend on a filesystem for boot2 and things loaded by boot2. It is easy to maintain such a file system somewhere (perhaps on removable write-only media), but can be hard to find it or ensure that it is the one booted (this often bites me when bringing up a new system from a USB drive; first it can be hard to boot from USB, and then I forgot how the standard boot0 misbehaves and hit F5 which tends to switch to a Windows drive with an unusable MBR on it). Once a known-good partition (with a good file system including boot2 or even loader on it) is found. It is easy to control things by booting to the kernel on that. My method for cycling through kernels to run run benchmarks on them is to copy the next kernel to a standard place and boot to there. The kernel is selected by an index in a text file. Cycling is done by incrementing the index. I only do this for rebooting within a single partition, but could immediately use a variation that switches between i386 and amd64 partitions. To use this method for nextboot, the main cycle would have to be of length 2, to switch between a know-good partition and the next try on a not-known-good partition (after booting to the known-good partition, it is is easy to clean up the other partition and copy a hopefull-better kernel or even a whole filesystem to it). The index (of 0 or 1) for the main cycle can't be stored in the known-good filesystem since after a crash booting a bad partition there is no safe way to update the index there. On x86, there should be space reserved for OS use in CMOS, but unfortunately nothing is properly reserved there. I have though of using the alarm register[s] for this. The alarm register[s] are not normally used, and for cycles of nextbooting the OS could simply turn off alarms and use them. Add ECC to this and it becomes very safe to use them. At worst, another OS might boot in the middle of the cycle and change the alarm setting. Just boot to the known-good partition when ECC detects an error, and trust ECC to detect the unlikely interruption and change. Recently, I noticed that the entire msgbuf survives rebooting on amd64 systems with 16GB memory. The msgbuf is in high memory for amd64 and this seems to survive warm boots and is not clobbered by the BIOS. But the BIOS on the same system scribbles over almost all memory below 4GB. It leaves large portitions of the msbguf intact, but the msgbuf is protected by a stupid 32-bit checksum and always detects the clobbering. Change this to ECC and apply it to individual messages and we can recover most of the message buffer on i386, without expanding it much. Add redundancy/ECC to recover more of it. It also has atomic update problems that are best fix by redundancy and localized checksums which could be ECC exept that is a bit over-engineered. If we can robustly prreserve entire msgbufs across reboot, then it is trivial to preserve a single status bit for nextboot. Just not so easy to do ECC for this bit in 512 bytes in boot0. The memory bit could be for extra checking of the RTC registers, with simple checksums instead of ECC on both. > the current nextboot is not nearly as useful and needs to be replaced as = soon=20 > as possible as a failed experiment. > things we coudl do to improve nextboot functionality: > 1/ declare a partition type freebsd-bootinfo tha t is just raw boot info. Ugh, this is as bad as Windows using multiple precious (non-GPT) partitions for itself. My method needs a known-good partition, but this can be a FreeBSD partition. My methods would actually have to put the decisions int= o boot2, since there is not enough space in boot0 and avoid using loader: - boot0: boot to known-good slice, say ad4s3 - boot2: this actually lives at the start of the slice, not in a partition, so is easy to find. One reason I don't like loader is that it lives on a file system, so deferring decisions to it is not so robust. - boot2 has to find the right drive and slice. This is not so easy. The default of the first FreeBSD slice is wrong in some of my configurations= =2E This can be made more robust by hard-coding values in the boot2 binary. - boot2 then has to find the right partition. It almost always defaults to the 'a' partition, and loads /boot.config from there to possibly override the default. It is safest to always make the known-good partition 'a'. - before reading boot.config, boot2 does ECC on various places to find overrides. With nextboot inactive or the cycle-control value is 0, it reads boot.config from the known-good partition. Otherwise, it reads boot.config from somewhere else, say the the 'b' partition or just an alternative boot.config on the known-good partition. It ca contain anything, so the next try is not limited to 1 alernative. > 2/ store the info in a known place in the freebsd-zfs partition (what and= riy=20 > is doing I believe) > 3/ store it at the end of the freebsd-boot partition. > It should be read by gptzfsboot and set into the environment (what comes= =20 > earlier in a gpt system?) originally I read it using bios calls from boo= t0. > that was of course a UFS system on a dedicated drive. It is fundamentally insecure to allow booting from all over the place, especially when selected by simple binary values written to raw drives. My method actually works well to fix this. Better write the alternative boot.config to the same known-good partition as the non-alternative (this is only impossibly of the known-good partition is read-only). Then the simple binary value is not very robust, but all it does is select between the known-good boot.config and the alternative one. Security is attained by never pointing the alternative one to an insecure partition. Bruce From owner-freebsd-fs@freebsd.org Thu Mar 9 14:32:02 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27684D0437E; Thu, 9 Mar 2017 14:32:02 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC10A1568; Thu, 9 Mar 2017 14:32:01 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 178-164-145-249.pool.digikabel.hu ([178.164.145.249] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1clz6j-000NiM-Le; Thu, 09 Mar 2017 14:31:57 +0000 Subject: Re: process killed: text file modification To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> From: Gergely Czuczy Message-ID: <45436522-77df-f894-0569-737a6a74958f@harmless.hu> Date: Thu, 9 Mar 2017 15:31:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:32:02 -0000 [+freebsd-fs] On 2017. 03. 09. 14:20, Gergely Czuczy wrote: > On 2017. 03. 09. 11:27, Gergely Czuczy wrote: >> Hello, >> >> I'm trying to build a few things from ports on an rpi3, the ports >> collection is mounted over NFS from another machine. When it's trying >> to build pkg i'm getting the error message in syslog: >> >> rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification >> >> The report to pkg@: >> https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html >> >> In ports-mgmt/pkg's config.log It fails at the following entry: >> configure:3726: checking whether we are cross compiling >> configure:3734: cc -o conftest -O2 -pipe -Wno-error >> -fno-strict-aliasing conftest.c >&5 >> configure:3738: $? = 0 >> configure:3745: ./conftest >> configure:3749: $? = 137 >> configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0': >> configure:3760: error: cannot run C compiled programs. >> If you meant to cross compile, use `--host'. >> See `config.log' for more details >> >> # uname -a >> FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9 >> 08:58:46 CET 2017 >> aegir@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR >> arm64 > So far, a few additions: > Time is synced between the NFS server and the client. > it's an open() call which is getting the kill, and it's not the file > what's being opened, but the process executing it. > Here's a simple code that reproduces it: > #include > > int main() { > > FILE *f = fopen ("/bar", "w"); > > fclose(f); > return 0; > } > > Conditions to reproduce it: > - The resulting binary must be executed from the nfs mount > - The binary must be built after mounting the NFS share. > > I haven't tried building it on a different host, I don't have access > to multiple RPis. Also, if I build the binary, umount/remount the NFS > mount point, which has the binary, execute it, then it works. > > I've also tried this with the raspbsd.org's image, I could reproduce > it as well. > > Another interesting thing is, when I first booted the RPi up, the NFS > server was a 10.2-STABLE, and later got updated to 11-STABLE. While it > was 10.2 I've tried to build some port, and I don't remember having > this issue. > > So, could someone please help me figure this out and fix it? This > stuff should work pretty much. > So, this error message comes from here: https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio.c?revision=314436&view=markup#l1674 It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np->n_vattr.na_mtime) comparision that fails, np should be the NFS node structure, from the vnode's v_data, and n_vattr is the attribute cache. As I've seen these two are being updated together, so I don't really see by the code why they might differ. Could someone please take a look at it, with more experience in the NFS code? -czg From owner-freebsd-fs@freebsd.org Thu Mar 9 16:23:10 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5F72D057E3 for ; Thu, 9 Mar 2017 16:23:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A32971BDC for ; Thu, 9 Mar 2017 16:23:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v29GN9Wb072876 for ; Thu, 9 Mar 2017 16:23:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194513] zfs recv hangs in state kmem arena Date: Thu, 09 Mar 2017 16:23:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: smh@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:23:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194513 --- Comment #22 from Steven Hartland --- (In reply to Dave Baukus from comment #21) This is possible if you are seeing this issue do try increasing it to SPA_MAXBLOCKSIZE to see if it helps. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Mar 9 18:46:58 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F8D0D05A3A; Thu, 9 Mar 2017 18:46:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CE51A70; Thu, 9 Mar 2017 18:46:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 3B21010A7B9; Thu, 9 Mar 2017 13:46:54 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Gergely Czuczy , freebsd-fs@freebsd.org Subject: Re: process killed: text file modification Date: Thu, 09 Mar 2017 10:44:27 -0800 Message-ID: <55189643.aaZPuY77s8@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <45436522-77df-f894-0569-737a6a74958f@harmless.hu> References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 09 Mar 2017 13:46:54 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:46:58 -0000 On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote: > [+freebsd-fs] > > > On 2017. 03. 09. 14:20, Gergely Czuczy wrote: > > On 2017. 03. 09. 11:27, Gergely Czuczy wrote: > >> Hello, > >> > >> I'm trying to build a few things from ports on an rpi3, the ports > >> collection is mounted over NFS from another machine. When it's trying > >> to build pkg i'm getting the error message in syslog: > >> > >> rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification > >> > >> The report to pkg@: > >> https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html > >> > >> In ports-mgmt/pkg's config.log It fails at the following entry: > >> configure:3726: checking whether we are cross compiling > >> configure:3734: cc -o conftest -O2 -pipe -Wno-error > >> -fno-strict-aliasing conftest.c >&5 > >> configure:3738: $? = 0 > >> configure:3745: ./conftest > >> configure:3749: $? = 137 > >> configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0': > >> configure:3760: error: cannot run C compiled programs. > >> If you meant to cross compile, use `--host'. > >> See `config.log' for more details > >> > >> # uname -a > >> FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9 > >> 08:58:46 CET 2017 > >> aegir@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR > >> arm64 > > So far, a few additions: > > Time is synced between the NFS server and the client. > > it's an open() call which is getting the kill, and it's not the file > > what's being opened, but the process executing it. > > Here's a simple code that reproduces it: > > #include > > > > int main() { > > > > FILE *f = fopen ("/bar", "w"); > > > > fclose(f); > > return 0; > > } > > > > Conditions to reproduce it: > > - The resulting binary must be executed from the nfs mount > > - The binary must be built after mounting the NFS share. > > > > I haven't tried building it on a different host, I don't have access > > to multiple RPis. Also, if I build the binary, umount/remount the NFS > > mount point, which has the binary, execute it, then it works. > > > > I've also tried this with the raspbsd.org's image, I could reproduce > > it as well. > > > > Another interesting thing is, when I first booted the RPi up, the NFS > > server was a 10.2-STABLE, and later got updated to 11-STABLE. While it > > was 10.2 I've tried to build some port, and I don't remember having > > this issue. > > > > So, could someone please help me figure this out and fix it? This > > stuff should work pretty much. > > > So, this error message comes from here: > https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio.c?revision=314436&view=markup#l1674 > > It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np->n_vattr.na_mtime) > comparision that fails, np should be the NFS node structure, from the > vnode's v_data, and n_vattr is the attribute cache. As I've seen these > two are being updated together, so I don't really see by the code why > they might differ. Could someone please take a look at it, with more > experience in the NFS code? -czg Can you print out the two mtimes? I wonder if what's happening is that your server uses different granularity (for example just seconds) than your client, so on the client we generate a timestamp with a non-zero nanoseconds but when the server receives that timestamp it "truncates" it. During open() we forcefully re-fetch the timestamp (for CTO consistency) and then notice it doesn't match. For now I would start with comparing the timestamps and maybe the vfs.timestamp_precision sysctls on client and server (if server is a FreeBSD box). -- John Baldwin From owner-freebsd-fs@freebsd.org Thu Mar 9 19:47:21 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A98E6D04445; Thu, 9 Mar 2017 19:47:21 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C187635; Thu, 9 Mar 2017 19:47:20 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 178-164-145-249.pool.digikabel.hu ([178.164.145.249] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cm41u-000Bf3-8a; Thu, 09 Mar 2017 19:47:18 +0000 Subject: Re: process killed: text file modification To: John Baldwin , freebsd-current@freebsd.org References: <646c1395-9482-b214-118c-01573243ae5a@harmless.hu> <45436522-77df-f894-0569-737a6a74958f@harmless.hu> <55189643.aaZPuY77s8@ralph.baldwin.cx> Cc: freebsd-fs@freebsd.org From: Gergely Czuczy Message-ID: <3ed3e4a3-23af-7267-39f1-9090093c9c1e@harmless.hu> Date: Thu, 9 Mar 2017 20:47:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <55189643.aaZPuY77s8@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:47:21 -0000 On 2017. 03. 09. 19:44, John Baldwin wrote: > On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote: >> [+freebsd-fs] >> >> >> On 2017. 03. 09. 14:20, Gergely Czuczy wrote: >>> On 2017. 03. 09. 11:27, Gergely Czuczy wrote: >>>> Hello, >>>> >>>> I'm trying to build a few things from ports on an rpi3, the ports >>>> collection is mounted over NFS from another machine. When it's trying >>>> to build pkg i'm getting the error message in syslog: >>>> >>>> rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification >>>> >>>> The report to pkg@: >>>> https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html >>>> >>>> In ports-mgmt/pkg's config.log It fails at the following entry: >>>> configure:3726: checking whether we are cross compiling >>>> configure:3734: cc -o conftest -O2 -pipe -Wno-error >>>> -fno-strict-aliasing conftest.c >&5 >>>> configure:3738: $? = 0 >>>> configure:3745: ./conftest >>>> configure:3749: $? = 137 >>>> configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0': >>>> configure:3760: error: cannot run C compiled programs. >>>> If you meant to cross compile, use `--host'. >>>> See `config.log' for more details >>>> >>>> # uname -a >>>> FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9 >>>> 08:58:46 CET 2017 >>>> aegir@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR >>>> arm64 >>> So far, a few additions: >>> Time is synced between the NFS server and the client. >>> it's an open() call which is getting the kill, and it's not the file >>> what's being opened, but the process executing it. >>> Here's a simple code that reproduces it: >>> #include >>> >>> int main() { >>> >>> FILE *f = fopen ("/bar", "w"); >>> >>> fclose(f); >>> return 0; >>> } >>> >>> Conditions to reproduce it: >>> - The resulting binary must be executed from the nfs mount >>> - The binary must be built after mounting the NFS share. >>> >>> I haven't tried building it on a different host, I don't have access >>> to multiple RPis. Also, if I build the binary, umount/remount the NFS >>> mount point, which has the binary, execute it, then it works. >>> >>> I've also tried this with the raspbsd.org's image, I could reproduce >>> it as well. >>> >>> Another interesting thing is, when I first booted the RPi up, the NFS >>> server was a 10.2-STABLE, and later got updated to 11-STABLE. While it >>> was 10.2 I've tried to build some port, and I don't remember having >>> this issue. >>> >>> So, could someone please help me figure this out and fix it? This >>> stuff should work pretty much. >>> >> So, this error message comes from here: >> https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio.c?revision=314436&view=markup#l1674 >> >> It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np->n_vattr.na_mtime) >> comparision that fails, np should be the NFS node structure, from the >> vnode's v_data, and n_vattr is the attribute cache. As I've seen these >> two are being updated together, so I don't really see by the code why >> they might differ. Could someone please take a look at it, with more >> experience in the NFS code? -czg > Can you print out the two mtimes? I wonder if what's happening is that > your server uses different granularity (for example just seconds) than > your client, so on the client we generate a timestamp with a non-zero > nanoseconds but when the server receives that timestamp it "truncates" > it. During open() we forcefully re-fetch the timestamp (for CTO > consistency) and then notice it doesn't match. For now I would start > with comparing the timestamps and maybe the vfs.timestamp_precision > sysctls on client and server (if server is a FreeBSD box). Here are the time values: Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 + -3298114786336 &np->n_vattr.na_mtime: -3298114786616 + -3298114786608 Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: text file modification Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 + -3298114786336 &np->n_vattr.na_mtime: -3298114786616 + -3298114786608 Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: text file modification Printed this way: printf("np->n_mtime: %ji + %ji &np->n_vattr.na_mtime: %ji + %ji", (intmax_t)(&np->n_mtime.tv_sec), (intmax_t)(&np->n_mtime.tv_nsec), (intmax_t)(&np->n_vattr.na_mtime.tv_sec), (intmax_t)(&np->n_vattr.na_mtime.tv_nsec)); From owner-freebsd-fs@freebsd.org Sat Mar 11 00:31:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 249DCD0470D for ; Sat, 11 Mar 2017 00:31:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1442C1B55 for ; Sat, 11 Mar 2017 00:31:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2B0Vr5C017901 for ; Sat, 11 Mar 2017 00:31:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 217686] zfs_enable=YES causing vm_fault: pager read error, pid 1 (init) Date: Sat, 11 Mar 2017 00:31:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 00:31:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217686 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|conf |kern Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.=