From owner-freebsd-fs@freebsd.org Sun Sep 25 15:42:12 2016 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 B67A9BE9F39 for ; Sun, 25 Sep 2016 15: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 A642FAFB for ; Sun, 25 Sep 2016 15: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 u8PFgBo4044458 for ; Sun, 25 Sep 2016 15:42:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Date: Sun, 25 Sep 2016 15:42:12 +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: 11.0-RC1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: Andrew@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: Sun, 25 Sep 2016 15:42:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 --- Comment #14 from Andrew Turner --- I have setup one of the netperf ThunderX machines with UFS SU+J. I can trig= ger this issue with a buildworld in a loop. I tried adding logging to see what memory was allocated but didn't manage to trigger the issue. I then tried adding an atomic memory barrier into worklist_insert and worklist_remove. I'm currently testing this change, and have yet to see the issue after about 2 hours. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Sep 25 16:08:52 2016 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 39EAFBE8602 for ; Sun, 25 Sep 2016 16:08:52 +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 27A97665 for ; Sun, 25 Sep 2016 16:08:52 +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 u8PG8ow1038165 for ; Sun, 25 Sep 2016 16:08:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Date: Sun, 25 Sep 2016 16:08:51 +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: 11.0-RC1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kib@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: Sun, 25 Sep 2016 16:08:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 --- Comment #15 from Konstantin Belousov --- (In reply to Andrew Turner from comment #14) Is trim enabled on the disk where the UFS volume is mounted, and on the vol= ume itself (tunefs -t enable) ? If yes, does the issue go away if you disable trim with tunefs ? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Sep 25 16:32:35 2016 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 3C34BBE8BB2 for ; Sun, 25 Sep 2016 16:32:35 +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 2BD1D125 for ; Sun, 25 Sep 2016 16:32:35 +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 u8PGWYEI091109 for ; Sun, 25 Sep 2016 16:32:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Date: Sun, 25 Sep 2016 16:32:35 +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: 11.0-RC1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: Andrew@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: Sun, 25 Sep 2016 16:32:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 --- Comment #16 from Andrew Turner --- (In reply to Konstantin Belousov from comment #15) The disk doesn't support TRIM, and it's not enabled in the filesystem. root@cavium2:~ # camcontrol identify /dev/ada0 pass0: ATA8-ACS SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model WDC WD5001AALS-00E3A0 firmware revision 05.01D05 serial number WD-WCATR2780527 WWN 50014ee2af913f22 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 976773168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6=20 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management yes no 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 976773168/976773168 HPA - Security no root@cavium2:~ # tunefs -p /dev/ufs/thunderxroot tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) thunderxroot --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Sep 25 19:37:16 2016 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 C14C9BE95C3 for ; Sun, 25 Sep 2016 19:37:16 +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 B0DBA642 for ; Sun, 25 Sep 2016 19:37:16 +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 u8PJbFQp093400 for ; Sun, 25 Sep 2016 19:37:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Date: Sun, 25 Sep 2016 19:37:15 +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: 11.0-RC1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kib@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: Sun, 25 Sep 2016 19:37:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 --- Comment #17 from Konstantin Belousov --- (In reply to Andrew Turner from comment #16) Ok. If you copy/paste WORKLIST_INSERT_UNLOCKED and only add the barrier there, = does the issue disappear as well ? There is only one use of WORKLIST_INSERT_UNLOCKED in the ffs_softdep.c, and= no uses of WORKLIST_REMOVE_UNLOCKED at all. All other calls are for WORKLIST_INSERT/REMOVE(), which assert that the mount point' softdep lock is owned. Of course, it might be some other access for read which is not under softdep lock. The only use of WORKLIST_INSERT_UNLOCKED() is for the ffs_blkfree(), where = some local worklist is formed from the items. The list is processed in the same thread (passed to softdep_setup_blkfree()) in ffs_blkfree()->ffs_blkfree_cg= () for !TRIM case. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Sep 25 21:00:29 2016 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 CE6F4BE8CBF for ; Sun, 25 Sep 2016 21:00:29 +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 C1983C28 for ; Sun, 25 Sep 2016 21:00:29 +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 u8PL01pX001807 for ; Sun, 25 Sep 2016 21:00:29 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201609252100.u8PL01pX001807@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, 25 Sep 2016 21:00:29 +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, 25 Sep 2016 21:00:29 -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 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 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Sep 26 13:36:44 2016 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 A3721BE88AC for ; Mon, 26 Sep 2016 13:36:44 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:d250:99ff:fe57:4030]) (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 7628C15BA; Mon, 26 Sep 2016 13:36:43 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id u8QDagnu056294; Mon, 26 Sep 2016 06:36:42 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201609261336.u8QDagnu056294@chez.mckusick.com> From: Kirk McKusick To: Andy Turner , Konstantin Belousov Subject: Re: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) cc: freebsd-fs@FreeBSD.org In-reply-to: X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick MIME-Version: 1.0 Content-ID: <56270.1474896967.0@chez.mckusick.com> Date: Mon, 26 Sep 2016 06:36:42 -0700 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: Mon, 26 Sep 2016 13:36:44 -0000 > From: bugzilla-noreply@freebsd.org > To: freebsd-fs@FreeBSD.org > Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedead= c0de) > Date: Sun, 25 Sep 2016 19:37:15 +0000 > = > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 My current theory is that some other ARM subsystem is allocating a piece of memory of the same size as one of the soft updates dependencies. The memory is freed by that subsystem and allocated by soft updates. While soft updates is using it the other ARM subsystem frees it a second time causing the dependency to be trashed. To test this theory, I have changed the soft updates allocator to keep its own private pool of structures (e.g., once allocated it is never returned). Since I have not created separate zones, it is still possible that it will get a piece of memory that will later be trashed, but that is much less likely. If the problem persists, I'll take the added step of creating zones. The patch is attached. Hopefully Andy can check it out if his latest fix fails to correct the problem. Kirk McKusick From owner-freebsd-fs@freebsd.org Tue Sep 27 20:53:29 2016 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 2279FC00711; Tue, 27 Sep 2016 20:53:29 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 D8428BBE; Tue, 27 Sep 2016 20:53:28 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id g192so16479323ywh.1; Tue, 27 Sep 2016 13:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=MpkR8xSNNjte7BBdwY3ZQgGfIMccdvr19OnWtcO8oVE=; b=TkgEAS1dsAN2TqJyU6bIN0FCcT0YgEjbaB5A2JwJdw/VBhO0jzP4xxpXnnGTNMK2Pv cWnVs6SUhr+wMoA3D9FTx9UCHLes2gQ02szS9FWKJptnWOtXaLPFthyfNlOXVNkc+sL7 NMqt4gWUBTzY5dKO0dSfQFtYu0hsqhGl8EWRZkeoWFCjMxvsJZ+OUpq0I5ZXKLlEncWY bUay/L3GL9O85XGtYL6RytPuIB+L0oCHdG20mbq945Ekx2MjE7BRlnxyvEgS3O8aacUT Kga/VB5qxX4JSenundVnLZvVw7HrDgeM5ttmaepGe/v4JredLao2GOBoVx6k6j/GCACN NaQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MpkR8xSNNjte7BBdwY3ZQgGfIMccdvr19OnWtcO8oVE=; b=L05NO3r/fRvoJF5jrph8+lRYpv8GvEeKznIWXmmWPINXtC3lFLOMFAgXzdraseSx/2 siWjos45A2j4n2Rsh/FBizH36lo7WkMchzJ+pjj1IV4E3sSDWBmDlNuYBhb7j/y1TL8A /kv5+2AxCoBp3w/CBTWbaTYGKzcjqpHercOqsgnTX5dxqfJ/UsLRrSsYe+YeB+49Jjte LLsmfY6bZQGRZ1l/oYzCcfvzZOyTxMcbDD8SoCM6airTMyOOGw8OY4XFir78pW7/e7QO DA1qN+2TkdtK0JJHyomEINg78ytcuwltc97S3rdDDvT6EhctLCpFH4T2GSdOShMrXR53 Nzjw== X-Gm-Message-State: AE9vXwOXAfZ8WLQmYAqLkoUUJ8wI6IPcblg9dPh6flPhfqULMmCRdOMPzFR7+PS9RKg1ZjtVAP0d+pBlpoqpnQ== X-Received: by 10.129.178.5 with SMTP id q5mr21332219ywh.246.1475009607896; Tue, 27 Sep 2016 13:53:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.18.213 with HTTP; Tue, 27 Sep 2016 13:53:27 -0700 (PDT) From: Ultima Date: Tue, 27 Sep 2016 16:53:27 -0400 Message-ID: Subject: zpool (online|replace|labelclear) issues, -f option also failing To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 27 Sep 2016 20:53:29 -0000 Hello, I am currently trying to replace a disk that was offlined and getting the following error: # zpool replace tank 14989197580381994958 gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification use '-f' to override the following errors: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool replace -f tank 14989197580381994958 gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool status tank pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: resilvered 1.10T in 9h4m with 0 errors on Tue Sep 20 00:33:32 2016 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2-0 ONLINE 0 0 0 gptid/8bdbd180-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c4df91d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8ccf21a3-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8d5521cb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8de13b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8e842f92-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 raidz2-1 DEGRADED 0 0 0 gptid/8bba4a82-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c26d491-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8ca3fea6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 14989197580381994958 OFFLINE 0 0 0 was /dev/diskid/DISK-********p2 gptid/8db26351-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8e4bfa70-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 raidz2-2 ONLINE 0 0 0 gptid/8b957b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c0340da-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c77ddcb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8cf6b7f1-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8d84b31e-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8e146dad-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 raidz2-3 ONLINE 0 0 0 gptid/8ebb39df-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8ef49770-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/2f94035d-7e9f-11e6-abe9-fcaa14edc6a6 ONLINE 0 0 0 gptid/8f69cf08-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8fa7c0a6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8fe7816d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 logs gptid/683dc146-f531-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 errors: No known data errors # glabel status | grep da14 gptid/24a57a9b-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p1 gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p2 diskid/DISK-******** N/A da14 # gpart show da13 da14 => 40 7814037088 da13 GPT (3.6T) 40 4194304 1 freebsd-swap (2.0G) 4194344 7809842784 2 freebsd-zfs (3.6T) => 40 7814037088 da14 GPT (3.6T) 40 4194304 1 freebsd-swap (2.0G) 4194344 7809842784 2 freebsd-zfs (3.6T) # uname -a FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r306300: Sat Sep 24 14:24:23 EDT 2016 root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG amd64 I recently offlined the device and after onlining it the label changed to geom. After a few reboots the pool started importing by diskid. After attempting to offline/online by gptid, would continue to fail with an error. I decided try to replace it and is also failing with the error above. I also wiped the first & last 2MB of the disk without success. Is they're a known issue or perhaps I'm missing something obvious? zpool labelclear is also providing a similar error. The -f options are not helping. Any ideas what my issue maybe? The error suggests it is currently active on the pool, however the offline should have changed that status correct? Ultima From owner-freebsd-fs@freebsd.org Wed Sep 28 10:57:43 2016 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 AB7CFC0062F; Wed, 28 Sep 2016 10:57:43 +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 6A37719AE; Wed, 28 Sep 2016 10:57:43 +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 1bpCJM-0005ud-MN; Wed, 28 Sep 2016 12:42:01 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, Ultima Subject: Re: zpool (online|replace|labelclear) issues, -f option also failing References: Date: Wed, 28 Sep 2016 12:42:00 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: 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: 96329e479c93ffb0716cf569fedf443d 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, 28 Sep 2016 10:57:43 -0000 Hi, As a start you can use these in /boot/loader.conf to prevent the confusion about gptid or disk_ident. I disabled gptid at my computer. But if I understand you would like to disable disk_ident. For ZFS it should not matter what you use. $ sysctl kern.geom.label kern.geom.label.disk_ident.enable: 1 kern.geom.label.gptid.enable: 0 kern.geom.label.gpt.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.ext2fs.enable: 1 kern.geom.label.debug: 0 Further. Does ZFS see 14989197580381994958 and gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 as the same disk? Zpool replace also has an option to replace the disk 'with itself'. Just provide it one parameter like this: # zpool replace tank 14989197580381994958 or # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 Does that help? Oh, while I read your mail again. You have 2 GB swap configured on the disk so wiping 2MB at the start of the disk does not wipe the freebsd-zfs metadata of the da14p2 partition. Try wiping 3GB from the start and end of the disk and repartition it. Success. Ronald. On Tue, 27 Sep 2016 22:53:27 +0200, Ultima wrote: > Hello, > > I am currently trying to replace a disk that was offlined and getting > the > following error: > > # zpool replace tank 14989197580381994958 > gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > invalid vdev specification > use '-f' to override the following errors: > /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool > 'tank' > > # zpool replace -f tank 14989197580381994958 > gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > invalid vdev specification > the following errors must be manually repaired: > /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool > 'tank' > > # zpool status tank > pool: tank > state: DEGRADED > status: One or more devices has been taken offline by the administrator. > Sufficient replicas exist for the pool to continue functioning in a > degraded state. > action: Online the device using 'zpool online' or replace the device with > 'zpool replace'. > scan: resilvered 1.10T in 9h4m with 0 errors on Tue Sep 20 00:33:32 > 2016 > config: > > NAME STATE READ WRITE > CKSUM > tank DEGRADED 0 0 > 0 > raidz2-0 ONLINE 0 0 0 > gptid/8bdbd180-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8c4df91d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8ccf21a3-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8d5521cb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8de13b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8e842f92-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > raidz2-1 DEGRADED 0 0 0 > gptid/8bba4a82-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8c26d491-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8ca3fea6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > 14989197580381994958 OFFLINE 0 0 0 > was /dev/diskid/DISK-********p2 > gptid/8db26351-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8e4bfa70-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > raidz2-2 ONLINE 0 0 0 > gptid/8b957b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8c0340da-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8c77ddcb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8cf6b7f1-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8d84b31e-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8e146dad-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > raidz2-3 ONLINE 0 0 0 > gptid/8ebb39df-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8ef49770-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/2f94035d-7e9f-11e6-abe9-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8f69cf08-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8fa7c0a6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > gptid/8fe7816d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > logs > gptid/683dc146-f531-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > > errors: No known data errors > > # glabel status | grep da14 > gptid/24a57a9b-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p1 > gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p2 > diskid/DISK-******** N/A da14 > > # gpart show da13 da14 > => 40 7814037088 da13 GPT (3.6T) > 40 4194304 1 freebsd-swap (2.0G) > 4194344 7809842784 2 freebsd-zfs (3.6T) > > => 40 7814037088 da14 GPT (3.6T) > 40 4194304 1 freebsd-swap (2.0G) > 4194344 7809842784 2 freebsd-zfs (3.6T) > > # uname -a > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r306300: Sat Sep 24 > 14:24:23 EDT 2016 > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > amd64 > > I recently offlined the device and after onlining it the label changed to > geom. After a few reboots the pool started importing by diskid. After > attempting to offline/online by gptid, would continue to fail with an > error. I decided try to replace it and is also failing with the error > above. I also wiped the first & last 2MB of the disk without success. Is > they're a known issue or perhaps I'm missing something obvious? zpool > labelclear is also providing a similar error. The -f options are not > helping. > > > Any ideas what my issue maybe? The error suggests it is currently active > on > the pool, however the offline should have changed that status correct? > > Ultima > _______________________________________________ > 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 Sep 28 23:00:44 2016 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 1C186C00B04; Wed, 28 Sep 2016 23:00:44 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 CF1109AF; Wed, 28 Sep 2016 23:00:43 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id i129so38332206ywb.0; Wed, 28 Sep 2016 16:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=L7T7g2cAVwgC+B5SUypGa6RrR07NC6NKO5/LevFl+qI=; b=rlrxkaple15bMahKGCkqL076NNeLr9rEHrlcC8+gPrHgcBYqV65JjYqKV/xVMPJGGA fgV80PDWNWNAWd9wmfR3N0uscCe1bwKhOUmmspS4yHwu1+lOoaI6N4V/8feMU4Q5094v Mp6efs2aG9/wCp78RJWKuPo7o4/hUCM8Qzi02CLm8jCxref9DXfAC4vPeUyS93qypPgO m5xIYNIk5GcMcFZDSnE7Pa9U0Vc1xEmPW2s/TDJ41bCK8vU+D/obU/ecLgwsb3gL8h2/ nDJdaaLQ2O1LIXHQKnP6AbI/54eRflPuLunL7C/y5mSB1dFiyjRXzCw62Wrq+Z/DJ3zu 6idQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=L7T7g2cAVwgC+B5SUypGa6RrR07NC6NKO5/LevFl+qI=; b=iNKVetoP4krr957gFMBaP29igpVLB0TMp6WZXNtytln3RDYCRu31QFZeifAcyX2itj VZ30DWoW9EEFMMADNPIqxBx252ymt3hBCfsM/U1yDRFKtp9xneJZk8RqYaF/jF1B/ROT AtLoHT5ZCM3tsklGqpfCQYmjeN96OH+Q6iNrEum45nbVhqnzm0O77ZYK6FNB0Je5qOAC n/VeKYl+2gag1sPNgemGaHs3/6macmI+Uyk4mUuS4ZzQPdHpzpbYGJ2+GRF6ywGm9FeE zlPIJ8tvWQQbvJq5iRrDemEno4JvpslvZVuPeB9vNuVGrg5E/Esp4t85tvSkHY9yqkO8 NO+A== X-Gm-Message-State: AE9vXwNYSeNzO/TatMv41uvQgbUS3yYfLI8tOeXmu8tlI4dfioYdWAguSuwbzHuhBs4juyqEMzZYgf+g+TRWbw== X-Received: by 10.129.124.130 with SMTP id x124mr27705857ywc.101.1475103643013; Wed, 28 Sep 2016 16:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.18.213 with HTTP; Wed, 28 Sep 2016 16:00:42 -0700 (PDT) In-Reply-To: References: From: Ultima Date: Wed, 28 Sep 2016 19:00:42 -0400 Message-ID: Subject: Re: zpool (online|replace|labelclear) issues, -f option also failing To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 28 Sep 2016 23:00:44 -0000 > Hi, > As a start you can use these in /boot/loader.conf to prevent the confusion about gptid or disk_ident. I disabled gptid at my computer. But if > I understand you would like to disable disk_ident. For ZFS it should not matter what you use. > $ sysctl kern.geom.label > kern.geom.label.disk_ident.enable: 1 > kern.geom.label.gptid.enable: 0 > kern.geom.label.gpt.enable: 1 > kern.geom.label.ufs.enable: 1 > kern.geom.label.ufsid.enable: 1 > kern.geom.label.reiserfs.enable: 1 > kern.geom.label.ntfs.enable: 1 > kern.geom.label.msdosfs.enable: 1 > kern.geom.label.iso9660.enable: 1 > kern.geom.label.ext2fs.enable: 1 > kern.geom.label.debug: 0 Thanks for that, this would probably work, but I don't understand why it would change in the first place. I know that when it occurred it was offline and I think it came back online when the system was rebooted. I'm not positive tho. My guess is the scan found it on diskid before dptid, but then why is gptid first for the others? I'm just going to replace the drive with itself with gptid because I'v already wiped some data with dd. (even tho a scrub would prob be good enough) > Further. Does ZFS see 14989197580381994958 and gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 as the same disk? Zpool replace also has an option to replace the disk 'with itself'. Just provide it one parameter like this: > # zpool replace tank 14989197580381994958 > or > # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > Does that help? I actually didn't realize this. However the same error persists. # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool replace -f tank /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' > Oh, while I read your mail again. You have 2 GB swap configured on the disk so wiping 2MB at the start of the disk does not wipe the freebsd-zfs metadata of the da14p2 partition. Try wiping 3GB from the start and end of the disk and repartition it. Thanks for pointing this out! It would probably help if the correct area on the disk is wiped. Although it still seems that labelclear isn't up for the task. I really think the force (-f) flag needs a bump in power (for both replace and labelclear). Am I misunderstanding the use for the labelclear command? It clears the label that zdb will show for possibly similar circumstances that i'm encountering? # zpool labelclear -f gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is a member (ACTIVE) of pool "tank" Apologies, I failed to mention labelclear in my original post. It is providing similar output as the replace command. As the device is offline from the pool. Is this the correct behavior to show being an (ACTIVE) member of the pool? After wiping the correct area on the disk via dd, the replace successfully added the drive back to the pool! Thanks for pointing out my error. Thanks for taking a look at this Ronald and Allan! Ultima From owner-freebsd-fs@freebsd.org Thu Sep 29 12:24:56 2016 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 05D3AC02E0D; Thu, 29 Sep 2016 12:24:56 +0000 (UTC) (envelope-from martymac@FreeBSD.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C962266B; Thu, 29 Sep 2016 12:24:55 +0000 (UTC) (envelope-from martymac@FreeBSD.org) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id 0F7171FA5CD3; Thu, 29 Sep 2016 14:24:54 +0200 (CEST) From: "Ganael LAPLANCHE" To: Ultima Cc: freebsd-current@freebsd.org,freebsd-fs@freebsd.org Subject: Re: zpool (online|replace|labelclear) issues, -f option also failing X-Openwebmail-Date: Thu, 29 Sep 2016 14:24:54 +0100 Message-Id: <20160929121325.M80322@martymac.org> In-Reply-To: References: X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 109.190.254.5 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 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: , Date: Thu, 29 Sep 2016 12:24:56 -0000 X-List-Received-Date: Thu, 29 Sep 2016 12:24:56 -0000 On Wed, 28 Sep 2016 19:00:42 -0400, Ultima wrote Hi Ultima, > I really think the force (-f) flag needs a bump in power (for both > replace and labelclear) [...]. In case you are interested, I have posted a patch to improve the 'zpool labelclear' command here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 - force ('-f') will now allow to erase labels, even if they are broken (restoring the behaviour of our previous -FreeBSD- version of labelclear) - You can select which label you want to erase (beginning, end or specific index) - You can use a 'minimal' mode which will invalidate a label by changing only a single byte. This is useful to minimize the chances to overwrite/destroy a FS that would have been created over the label, but still leaving the label visible. Regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-fs@freebsd.org Thu Sep 29 18:13:53 2016 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 B68D0C02872 for ; Thu, 29 Sep 2016 18:13:53 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 740F7A77 for ; Thu, 29 Sep 2016 18:13:53 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yb0-x236.google.com with SMTP id e2so20224294ybi.1 for ; Thu, 29 Sep 2016 11:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=0RrOPJRAKg4HvXLy1IRJvdoYZ5p5SDAF8rWNZpmablI=; b=uj2JYEUIDEBhmVZW9XgdA5N6QuLruGQ2wGRW1pbwneopvrACCASGLdNX8dV4Zmkrhn acxl3FAWmNELUs2XYa5Ts0BBxHE0xl7mMqkz4SrLTfea5RzHDKyOWyrDbt1SoES60iOf nqbyQlgnsM51Cc6F7e7x571NZOR9Ab6PheRBrfSHm9vs3kXJWG7uQa/iXt7EqXWnsn8B wItbr7p19dzIsQOxG+MQ8AvmxjKv3fsG9PpAnjK7BdtBhHlbybXUA4uI8ZJ5MQy/m0po IjS59ghSM4jnLxjnAENAsFFDUMvJ9kES+yrySA37kKbATLVX14HfGKUDItSLM5GoRHmg vJUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=0RrOPJRAKg4HvXLy1IRJvdoYZ5p5SDAF8rWNZpmablI=; b=UEDO9FZ35dtra5EJPQkGTBW47GecVW52cqWepLa91NnWkANqOUroaK0eLV7C1ICpmp rqJMJakJLGnInjz8HpXJh/AoJouxLaFyJjwGkdlkqn6phCjupYch+Xy/qJVct0bB292X wp1qgp8bU3wjp3PNev4wrYiuHvynm5mtXoGQM2A/k/ieLAcnNRUtkJw9fCdKHLHfMoOM kOEMIcxr1iGwGY2Spey3+0qi1cio/LrsqRxZf3tdvPqzCLqBc5mdGyHw5umaFTEzGID4 IV715msybLdqmE+t9sbJTETpCEsWtMbaIPTk0z0YpqLUsIbdFKBx9yC0wh+bU6JHdUph jh+g== X-Gm-Message-State: AA6/9RnALD66UAtwIXGJf545vs8SF3+T4TM2RXief043WA5z8uBSRgC+izxvjeNHcRbv+2Lf/SbR6jcv/CE5oQ== X-Received: by 10.37.217.204 with SMTP id q195mt1018009ybg.97.1475172832598; Thu, 29 Sep 2016 11:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.18.213 with HTTP; Thu, 29 Sep 2016 11:13:52 -0700 (PDT) In-Reply-To: <20160929121325.M80322@martymac.org> References: <20160929121325.M80322@martymac.org> From: Ultima Date: Thu, 29 Sep 2016 14:13:52 -0400 Message-ID: Subject: Re: zpool (online|replace|labelclear) issues, -f option also failing Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 29 Sep 2016 18:13:53 -0000 This patch looks good its too bad the core hasn't looked at it yet. Ill do some testing and report any issues found. Some points you bring up in the bug are quite valid. Thanks for working on this! =] Ultima On Thu, Sep 29, 2016 at 8:25 AM, Ganael LAPLANCHE wrote: > On Wed, 28 Sep 2016 19:00:42 -0400, Ultima wrote > > Hi Ultima, > > > I really think the force (-f) flag needs a bump in power (for both > > replace and labelclear) [...]. > > In case you are interested, I have posted a patch to improve the 'zpool > labelclear' command here : > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 > > - force ('-f') will now allow to erase labels, even if they are broken > (restoring the behaviour of our previous -FreeBSD- version of labelclear) > - You can select which label you want to erase (beginning, end or > specific index) > - You can use a 'minimal' mode which will invalidate a label by changing > only a single byte. This is useful to minimize the chances to > overwrite/destroy a FS that would have been created over the label, but > still leaving the label visible. > > Regards, > > -- > Ganael LAPLANCHE > http://www.martymac.org | http://contribs.martymac.org > FreeBSD: martymac , http://www.FreeBSD.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Fri Sep 30 06:43:05 2016 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 51751C03214 for ; Fri, 30 Sep 2016 06:43: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 408FC775 for ; Fri, 30 Sep 2016 06:43: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 u8U6h4r7028926 for ; Fri, 30 Sep 2016 06:43:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 213112] [zfs] [panic] solaris assert: !RRM_LOCK_HELD(&zfsvfs->z_teardown_lock), file zfs_vnops.c, line 1457 (5978) Date: Fri, 30 Sep 2016 06:43:05 +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 Only Me X-Bugzilla-Who: avos@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: Fri, 30 Sep 2016 06:43:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213112 Andriy Voskoboinyk 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 Fri Sep 30 06:43:57 2016 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 B0770C0333A for ; Fri, 30 Sep 2016 06:43:57 +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 9FC098A7 for ; Fri, 30 Sep 2016 06:43:57 +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 u8U6hvJK030646 for ; Fri, 30 Sep 2016 06:43:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 213112] [zfs] [panic] solaris assert: !RRM_LOCK_HELD(&zfsvfs->z_teardown_lock), file zfs_vnops.c, line 1457 (5978) Date: Fri, 30 Sep 2016 06:43:57 +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 Only Me X-Bugzilla-Who: avos@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: attachments.created 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: Fri, 30 Sep 2016 06:43:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213112 --- Comment #1 from Andriy Voskoboinyk --- Created attachment 175299 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D175299&action= =3Dedit LOR + panic with sys_extattr_get_file() --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Sep 30 06:45:30 2016 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 858CEC0341B for ; Fri, 30 Sep 2016 06:45:30 +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 75529A63 for ; Fri, 30 Sep 2016 06:45:30 +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 u8U6jULP033992 for ; Fri, 30 Sep 2016 06:45:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 213068] [smbfs] panic in smbfs.ko during operations Date: Fri, 30 Sep 2016 06:45:30 +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.2-STABLE 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: Fri, 30 Sep 2016 06:45:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213068 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 Fri Sep 30 09:56:59 2016 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 50524C0148E; Fri, 30 Sep 2016 09:56:59 +0000 (UTC) (envelope-from martymac@FreeBSD.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1184519A9; Fri, 30 Sep 2016 09:56:59 +0000 (UTC) (envelope-from martymac@FreeBSD.org) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id 29F0F1FA5CFC; Fri, 30 Sep 2016 11:56:57 +0200 (CEST) From: "Ganael LAPLANCHE" To: Ultima Cc: freebsd-current@freebsd.org,freebsd-fs@freebsd.org Subject: Re: [patch] Improving the 'zpool labelclear' command X-Openwebmail-Date: Fri, 30 Sep 2016 11:56:57 +0100 Message-Id: <20160930095205.M29574@martymac.org> In-Reply-To: References: <20160929121325.M80322@martymac.org> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 109.190.254.5 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 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: , Date: Fri, 30 Sep 2016 09:56:59 -0000 X-List-Received-Date: Fri, 30 Sep 2016 09:56:59 -0000 On Thu, 29 Sep 2016 14:13:52 -0400, Ultima wrote > > In case you are interested, I have posted a patch to improve the 'zpool > > labelclear' command here : > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 > > > > - force ('-f') will now allow to erase labels, even if they are broken > > (restoring the behaviour of our previous -FreeBSD- version of labelclear) > > - You can select which label you want to erase (beginning, end or > > specific index) > > - You can use a 'minimal' mode which will invalidate a label by changing > > only a single byte. This is useful to minimize the chances to > > overwrite/destroy a FS that would have been created over the label, but > > still leaving the label visible. > > This patch looks good its too bad the core hasn't looked at it > yet. Ill do some testing and report any issues found. Some > points you bring up in the bug are quite valid. Thanks for > working on this! =] Thanks. Yes, it would be nice if a src committer could take a look at it. Any feedback welcome :) -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-fs@freebsd.org Fri Sep 30 13:27:34 2016 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 6456CC02B66 for ; Fri, 30 Sep 2016 13:27:34 +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 541D3637 for ; Fri, 30 Sep 2016 13:27:34 +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 u8UDRYuh009245 for ; Fri, 30 Sep 2016 13:27:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) Date: Fri, 30 Sep 2016 13:27:34 +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: 11.0-RC1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: mckusick@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: Fri, 30 Sep 2016 13:27:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 --- Comment #18 from Kirk McKusick --- (In reply to Andrew Turner from comment #14) Has your addition of an atomic memory barrier into worklist_insert and worklist_remove solved the problem? If not, have you had a chance to test t= he patch that I sent to you to isolate the soft updates malloc pool? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Sep 30 14:28:34 2016 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 E8315C034C3 for ; Fri, 30 Sep 2016 14:28:34 +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 D792BB84 for ; Fri, 30 Sep 2016 14:28:34 +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 u8UESYwD090170 for ; Fri, 30 Sep 2016 14:28:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 213112] [zfs] [panic] solaris assert: !RRM_LOCK_HELD(&zfsvfs->z_teardown_lock), file zfs_vnops.c, line 1457 (5978) Date: Fri, 30 Sep 2016 14:28:35 +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 Only Me X-Bugzilla-Who: avg@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: Fri, 30 Sep 2016 14:28:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213112 --- Comment #2 from Andriy Gapon --- It seems that you have DIAGNOSTIC turned on. Thank you for testing! You can remove sections guarded with DIAGNOSTIC in zfs_vnops.c to fix the panic. The checks done there are simply incorrect for extended attributes. See https://svnweb.freebsd.org/changeset/base/306292 for a note about that. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Sep 30 14:29:05 2016 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 28855C0353C for ; Fri, 30 Sep 2016 14:29: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 17C95C0E for ; Fri, 30 Sep 2016 14:29: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 u8UET4Bf090842 for ; Fri, 30 Sep 2016 14:29:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 213112] [zfs] [panic] solaris assert: !RRM_LOCK_HELD(&zfsvfs->z_teardown_lock), file zfs_vnops.c, line 1457 (5978) Date: Fri, 30 Sep 2016 14:29:05 +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 Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: avg@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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: Fri, 30 Sep 2016 14:29:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213112 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Assignee|freebsd-fs@FreeBSD.org |avg@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Oct 1 04:42:27 2016 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 6852BC04B8B for ; Sat, 1 Oct 2016 04:42:27 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from hz.citrin.ru (hz.citrin.ru [88.198.212.3]) (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 2D5F8676 for ; Sat, 1 Oct 2016 04:42:26 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [IPv6:2601:18a:c301:8eee:e07a:e3b6:a7ad:cc68] (unknown [IPv6:2601:18a:c301:8eee:e07a:e3b6:a7ad:cc68]) (Authenticated sender: citrin@citrin.ru) by hz.citrin.ru (Postfix) with ESMTPSA id 0D37B2874D1 for ; Sat, 1 Oct 2016 04:42:22 +0000 (UTC) To: "freebsd-fs@freebsd.org" From: Anton Yuzhaninov Subject: UFS: unaligned read from GELI with 8k sectorsize Message-ID: Date: Sat, 1 Oct 2016 00:42:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrin.ru; s=s0; t=1475296943; bh=b7iK9Hnd4NWHi9pFfWD6F/rtfynbeZC8BJomI41WyCk=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HlNNTW2dJzWi4xBuyDTLUJqINymVjO9ehss17i8T8EmmazBfCP/0gtEt3G27R/BhxeO0CobF0rPDofKopAKHe8xPHzvzXA3xjwPr9WJCENiroEtPCW+4ZvDEn+zdERhYjxT0WITWMJeRyB/lhfsHLGCgjXuO9KMj0aq4zILs1kA= 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, 01 Oct 2016 04:42:27 -0000 Hi all. I'm trying to install FreeBSD with an encrypted root. Main difference from commonly used configuration - I want to use geli with 8k sectorsize. I've created a geli provider, made UFS with 64k block and 8k fragment, extracted files to this FS. While booting from installed system kernel panics after entering geli passphrase: g_vfs_done():ada1p6.eli:[READ(offset=21938548736, length=8192)]error = 22 vnode_page_generic_gatpager_done: I/O read error 5 inid died (signal 6, exit 0) panic: Going nowhere without my init! errno 22 is EINVAL and it probably returned because 21938548736 is not multiple of 8192 (geli sectorsize). Why UFS tries to read with offset, which is not multiple of frag size? And why this error happens only while mounting geli as root? If I boot FreeBSD from a USB stick I can attach this geli, mount UFS and read all files without problem. FreeBSD 11 / amd64. From owner-freebsd-fs@freebsd.org Sat Oct 1 11:45:51 2016 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 BA453C04221 for ; Sat, 1 Oct 2016 11:45:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 38EFD1EE1 for ; Sat, 1 Oct 2016 11:45:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u91BjatU091694 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 1 Oct 2016 14:45:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u91BjatU091694 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u91BjanM091691; Sat, 1 Oct 2016 14:45:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 1 Oct 2016 14:45:36 +0300 From: Konstantin Belousov To: Anton Yuzhaninov Cc: "freebsd-fs@freebsd.org" Subject: Re: UFS: unaligned read from GELI with 8k sectorsize Message-ID: <20161001114536.GX38409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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, 01 Oct 2016 11:45:51 -0000 On Sat, Oct 01, 2016 at 12:42:09AM -0400, Anton Yuzhaninov wrote: > Hi all. > > I'm trying to install FreeBSD with an encrypted root. > > Main difference from commonly used configuration - I want to use geli > with 8k sectorsize. > > I've created a geli provider, made UFS with 64k block and 8k fragment, > extracted files to this FS. > > While booting from installed system kernel panics after entering geli > passphrase: > > g_vfs_done():ada1p6.eli:[READ(offset=21938548736, length=8192)]error = 22 > vnode_page_generic_gatpager_done: I/O read error 5 > inid died (signal 6, exit 0) > panic: Going nowhere without my init! > > errno 22 is EINVAL and it probably returned because 21938548736 is not > multiple of 8192 (geli sectorsize). > > Why UFS tries to read with offset, which is not multiple of frag size? > And why this error happens only while mounting geli as root? If I boot > FreeBSD from a USB stick I can attach this geli, mount UFS and read all > files without problem. > > FreeBSD 11 / amd64. FreeBSD vnode pager assumes that it can read at page granularity. Since x86 page size is 4k, sometimes page-in has to occur not on the fragment boundary. In other words, fragment size > 4k are effectively not supported. Boot needs to execute files from the root mount, which results in the mmap(2) attempts on your file system. While mount and reads/writes do not involve the pager, which does not trigger further bugs in the buffer cache code. It should break if you try to execute badly aligned ELF binary from your stick, or just mmap() a file from the stick with non-8k aligned offset. From owner-freebsd-fs@freebsd.org Sat Oct 1 11:54:55 2016 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 B0470C043DA for ; Sat, 1 Oct 2016 11:54:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 51E071213 for ; Sat, 1 Oct 2016 11:54:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u91BsdkH093907 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 1 Oct 2016 14:54:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u91BsdkH093907 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u91BsdW6093906; Sat, 1 Oct 2016 14:54:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 1 Oct 2016 14:54:39 +0300 From: Konstantin Belousov To: Anton Yuzhaninov Cc: "freebsd-fs@freebsd.org" Subject: Re: UFS: unaligned read from GELI with 8k sectorsize Message-ID: <20161001115439.GY38409@kib.kiev.ua> References: <20161001114536.GX38409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161001114536.GX38409@kib.kiev.ua> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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, 01 Oct 2016 11:54:55 -0000 On Sat, Oct 01, 2016 at 02:45:36PM +0300, Konstantin Belousov wrote: > On Sat, Oct 01, 2016 at 12:42:09AM -0400, Anton Yuzhaninov wrote: > > Hi all. > > > > I'm trying to install FreeBSD with an encrypted root. > > > > Main difference from commonly used configuration - I want to use geli > > with 8k sectorsize. > > > > I've created a geli provider, made UFS with 64k block and 8k fragment, > > extracted files to this FS. > > > > While booting from installed system kernel panics after entering geli > > passphrase: > > > > g_vfs_done():ada1p6.eli:[READ(offset=21938548736, length=8192)]error = 22 > > vnode_page_generic_gatpager_done: I/O read error 5 > > inid died (signal 6, exit 0) > > panic: Going nowhere without my init! > > > > errno 22 is EINVAL and it probably returned because 21938548736 is not > > multiple of 8192 (geli sectorsize). > > > > Why UFS tries to read with offset, which is not multiple of frag size? > > And why this error happens only while mounting geli as root? If I boot > > FreeBSD from a USB stick I can attach this geli, mount UFS and read all > > files without problem. > > > > FreeBSD 11 / amd64. > > FreeBSD vnode pager assumes that it can read at page granularity. > Since x86 page size is 4k, sometimes page-in has to occur not on the > fragment boundary. In other words, fragment size > 4k are effectively > not supported. > > Boot needs to execute files from the root mount, which results in the > mmap(2) attempts on your file system. While mount and reads/writes do > not involve the pager, which does not trigger further bugs in the > buffer cache code. It should break if you try to execute badly aligned > ELF binary from your stick, or just mmap() a file from the stick with > non-8k aligned offset. It might be not too hard to make this case working, although the speed of the pagein will be detrimental. Try this, please. diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c index a80a9c2..01e2ea2 100644 --- a/sys/vm/vnode_pager.c +++ b/sys/vm/vnode_pager.c @@ -796,7 +796,7 @@ vnode_pager_generic_getpages(struct vnode *vp, vm_page_t *m, int count, * getting pages via VOP_READ. */ error = VOP_BMAP(vp, foff / bsize, &bo, &bp->b_blkno, &after, &before); - if (error == EOPNOTSUPP) { + if (error == EOPNOTSUPP || (error == 0 && bo->bo_bsize > PAGE_SIZE)) { relpbuf(bp, freecnt); VM_OBJECT_WLOCK(object); for (i = 0; i < count; i++) { From owner-freebsd-fs@freebsd.org Sat Oct 1 16:04:06 2016 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 0B97FC0538B; Sat, 1 Oct 2016 16:04:06 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id E4F26126D; Sat, 1 Oct 2016 16:04:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Sat, 01 Oct 2016 18:02:59 +0200 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 8162B673-F8D6-4535-AEF2-116319825659.1 envelope-from (authenticated bits=0); Sat, 01 Oct 2016 18:02:47 +0200 From: Rainer Duffner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: zfs receive leads to a stuck server Date: Sat, 1 Oct 2016 18:02:40 +0200 Message-Id: <4707908B-4868-4AA6-ADD6-D24121EFAE38@ultra-secure.de> Cc: freebsd-stable To: FreeBSD Filesystems Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=12 total_conn=1 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 1257, bad: 1, connections: 1567, history: 1256, asn_score: 736, asn_connections: 826, asn_good: 738, asn_bad: 2, pass:asn, relaying 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, 01 Oct 2016 16:04:06 -0000 Hi, I posted this before, but I didn=E2=80=99t really get an answer and = I=E2=80=99m still looking for ways to debug this. I have to servers (HP DL 380 Gen8, 192 GB RAM, 6C CPU). I=E2=80=99ve outfitted them with HP=E2=80=99s H22x cards (really OEMed = 9207-8x, three altogether) that I recently cross-flashed to LSI=E2=80=99s = latest firmware. They have: - 14 600GB SAS disks in their internal cages (2x ZFs mirror to boot = from and 2x RAIDZ2) - another 12 1200 GB SAS disks in an external HP 2700 enclosure (2x = RAID-Z2) - all the RAID Z2s together form a single zpool These are NFS-servers (master + warm standby) and MySQL slaves. The client uses the NFS-server and previously used both MySQL-Slaves for = SELECT queries only (via a middleware that seems to be able to sort this = out). When this system was built, we had twelve single RAID0 logical volumes = on HP P4x0 RAID-controllers (with 2 GB cache), merged into two RAID-Z2 = vdevs for storage (and a RAID1 boot-drive). However, the customer outgrew that solution and because there are no = native HP utilities for managing the RAID-cards on FreeBSD, each time a = drive dies on such a setup, you have to reboot the server to make sure = ZFS =E2=80=9Esees=E2=80=9C the new drive (go into adapter BIOS, destroy = RAID, create RAID=E2=80=A6). So, I switched to LSI-type JBOD HBAs. I had to re-install both servers from scratch, obviously, and also = upgraded to 10.3 (from 10.1). I have zfsnap (sysutils/zfsnap) create hourly, daily and weekly = snapshots that I transfer via zxfer from server1 to server2. Previously, this only took a couple of seconds. But since I switched to = LSI HBAs, it=E2=80=99s taking longer - even though the deltas are really = small in most cases. After 03:00 AM, when zfsnap deletes some snapshots on the source system, = it even takes several minutes to zxfer the snapshots. At that point, it=E2=80=99s really noticeable that the 2nd system = complete freezes. The first system (that zfs sends) is absolutely = unaffected and continues like normal. I=E2=80=99ve setup a cron-job that outputs iostat and vmstat into = second-timestamped files and a few seconds after the zxfer starts, it = doesn=E2=80=99t generate any new files until shortly before it finishes. With these hangs, the customer can=E2=80=99t use the 2nd MySQL-server = and is thus unhappy. I=E2=80=99ve upgraded to 11.0-RELEAE on the 2nd system - but it hasn=E2=80= =99t helped (it might even be slower actually). How can I debug this? What=E2=80=99s the best way forward? I don=E2=80=99t have any ZFS errors (checksum etc.). So, I doubt it=E2=80=99= s a cable. Here=E2=80=99s various system information ------------------------------------------------------------------------ ZFS Subsystem Report Sat Oct 1 17:50:48 2016 ------------------------------------------------------------------------ System Information: Kernel Version: 1100122 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 5000 ZFS Filesystem Version: 5 FreeBSD 11.0-RELEASE #0 r306211: Thu Sep 22 21:43:30 UTC 2016 root 5:50PM up 2 days, 19:50, 1 users, load averages: 0.11, 0.09, 0.08 ------------------------------------------------------------------------ System Memory: 0.26% 506.77 MiB Active, 11.52% 21.54 GiB Inact 62.29% 116.49 GiB Wired, 0.00% 0 Cache 25.93% 48.49 GiB Free, 0.00% 0 Gap Real Installed: 192.00 GiB Real Available: 99.96% 191.93 GiB Real Managed: 97.44% 187.01 GiB Logical Total: 192.00 GiB Logical Used: 63.53% 121.97 GiB Logical Free: 36.47% 70.03 GiB Kernel Memory: 2.15 GiB Data: 98.41% 2.12 GiB Text: 1.59% 35.02 MiB Kernel Memory Map: 187.01 GiB Size: 40.16% 75.10 GiB Free: 59.84% 111.92 GiB ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 2.16m Recycle Misses: 0 Mutex Misses: 1.92k Evict Skips: 54.73k ARC Size: 64.39% 41.21 GiB Target Size: (Adaptive) 100.00% 64.00 GiB Min Size (Hard Limit): 36.33% 23.25 GiB Max Size (High Water): 2:1 64.00 GiB ARC Size Breakdown: Recently Used Cache Size: 89.29% 57.14 GiB Frequently Used Cache Size: 10.71% 6.86 GiB ARC Hash Breakdown: Elements Max: 5.37m Elements Current: 92.43% 4.97m Collisions: 2.58m Chain Max: 5 Chains: 333.76k ------------------------------------------------------------------------ ARC Efficiency: 265.65m Cache Hit Ratio: 61.83% 164.25m Cache Miss Ratio: 38.17% 101.40m Actual Hit Ratio: 55.18% 146.57m Data Demand Efficiency: 10.17% 7.66m Data Prefetch Efficiency: 0.00% 32 CACHE HITS BY CACHE LIST: Anonymously Used: 8.77% 14.41m Most Recently Used: 29.22% 48.00m Most Frequently Used: 60.02% 98.58m Most Recently Used Ghost: 1.67% 2.74m Most Frequently Used Ghost: 0.33% 536.90k CACHE HITS BY DATA TYPE: Demand Data: 0.47% 778.95k Prefetch Data: 0.00% 0 Demand Metadata: 88.30% 145.04m Prefetch Metadata: 11.22% 18.43m CACHE MISSES BY DATA TYPE: Demand Data: 6.79% 6.88m Prefetch Data: 0.00% 32 Demand Metadata: 84.42% 85.60m Prefetch Metadata: 8.79% 8.91m ------------------------------------------------------------------------ L2ARC is disabled ------------------------------------------------------------------------ File-Level Prefetch: (HEALTHY) DMU Efficiency: 970.94m Hit Ratio: 0.22% 2.09m Miss Ratio: 99.78% 968.85m Colinear: 0 Hit Ratio: 100.00% 0 Miss Ratio: 100.00% 0 Stride: 0 Hit Ratio: 100.00% 0 Miss Ratio: 100.00% 0 DMU Misc: Reclaim: 0 Successes: 100.00% 0 Failures: 100.00% 0 Streams: 0 +Resets: 100.00% 0 -Resets: 100.00% 0 Bogus: 0 ------------------------------------------------------------------------ VDEV cache is disabled ------------------------------------------------------------------------ ZFS Tunables (sysctl): kern.maxusers 12619 vm.kmem_size 200803987456 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 1319413950874 vfs.zfs.trim.max_interval 1 vfs.zfs.trim.timeout 30 vfs.zfs.trim.txg_delay 32 vfs.zfs.trim.enabled 1 vfs.zfs.vol.unmap_enabled 1 vfs.zfs.vol.recursive 0 vfs.zfs.vol.mode 1 vfs.zfs.version.zpl 5 vfs.zfs.version.spa 5000 vfs.zfs.version.acl 1 vfs.zfs.version.ioctl 6 vfs.zfs.debug 1 vfs.zfs.super_owner 0 vfs.zfs.sync_pass_rewrite 2 vfs.zfs.sync_pass_dont_compress 5 vfs.zfs.sync_pass_deferred_free 2 vfs.zfs.zio.exclude_metadata 0 vfs.zfs.zio.use_uma 1 vfs.zfs.cache_flush_disable 0 vfs.zfs.zil_replay_disable 0 vfs.zfs.min_auto_ashift 12 vfs.zfs.max_auto_ashift 13 vfs.zfs.vdev.trim_max_pending 10000 vfs.zfs.vdev.bio_delete_disable 0 vfs.zfs.vdev.bio_flush_disable 0 vfs.zfs.vdev.write_gap_limit 4096 vfs.zfs.vdev.read_gap_limit 32768 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.trim_max_active 64 vfs.zfs.vdev.trim_min_active 1 vfs.zfs.vdev.scrub_max_active 2 vfs.zfs.vdev.scrub_min_active 1 vfs.zfs.vdev.async_write_max_active 10 vfs.zfs.vdev.async_write_min_active 1 vfs.zfs.vdev.async_read_max_active 3 vfs.zfs.vdev.async_read_min_active 1 vfs.zfs.vdev.sync_write_max_active 10 vfs.zfs.vdev.sync_write_min_active 10 vfs.zfs.vdev.sync_read_max_active 10 vfs.zfs.vdev.sync_read_min_active 10 vfs.zfs.vdev.max_active 1000 vfs.zfs.vdev.async_write_active_max_dirty_percent60 vfs.zfs.vdev.async_write_active_min_dirty_percent30 vfs.zfs.vdev.mirror.non_rotating_seek_inc1 vfs.zfs.vdev.mirror.non_rotating_inc 0 vfs.zfs.vdev.mirror.rotating_seek_offset1048576 vfs.zfs.vdev.mirror.rotating_seek_inc 5 vfs.zfs.vdev.mirror.rotating_inc 0 vfs.zfs.vdev.trim_on_init 1 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.cache.size 0 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.metaslabs_per_vdev 200 vfs.zfs.txg.timeout 5 vfs.zfs.space_map_blksz 4096 vfs.zfs.spa_slop_shift 5 vfs.zfs.spa_asize_inflation 24 vfs.zfs.deadman_enabled 1 vfs.zfs.deadman_checktime_ms 5000 vfs.zfs.deadman_synctime_ms 1000000 vfs.zfs.debug_flags 0 vfs.zfs.recover 0 vfs.zfs.spa_load_verify_data 1 vfs.zfs.spa_load_verify_metadata 1 vfs.zfs.spa_load_verify_maxinflight 10000 vfs.zfs.ccw_retry_interval 300 vfs.zfs.check_hostid 1 vfs.zfs.mg_fragmentation_threshold 85 vfs.zfs.mg_noalloc_threshold 0 vfs.zfs.condense_pct 200 vfs.zfs.metaslab.bias_enabled 1 vfs.zfs.metaslab.lba_weighting_enabled 1 vfs.zfs.metaslab.fragmentation_factor_enabled1 vfs.zfs.metaslab.preload_enabled 1 vfs.zfs.metaslab.preload_limit 3 vfs.zfs.metaslab.unload_delay 8 vfs.zfs.metaslab.load_pct 50 vfs.zfs.metaslab.min_alloc_size 33554432 vfs.zfs.metaslab.df_free_pct 4 vfs.zfs.metaslab.df_alloc_threshold 131072 vfs.zfs.metaslab.debug_unload 0 vfs.zfs.metaslab.debug_load 0 vfs.zfs.metaslab.fragmentation_threshold70 vfs.zfs.metaslab.gang_bang 16777217 vfs.zfs.free_bpobj_enabled 1 vfs.zfs.free_max_blocks -1 vfs.zfs.no_scrub_prefetch 0 vfs.zfs.no_scrub_io 0 vfs.zfs.resilver_min_time_ms 3000 vfs.zfs.free_min_time_ms 1000 vfs.zfs.scan_min_time_ms 1000 vfs.zfs.scan_idle 50 vfs.zfs.scrub_delay 4 vfs.zfs.resilver_delay 2 vfs.zfs.top_maxinflight 32 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.zfetch.max_distance 8388608 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.max_streams 8 vfs.zfs.prefetch_disable 0 vfs.zfs.delay_scale 500000 vfs.zfs.delay_min_dirty_percent 60 vfs.zfs.dirty_data_sync 67108864 vfs.zfs.dirty_data_max_percent 10 vfs.zfs.dirty_data_max_max 4294967296 vfs.zfs.dirty_data_max 4294967296 vfs.zfs.max_recordsize 1048576 vfs.zfs.mdcomp_disable 0 vfs.zfs.nopwrite_enabled 1 vfs.zfs.dedup.prefetch 1 vfs.zfs.l2c_only_size 0 vfs.zfs.mfu_ghost_data_lsize 57031680 vfs.zfs.mfu_ghost_metadata_lsize 24999013888 vfs.zfs.mfu_ghost_size 25056045568 vfs.zfs.mfu_data_lsize 7619584 vfs.zfs.mfu_metadata_lsize 2427032064 vfs.zfs.mfu_size 7355872768 vfs.zfs.mru_ghost_data_lsize 0 vfs.zfs.mru_ghost_metadata_lsize 27116232704 vfs.zfs.mru_ghost_size 27116232704 vfs.zfs.mru_data_lsize 12935902208 vfs.zfs.mru_metadata_lsize 18539549696 vfs.zfs.mru_size 31494193152 vfs.zfs.anon_data_lsize 0 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_size 233472 vfs.zfs.l2arc_norw 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_noprefetch 1 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_write_boost 8388608 vfs.zfs.l2arc_write_max 8388608 vfs.zfs.arc_meta_limit 17179869184 vfs.zfs.arc_free_target 339900 vfs.zfs.arc_shrink_shift 7 vfs.zfs.arc_average_blocksize 8192 vfs.zfs.arc_min 24966280704 vfs.zfs.arc_max 68719476736 = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94 Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-RELEASE #0 r306211: Thu Sep 22 21:43:30 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on = LLVM 3.8.0) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz (2294.52-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x206d7 Family=3D0x6 Model=3D0x2d = Stepping=3D7 = Features=3D0xbfebfbff = Features2=3D0x1fbee3ff AMD Features=3D0x2c100800 AMD Features2=3D0x1 XSAVE Features=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory =3D 206158430208 (196608 MB) avail memory =3D 200330240000 (191049 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 hardware threads random: unblocking device. ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, = using default 16 (20160527/tbfadt-733) ACPI BIOS Warning (bug): Invalid length for FADT/Pm2ControlBlock: 32, = using default 8 (20160527/tbfadt-733) ioapic1 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff8101c950, 0) error 19 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: numa-domain 0 on acpi0 cpu1: numa-domain 0 on acpi0 cpu2: numa-domain 0 on acpi0 cpu3: numa-domain 0 on acpi0 cpu4: numa-domain 0 on acpi0 cpu5: numa-domain 0 on acpi0 cpu6: numa-domain 0 on acpi0 cpu7: numa-domain 0 on acpi0 cpu8: numa-domain 0 on acpi0 cpu9: numa-domain 0 on acpi0 cpu10: numa-domain 0 on acpi0 cpu11: numa-domain 0 on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 Event timer "HPET3" frequency 14318180 Hz quality 340 Event timer "HPET4" frequency 14318180 Hz quality 340 Event timer "HPET5" frequency 14318180 Hz quality 340 Event timer "HPET6" frequency 14318180 Hz quality 340 Event timer "HPET7" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 pcib0: numa-domain 0 on acpi0 pcib0: _OSC returned error 0x10 pci0: numa-domain 0 on pcib0 pcib1: at device 1.0 numa-domain 0 on pci0 pci1: numa-domain 0 on pcib1 mps0: port 0x6000-0x60ff mem = 0xfbef0000-0xfbefffff,0xfbe80000-0xfbebffff irq 26 at device 0.0 = numa-domain 0 on pci1 mps0: Firmware: 20.00.07.00, Driver: 21.01.00.00-fbsd mps0: IOCCapabilities: = 5285c= pcib2: at device 1.1 numa-domain 0 on pci0 pci2: numa-domain 0 on pcib2 pcib3: at device 2.0 numa-domain 0 on pci0 pci3: numa-domain 0 on pcib3 bge0: mem = 0xfabf0000-0xfabfffff,0xfabe0000-0xfabeffff,0xfabd0000-0xfabdffff irq 32 = at device 0.0 numa-domain 0 on pci3 bge0: APE FW version: NCSI v1.3.12.0 bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus0: numa-domain 0 on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Using defaults for TSO: 65518/35/2048 bge0: Ethernet address: 2c:44:fd:91:c2:bc bge1: mem = 0xfabc0000-0xfabcffff,0xfabb0000-0xfabbffff,0xfaba0000-0xfabaffff irq 36 = at device 0.1 numa-domain 0 on pci3 bge1: APE FW version: NCSI v1.3.12.0 bge1: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus1: numa-domain 0 on bge1 brgphy1: PHY 2 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Using defaults for TSO: 65518/35/2048 bge1: Ethernet address: 2c:44:fd:91:c2:bd bge2: mem = 0xfab90000-0xfab9ffff,0xfab80000-0xfab8ffff,0xfab70000-0xfab7ffff irq 32 = at device 0.2 numa-domain 0 on pci3 bge2: APE FW version: NCSI v1.3.12.0 bge2: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus2: numa-domain 0 on bge2 brgphy2: PHY 3 on miibus2 brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge2: Using defaults for TSO: 65518/35/2048 bge2: Ethernet address: 2c:44:fd:91:c2:be bge3: mem = 0xfab60000-0xfab6ffff,0xfab50000-0xfab5ffff,0xfab40000-0xfab4ffff irq 36 = at device 0.3 numa-domain 0 on pci3 bge3: APE FW version: NCSI v1.3.12.0 bge3: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus3: numa-domain 0 on bge3 brgphy3: PHY 4 on miibus3 brgphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge3: Using defaults for TSO: 65518/35/2048 bge3: Ethernet address: 2c:44:fd:91:c2:bf pcib4: at device 2.1 numa-domain 0 on pci0 pci4: numa-domain 0 on pcib4 pcib5: at device 2.2 numa-domain 0 on pci0 pci5: numa-domain 0 on pcib5 pcib6: at device 2.3 numa-domain 0 on pci0 pci6: numa-domain 0 on pcib6 pcib7: at device 3.0 numa-domain 0 on pci0 pci7: numa-domain 0 on pcib7 mps1: port 0x5000-0x50ff mem = 0xfbdf0000-0xfbdfffff,0xfbd80000-0xfbdbffff irq 40 at device 0.0 = numa-domain 0 on pci7 mps1: Firmware: 20.00.07.00, Driver: 21.01.00.00-fbsd mps1: IOCCapabilities: = 5285c= pcib8: at device 3.1 numa-domain 0 on pci0 pci8: numa-domain 0 on pcib8 pcib9: at device 3.2 numa-domain 0 on pci0 pci9: numa-domain 0 on pcib9 pcib10: at device 3.3 numa-domain 0 on pci0 pci10: numa-domain 0 on pcib10 pcib11: at device 17.0 numa-domain 0 on pci0 pci11: numa-domain 0 on pcib11 ehci0: mem 0xfac60000-0xfac603ff irq = 21 at device 26.0 numa-domain 0 on pci0 usbus0: EHCI version 1.0 usbus0 numa-domain 0 on ehci0 pcib12: at device 28.0 numa-domain 0 on pci0 pci12: numa-domain 0 on pcib12 mps2: port 0x7000-0x70ff mem = 0xfbff0000-0xfbffffff,0xfbf80000-0xfbfbffff irq 16 at device 0.0 = numa-domain 0 on pci12 mps2: Firmware: 20.00.07.00, Driver: 21.01.00.00-fbsd mps2: IOCCapabilities: = 5285c= pcib13: at device 28.7 numa-domain 0 on pci0 pci13: numa-domain 0 on pcib13 vgapci0: mem = 0xf9000000-0xf9ffffff,0xfbce0000-0xfbce3fff,0xfb000000-0xfb7fffff irq 16 = at device 0.1 numa-domain 0 on pci13 vgapci0: Boot video device uhci0: port 0x3c00-0x3c1f irq = 16 at device 0.4 numa-domain 0 on pci13 usbus1 numa-domain 0 on uhci0 ehci1: mem 0xfac50000-0xfac503ff irq = 20 at device 29.0 numa-domain 0 on pci0 usbus2: EHCI version 1.0 usbus2 numa-domain 0 on ehci1 pcib14: at device 30.0 numa-domain 0 on pci0 pci14: numa-domain 0 on pcib14 isab0: at device 31.0 numa-domain 0 on pci0 isa0: numa-domain 0 on isab0 atapci0: port = 0x4000-0x4007,0x4008-0x400b,0x4010-0x4017,0x4018-0x401b,0x4020-0x402f,0x40= 30-0x403f irq 17 at device 31.2 numa-domain 0 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart1: port 0x2f8-0x2ff irq = 3 on acpi0 orm0: at iomem 0xc0000-0xc7fff on isa0 ppc0: cannot reserve I/O port range uart0: at port 0x3f8 irq 4 = flags 0x10 on isa0 uart0: console (115200,n,8,1) est0: numa-domain 0 on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est0 attach returned 6 est1: numa-domain 0 on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est1 attach returned 6 est2: numa-domain 0 on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est2 attach returned 6 est3: numa-domain 0 on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est3 attach returned 6 est4: numa-domain 0 on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est4 attach returned 6 est5: numa-domain 0 on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est5 attach returned 6 est6: numa-domain 0 on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est6 attach returned 6 est7: numa-domain 0 on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est7 attach returned 6 est8: numa-domain 0 on cpu8 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est8 attach returned 6 est9: numa-domain 0 on cpu9 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est9 attach returned 6 est10: numa-domain 0 on cpu10 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est10 attach returned 6 est11: numa-domain 0 on cpu11 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 221b00001a00 device_attach: est11 attach returned 6 usbus0: 480Mbps High Speed USB v2.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec nvme cam probe device init usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ugen0.2: at usbus0 uhub3: = on usbus0 ugen2.2: at usbus2 uhub4: = on usbus2 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered ugen2.3: at usbus2 uhub5: = on usbus2 uhub5: 2 ports with 1 removable, self powered ses0 at mps2 bus 0 scbus2 target 10 lun 0 ses0: Fixed Enclosure Services SPC-3 SCSI = device ses0: Serial Number 7CE539P12M =20 ses0: 600.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 ENC Device (da0:mps0:0:8:0): UNMAPPED (da1:da0 at mps0 bus 0 scbus0 target 8 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number S0M1F2B10000B418HVFX da0: 600.000MB/s transfers da0: Command Queueing enabled da0: 572325MB (1172123568 512 byte sectors) mps0:0:9:0): UNMAPPED (da2:da1 at mps0 bus 0 scbus0 target 9 lun 0 da1: Fixed Direct Access SPC-4 SCSI device da1: Serial Number S0M1F7CG0000M419BS87 da1: 600.000MB/s transfers da1: Command Queueing enabled da1: 572325MB (1172123568 512 byte sectors) ses0: (none): SAS Device Slot Element: 1 Phys at Slot 1, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ec197c9 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 2, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ebde785 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 3, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ec1ae59 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 4, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008eb2e04d ses0: (none): SAS Device Slot Element: 1 Phys at Slot 5, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ebdfe25 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 6, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ebfea71 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 7, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ec3f06d ses0: (none): SAS Device Slot Element: 1 Phys at Slot 8, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ebf2ab5 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 9, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ec3c2f9 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 10, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ebedb35 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 11, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ec012b9 ses0: (none): SAS Device Slot Element: 1 Phys at Slot 12, Not All Phys ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5001438035a2617f addr 5000c5008ec58d09 mps0:0:10:0): UNMAPPED (da3:da2 at mps0 bus 0 scbus0 target 10 lun 0 da2: Fixed Direct Access SPC-4 SCSI device da2: Serial Number S0M1EQSL0000B419CE37 da2: 600.000MB/s transfers da2: Command Queueing enabled da2: 572325MB (1172123568 512 byte sectors) mps0:0:11:0): UNMAPPED (da4:da3 at mps0 bus 0 scbus0 target 11 lun 0 da3: Fixed Direct Access SPC-4 SCSI device da3: Serial Number S0M1EQHL0000B419CG8Y da3: 600.000MB/s transfers da3: Command Queueing enabled da3: 572325MB (1172123568 512 byte sectors) mps0:0:12:0): UNMAPPED (da5:da4 at mps0 bus 0 scbus0 target 12 lun 0 da4: Fixed Direct Access SPC-4 SCSI device da4: Serial Number S0M1ERQR0000M41919NZ da4: 600.000MB/s transfers da4: Command Queueing enabled da4: 572325MB (1172123568 512 byte sectors) mps0:0:13:0): UNMAPPED (da6:da5 at mps0 bus 0 scbus0 target 13 lun 0 da5: Fixed Direct Access SPC-4 SCSI device da5: Serial Number S0M1EP8H0000M419667Y da5: 600.000MB/s transfers da5: Command Queueing enabled da5: 572325MB (1172123568 512 byte sectors) mps0:0:14:0): UNMAPPED (da7:da6 at mps0 bus 0 scbus0 target 14 lun 0 da6: Fixed Direct Access SPC-4 SCSI device da6: Serial Number S0M1F9B00000B419CQF1 da6: 600.000MB/s transfers da6: Command Queueing enabled da6: 572325MB (1172123568 512 byte sectors) mps0:0:15:0): UNMAPPED (da8:da7 at mps0 bus 0 scbus0 target 15 lun 0 da7: Fixed Direct Access SPC-4 SCSI device da7: Serial Number S0M1ER7Y0000B418J2VA da7: 600.000MB/s transfers da7: Command Queueing enabled da7: 572325MB (1172123568 512 byte sectors) mps1:0:8:0): UNMAPPED (da9:da8 at mps1 bus 0 scbus1 target 8 lun 0 da8: Fixed Direct Access SPC-4 SCSI device da8: Serial Number S0M1E2VZ0000B419CQAF da8: 600.000MB/s transfers da8: Command Queueing enabled da8: 572325MB (1172123568 512 byte sectors) mps1:0:9:0): UNMAPPED (da10:da9 at mps1 bus 0 scbus1 target 9 lun 0 da9: Fixed Direct Access SPC-4 SCSI device da9: Serial Number S0M1ESN20000M418DKFL da9: 600.000MB/s transfers da9: Command Queueing enabled da9: 572325MB (1172123568 512 byte sectors) mps1:0:10:0): UNMAPPED (da11:da10 at mps1 bus 0 scbus1 target 10 lun 0 da10: Fixed Direct Access SPC-4 SCSI device da10: Serial Number S0M1F8V00000B419CPWR da10: 600.000MB/s transfers da10: Command Queueing enabled da10: 572325MB (1172123568 512 byte sectors) mps1:0:11:0): UNMAPPED (da12:da11 at mps1 bus 0 scbus1 target 11 lun 0 da11: Fixed Direct Access SPC-4 SCSI device da11: Serial Number S0M1ESLL0000B419DALG da11: 600.000MB/s transfers da11: Command Queueing enabled da11: 572325MB (1172123568 512 byte sectors) mps1:0:12:0): UNMAPPED (da13:da12 at mps1 bus 0 scbus1 target 12 lun 0 da12: Fixed Direct Access SPC-4 SCSI device da12: Serial Number S0M1DXJR0000B419CJKG da12: 600.000MB/s transfers da12: Command Queueing enabled da12: 572325MB (1172123568 512 byte sectors) mps1:0:13:0): UNMAPPED (da14:da13 at mps1 bus 0 scbus1 target 13 lun 0 da13: Fixed Direct Access SPC-4 SCSI device da13: Serial Number S0M1ES7R0000B419CJZX da13: 600.000MB/s transfers da13: Command Queueing enabled da13: 572325MB (1172123568 512 byte sectors) mps1:0:14:0): UNMAPPED (da15:da14 at mps1 bus 0 scbus1 target 14 lun 0 da14: Fixed Direct Access SPC-4 SCSI device da14: Serial Number S0M19J9D0000B419CEEC da14: 600.000MB/s transfers da14: Command Queueing enabled da14: 572325MB (1172123568 512 byte sectors) mps1:0:15:0): UNMAPPED (da16:da15 at mps1 bus 0 scbus1 target 15 lun 0 da15: Fixed Direct Access SPC-4 SCSI device da15: Serial Number S0M1EQPR0000B419CGAC da15: 600.000MB/s transfers da15: Command Queueing enabled da15: 572325MB (1172123568 512 byte sectors) mps2:0:11:0): UNMAPPED (da17:da16 at mps2 bus 0 scbus2 target 11 lun 0 da16: Fixed Direct Access SPC-4 SCSI device da16: Serial Number S3L29R3L0000M608CP3Y da16: 600.000MB/s transfers da16: Command Queueing enabled da16: 1144641MB (2344225968 512 byte sectors) mps2:0:13:0): UNMAPPED (da18:da17 at mps2 bus 0 scbus2 target 13 lun 0 da17: Fixed Direct Access SPC-4 SCSI device da17: Serial Number S3L29XFQ0000M608CQD6 da17: 600.000MB/s transfers da17: Command Queueing enabled da17: 1144641MB (2344225968 512 byte sectors) mps2:0:14:0): UNMAPPED (da19:da18 at mps2 bus 0 scbus2 target 14 lun 0 da18: Fixed Direct Access SPC-4 SCSI device da18: Serial Number S3L29QTK0000M608CN9K da18: 600.000MB/s transfers da18: Command Queueing enabled da18: 1144641MB (2344225968 512 byte sectors) mps2:0:15:0): UNMAPPED (da20:da19 at mps2 bus 0 scbus2 target 15 lun 0 da19: Fixed Direct Access SPC-4 SCSI device da19: Serial Number S3L29TAA0000M608CS65 da19: 600.000MB/s transfers da19: Command Queueing enabled da19: 1144641MB (2344225968 512 byte sectors) mps2:0:16:0): UNMAPPED (da21:da20 at mps2 bus 0 scbus2 target 16 lun 0 da20: Fixed Direct Access SPC-4 SCSI device da20: Serial Number S3L28ZFA0000M607T1JN da20: 600.000MB/s transfers da20: Command Queueing enabled da20: 1144641MB (2344225968 512 byte sectors) mps2:0:17:0): UNMAPPED (da22:da21 at mps2 bus 0 scbus2 target 17 lun 0 da21: Fixed Direct Access SPC-4 SCSI device da21: Serial Number S3L29PG90000M6089MMG da21: 600.000MB/s transfers da21: Command Queueing enabled da21: 1144641MB (2344225968 512 byte sectors) mps2:0:18:0): UNMAPPED (da23:da22 at mps2 bus 0 scbus2 target 18 lun 0 da22: Fixed Direct Access SPC-4 SCSI device da22: Serial Number S3L29RHR0000M608STP7 da22: 600.000MB/s transfers da22: Command Queueing enabled da22: 1144641MB (2344225968 512 byte sectors) mps2:0:19:0): UNMAPPED (da24:da23 at mps2 bus 0 scbus2 target 19 lun 0 da23: Fixed Direct Access SPC-4 SCSI device da23: Serial Number S3L29VQT0000M6069ZU8 da23: 600.000MB/s transfers da23: Command Queueing enabled da23: 1144641MB (2344225968 512 byte sectors) mps2:0:20:0): UNMAPPED (da25:da24 at mps2 bus 0 scbus2 target 20 lun 0 da24: Fixed Direct Access SPC-4 SCSI device da24: Serial Number S3L2A7WM0000M608SSU7 da24: 600.000MB/s transfers da24: Command Queueing enabled da24: 1144641MB (2344225968 512 byte sectors) mps2:0:21:0): UNMAPPED (da26:da25 at mps2 bus 0 scbus2 target 21 lun 0 da25: Fixed Direct Access SPC-4 SCSI device da25: Serial Number S3L29GXN0000M605A4C6 da25: 600.000MB/s transfers da25: Command Queueing enabled da25: 1144641MB (2344225968 512 byte sectors) mps2:0:22:0): UNMAPPED (da27:da26 at mps2 bus 0 scbus2 target 22 lun 0 da26: Fixed Direct Access SPC-4 SCSI device da26: Serial Number S3L29TPT0000M608CSAA da26: 600.000MB/s transfers da26: Command Queueing enabled da26: 1144641MB (2344225968 512 byte sectors) mps2:0:23:0): UNMAPPED da27 at mps2 bus 0 scbus2 target 23 lun 0 da27: Fixed Direct Access SPC-4 SCSI device da27: Serial Number S3L2A4EJ0000M607J095 da27: 600.000MB/s transfers da27: Command Queueing enabled da27: 1144641MB (2344225968 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #5 Launched! Timecounter "TSC-low" frequency 1147258217 Hz quality 1000 Trying to mount root from zfs:zroot/ROOT/default []... GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_ELI: Device mirror/swap.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software bge0: link state changed to DOWN bge1: link state changed to DOWN bge2: link state changed to DOWN ums0: on usbus1 bge0: link state changed to UP bge1: link state changed to UP bge2: link state changed to UP ugen1.2: at usbus1 (disconnected) ukbd0: at uhub1, port 1, addr 2 (disconnected) ums0: at uhub1, port 1, addr 2 (disconnected) vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1ESLL_C1S03. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1ESLL_C1S03. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1ESLL_C1S03. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1F8V0_C1S04. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F8V0_C1S04. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F8V0_C1S04. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1EQPR_C1S05. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1EQPR_C1S05. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1EQPR_C1S05. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M19J9D_C1S06. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M19J9D_C1S06. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M19J9D_C1S06. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1ES7R_C1S07. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1ES7R_C1S07. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1ES7R_C1S07. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1DXJR_C1S08. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1DXJR_C1S08. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1DXJR_C1S08. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1EQHL_C2S01. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1EQHL_C2S01. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1EQHL_C2S01. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1EQSL_C2S02. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1EQSL_C2S02. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1EQSL_C2S02. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1F7CG_C2S03. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F7CG_C2S03. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F7CG_C2S03. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1F2B1_C2S04. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F2B1_C2S04. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F2B1_C2S04. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1ER7Y_C2S05. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1ER7Y_C2S05. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1ER7Y_C2S05. vdev_geom_close_locked:336[1]: Closing access to gpt/S0M1F9B0_C2S06. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F9B0_C2S06. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F9B0_C2S06. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29R3L_EC1_S01. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29R3L_EC1_S01. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29R3L_EC1_S01. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29XFQ_EC1_S02. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29XFQ_EC1_S02. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29XFQ_EC1_S02. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29QTK_EC1_S03. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29QTK_EC1_S03. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29QTK_EC1_S03. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L28ZFA_EC1_S04. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L28ZFA_EC1_S04. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L28ZFA_EC1_S04. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29PG9_EC1_S05. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29PG9_EC1_S05. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29PG9_EC1_S05. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29TAA_EC1_S06. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29TAA_EC1_S06. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29TAA_EC1_S06. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29RHR_EC1_S07. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29RHR_EC1_S07. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29RHR_EC1_S07. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29VQT_EC1_S08. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29VQT_EC1_S08. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29VQT_EC1_S08. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L2A7WM_EC1_S09. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L2A7WM_EC1_S09. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L2A7WM_EC1_S09. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29GXN_EC1_S10. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29GXN_EC1_S10. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29GXN_EC1_S10. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L29TPT_EC1_S11. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29TPT_EC1_S11. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29TPT_EC1_S11. vdev_geom_close_locked:336[1]: Closing access to gpt/S3L2A4EJ_EC1_S12. vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L2A4EJ_EC1_S12. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L2A4EJ_EC1_S12. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1ESLL_C1S03. vdev_geom_attach:192[1]: Attaching to gpt/S0M1ESLL_C1S03. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1ESLL_C1S03. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1ESLL_C1S03... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1ESLL_C1S03. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1ESLL_C1S03. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1ESLL_C1S03. vdev_geom_attach:192[1]: Attaching to gpt/S0M1ESLL_C1S03. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1ESLL_C1S03. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1F8V0_C1S04. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F8V0_C1S04. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F8V0_C1S04. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1F8V0_C1S04... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F8V0_C1S04. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F8V0_C1S04. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1F8V0_C1S04. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F8V0_C1S04. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F8V0_C1S04. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1EQPR_C1S05. vdev_geom_attach:192[1]: Attaching to gpt/S0M1EQPR_C1S05. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1EQPR_C1S05. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1EQPR_C1S05... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1EQPR_C1S05. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1EQPR_C1S05. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1EQPR_C1S05. vdev_geom_attach:192[1]: Attaching to gpt/S0M1EQPR_C1S05. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1EQPR_C1S05. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M19J9D_C1S06. vdev_geom_attach:192[1]: Attaching to gpt/S0M19J9D_C1S06. vdev_geom_attach:256[1]: Created consumer for gpt/S0M19J9D_C1S06. vdev_geom_read_config:429[1]: Reading config from gpt/S0M19J9D_C1S06... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M19J9D_C1S06. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M19J9D_C1S06. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M19J9D_C1S06. vdev_geom_attach:192[1]: Attaching to gpt/S0M19J9D_C1S06. vdev_geom_attach:256[1]: Created consumer for gpt/S0M19J9D_C1S06. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1ES7R_C1S07. vdev_geom_attach:192[1]: Attaching to gpt/S0M1ES7R_C1S07. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1ES7R_C1S07. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1ES7R_C1S07... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1ES7R_C1S07. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1ES7R_C1S07. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1ES7R_C1S07. vdev_geom_attach:192[1]: Attaching to gpt/S0M1ES7R_C1S07. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1ES7R_C1S07. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1DXJR_C1S08. vdev_geom_attach:192[1]: Attaching to gpt/S0M1DXJR_C1S08. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1DXJR_C1S08. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1DXJR_C1S08... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1DXJR_C1S08. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1DXJR_C1S08. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1DXJR_C1S08. vdev_geom_attach:192[1]: Attaching to gpt/S0M1DXJR_C1S08. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1DXJR_C1S08. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1EQHL_C2S01. vdev_geom_attach:192[1]: Attaching to gpt/S0M1EQHL_C2S01. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1EQHL_C2S01. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1EQHL_C2S01... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1EQHL_C2S01. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1EQHL_C2S01. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1EQHL_C2S01. vdev_geom_attach:192[1]: Attaching to gpt/S0M1EQHL_C2S01. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1EQHL_C2S01. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1EQSL_C2S02. vdev_geom_attach:192[1]: Attaching to gpt/S0M1EQSL_C2S02. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1EQSL_C2S02. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1EQSL_C2S02... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1EQSL_C2S02. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1EQSL_C2S02. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1EQSL_C2S02. vdev_geom_attach:192[1]: Attaching to gpt/S0M1EQSL_C2S02. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1EQSL_C2S02. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1F7CG_C2S03. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F7CG_C2S03. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F7CG_C2S03. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1F7CG_C2S03... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F7CG_C2S03. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F7CG_C2S03. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1F7CG_C2S03. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F7CG_C2S03. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F7CG_C2S03. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1F2B1_C2S04. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F2B1_C2S04. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F2B1_C2S04. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1F2B1_C2S04... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F2B1_C2S04. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F2B1_C2S04. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1F2B1_C2S04. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F2B1_C2S04. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F2B1_C2S04. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1ER7Y_C2S05. vdev_geom_attach:192[1]: Attaching to gpt/S0M1ER7Y_C2S05. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1ER7Y_C2S05. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1ER7Y_C2S05... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1ER7Y_C2S05. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1ER7Y_C2S05. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1ER7Y_C2S05. vdev_geom_attach:192[1]: Attaching to gpt/S0M1ER7Y_C2S05. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1ER7Y_C2S05. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S0M1F9B0_C2S06. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F9B0_C2S06. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F9B0_C2S06. vdev_geom_read_config:429[1]: Reading config from gpt/S0M1F9B0_C2S06... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S0M1F9B0_C2S06. vdev_geom_detach:311[1]: Destroying consumer to gpt/S0M1F9B0_C2S06. vdev_attach_ok:651[1]: guids match for provider /dev/gpt/S0M1F9B0_C2S06. vdev_geom_attach:192[1]: Attaching to gpt/S0M1F9B0_C2S06. vdev_geom_attach:256[1]: Created consumer for gpt/S0M1F9B0_C2S06. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29R3L_EC1_S01. vdev_geom_attach:192[1]: Attaching to gpt/S3L29R3L_EC1_S01. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29R3L_EC1_S01. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29R3L_EC1_S01... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29R3L_EC1_S01. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29R3L_EC1_S01. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29R3L_EC1_S01. vdev_geom_attach:192[1]: Attaching to gpt/S3L29R3L_EC1_S01. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29R3L_EC1_S01. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29XFQ_EC1_S02. vdev_geom_attach:192[1]: Attaching to gpt/S3L29XFQ_EC1_S02. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29XFQ_EC1_S02. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29XFQ_EC1_S02... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29XFQ_EC1_S02. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29XFQ_EC1_S02. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29XFQ_EC1_S02. vdev_geom_attach:192[1]: Attaching to gpt/S3L29XFQ_EC1_S02. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29XFQ_EC1_S02. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29QTK_EC1_S03. vdev_geom_attach:192[1]: Attaching to gpt/S3L29QTK_EC1_S03. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29QTK_EC1_S03. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29QTK_EC1_S03... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29QTK_EC1_S03. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29QTK_EC1_S03. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29QTK_EC1_S03. vdev_geom_attach:192[1]: Attaching to gpt/S3L29QTK_EC1_S03. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29QTK_EC1_S03. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L28ZFA_EC1_S04. vdev_geom_attach:192[1]: Attaching to gpt/S3L28ZFA_EC1_S04. vdev_geom_attach:256[1]: Created consumer for gpt/S3L28ZFA_EC1_S04. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L28ZFA_EC1_S04... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L28ZFA_EC1_S04. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L28ZFA_EC1_S04. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L28ZFA_EC1_S04. vdev_geom_attach:192[1]: Attaching to gpt/S3L28ZFA_EC1_S04. vdev_geom_attach:256[1]: Created consumer for gpt/S3L28ZFA_EC1_S04. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29PG9_EC1_S05. vdev_geom_attach:192[1]: Attaching to gpt/S3L29PG9_EC1_S05. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29PG9_EC1_S05. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29PG9_EC1_S05... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29PG9_EC1_S05. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29PG9_EC1_S05. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29PG9_EC1_S05. vdev_geom_attach:192[1]: Attaching to gpt/S3L29PG9_EC1_S05. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29PG9_EC1_S05. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29TAA_EC1_S06. vdev_geom_attach:192[1]: Attaching to gpt/S3L29TAA_EC1_S06. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29TAA_EC1_S06. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29TAA_EC1_S06... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29TAA_EC1_S06. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29TAA_EC1_S06. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29TAA_EC1_S06. vdev_geom_attach:192[1]: Attaching to gpt/S3L29TAA_EC1_S06. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29TAA_EC1_S06. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29RHR_EC1_S07. vdev_geom_attach:192[1]: Attaching to gpt/S3L29RHR_EC1_S07. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29RHR_EC1_S07. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29RHR_EC1_S07... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29RHR_EC1_S07. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29RHR_EC1_S07. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29RHR_EC1_S07. vdev_geom_attach:192[1]: Attaching to gpt/S3L29RHR_EC1_S07. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29RHR_EC1_S07. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29VQT_EC1_S08. vdev_geom_attach:192[1]: Attaching to gpt/S3L29VQT_EC1_S08. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29VQT_EC1_S08. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29VQT_EC1_S08... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29VQT_EC1_S08. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29VQT_EC1_S08. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29VQT_EC1_S08. vdev_geom_attach:192[1]: Attaching to gpt/S3L29VQT_EC1_S08. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29VQT_EC1_S08. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L2A7WM_EC1_S09. vdev_geom_attach:192[1]: Attaching to gpt/S3L2A7WM_EC1_S09. vdev_geom_attach:256[1]: Created consumer for gpt/S3L2A7WM_EC1_S09. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L2A7WM_EC1_S09... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L2A7WM_EC1_S09. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L2A7WM_EC1_S09. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L2A7WM_EC1_S09. vdev_geom_attach:192[1]: Attaching to gpt/S3L2A7WM_EC1_S09. vdev_geom_attach:256[1]: Created consumer for gpt/S3L2A7WM_EC1_S09. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29GXN_EC1_S10. vdev_geom_attach:192[1]: Attaching to gpt/S3L29GXN_EC1_S10. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29GXN_EC1_S10. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29GXN_EC1_S10... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29GXN_EC1_S10. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29GXN_EC1_S10. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29GXN_EC1_S10. vdev_geom_attach:192[1]: Attaching to gpt/S3L29GXN_EC1_S10. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29GXN_EC1_S10. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L29TPT_EC1_S11. vdev_geom_attach:192[1]: Attaching to gpt/S3L29TPT_EC1_S11. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29TPT_EC1_S11. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L29TPT_EC1_S11... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L29TPT_EC1_S11. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L29TPT_EC1_S11. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L29TPT_EC1_S11. vdev_geom_attach:192[1]: Attaching to gpt/S3L29TPT_EC1_S11. vdev_geom_attach:256[1]: Created consumer for gpt/S3L29TPT_EC1_S11. vdev_geom_open_by_path:744[1]: Found provider by name = /dev/gpt/S3L2A4EJ_EC1_S12. vdev_geom_attach:192[1]: Attaching to gpt/S3L2A4EJ_EC1_S12. vdev_geom_attach:256[1]: Created consumer for gpt/S3L2A4EJ_EC1_S12. vdev_geom_read_config:429[1]: Reading config from = gpt/S3L2A4EJ_EC1_S12... vdev_geom_detach:297[1]: Detaching consumer. Provider = gpt/S3L2A4EJ_EC1_S12. vdev_geom_detach:311[1]: Destroying consumer to gpt/S3L2A4EJ_EC1_S12. vdev_attach_ok:651[1]: guids match for provider = /dev/gpt/S3L2A4EJ_EC1_S12. vdev_geom_attach:192[1]: Attaching to gpt/S3L2A4EJ_EC1_S12. vdev_geom_attach:256[1]: Created consumer for gpt/S3L2A4EJ_EC1_S12. console=3D"comconsole,vidconsole" comconsole_speed=3D"115200" geom_mirror_load=3D"YES" kern.geom.label.gptid.enable=3D"0" kern.geom.label.disk_ident.enable=3D"0" zfs_load=3D"YES" kern.cam.scsi_delay=3D15000 # $FreeBSD: releng/11.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux = $ # # This file is read when going to multi-user and its contents piped = thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. # # Uncomment this to prevent users from seeing information about = processes that # are being run under another UID. #security.bsd.see_other_uids=3D0 kern.ipc.shm_use_phys=3D1 kern.ipc.somaxconn=3D16384 # seems to be higher anyway #kern.ipc.maxsockets=3D131072 #kern.maxfiles=3D131072 #kern.maxfilesperproc=3D104856 #kern.threads.max_threads_per_proc=3D4096 net.inet.tcp.fast_finwait2_recycle=3D1 net.inet.tcp.finwait2_timeout=3D15000 net.inet.tcp.msl=3D5000 machdep.panic_on_nmi=3D0 net.inet6.ip6.auto_flowlabel=3D0 security.bsd.see_other_gids=3D0 security.bsd.see_other_uids=3D0 # was 49152 net.inet.ip.portrange.hifirst=3D10000 security.bsd.unprivileged_proc_debug=3D0 net.inet.ip.redirect=3D0 net.inet6.ip6.redirect=3D0 net.inet.icmp.drop_redirect=3D1 net.inet6.icmp6.rediraccept=3D0 security.bsd.hardlink_check_uid=3D1 security.bsd.hardlink_check_gid=3D1 kern.coredump=3D0 kern.nodump_coredump=3D1 net.inet.ip.random_id=3D1 net.inet.ip.check_interface=3D1 net.inet.tcp.blackhole=3D1 net.inet.udp.blackhole=3D1 security.bsd.unprivileged_read_msgbuf=3D0 vfs.zfs.min_auto_ashift=3D12 vfs.zfs.arc_max=3D68719476736 I=E2=80=99ve set vfs.zfs.debug to 1. Does anybody know what the attach/detach messages from GEOM mean? From owner-freebsd-fs@freebsd.org Sat Oct 1 17:01:37 2016 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 8B1C8C05E4A for ; Sat, 1 Oct 2016 17:01: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 7AFDB1B3C for ; Sat, 1 Oct 2016 17:01: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 u91H1T37093468 for ; Sat, 1 Oct 2016 17:01:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Sat, 01 Oct 2016 17:01:30 +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.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: chris@cretaforce.gr X-Bugzilla-Status: In Progress 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: Sat, 01 Oct 2016 17:01:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #31 from chris@cretaforce.gr --- Is it possible to have this for 10.3 as errata patch? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Oct 1 19:52:05 2016 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 3BDBAA947B6 for ; Sat, 1 Oct 2016 19:52:05 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from hz.citrin.ru (hz.citrin.ru [88.198.212.3]) (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 00E7683A for ; Sat, 1 Oct 2016 19:52:04 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [192.168.0.144] (c-24-60-168-172.hsd1.ct.comcast.net [24.60.168.172]) (Authenticated sender: citrin@citrin.ru) by hz.citrin.ru (Postfix) with ESMTPSA id 18941286BDC; Sat, 1 Oct 2016 19:51:54 +0000 (UTC) Subject: Re: UFS: unaligned read from GELI with 8k sectorsize To: Konstantin Belousov References: <20161001114536.GX38409@kib.kiev.ua> Cc: "freebsd-fs@freebsd.org" From: Anton Yuzhaninov Message-ID: Date: Sat, 1 Oct 2016 15:51:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161001114536.GX38409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrin.ru; s=s0; t=1475351515; bh=j5UO6r2fRZfPcb0+jqs5N0fGAT8TXQm+ag1uVqMTB4k=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oW8EVtZSznMkpZG03k2P2NRAY94R7kgtA9P/Yprh6O4DWDEJSlY9PtLNlMJ7ucKEt6CD/MQuRa88GJqTQqunMwlmvkeEjEu0VWP7ZvHvZqXzOaBgKq/b8EI4oj3dyH6Tk3pKfnYnXnCZxVB1F8nJjxE64nfYWkrSz9g7BoOAGjs= 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, 01 Oct 2016 19:52:05 -0000 On 2016-10-01 07:45, Konstantin Belousov wrote: > On Sat, Oct 01, 2016 at 12:42:09AM -0400, Anton Yuzhaninov wrote: > FreeBSD vnode pager assumes that it can read at page granularity. > Since x86 page size is 4k, sometimes page-in has to occur not on the > fragment boundary. In other words, fragment size > 4k are effectively > not supported. You mean that geom sector size > 4k is not supported? UFS with 8k fragment should work (over geom provider with sector size <= 4k). > Boot needs to execute files from the root mount, which results in the > mmap(2) attempts on your file system. While mount and reads/writes do > not involve the pager, which does not trigger further bugs in the > buffer cache code. It should break if you try to execute badly aligned > ELF binary from your stick, or just mmap() a file from the stick with > non-8k aligned offset. Thank you for detailed answer! From owner-freebsd-fs@freebsd.org Sat Oct 1 20:26:36 2016 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 6FDA9A940B8 for ; Sat, 1 Oct 2016 20:26:36 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from hz.citrin.ru (hz.citrin.ru [IPv6:2a01:4f8:d16:10c3::2]) (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 3791DA4C for ; Sat, 1 Oct 2016 20:26:36 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [192.168.0.144] (c-24-60-168-172.hsd1.ct.comcast.net [24.60.168.172]) (Authenticated sender: citrin@citrin.ru) by hz.citrin.ru (Postfix) with ESMTPSA id 0178B2874D1; Sat, 1 Oct 2016 20:26:32 +0000 (UTC) Subject: Re: UFS: unaligned read from GELI with 8k sectorsize To: Konstantin Belousov References: <20161001114536.GX38409@kib.kiev.ua> <20161001115439.GY38409@kib.kiev.ua> Cc: "freebsd-fs@freebsd.org" From: Anton Yuzhaninov Message-ID: <68a8ed6d-e302-799c-3d2c-1d85c48d07bf@citrin.ru> Date: Sat, 1 Oct 2016 16:26:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161001115439.GY38409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrin.ru; s=s0; t=1475353593; bh=4z2uK2adxY83nEXQCwvpktgqfsvR0ZUZH6IAd600Pzg=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JXZtA0ILJ73FYlngqdynGZKsNcpTLIcbdY2h+5YNTiEtKN+jQOu1GCkzKOPDwmZQh+EczHzQaIq9EB2eXA5X9/bvyUBQMYVqAnm2j9i6gdb3copgyRMNGmE7UARYCqrwNiA2UVqplwHPkmNajmnBpGMfZeI6jWl+B7qXMdrO7Eo= 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, 01 Oct 2016 20:26:36 -0000 On 2016-10-01 07:54, Konstantin Belousov wrote: > It might be not too hard to make this case working, although the speed > of the pagein will be detrimental. Try this, please. > diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c > index a80a9c2..01e2ea2 100644 > --- a/sys/vm/vnode_pager.c > +++ b/sys/vm/vnode_pager.c > @@ -796,7 +796,7 @@ vnode_pager_generic_getpages(struct vnode *vp, vm_page_t *m, int count, > * getting pages via VOP_READ. > */ > error = VOP_BMAP(vp, foff / bsize, &bo, &bp->b_blkno, &after, &before); > - if (error == EOPNOTSUPP) { > + if (error == EOPNOTSUPP || (error == 0 && bo->bo_bsize > PAGE_SIZE)) { > relpbuf(bp, freecnt); > VM_OBJECT_WLOCK(object); > for (i = 0; i < count; i++) { With this patch there is no panic, but boot process stops after message: start_init: trying /sbin/init (boot -v was used) And nothing happens after. There is two reasons why I tried to use GELI on SSD with 8k sector size: 1. SSD internally reads data by pages. Host can request from SSD 512 bytes, but full page will be read inside SSD. For my SSD page size is 8k. 2. GELI work faster with big blocks. Quick benchmark for geli on gzero (AES-NI, single geli thread, several parallel dd if=/dev/gzero.eli): 4k sector ~ 350 Mb/s 8k sector ~ 400 Mb/s Bigger sector sizes works even faster, but not useful on real workloads because on small reads by user application more data then necessary will be read and decrypted. Given that vnode_pager is not designed to work with sector size > VM page size it will be more easy for me to reinstall FreeBSD on geli with 4k sectors. From owner-freebsd-fs@freebsd.org Sat Oct 1 21:10:38 2016 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 C7FB8A94D6D for ; Sat, 1 Oct 2016 21:10:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 624E129B for ; Sat, 1 Oct 2016 21:10:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u91LAPVo028679 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 2 Oct 2016 00:10:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u91LAPVo028679 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u91LAPTL028678; Sun, 2 Oct 2016 00:10:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Oct 2016 00:10:25 +0300 From: Konstantin Belousov To: Anton Yuzhaninov Cc: "freebsd-fs@freebsd.org" Subject: Re: UFS: unaligned read from GELI with 8k sectorsize Message-ID: <20161001211025.GD38409@kib.kiev.ua> References: <20161001114536.GX38409@kib.kiev.ua> <20161001115439.GY38409@kib.kiev.ua> <68a8ed6d-e302-799c-3d2c-1d85c48d07bf@citrin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68a8ed6d-e302-799c-3d2c-1d85c48d07bf@citrin.ru> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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, 01 Oct 2016 21:10:38 -0000 On Sat, Oct 01, 2016 at 04:26:17PM -0400, Anton Yuzhaninov wrote: > With this patch there is no panic, but boot process stops after message: > start_init: trying /sbin/init > (boot -v was used) > > And nothing happens after. What happens if you boot, mount your USB drive with 8k sectors, and try to execute some binary from it ? E.g., try to execute the init. I do not care about app errors (most likely it should complain about uid != 0 or pid != 1), but rather want to know whether the image is activated or not. From owner-freebsd-fs@freebsd.org Sat Oct 1 22:02:33 2016 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 3E10EA94C90 for ; Sat, 1 Oct 2016 22:02:33 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from hz.citrin.ru (hz.citrin.ru [88.198.212.3]) (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 F3CCBC73 for ; Sat, 1 Oct 2016 22:02:32 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [192.168.0.157] (c-24-60-168-172.hsd1.ct.comcast.net [24.60.168.172]) by hz.citrin.ru (Postfix) with ESMTPSA id 690CF287D54; Sat, 1 Oct 2016 22:02:29 +0000 (UTC) Subject: Re: UFS: unaligned read from GELI with 8k sectorsize To: Konstantin Belousov References: <20161001114536.GX38409@kib.kiev.ua> <20161001115439.GY38409@kib.kiev.ua> <68a8ed6d-e302-799c-3d2c-1d85c48d07bf@citrin.ru> <20161001211025.GD38409@kib.kiev.ua> Cc: "freebsd-fs@freebsd.org" From: Anton Yuzhaninov Message-ID: <999638f9-3fee-82e3-d67f-cffef53b74e8@citrin.ru> Date: Sat, 1 Oct 2016 18:02:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161001211025.GD38409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrin.ru; s=s0; t=1475359349; bh=RcVLYBTyQeVJHoYvg1bKKlnGKEZJ28Qc2KrB5/+taZ8=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=6LbSUvgob6G0Lv/CUhDhHMLDbdOj137H52TQbDZZnpHrnriQhkgEx26YwNGIdWUYcMClJEbohI+dgqOpKCg1ryUgevB0WMxnv28WUNUB/PWDL69W5H2MByOgFAiet2FYniSaJMtmSQFJCm4iRaWvS56+qrjlyQTKBfVIyvQH1rs= 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, 01 Oct 2016 22:02:33 -0000 On 2016-10-01 17:10, Konstantin Belousov wrote: > What happens if you boot, mount your USB drive with 8k sectors, and try > to execute some binary from it ? E.g., try to execute the init. I do > not care about app errors (most likely it should complain about uid != 0 > or pid != 1), but rather want to know whether the image is activated or not. I booted from a USB stick with patched kernel and attached geli with 8k sector. It seems to be the image is not activated: root@:~ # /mnt/ssdroot/sbin/ping load: 0.16 cmd: csh 714 [pgrbwt] 11.46r 0.00u 0.00s 0% 3720k root@:~ # procstat -k 714 PID TID COMM TDNAME KSTACK procstat: sysctl: kern.proc.kstack: 714: Device busy DDB backtrace for shell: https://imgur.com/a/JDLry