From owner-freebsd-fs@freebsd.org Sun Feb 7 21:00:16 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 64917537446 for ; Sun, 7 Feb 2021 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DYhPX272Lz3MnC for ; Sun, 7 Feb 2021 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 48C5F537445; Sun, 7 Feb 2021 21:00:16 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 488AE5373D4 for ; Sun, 7 Feb 2021 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYhPX1ZKPz3MqS for ; Sun, 7 Feb 2021 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 277BA2F15 for ; Sun, 7 Feb 2021 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 117L0GfI049734 for ; Sun, 7 Feb 2021 21:00:16 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 117L0GKI049733 for fs@FreeBSD.org; Sun, 7 Feb 2021 21:00:16 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202102072100.117L0GKI049733@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: fs@FreeBSD.org Subject: Problem reports for fs@FreeBSD.org that need special attention Date: Sun, 7 Feb 2021 21:00:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 21:00:16 -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 | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS Open | 221909 | [ZFS] Add a sysctl to toggle send_corrupt_data Open | 235665 | panic: handle_written_inodeblock: live inodedep Open | 237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w Open | 240831 | zfs: Panic during snapshot on 12.1-STABLE r352648 Open | 243973 | [zfs] rollback segmentation fault Open | 244656 | zfs: resilver doesn't provide enough information Open | 244692 | gjournal: Does not support TRIM Open | 244899 | [PATCH] zfs: xattr on a symlink target > 136 caus Open | 251035 | [zfs] Allow 64 bit ZFS to support 32 bit ioctls ( 12 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Feb 8 06:45:52 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C5645473ED for ; Mon, 8 Feb 2021 06:45:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DYxPD208vz4lk7 for ; Mon, 8 Feb 2021 06:45:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 444945476D5; Mon, 8 Feb 2021 06:45:52 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 440C15476D4 for ; Mon, 8 Feb 2021 06:45:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYxPD1PPZz4lmZ for ; Mon, 8 Feb 2021 06:45:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 23B7213028 for ; Mon, 8 Feb 2021 06:45:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1186jqeJ038145 for ; Mon, 8 Feb 2021 06:45:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1186jqNo038144 for fs@FreeBSD.org; Mon, 8 Feb 2021 06:45:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 224292] processes are hanging in state ufs / possible deadlock in file system Date: Mon, 08 Feb 2021 06:45:52 +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: sigsys@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 06:45:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224292 sigsys@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sigsys@gmail.com --- Comment #15 from sigsys@gmail.com --- I'm getting occasional UFS "hangs" of sorts on a -CURRENT VM too. Must be unrelated to whatever the problem was in the original bug report but I figu= red I'd dump this here in case it could help figuring out more recent problems. Last time it happened and that I saved some infos was from a little while a= go (FreeBSD 13.0-CURRENT #32 main-c529869-g4f597837d531: Tue Jan 12 14:41:03 E= ST 2021). I'll update and try to get more infos if it happens again. `pkg upgrade` and running kyua tests are what usually trigger it but it sti= ll happens very rarely. load: 1.71 cmd: pkg 11799 [biowr] 331.89r 20.33u 66.48s 52% 764496k mi_switch+0x155 sleepq_switch+0x109 _sleep+0x2b4 bufwait+0xc4 bufwrite+0x25a ffs_update+0x2ed ffs_syncvnode+0x4da ffs_fsync+0x1f softdep_prerename+0x21a ufs_rename+0x3ee VOP_RENAME_APV+0x40 kern_renameat+0x3fd amd64_syscall+0x149 fast_syscall_common+0xf8=20 root@vm2:[~] # procstat -kk 11799 PID TID COMM TDNAME KSTACK=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 11799 100255 pkg - __mtx_lock_sleep+0xe8 __mtx_lock_flags+0xe5 process_worklist_item+0x63 softdep_prerename+0x4bd ufs_rename+0x3ee VOP_RENAME_APV+0x40 kern_renameat+0x3fd amd64_syscall+0x149 fast_syscall_common+0xf8=20 root@vm2:[~] # procstat -kk 11799 PID TID COMM TDNAME KSTACK=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 11799 100255 pkg - mi_switch+0x155 sleepq_switch+0x109 _sleep+0x2b4 bufwait+0xc4 bufwrite+0x25a ffs_update+0x2= ed ffs_syncvnode+0x4da ffs_fsync+0x1f softdep_prerename+0x21a ufs_rename+0x3ee VOP_RENAME_APV+0x40 kern_renameat+0x3fd amd64_syscall+0x149 fast_syscall_common+0xf8=20 root@vm2:[~] # ps -lp 11799 UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 11799 11798 4 52 0 828024 764512 - R+ 1 2:38.77 pkg upgrade root@vm2:[~] # iostat -w 1 -d vtbd0 vtbd1 vtbd2=20 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s=20 24.4 10 0.2 33.3 2 0.1 38.2 0 0.0=20 32.0 25091 784.1 0.0 0 0.0 0.0 0 0.0=20 32.0 23305 728.3 0.0 0 0.0 0.0 0 0.0=20 32.0 23539 735.6 0.0 0 0.0 0.0 0 0.0=20 32.0 22151 692.2 0.0 0 0.0 0.0 0 0.0=20 32.0 19310 603.4 0.0 0 0.0 0.0 0 0.0=20 32.0 22848 714.0 0.0 0 0.0 0.0 0 0.0=20 32.0 24287 759.0 0.0 0 0.0 0.0 0 0.0=20 32.0 23392 731.0 0.0 0 0.0 0.0 0 0.0=20 32.0 24586 768.3 0.0 0 0.0 0.0 0 0.0=20 32.0 23980 749.4 0.0 0 0.0 0.0 0 0.0=20 32.0 23549 735.9 0.0 0 0.0 0.0 0 0.0=20 32.0 23328 729.0 0.0 0 0.0 0.0 0 0.0=20 32.0 23173 724.2 0.0 0 0.0 0.0 0 0.0=20 32.0 24906 778.3 0.0 0 0.0 0.0 0 0.0=20 32.0 23534 735.4 0.0 0 0.0 0.0 0 0.0=20 32.0 24242 757.6 0.0 0 0.0 0.0 0 0.0=20 32.0 21295 665.5 0.0 0 0.0 0.0 0 0.0=20 32.0 19002 593.8 0.0 0 0.0 0.0 0 0.0=20 32.0 18702 584.4 0.0 0 0.0 0.0 0 0.0=20 32.0 19285 602.7 0.0 0 0.0 0.0 0 0.0=20 32.0 18171 567.8 0.0 0 0.0 0.0 0 0.0=20 32.0 18603 581.3 0.0 0 0.0 0.0 0 0.0=20 I think there's always rmdir/mkdir or rename in the kernel call stack of the hung processes when it happens. And it's really going nuts with the I/O. Makes me think it must be some ki= nd of live lock within softupdates. When some processes get stuck in this state, more and more processes eventu= ally get stuck until the VM is unusable. But running `sync` unwedges the whole thing and everything seems to be running fine after that. I'll try to get a core dump next time. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Feb 8 08:09:01 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E6C2C5299E3 for ; Mon, 8 Feb 2021 08:09:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DYzF961s3z4q2k for ; Mon, 8 Feb 2021 08:09:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CBF9B5299E2; Mon, 8 Feb 2021 08:09:01 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA7E752955B for ; Mon, 8 Feb 2021 08:09:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYzF95218z4pv1 for ; Mon, 8 Feb 2021 08:09:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9FA6013DD8 for ; Mon, 8 Feb 2021 08:09:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 118891IX089776 for ; Mon, 8 Feb 2021 08:09:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 118891oI089775 for fs@FreeBSD.org; Mon, 8 Feb 2021 08:09:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235665] panic: handle_written_inodeblock: live inodedep Date: Mon, 08 Feb 2021 08:09:01 +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: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pho@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? mfc-stable11? X-Bugzilla-Changed-Fields: resolution bug_status 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 08:09:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235665 Peter Holm changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Open |Closed --- Comment #2 from Peter Holm --- The problem is not seen in: FreeBSD 14.0-CURRENT #0 main-n244671-b3c6fe663bb --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Feb 8 11:54:52 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EB8D55301C1 for ; Mon, 8 Feb 2021 11:54:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DZ4Fm696Rz3MTB for ; Mon, 8 Feb 2021 11:54:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CFD1C52FE63; Mon, 8 Feb 2021 11:54:52 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CF9D152FF2C for ; Mon, 8 Feb 2021 11:54:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZ4Fm4nwqz3MT8 for ; Mon, 8 Feb 2021 11:54:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 937B316F29 for ; Mon, 8 Feb 2021 11:54:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 118BsqeB046086 for ; Mon, 8 Feb 2021 11:54:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 118BsqWA046085 for fs@FreeBSD.org; Mon, 8 Feb 2021 11:54:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 224292] processes are hanging in state ufs / possible deadlock in file system Date: Mon, 08 Feb 2021 11:54:52 +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: trasz@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 11:54:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224292 --- Comment #16 from Edward Tomasz Napierala --- I believe I'm seeing the same problem on my T420. It started a couple (thr= ee?) months ago. I'm not sure it's a deadlock/livelock, though: it almost seems like a buffer is being written to disk over and over. One particular case I remember is dd instance used to write out entropy (4k write to a file somewhere in /var). This was the culprit according to "top= -m io". On some other occurences of this bug I've seen Firefox doing an absurd amount of IO. Assuming we can trust top(1), this aligns with the idea of a buffer being written over and over. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Feb 8 14:06:10 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D7CAC533D8D for ; Mon, 8 Feb 2021 14:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DZ79G5bRrz3ltb for ; Mon, 8 Feb 2021 14:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BFF5C533BB1; Mon, 8 Feb 2021 14:06:10 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BFBE4533ADB for ; Mon, 8 Feb 2021 14:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZ79G51sFz3lnc for ; Mon, 8 Feb 2021 14:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9EB52189FB for ; Mon, 8 Feb 2021 14:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 118E6ATk023089 for ; Mon, 8 Feb 2021 14:06:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 118E6Alm023087 for fs@FreeBSD.org; Mon, 8 Feb 2021 14:06:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 224292] processes are hanging in state ufs / possible deadlock in file system Date: Mon, 08 Feb 2021 14:06:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 14:06:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224292 --- Comment #17 from Konstantin Belousov --- Try this https://kib.kiev.ua/git/gitweb.cgi?p=3Ddeviant3.git;a=3Dcommitdiff;hp=3Dmai= n;h=3Dufs_needsync I would be not surprised if the patch fixes the issue for you. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Feb 8 20:26:58 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4740A5405CF for ; Mon, 8 Feb 2021 20:26:58 +0000 (UTC) (envelope-from joe@via.net) Received: from smtp1.via.net (smtp1.via.net [157.22.3.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "via.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZHcd0qBGz4pGd for ; Mon, 8 Feb 2021 20:26:56 +0000 (UTC) (envelope-from joe@via.net) Received: from mail.via.net (mail.via.net [157.22.3.34]) by smtp1.via.net (8.15.2/8.14.1-VIANET) with ESMTPS id 118KQtEc015707 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 8 Feb 2021 12:26:55 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at smtp1.via.net Received: from [209.81.2.65] ([209.81.2.65]) by mail.via.net (8.15.2/8.14.1-VIANET) with ESMTP id 118KQtBu018586 for ; Mon, 8 Feb 2021 12:26:55 -0800 (PST) From: joe mcguckin Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: zpool list vs df free space? Message-Id: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> Date: Mon, 8 Feb 2021 12:26:45 -0800 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (smtp1.via.net [157.22.3.5]); Mon, 08 Feb 2021 12:26:55 -0800 (PST) X-Rspamd-Queue-Id: 4DZHcd0qBGz4pGd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of joe@via.net designates 157.22.3.5 as permitted sender) smtp.mailfrom=joe@via.net X-Spamd-Result: default: False [-1.90 / 15.00]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+MX]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[157.22.3.5:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[157.22.3.5:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7091, ipnet:157.22.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[joe]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[157.22.3.5:from:127.0.2.255]; DMARC_NA(0.00)[via.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MAILMAN_DEST(0.00)[freebsd-fs] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 20:26:58 -0000 df -h reports 66T available zpool list says 102T Why the discrepency? This is on a system with 7 16Tb drives configured as raidz2. Thanks, Joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From owner-freebsd-fs@freebsd.org Mon Feb 8 20:34:38 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C7C3540E00 for ; Mon, 8 Feb 2021 20:34:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZHnT0m7lz4prd for ; Mon, 8 Feb 2021 20:34:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f174.google.com with SMTP id l19so4552328oih.6 for ; Mon, 08 Feb 2021 12:34:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FnOcUOHNVYIyp37i1pvIe4EHtqSMyxoOr5tQwbWa20s=; b=GUoTU54CHIyG4arxoQA3XaYKGMwR+plviASzXKuORDJZZqZBL6/jE5M4Y99Y1fMT7X nFCXEz2T1yXr06TFqLg5PlpMXqcGhw/FqcF/I3AzZIDhyjn9aKyKwjvVS1MDX4VBVvcP YoCndB2mPVaAMQKLG7aes3khKiKluo9qCpLANmQIh0RBXO0LtCp0TkBb6M8w9p6QPSSH qw0bdH/e6NDmO9xyV2WMQpv9oM+qQpU6+I7aafkG8HIzvL4V4mNrPDA53FXSLzdx8mwr cGb1wFkr+pZew2PKnhIW3w1N4qG3R8FjYyXE4L3vYidNxeWxrxN3j1DBPFJG3lQ/0SB6 Tr5w== X-Gm-Message-State: AOAM533Sv57qAs+LzS7rSFFeYpXJ1Tr+tFXqRXYFcJZgYfqJsEI/Yb0u YpOv+fMt2wEGFkK/WfEVu5xvyteo5EfeXXigPh3XjIUA3Qg= X-Google-Smtp-Source: ABdhPJw0E7lRdmfT56d1hDmkXCRCzfMsNFi0to4skoiB9A3bJH2smuc2+t6TZUgt1EfC33XYx0qYMeqhQmEjhk19xuM= X-Received: by 2002:a54:4813:: with SMTP id j19mr339727oij.73.1612816475828; Mon, 08 Feb 2021 12:34:35 -0800 (PST) MIME-Version: 1.0 References: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> In-Reply-To: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> From: Alan Somers Date: Mon, 8 Feb 2021 13:34:24 -0700 Message-ID: Subject: Re: zpool list vs df free space? To: joe mcguckin Cc: freebsd-fs X-Rspamd-Queue-Id: 4DZHnT0m7lz4prd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.174:from]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.167.174:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.174:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.174:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 20:34:38 -0000 df is reporting usable space. "zpool list" includes RAID overhead and padding blocks. Try "zfs list" instead. That should be closer to what df reports. On Mon, Feb 8, 2021 at 1:27 PM joe mcguckin wrote: > df -h reports 66T available > > zpool list says 102T > > Why the discrepency? > > This is on a system with 7 16Tb drives configured as raidz2. > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > > _______________________________________________ > 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 Mon Feb 8 21:07:02 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 49BC0541F85 for ; Mon, 8 Feb 2021 21:07:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZJVs2CNmz4rvW for ; Mon, 8 Feb 2021 21:07:01 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-qv1-xf29.google.com with SMTP id ew18so7674335qvb.4 for ; Mon, 08 Feb 2021 13:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1b79eeWFr0EhcSUbTPsffs+X49iVF3A1u5ziBbkQLTY=; b=SgoR/UOeJ6nqEakR7/bs1JCuaOlQOvDTnzmiLXiaN07aIUJtP0iI7M+qA80o4DZ5BQ 9UC4ESrYrfxuGI9byM7GTT8zc70NcI9RhejhZHEr+8AO4CM5mfF3qE+W9SNZbR5y6sY4 obqXZrT9oTylTYJiNxVMdMlCW7Bdoor1LjIHu0YidwIE3xAEk8H+HuL0qqSUqvjGt5eF Hfx9vVgz2VqVCa2vzkIsHgy3vk2a9rv27aPZc5ql68LwwkGLYpfeQs5y9GQ4hA7m1v0A kBuPIKbpB2BtCQoP5rWrwRk1iBo3l8YqKZwKa2R6wstTErDhf+WusVLqJ9WnN8bfEee6 opRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1b79eeWFr0EhcSUbTPsffs+X49iVF3A1u5ziBbkQLTY=; b=YHPEux8ZJ3hnd7EEs2KEEh8r6ZJSIACyCQs7KPqKYKg3oHtHCRp/cFETU68xygBCG+ fdLkfmLQNKN9w/QCpyQhspaO1+4WGnUHa6sFSUWzgS2oz343cVn8+6Kc0ab7MtBMfcC3 udvoZQDp5J+KmxcCCrjH5sX7q/YFSR4tmhCfr/OSkvX9/66B1m3ZZdwMI/m0Nke51Gst FPjvppx/nvlzdegYsZEXHp+8WtheH1jOw5LrtFMeQz0BoQ4CAEHhyPJ5ciGi1eyNbFiQ 4KOef4W4Bv6pR5Ywx2Hy6rwN/+f46+cuqd2jMJwJedlcFHSbCKcJO44NIjqaSxhHS0S4 0G+g== X-Gm-Message-State: AOAM531egWGtu61zekqqP14UpiJpP8/8/N0xt91Dg90V9WfUlahVjM2d zwMRhSRcMNxKtNoBQtMwCDv81Bt3LtEMwBcYk0s= X-Google-Smtp-Source: ABdhPJyr+K9sCRC1y1b7ljUw8dZxl45NEDNuDqAlBxma9qN3mkKyLW+zExMFZjieZ0Al7wnLjf9JbOk2xd1gQ+tZAlk= X-Received: by 2002:a0c:ee89:: with SMTP id u9mr17943342qvr.40.1612818420498; Mon, 08 Feb 2021 13:07:00 -0800 (PST) MIME-Version: 1.0 References: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> In-Reply-To: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> From: Freddie Cash Date: Mon, 8 Feb 2021 13:06:49 -0800 Message-ID: Subject: Re: zpool list vs df free space? To: joe mcguckin Cc: FreeBSD Filesystems X-Rspamd-Queue-Id: 4DZJVs2CNmz4rvW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=SgoR/UOe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fjwcash@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=fjwcash@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f29:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f29:from:127.0.2.255]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 21:07:02 -0000 On Mon., Feb. 8, 2021, 12:27 p.m. joe mcguckin, wrote: > df -h reports 66T available > > zpool list says 102T > > Why the discrepency? > > This is on a system with 7 16Tb drives configured as raidz2. > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > "zpool list" shows the raw storage available on the pool, across all the disks in the pool, minus some internal reserved storage. "zfs list" shows the usable storage space after all the parity drives are removed from the calculation. "df" output can be misleading as it doesn't take into account compression and reservations and things like that. It can give you an approximation of available space, but it won't be as accurate as "zfs list". For example, if you have 6x 2 TB drives configured as a single raidz2 vdev, then: zpool list: around 12 TB (6 drives x 2 TB) zfs list: around 8 TB (4 data drives x 2 TB) df: should be around 8 TB Cheers, Freddie Typos due to smartphone keyboard. > From owner-freebsd-fs@freebsd.org Mon Feb 8 22:07:46 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E8BBD5437D4 for ; Mon, 8 Feb 2021 22:07:46 +0000 (UTC) (envelope-from joe@via.net) Received: from smtp3.via.net (smtp3.via.net [157.22.3.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "via.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZKry0d4jz3Crm for ; Mon, 8 Feb 2021 22:07:45 +0000 (UTC) (envelope-from joe@via.net) Received: from mail.via.net (mail.via.net [157.22.3.34]) by smtp3.via.net (8.15.2/8.14.1-VIANET) with ESMTPS id 118M7iAe005099 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 8 Feb 2021 14:07:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at smtp3.via.net Received: from [209.81.2.65] ([209.81.2.65]) by mail.via.net (8.15.2/8.14.1-VIANET) with ESMTP id 118M7ggS004417 for ; Mon, 8 Feb 2021 14:07:42 -0800 (PST) From: joe mcguckin Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: zfs send, recv questions Date: Mon, 8 Feb 2021 14:07:32 -0800 References: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> To: freebsd-fs@freebsd.org In-Reply-To: Message-Id: <1D71C028-33C7-4950-B3D5-6811A2C47ECE@via.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (smtp3.via.net [157.22.3.7]); Mon, 08 Feb 2021 14:07:44 -0800 (PST) X-Rspamd-Queue-Id: 4DZKry0d4jz3Crm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of joe@via.net designates 157.22.3.7 as permitted sender) smtp.mailfrom=joe@via.net X-Spamd-Result: default: False [-2.90 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[157.22.3.7:from]; FREEFALL_USER(0.00)[joe]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[157.22.3.7:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+MX]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[via.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7091, ipnet:157.22.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[157.22.3.7:from] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:07:47 -0000 I=E2=80=99m using zfs send to populate the test box with some sample = throwaway files. zfs recv wants the name of a non-existant = directory/mountpoint that it will create with all the new files. Is there a way to have zfs add the files = to an existing directory? I tried simply =E2=80=98mv=E2=80=99ing the = files to another directory on the same pool (trying to add the files to an existing directory) - Usually on UFS this = is very quick, just a quick change to the directory, but on zfs it=E2=80=99= s recopying all the files; yet another 30 minute wait=E2=80=A6 I guess since this is going across a mount point, FreeBSD wants to make = a copy. Is there a better way to achieve this? I=E2=80=99m cheating by doing ali of this as root, how to do zfs recv as = non-root? The Lucas book did a lot of hand-waving without a concrete = example. Thanks, Joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Feb 8, 2021, at 1:06 PM, Freddie Cash wrote: >=20 >=20 >=20 >=20 >=20 > On Mon., Feb. 8, 2021, 12:27 p.m. joe mcguckin, > wrote: > df -h reports 66T available >=20 > zpool list says 102T >=20 > Why the discrepency? >=20 > This is on a system with 7 16Tb drives configured as raidz2. >=20 > Thanks, >=20 > Joe >=20 >=20 > Joe McGuckin > ViaNet Communications >=20 > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax >=20 > "zpool list" shows the raw storage available on the pool, across all = the disks in the pool, minus some internal reserved storage. >=20 > "zfs list" shows the usable storage space after all the parity drives = are removed from the calculation. >=20 > "df" output can be misleading as it doesn't take into account = compression and reservations and things like that. It can give you an = approximation of available space, but it won't be as accurate as "zfs = list". >=20 > For example, if you have 6x 2 TB drives configured as a single raidz2 = vdev, then: >=20 > zpool list: around 12 TB (6 drives x 2 TB) > zfs list: around 8 TB (4 data drives x 2 TB) > df: should be around 8 TB >=20 > Cheers, > Freddie >=20 > Typos due to smartphone keyboard. From owner-freebsd-fs@freebsd.org Mon Feb 8 22:21:52 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C124154416A for ; Mon, 8 Feb 2021 22:21:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZL9C5PZYz3F0D for ; Mon, 8 Feb 2021 22:21:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id y11so15737275otq.1 for ; Mon, 08 Feb 2021 14:21:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JljHYookC+i82E1YQ7MVSn7ci/DbEgp4OJeMKrlkr8M=; b=I4hw7lhR/5rVX7Pk3WcNvJ1WqA3YXTB9lSFRkFC7YMdtTOMz0oiOfDipPHQ7qmfVCP VK733uM2iEqzGT2mLWGrL2HhvdIe6VJJdg4essod4ygrURXEThvP8gtxR+gfUFY25UKK taT9XON6yajGDSpMG05sJJrsKurgh2bCe0VRE0gVYGdBZrHba3iQvuzJRCltRRxDVrVi aVimLohgxvfl5RcAj4obsrpriHBbka0fnYecn/8y7T0d4OsuBoIB6PnSe6Hh9fqrms8I XthRODKK31ZMciMOp+KXd9dKrAZRk2HjD1/nNZP9NLCfyMAaW0FBFV0qyw5IviPu+Q0u qa8w== X-Gm-Message-State: AOAM531sPHfOTn9Wa776T24kOqb0BlvmjfqPrq0qpUT6coK6CvCNHGCH fQ3jOplHzLAu5oS7bAx/zNeNfWQyV+vKZrkdRDUEphu3KWk= X-Google-Smtp-Source: ABdhPJxO2uTCDw9Cobei9SgVy266ouz76NePvUhlEhimb/Ttkt3CyEWM8BbQrq2gDXWzGsa9DhP1CjvTg3QdA9mss6g= X-Received: by 2002:a9d:4e81:: with SMTP id v1mr13274206otk.18.1612822909992; Mon, 08 Feb 2021 14:21:49 -0800 (PST) MIME-Version: 1.0 References: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> <1D71C028-33C7-4950-B3D5-6811A2C47ECE@via.net> In-Reply-To: <1D71C028-33C7-4950-B3D5-6811A2C47ECE@via.net> From: Alan Somers Date: Mon, 8 Feb 2021 15:21:38 -0700 Message-ID: Subject: Re: zfs send, recv questions To: joe mcguckin Cc: freebsd-fs X-Rspamd-Queue-Id: 4DZL9C5PZYz3F0D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.47 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.47:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.210.47:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.210.47:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.47:from]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 22:21:52 -0000 "zfs recv" creates a new dataset; that's how it works. And your guess is correct about why mv must copy files when it crosses a mount point; those are different file systems. If they were different directories on the same file system, then mv would be near-instant. I don't know your situation, so I don't know why it's not acceptable for zfs recv to create a new dataset. But if you must use an existing dataset, then there really isn't a better option than cp. -Alan On Mon, Feb 8, 2021 at 3:07 PM joe mcguckin wrote: > > > I=E2=80=99m using zfs send to populate the test box with some sample thro= waway > files. zfs recv wants the name of a non-existant directory/mountpoint tha= t > it will > create with all the new files. Is there a way to have zfs add the files t= o > an existing directory? I tried simply =E2=80=98mv=E2=80=99ing the files t= o another > directory on the same pool > (trying to add the files to an existing directory) - Usually on UFS this > is very quick, just a quick change to the directory, but on zfs it=E2=80= =99s > recopying all the files; yet another 30 minute wait=E2=80=A6 > I guess since this is going across a mount point, FreeBSD wants to make a > copy. > > Is there a better way to achieve this? > > I=E2=80=99m cheating by doing ali of this as root, how to do zfs recv as = non-root? > The Lucas book did a lot of hand-waving without a concrete example. > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > > > On Feb 8, 2021, at 1:06 PM, Freddie Cash wrote: > > > > > > > > > > > > On Mon., Feb. 8, 2021, 12:27 p.m. joe mcguckin, joe@via.net>> wrote: > > df -h reports 66T available > > > > zpool list says 102T > > > > Why the discrepency? > > > > This is on a system with 7 16Tb drives configured as raidz2. > > > > Thanks, > > > > Joe > > > > > > Joe McGuckin > > ViaNet Communications > > > > joe@via.net > > 650-207-0372 cell > > 650-213-1302 office > > 650-969-2124 fax > > > > "zpool list" shows the raw storage available on the pool, across all th= e > disks in the pool, minus some internal reserved storage. > > > > "zfs list" shows the usable storage space after all the parity drives > are removed from the calculation. > > > > "df" output can be misleading as it doesn't take into account > compression and reservations and things like that. It can give you an > approximation of available space, but it won't be as accurate as "zfs lis= t". > > > > For example, if you have 6x 2 TB drives configured as a single raidz2 > vdev, then: > > > > zpool list: around 12 TB (6 drives x 2 TB) > > zfs list: around 8 TB (4 data drives x 2 TB) > > df: should be around 8 TB > > > > Cheers, > > Freddie > > > > Typos due to smartphone keyboard. > > _______________________________________________ > 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 Tue Feb 9 16:03:16 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D7DA5434E2 for ; Tue, 9 Feb 2021 16:03:16 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from smtp-a.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.userve.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZnjv0Z4tz3Db6 for ; Tue, 9 Feb 2021 16:03:14 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-a.userve.net (Postfix) with ESMTPS id 4A12D238484; Tue, 9 Feb 2021 16:03:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=userve.net; s=uk1; t=1612886586; bh=3vMeJ76iEALUynG8z8WfiijXO72yS6xBAo5H0PSLuxc=; h=From:To:Subject:Date:References:In-Reply-To; b=Gmx608w2JrktbKr/l1ze1Y/up4fyWZ7NCGQLahSWUTC+Mw9QemaA3f14AxSSh5cpF F4V2fIgF2Pnfb13Le7s8OnaKvVsLbi/au6aAyQhuC3S0RupCOG2WJLL9jWZGKBqzSP tAp/WukDpz63w6nN/zyD8zivCH3DCBpGYr/FtRUE= Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 9 Feb 2021 16:03:05 +0000 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0847.030; Tue, 9 Feb 2021 16:03:05 +0000 From: Matt Churchyard To: joe mcguckin , "freebsd-fs@freebsd.org" Subject: RE: zfs send, recv questions Thread-Topic: zfs send, recv questions Thread-Index: AQHW/mbexxDtIw6o0Ei57EA2eVF2KqpP+jLA Date: Tue, 9 Feb 2021 16:03:04 +0000 Message-ID: <06de39ea88584ad890a577f725a0115c@SERVER.ad.usd-group.com> References: <8BF84A0F-E66D-423A-AB99-0D19A9BB37EE@via.net> <1D71C028-33C7-4950-B3D5-6811A2C47ECE@via.net> In-Reply-To: <1D71C028-33C7-4950-B3D5-6811A2C47ECE@via.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.141.48.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4DZnjv0Z4tz3Db6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=userve.net header.s=uk1 header.b=Gmx608w2; dmarc=none; spf=pass (mx1.freebsd.org: domain of matt.churchyard@userve.net designates 217.196.1.22 as permitted sender) smtp.mailfrom=matt.churchyard@userve.net X-Spamd-Result: default: False [-1.53 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.196.1.22:from]; R_DKIM_ALLOW(-0.20)[userve.net:s=uk1]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.196.1.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[userve.net]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.87)[0.874]; SPAMHAUS_ZRD(0.00)[217.196.1.22:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[userve.net:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:20652, ipnet:217.196.0.0/20, country:GB]; MAILMAN_DEST(0.00)[freebsd-fs] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 16:03:16 -0000 WmZzIHNlbmQvcmVjdiBzcGVjaWZpY2FsbHkgd29ya3Mgb24gZW50aXJlIGRhdGFzZXRzLiBXaGV0 aGVyIGl04oCZcyBhIGZ1bGwgb3IgaW5jcmVtZW50YWwgc2VuZCwgeW91IGFyZSBlZmZlY3RpdmVs eSBjcmVhdGluZyBhIGZ1bGwgcmVwbGljYSBvZiB0aGUgZGF0YS4gWW91IGNhbm5vdCB1c2UgaXQg dG8gbWVyZ2UgZGF0YSBhdCB0aGUgZmlsZSBsZXZlbC4NCg0KSWYgeW91IGhhdmUgYSBkYXRhc2V0 IG9mIHRlc3QgZGF0YSwgYW5kIHdhbnQgYSBjb3B5IG9mIHRoYXQgb24gdGhlIHNhbWUgcG9vbCAo eW91IG1lbnRpb24gdXNpbmcgbXYgYWNyb3NzIGRpcmVjdG9yaWVzKSwgdGhlbiB5b3UgY2FuIGp1 c3QgY2xvbmUgdGhlIHNuYXBzaG90IHJhdGhlciB0aGFuIHNlbmQgaXQuIFRoZSBwcm9jZXNzIGlz IG5lYXIgaWRlbnRpY2FsIHRvIHNlbmRpbmcgYSBzbmFwc2hvdCwgYnV0IHlvdSBqdXN0IGdldCBh IG5ldyB3cml0YWJsZSBkYXRhc2V0IGJhc2VkIG9uIHRoZSBzbmFwc2hvdCB3aXRoIG5vIGRhdGEg Y29waWVkLiAob2J2aW91c2x5IGl0IHJlbGllcyBvbiB0aGUgb3JpZ2luYWwgZGF0YXNldCBzbyB5 b3UgY2FuJ3QgcmVtb3ZlIHRoZSBzb3VyY2Ugc25hcHNob3Qgd2l0aG91dCBkZWxldGluZyBhbGwg Y2xvbmVzKQ0KDQpBbmQgeWVzLCB5b3VyIGNvbXBhcmlzb24gaXNuJ3QgbGlrZSBmb3IgbGlrZS4g TW92aW5nIGFjcm9zcyBVRlMgbW91bnRzIHdvdWxkIHJlcXVpcmUgYWN0dWFsIGRhdGEgdG8gYmUg bW92ZWQgYW5kIGFsc28gYmUgc2xvdywganVzdCBhcyBtb3ZpbmcgZmlsZXMgaW5zaWRlIGEgc2lu Z2xlIFpGUyBkYXRhc2V0IHdvdWxkIGJlIGZhc3QuDQoNCk1hdHQNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IG93bmVyLWZyZWVic2QtZnNAZnJlZWJzZC5vcmcgPG93bmVyLWZy ZWVic2QtZnNAZnJlZWJzZC5vcmc+IE9uIEJlaGFsZiBPZiBqb2UgbWNndWNraW4NClNlbnQ6IDA4 IEZlYnJ1YXJ5IDIwMjEgMjI6MDgNClRvOiBmcmVlYnNkLWZzQGZyZWVic2Qub3JnDQpTdWJqZWN0 OiB6ZnMgc2VuZCwgcmVjdiBxdWVzdGlvbnMNCg0KDQoNCknigJltIHVzaW5nIHpmcyBzZW5kIHRv IHBvcHVsYXRlIHRoZSB0ZXN0IGJveCB3aXRoIHNvbWUgc2FtcGxlIHRocm93YXdheSBmaWxlcy4g emZzIHJlY3Ygd2FudHMgdGhlIG5hbWUgb2YgYSBub24tZXhpc3RhbnQgZGlyZWN0b3J5L21vdW50 cG9pbnQgdGhhdCBpdCB3aWxsIGNyZWF0ZSB3aXRoIGFsbCB0aGUgbmV3IGZpbGVzLiBJcyB0aGVy ZSBhIHdheSB0byBoYXZlIHpmcyBhZGQgdGhlIGZpbGVzIHRvIGFuIGV4aXN0aW5nIGRpcmVjdG9y eT8gSSB0cmllZCBzaW1wbHkg4oCYbXbigJlpbmcgdGhlIGZpbGVzIHRvIGFub3RoZXIgZGlyZWN0 b3J5IG9uIHRoZSBzYW1lIHBvb2wgKHRyeWluZyB0byBhZGQgdGhlIGZpbGVzIHRvIGFuIGV4aXN0 aW5nIGRpcmVjdG9yeSkgLSBVc3VhbGx5IG9uIFVGUyB0aGlzIGlzIHZlcnkgcXVpY2ssIGp1c3Qg YSBxdWljayBjaGFuZ2UgdG8gdGhlIGRpcmVjdG9yeSwgYnV0IG9uIHpmcyBpdOKAmXMgcmVjb3B5 aW5nIGFsbCB0aGUgZmlsZXM7IHlldCBhbm90aGVyIDMwIG1pbnV0ZSB3YWl04oCmIEkgZ3Vlc3Mg c2luY2UgdGhpcyBpcyBnb2luZyBhY3Jvc3MgYSBtb3VudCBwb2ludCwgRnJlZUJTRCB3YW50cyB0 byBtYWtlIGEgY29weS4NCg0KSXMgdGhlcmUgYSBiZXR0ZXIgd2F5IHRvIGFjaGlldmUgdGhpcz8N Cg0KSeKAmW0gY2hlYXRpbmcgYnkgZG9pbmcgYWxpIG9mIHRoaXMgYXMgcm9vdCwgaG93IHRvIGRv IHpmcyByZWN2IGFzIG5vbi1yb290PyBUaGUgTHVjYXMgYm9vayBkaWQgYSBsb3Qgb2YgaGFuZC13 YXZpbmcgd2l0aG91dCBhIGNvbmNyZXRlIGV4YW1wbGUuDQoNClRoYW5rcywNCg0KSm9lDQoNCg0K Sm9lIE1jR3Vja2luDQpWaWFOZXQgQ29tbXVuaWNhdGlvbnMNCg0Kam9lQHZpYS5uZXQNCjY1MC0y MDctMDM3MiBjZWxsDQo2NTAtMjEzLTEzMDIgb2ZmaWNlDQo2NTAtOTY5LTIxMjQgZmF4DQoNCg0K DQo+IE9uIEZlYiA4LCAyMDIxLCBhdCAxOjA2IFBNLCBGcmVkZGllIENhc2ggPGZqd2Nhc2hAZ21h aWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiBNb24uLCBGZWIuIDgsIDIw MjEsIDEyOjI3IHAubS4gam9lIG1jZ3Vja2luLCA8am9lQHZpYS5uZXQgPG1haWx0bzpqb2VAdmlh Lm5ldD4+IHdyb3RlOg0KPiBkZiAtaCByZXBvcnRzIDY2VCBhdmFpbGFibGUNCj4gDQo+IHpwb29s IGxpc3Qgc2F5cyAxMDJUDQo+IA0KPiBXaHkgdGhlIGRpc2NyZXBlbmN5Pw0KPiANCj4gVGhpcyBp cyBvbiBhIHN5c3RlbSB3aXRoIDcgMTZUYiBkcml2ZXMgY29uZmlndXJlZCBhcyByYWlkejIuDQo+ IA0KPiBUaGFua3MsDQo+IA0KPiBKb2UNCj4gDQo+IA0KPiBKb2UgTWNHdWNraW4NCj4gVmlhTmV0 IENvbW11bmljYXRpb25zDQo+IA0KPiBqb2VAdmlhLm5ldCA8bWFpbHRvOmpvZUB2aWEubmV0Pg0K PiA2NTAtMjA3LTAzNzIgY2VsbA0KPiA2NTAtMjEzLTEzMDIgb2ZmaWNlDQo+IDY1MC05NjktMjEy NCBmYXgNCj4gDQo+ICJ6cG9vbCBsaXN0IiBzaG93cyB0aGUgcmF3IHN0b3JhZ2UgYXZhaWxhYmxl IG9uIHRoZSBwb29sLCBhY3Jvc3MgYWxsIHRoZSBkaXNrcyBpbiB0aGUgcG9vbCwgbWludXMgc29t ZSBpbnRlcm5hbCByZXNlcnZlZCBzdG9yYWdlLg0KPiANCj4gInpmcyBsaXN0IiBzaG93cyB0aGUg dXNhYmxlIHN0b3JhZ2Ugc3BhY2UgYWZ0ZXIgYWxsIHRoZSBwYXJpdHkgZHJpdmVzIGFyZSByZW1v dmVkIGZyb20gdGhlIGNhbGN1bGF0aW9uLg0KPiANCj4gImRmIiBvdXRwdXQgY2FuIGJlIG1pc2xl YWRpbmcgYXMgaXQgZG9lc24ndCB0YWtlIGludG8gYWNjb3VudCBjb21wcmVzc2lvbiBhbmQgcmVz ZXJ2YXRpb25zIGFuZCB0aGluZ3MgbGlrZSB0aGF0LiBJdCBjYW4gZ2l2ZSB5b3UgYW4gYXBwcm94 aW1hdGlvbiBvZiBhdmFpbGFibGUgc3BhY2UsIGJ1dCBpdCB3b24ndCBiZSBhcyBhY2N1cmF0ZSBh cyAiemZzIGxpc3QiLg0KPiANCj4gRm9yIGV4YW1wbGUsIGlmIHlvdSBoYXZlIDZ4IDIgVEIgZHJp dmVzIGNvbmZpZ3VyZWQgYXMgYSBzaW5nbGUgcmFpZHoyIHZkZXYsIHRoZW46DQo+IA0KPiB6cG9v bCBsaXN0OiBhcm91bmQgMTIgVEIgKDYgZHJpdmVzIHggMiBUQikgemZzIGxpc3Q6IGFyb3VuZCA4 IFRCICg0IA0KPiBkYXRhIGRyaXZlcyB4IDIgVEIpDQo+IGRmOiBzaG91bGQgYmUgYXJvdW5kIDgg VEINCj4gDQo+IENoZWVycywNCj4gRnJlZGRpZQ0KPiANCj4gVHlwb3MgZHVlIHRvIHNtYXJ0cGhv bmUga2V5Ym9hcmQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpmcmVlYnNkLWZzQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0cHM6Ly9saXN0 cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtZnMNClRvIHVuc3Vic2NyaWJl LCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWZzLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-fs@freebsd.org Thu Feb 11 01:26:42 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 45F3E5316D5 for ; Thu, 11 Feb 2021 01:26:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dbf9Z1KLdz4RlV for ; Thu, 11 Feb 2021 01:26:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2B991531571; Thu, 11 Feb 2021 01:26:42 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2B64F53156F for ; Thu, 11 Feb 2021 01:26:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dbf9Z0gjcz4RTk for ; Thu, 11 Feb 2021 01:26:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0658127961 for ; Thu, 11 Feb 2021 01:26:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11B1Qf3Z000834 for ; Thu, 11 Feb 2021 01:26:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11B1Qfu3000833 for fs@FreeBSD.org; Thu, 11 Feb 2021 01:26:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253424] fusefs: statfs doesn't set f_iosize ("optimal transfer block size") Date: Thu, 11 Feb 2021 01:26:42 +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: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 01:26:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253424 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 02:07:04 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EEAAF5349D0 for ; Thu, 11 Feb 2021 02:07:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dbg486GV5z4WZ3 for ; Thu, 11 Feb 2021 02:07:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D716E53496C; Thu, 11 Feb 2021 02:07:04 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D6D70534B35 for ; Thu, 11 Feb 2021 02:07:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dbg485dhvz4WZ2 for ; Thu, 11 Feb 2021 02:07:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B4B0E873 for ; Thu, 11 Feb 2021 02:07:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11B274R2022618 for ; Thu, 11 Feb 2021 02:07:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11B274qs022617 for fs@FreeBSD.org; Thu, 11 Feb 2021 02:07:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253424] fusefs: statfs doesn't set f_iosize ("optimal transfer block size") Date: Thu, 11 Feb 2021 02:07: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: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 02:07:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253424 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asomers@FreeBSD.org --- Comment #1 from Alan Somers --- I think you're right about f_iosize. But what is this about "the wrapper implementation of statvfs"? What wrapper are you talking about? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 02:25:26 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E5935362D9 for ; Thu, 11 Feb 2021 02:25:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DbgTL13H9z4Z4Z for ; Thu, 11 Feb 2021 02:25:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 240E4536581; Thu, 11 Feb 2021 02:25:26 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23D3C536474 for ; Thu, 11 Feb 2021 02:25:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DbgTL0QT1z4YwP for ; Thu, 11 Feb 2021 02:25:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0196AD71 for ; Thu, 11 Feb 2021 02:25:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11B2PPad037488 for ; Thu, 11 Feb 2021 02:25:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11B2PPBp037487 for fs@FreeBSD.org; Thu, 11 Feb 2021 02:25:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253424] fusefs: statfs doesn't set f_iosize ("optimal transfer block size") Date: Thu, 11 Feb 2021 02:25:26 +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: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jmillikin@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 02:25:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253424 --- Comment #2 from John Millikin --- In libc, the `lib/libc/gen/statvfs.c' file contains an implementation of `statvfs()' that wraps the `statfs()' syscall. This wrapper copies most of = the fields, but does not copy the maximum name length -- for that, it uses: pcval =3D pathconf(path, _PC_NAME_MAX); if (pcval =3D=3D -1) result->f_namemax =3D ~0UL; else result->f_namemax =3D (unsigned long)pcval; --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 02:51:12 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2C50A537E2D for ; Thu, 11 Feb 2021 02:51:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dbh3342Q0z4cPK for ; Thu, 11 Feb 2021 02:51:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8198B537F91; Thu, 11 Feb 2021 02:51:11 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F61A537F90 for ; Thu, 11 Feb 2021 02:51:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dbh326pLwz4cRf for ; Thu, 11 Feb 2021 02:51:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C8DB610ED for ; Thu, 11 Feb 2021 02:51:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11B2pANh048899 for ; Thu, 11 Feb 2021 02:51:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11B2pA1S048898 for fs@FreeBSD.org; Thu, 11 Feb 2021 02:51:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253424] fusefs: statfs doesn't set f_iosize ("optimal transfer block size") Date: Thu, 11 Feb 2021 02:51:11 +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: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 02:51:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253424 --- Comment #3 from Alan Somers --- (In reply to John Millikin from comment #2) Oh, I thought you were talking about something that wraps statvfs. I would= n't call statvfs a wrapper; it's the standardized interface for getting informa= tion about a file system. statfs is the older, but non-portable version. And t= he reason that statvfs uses pathconf is because when it was written (2002) sta= tfs didn't have an f_namemax field. f_namemax was only added in 2003 when statfs(2) was updated for 64-bit block counts. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 04:09:58 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 00CE8539A31 for ; Thu, 11 Feb 2021 04:09:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dbjnx6Rddz4h2L for ; Thu, 11 Feb 2021 04:09:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id DD339539942; Thu, 11 Feb 2021 04:09:57 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD0255399AA for ; Thu, 11 Feb 2021 04:09:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dbjnx5kGqz4hHk for ; Thu, 11 Feb 2021 04:09:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B60CF22D1 for ; Thu, 11 Feb 2021 04:09:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11B49vFm091291 for ; Thu, 11 Feb 2021 04:09:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11B49v9J091290 for fs@FreeBSD.org; Thu, 11 Feb 2021 04:09:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Thu, 11 Feb 2021 04:09: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 Some People X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 04:09:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib-bugs@FreeBSD.org, | |rmacklem@FreeBSD.org Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 07:27:47 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 442E753D3CB for ; Thu, 11 Feb 2021 07:27:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DbpBC1HZFz4rWY for ; Thu, 11 Feb 2021 07:27:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2A6A653D701; Thu, 11 Feb 2021 07:27:47 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A2CB53D69A for ; Thu, 11 Feb 2021 07:27:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DbpBC0cSsz4rT9 for ; Thu, 11 Feb 2021 07:27:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 042724C4D for ; Thu, 11 Feb 2021 07:27:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11B7Rkfw004684 for ; Thu, 11 Feb 2021 07:27:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11B7Rkt8004683 for fs@FreeBSD.org; Thu, 11 Feb 2021 07:27:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Thu, 11 Feb 2021 07:27:46 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 07:27:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 Kirk McKusick changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #222084|0 |1 is obsolete| | --- Comment #7 from Kirk McKusick --- Created attachment 222359 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D222359&action= =3Dedit correct fix for bug The previous fix masked the problem but had other unintended side effects. The reported panic arises because the /mnt/.snap/.factory snapshot allocated the last block in the filesystem. The snapshot code allocates the last bloc= k in the filesystem as a way of setting its length to be the size of the filesys= tem. Part of taking a snapshot is to remove all the earlier snapshots from the i= mage of the newest snapshot so that newer snapshots will not claim the blocks of= the earlier snapshots. The panic occurs when the new snapshot finds that both it and an earlier snapshot claim the same block. The fix is to set the size of the snapshot to be one block after the last b= lock in the filesystem. This block can never be allocated since it is not a valid block in the filesystem. This extra block is used as a place to store the initial list of blocks that the snapshot has already copied and is used to avoid a deadlock in and speed up the copyonwrite() function. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 19:18:15 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 940555323FA for ; Thu, 11 Feb 2021 19:18:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dc5xy56DFz4gxm for ; Thu, 11 Feb 2021 19:18:14 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id r21so6166129otk.13 for ; Thu, 11 Feb 2021 11:18:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SfNpczcdUTuPYhRI4LClvkBMHTktarBYp1Vb1rS3N9g=; b=SYEmJ+sE3UwyTd7+BeBI9BLdZ69H6MRm3uOObvGTVFkCMv3WBBmKMmHLD38/1UDy7v mOUpARg7trIzCTkfqRv+ro5O2Ib5htqsS8sGVtArxo2+j4Zo9xbd7HCdZp1e/aEAAtWV TfAuLUd9+ofRbbPpbrH/l5/9EGtI/gLtxwK8wdhqADKknkD6ugERMRdPzg8rXeVZNg4I QDeXjuuWLN61iUVkkB/fzMQH4d6KBmIgQmFVIX8/Uae7W9PYMk40H8uzRbArAKueksyE 1RxVU3fnxvQLGIADKuglpBUi8Bjp6MyBTYdbNOGxum1/kgZ9Hm5bMisKxLhtV0m/dNzK qeTQ== X-Gm-Message-State: AOAM5331jE5N1gR3xp3b1ErZnP1z2OOtTbl1oYAfjBZxegwEzchFO4Zp PV1Av2ciLRyfddCZWqYslPLBLqXZnOI0X69pwvhQZ8BsVpQVgw== X-Google-Smtp-Source: ABdhPJzut90AHf0mODrFXinCeh8z9GfuF4WaX0DUSCPhIUAtUb+k968N3eedLVl8Zvge91g9PzZ++HfTZlO6UgGIUVk= X-Received: by 2002:a9d:6c92:: with SMTP id c18mr1542464otr.18.1613071092922; Thu, 11 Feb 2021 11:18:12 -0800 (PST) MIME-Version: 1.0 From: Alan Somers Date: Thu, 11 Feb 2021 12:18:02 -0700 Message-ID: Subject: NFS delegations don't expire after unmounting client To: freebsd-fs X-Rspamd-Queue-Id: 4Dc5xy56DFz4gxm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.44 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.44:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.210.44:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[209.85.210.44:from:127.0.2.255]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.44:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:18:15 -0000 I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD 12.2-RELEASE server. Today, most of those clients' mounts hung, and their dmesg displayed "nfs: server XXX not responding, still trying". But one client kept running fine. nfsdumpstate on the server showed that that client, and that one only, had 2 delegations. It also had 1 OpenOwner, 1 Open, and the CB flags set. It was the only client that had CB set. On the theory that its delegation callbacks weren't working, I tried unmounting all of its NFS shares. That worked, but to my surprise nfsdumpstate showed no change! I could see that the lease time recorded in /var/run/nfs-stablerestart was 120s, and I must've waited about 30m in all before disabling delegations, unmounting everything, and returning to NFS v3. So my questions are, what can cause a delegation to linger around long after it should've expired, and what else can I do to debug this problem if it recurs? -Alan From owner-freebsd-fs@freebsd.org Thu Feb 11 21:07:40 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED5285353C5 for ; Thu, 11 Feb 2021 21:07:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660075.outbound.protection.outlook.com [40.107.66.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dc8NC3FJlz4nZ9; Thu, 11 Feb 2021 21:07:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RKq3NA2sbhu5JVT/pg/G9/whdVngM9vKd1vs7aP3rLjG36U1JIrkVpjrSjgawew8zNN8tSSf+wd4v9hzZLyuZyk+xuf2b9TM1+TZhGDddwH3PI2SFnkDT2SoF+QtqIfTgemi3/3n0l97RgeWPCnhJpx3htezmaNc5Ukdwyi398asUI5+6WuAi07J8U9mxnbUH6dCWljl2DZwzjPye3hqcVd0E6P0tu6vmJ+cJzAaUxOm9k71hQqG+9YIfy1BD1EiFaKgyl4HkW49N5zgWNdExz9jBQEfH5Y2eeQfR0NUrTE+Tx6kKgzTz8/4PdcbbzTXEsfGE0fYi0DvHdQ8WGLoNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dgUxeN47lDRz0X2kB2qQyFJdfDcmVJMDF0LuR8zAtXo=; b=CLZvYsv3s7pn4EeV5QPVkbmj08IOemmF91ad3Nhiy4w9N145WfBisWe/A3z0RaZsSAbkHkyKdNbtpdqXtwqGXILxXv+MVHNYFcYl0OUIeDyWVHLVrU2OPQMVBACUFiVPjlqOwTkMhEZZNpwdcZucE/DdTNIUjKoNRjboWo4QnHzQ2/14rJXqgRadjXcqTVlL9VeVnUlsBO+JrPdUkBnw17hHmqEmmS+osq5EiDkRDyxsD2ajU4G8FYYRC/yjN9JxesygrFOEzoifQWx9Oa9bW3iSd5b0YCy9ai2SVAajNG53SMne3d/z7U1Q+kwUbprVmgn0p6zPa4iBjwFCkRtxzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dgUxeN47lDRz0X2kB2qQyFJdfDcmVJMDF0LuR8zAtXo=; b=RYW7xmakBVoN1rJPuzeVM1oE+1BWjjnUVRWkcvQ1wgziKiXkl9cAAgThi8xg/jdCpKp3/9D0wUHmdaJJF6pvxrpgpbHudNjJLxLsCvEx07jmrOqQ9T3ijNUFspLR6cvJmJwrIlqYooW5lHByZ7q2JbVXQgnmICKTPZ0dgGlzXAKk6CetYhDWAvbTGVghC4/RtD7u6nNowDTU4AILNSq6ksJrHm/zZZfwb6KCgYPsEDaczDuzFyeia6LBio5ETw8IMgZIVUBPYOyPnOdZKw17P5qCVfal5MSUhawiinsic51y0Md6vi6j3cHFE756M4OhkCPrMV25k5vuqpAjVAhjhg== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB4130.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.20; Thu, 11 Feb 2021 21:07:37 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a%7]) with mapi id 15.20.3825.030; Thu, 11 Feb 2021 21:07:37 +0000 From: Rick Macklem To: Alan Somers , freebsd-fs Subject: Re: NFS delegations don't expire after unmounting client Thread-Topic: NFS delegations don't expire after unmounting client Thread-Index: AQHXAKqojQBgScYUMUKehj4UI3CsMKpTbdB+ Date: Thu, 11 Feb 2021 21:07:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e2d69238-db69-4a70-effe-08d8ced10f9c x-ms-traffictypediagnostic: YQBPR0101MB4130: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n9NI3fh2u5P+0Qvgha2QpQlDN+pWkliVapxvid2p9/EgMR4zj5YetAwwBALPHZQtSwrSJAZs6hi9qbM1R5i6ACdtdFeLn8zZU3MC7BREsiHra7vDT7C2sw1OAdqBf0B+gRmnhhAfvQqLg6551NuS3AlPjMedomAVm04onbylDJ8CRTuPTXw1XYSs1L3Ne4LyWmNym1AKdofGLOcEP81zsK8kIQ/243+sy7XC6p4tnDckZ5uXKDVdTWTQk1l6aA+FH1TbaWD2L1VBvBOnP0PSCmLgMTMnJ2d2zpZqTEHEVvvm+p63xYAJMie25ErEjikotjxdB843Ld36jYF9vd5Ee0LabmujZnZkR/YluiEUdWA8BkoDClzkORWy5rgepK5rfZXZta69cpYuglY+3V6tlfo6zT3J25iYLac8q8OSbg5hztN7FWCHiBHWgzEzgl24yEvZy6kAS0cr8taoUXIGl8eI3Wh3DdpVUCNPSaAtQc5oXnddbzZVUaDcYZQA/2N7ye+CcW5AbOCRQiLjrPVhJsxdM2cXJv/F3PrFIT+P19jBdFLrZka1i9WmhL18lRAV9D09jvq6ZhmUolnXKs/Yv9EB+paPCKw1HBoHYt0TLmtJIbakhir/ryh01Pkybw9FsOg9kwZ+BTIQ5XKpD/NPFg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(396003)(136003)(39860400002)(376002)(366004)(86362001)(2906002)(5660300002)(55016002)(66556008)(52536014)(6506007)(478600001)(7696005)(66476007)(66446008)(71200400001)(966005)(64756008)(110136005)(76116006)(33656002)(450100002)(66946007)(786003)(91956017)(83380400001)(9686003)(316002)(8936002)(186003)(8676002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?ZsWLp2z4iTGo5TSRcWsRpGNb0SXouyrQTikWMftzJFihq5SR/93l4F8BPo?= =?iso-8859-1?Q?Lvb1807emWd1/d+bKXKQSOWW6SGZZTIOi4Du2ITLU7cJnIJwaX+4TtgKVX?= =?iso-8859-1?Q?QT/BrQZQxpHVprDQqrgDTZ6yVQZYcQGp7dscIZ4DPh9ESf9r8zZpS39cog?= =?iso-8859-1?Q?dZNriqF+C/tYUAcwP3SAucO7GYx9dkI2//46Yo5Q/Fje933voGkUD81nvE?= =?iso-8859-1?Q?O8Z3OfAkUdR/cYgW0civaQBYdCLGwqlzSZjW2ZBsgCC3sCVf/FQz6PAx5C?= =?iso-8859-1?Q?Jgkkqpq45fhnTgeX5oo0CDqvjOQoeHP0osua8EdDRp+QTwpyzgPJMfa5Ce?= =?iso-8859-1?Q?Ge8E8hDtPWfi8s/dfyiUmkJ0gqY/bEd/QlpXV19AOY2aFnWX1/PaSFokZl?= =?iso-8859-1?Q?oKXc+P3kI8G+cs5hWhPqaeReGXrTPe4DoYfULumF6xlPzNLXk55EyHcG7M?= =?iso-8859-1?Q?XuxESUaegMr4eeYnG/j/UZu/qgiQeslf3F8HfzSNLUTl5wFwKRwZeBneGb?= =?iso-8859-1?Q?LJzSge6BZcoZFg029c/mM0rpdAv6QhQt+0XdIo4HYbJ0ABcqCmaReeOWx4?= =?iso-8859-1?Q?/jbyR6A9okjOxJr0q5Bk8YQByKvjyg/3X/aZkyLRY3CckUkWdBxpvBMzPs?= =?iso-8859-1?Q?ad+VLZmqevzqJvZgcHtVhKruRRvwEsdrMl1T/pHUZ2BeR1Hui58t6BAAGO?= =?iso-8859-1?Q?0oz1l+rir7CHS8qkuFEmn/aR+5Fpi6FqXGxqrkdJCsWoHRfsmzIh+zw3gj?= =?iso-8859-1?Q?3x1h6lLxpbeh3Lr7bjP4c2ZLoWWICdcK2Ia6orCPYzPvCRt/LRoRD5CV7x?= =?iso-8859-1?Q?alN5mRGkRPaWGDQ0zYdgE0CoRSsrf2emRQ3Jb+I6GOIS1O4DzaQ10OvZZM?= =?iso-8859-1?Q?Ew8/02T8HgKwiHvLRacvxSG+KX3H1ibs8h+gkgnxK4UdLK/svoyl4pD+Sn?= =?iso-8859-1?Q?D/M/UXLIQjUEJyRw+6aDWz5tzQntMp3BIu9SGiB4ERFO+hgMEtcPsDFWDl?= =?iso-8859-1?Q?Kh82lR9ZM1gQY2nxiCyl6EjX6LgMfl/iCVSw7CyBBXT29LtasO6Gk3MNVR?= =?iso-8859-1?Q?d2gYCnlKOjICQCkFBccVae+OuALdM+BmuT7RXdABXiwfsgdo/QDNnn2NbH?= =?iso-8859-1?Q?/p6sOb3oZwoeAVPO4fIl2MK30R4fLG7qWSNewIzffAvGBmTU7xf0GGvwEy?= =?iso-8859-1?Q?ePKhBzzAQYhVqh9JcMMimLRVO9uip9jzzEtvNWIvcCrm5jRMXbpc+VSR2c?= =?iso-8859-1?Q?g0JCgsABitVWzYY8fqh+K0GyRpMCr8XGiOJNAyzWvpkc8J0+17pMkg8TQL?= =?iso-8859-1?Q?6y1OEDLR3VxTIOoN+HXMBrREbzo4b8EsYhvC2lleKi3ttrdGS+x8GJHlDk?= =?iso-8859-1?Q?mDgAP/BDJp2QrQcR7THyvhVf2yqLoxiVUndHksB7UjzozJdNrOztU=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e2d69238-db69-4a70-effe-08d8ced10f9c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 21:07:37.7535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fFwTc1y/oyylV0c+mPoyTQo82WEmeKVxUU0vslLvsJVacBWPHEGof2RF7jMpuc9qs1ZuVAJU9at25A4vg6JDpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB4130 X-Rspamd-Queue-Id: 4Dc8NC3FJlz4nZ9 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=RYW7xmak; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.75 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.66.75:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[40.107.66.75:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.75:from]; NEURAL_HAM_SHORT(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-fs]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.75:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:07:41 -0000 Alan Somers wrote:=0A= >I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD= =0A= >12.2-RELEASE server. Today, most of those clients' mounts hung, and their= =0A= >dmesg displayed "nfs: server XXX not responding, still trying". But one= =0A= >client kept running fine. nfsdumpstate on the server showed that that=0A= >client, and that one only, had 2 delegations. It also had 1 OpenOwner, 1= =0A= >Open, and the CB flags set. It was the only client that had CB set. On= =0A= >the theory that its delegation callbacks weren't working, I tried=0A= >unmounting all of its NFS shares. That worked, but to my surprise=0A= >nfsdumpstate showed no change! I could see that the lease time recorded i= n=0A= >/var/run/nfs-stablerestart was 120s, and I must've waited about 30m in all= =0A= >before disabling delegations, unmounting everything, and returning to NFS= =0A= >v3. So my questions are, what can cause a delegation to linger around lon= g=0A= >after it should've expired, and what else can I do to debug this problem i= f=0A= >it recurs?=0A= The FreeBSD NFSv4 server implements "courtesy locks" (my idea, but someone= =0A= else coined the term for it), where a lock is not thrown away until both th= e=0A= lease has expired and a conflicting lock request is received from another c= lient.=0A= --> In this case, that would be an Open of the file from another client.=0A= The idea is to avoid loss of lock state when there is a networking partitio= ning=0A= that exceeds the lease duration.=0A= =0A= When a client dismounts, it should tell the server it is done with the open= /lock=0A= state by doing a DestroyClientID operation. (SetClientID/SetClientIDConfirm= for 4.0)=0A= --> If the Linux client did this, then it sounds like something is broken i= n the server,=0A= but my hunch is that the Linux client did not do this.=0A= If you can capture packets during a dismount, you should be able to look=0A= at them in wireshark and see if the DestroyClientID happened.=0A= =0A= There is also the nfsrevoke command, which is supposed to be able to=0A= get rid of client lock state, but I'll admit I haven't tested it in like a = decade;-)=0A= =0A= Maybe courtesy locks should be made optional, but they have never=0A= caused problems and I'd have to look at the code to see if that can=0A= easily be done. Might need to do so as another "make the broken Linux=0A= client work" sysctl;-). They are now the defacto standard, you know;-)=0A= =0A= rick=0A= =0A= -Alan=0A= _______________________________________________=0A= freebsd-fs@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A= =0A= From owner-freebsd-fs@freebsd.org Thu Feb 11 21:32:15 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7ABFC5357F6 for ; Thu, 11 Feb 2021 21:32:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dc8wb2V23z4qWK for ; Thu, 11 Feb 2021 21:32:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f45.google.com with SMTP id l23so6548925otn.10 for ; Thu, 11 Feb 2021 13:32:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QkuGPVcmfhH+E5MI9jHcmE/9ONB6KPYKkeOEfdeAF10=; b=NhFgetChZHwv77qQJ/u60MGX38UZ70b5saTaVhKzmP6gHy9iCT16E9ESSurqp5tgnk sL3L4iDdWGgehKQ0y0EQnUvyMPMfwk0OACndEAcIP9R2aDqgX00gCAdvA0tCq2YCVDxI ePmZ9cj59cc7binvVBTwO+/Hrz5aO0XscCDemA+j7l0z+y/MFjwBOGgjja+1yEhTgtEx 3dIqVvfHkiogei77+3KbdRAa35odYjQwkCPkIie/QnGmxDH9HMsUh7pNh3qg+StWDidA sl6yOVrd+IXuwJWKq77kNCVYFBz7gHFqqHS3nBPmACMMQXoCR9T4KQPWvsC7m89dOyc9 4/1g== X-Gm-Message-State: AOAM531D3JTpRTIjKxMm4waHsB47/tJqQCwkJF5U4gHe6gj1ranZENWU 9e1kqPy0Lrf8bvoHzpPsXYzjbBVAxUzPLvoxF4g= X-Google-Smtp-Source: ABdhPJwUjSn5AhXhrYW2NCxNsqLfERIfvDrXm9ZXYyj3BG9sS5WhaGeUQQSgYy7Q5WlEgQ1Vt+UbWdTeLnF/epGqQGc= X-Received: by 2002:a05:6830:18e6:: with SMTP id d6mr6895otf.251.1613079134363; Thu, 11 Feb 2021 13:32:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 11 Feb 2021 14:32:03 -0700 Message-ID: Subject: Re: NFS delegations don't expire after unmounting client To: Rick Macklem Cc: freebsd-fs X-Rspamd-Queue-Id: 4Dc8wb2V23z4qWK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:32:15 -0000 On Thu, Feb 11, 2021 at 2:07 PM Rick Macklem wrote: > Alan Somers wrote: > >I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD > >12.2-RELEASE server. Today, most of those clients' mounts hung, and their > >dmesg displayed "nfs: server XXX not responding, still trying". But one > >client kept running fine. nfsdumpstate on the server showed that that > >client, and that one only, had 2 delegations. It also had 1 OpenOwner, 1 > >Open, and the CB flags set. It was the only client that had CB set. On > >the theory that its delegation callbacks weren't working, I tried > >unmounting all of its NFS shares. That worked, but to my surprise > >nfsdumpstate showed no change! I could see that the lease time recorded > in > >/var/run/nfs-stablerestart was 120s, and I must've waited about 30m in all > >before disabling delegations, unmounting everything, and returning to NFS > >v3. So my questions are, what can cause a delegation to linger around > long > >after it should've expired, and what else can I do to debug this problem > if > >it recurs? > The FreeBSD NFSv4 server implements "courtesy locks" (my idea, but someone > else coined the term for it), where a lock is not thrown away until both > the > lease has expired and a conflicting lock request is received from another > client. > --> In this case, that would be an Open of the file from another client. > The idea is to avoid loss of lock state when there is a networking > partitioning > that exceeds the lease duration. > Ahh, so maybe the stale delegation was a red herring! That would make sense. Especially because the client with the stale delegation was mounting a different share than at least one of the hung clients. > > When a client dismounts, it should tell the server it is done with the > open/lock > state by doing a DestroyClientID operation. > (SetClientID/SetClientIDConfirm for 4.0) > --> If the Linux client did this, then it sounds like something is broken > in the server, > but my hunch is that the Linux client did not do this. > If you can capture packets during a dismount, you should be able to look > at them in wireshark and see if the DestroyClientID happened. > > There is also the nfsrevoke command, which is supposed to be able to > get rid of client lock state, but I'll admit I haven't tested it in like a > decade;-) > Well, it looks like it works. When I tried it, the delegation disappeared from nfsdumpstate's output. That did not resolve the hang, however. So the delegation was probably red herring then. I guess I'll have to roll up my sleeves and start tcpdumping then. Sigh. Thanks for the tips. -Alan From owner-freebsd-fs@freebsd.org Thu Feb 11 21:54:30 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CBD85537C54 for ; Thu, 11 Feb 2021 21:54:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670068.outbound.protection.outlook.com [40.107.67.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dc9QF5PLVz4t8g; Thu, 11 Feb 2021 21:54:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OZQsSoX4YE2PRfxuVFbVSMMl78j9kVFcq5QRxMzgwNtwVDVsE7CCNiRaXg2Fm92tuRoG6NOvkSzjQwpEi+lMCvWsxo4GPR0cc8jTttXKlJ3ygmdO4bA/PaIAovxYarI4BoN5oyWJfxps5s/vVoRjuzQX3wFXKzpkSZ9+vlNXBSeTAdPF7fv+yezUoWDP9nmZxJMwl+2H2pFuWlfI45+39tuIQmpSmvDBVRGxmI5vfhxnOLd/NvdsXWkTNmBXnleDfooYYM4Y/uJYvx/m8BF+f3tiDhZ02Xyx8SFz0YYouEOij4w9GvTGW2lA1nfqoQNszg6xVpjSJjNbOLONUkTQxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6gzuyQtxkNq0Kwctzr6ElCa7yjxvZ3m6oCd/FsBRRRk=; b=T4Ufo0FW5OjzckkXIiBVBEq4RdccepPlXEOq1hVnvjjw+gigvodQ90LKNkfYqtdot+rGwb4gP/BEjkAxxr3sZmz5+fjZYkJpworz6VnJhIyS5x+QjaQ0jMpD627lGfRirOx85unNaNDU2YlWKovtt902kz28LnQ+5Sz8GguBG/m0ORFPuu2ND2a9vD8TS1WRYomuy1ZQhxdViacgu/clRGfoDbnzHUTOLqqqnkBi2XFLnF3qrDwA2BdoSBV9vLmSe0oChkTewRax2VskZ8Y3c6GB0mYK+BsLrJhMJRdBo/d6cHJUGtNt4QreWN1eYEw7donwKDbhFdHSZLJ7Pxi/GA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6gzuyQtxkNq0Kwctzr6ElCa7yjxvZ3m6oCd/FsBRRRk=; b=YNhzNTlipHvsjFIL92mkOFDwIaDPcK+7xoNKuRvCbiECSjDn8Ygi52LsPAvCXqW2kmu+AiTEH3lNkRPobw2bWVFP7ro3gMkn+SmDj+k5xCZHTd9j7B6/KrC7H1kM/8i3M8i4B/p/BiXHRCTH7S1Pj/tLyralrZ5XL44mrwAlRUHwes3shxG0Qwcp5C+1CQkjBHEIXdDT/vXlJ7iXuBEPOZndxLtCu4UmJdvW9fkAObC5vZrkw/WEKR4e+Fv4CjVUowN7haeO4QMLwAlTwXMXnU8YH35ZgUm/rZW/TKe+QbfSO89MfumHYYrRqaj6fbRwnz/93CfIV+KHB4M60vMLRA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB2487.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:51::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.23; Thu, 11 Feb 2021 21:54:27 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a%7]) with mapi id 15.20.3825.030; Thu, 11 Feb 2021 21:54:27 +0000 From: Rick Macklem To: Alan Somers , freebsd-fs Subject: Re: NFS delegations don't expire after unmounting client Thread-Topic: NFS delegations don't expire after unmounting client Thread-Index: AQHXAKqojQBgScYUMUKehj4UI3CsMKpTfXiC Date: Thu, 11 Feb 2021 21:54:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38f1503a-03df-4eae-a075-08d8ced79a90 x-ms-traffictypediagnostic: YQXPR01MB2487: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EiLqqCmo8195S92MfrznzlCBidEQAS6DcMwS2cIyhR9I2c46r5JnXScR2IYVf/3a6QoNUoBG7P8xnPcHcdt0p4xA6Xb8fQACQ0ygHDZs7lCsdAjBxe5WtM3gnStkyqDu48gQrYXzvpMEvAhefOEQ39YkazXTBqH0DuhyJv/qZWmjogQ3p25StN41D96CjIgCI4DpmN8LuCv4Sh/kcktBXyZiOxXXrDgNKZ/7D8ZpThMnn+zQFVohVkkl0i0MVcQwhEy5uHWcT4IdiEZmphNoOU5eeRnOfLEAZilGiFXVGzN4cgn3druyF+Au5jOHHeM/g4uAUv597PMzRKOGzbgMOhb/sqy2YdAJ6x7l3iCcfc6i76GYTBeOrWePgQDySFAHElhaAC4ENDpVJGGL4rmKUOWuFst5lVDuewxxXpzX1zYQtUAT2YWK9SGiYYuVBYx0Y0hKRn1xg6YpnGEltb0yqWChfwBV8m65GEJic6v+pDXvm8MZiLP8Hp3jSz6U87ssVCuacwbdWYNu4z3DqvZ+CUj9vzCsPvVA1IR1z4+wF9gDIh0m7YK1oC0f+G88BkiXpQ26J+8Rhxok5lgVlEtMrOe+ofx2N/zMcGf5cBi7L2yTHDBvJkfmaRjB+tKb6MfDAoHlkk+pJvUWjsjAx7Dv+g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(39860400002)(136003)(376002)(396003)(9686003)(966005)(186003)(83380400001)(55016002)(8936002)(71200400001)(86362001)(786003)(316002)(91956017)(66946007)(6506007)(110136005)(8676002)(478600001)(76116006)(450100002)(2906002)(7696005)(66556008)(66476007)(66446008)(64756008)(33656002)(52536014)(5660300002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?mgXCHJetEWPXuOcAa+D9zu+9WXSvpYu+LRlcv+23k1mX/zh29AMUu6urMS?= =?iso-8859-1?Q?RKjcow4H/DMV9mxLtdEa5a7S/N+myJ910syABkRJbFsZQX36t9q+U9O+Sz?= =?iso-8859-1?Q?I0df0USax41M8aER76GO4LuhUODuJ5TZwudHHMApYiMW9vO12JUpzNImbl?= =?iso-8859-1?Q?5t+i/WOSvAJUtWfxTL316Habqki2H3onMdBs46M5pB+onddkm1DyJUlHpV?= =?iso-8859-1?Q?n7rdTAJwK6v0eorGLJD0lMyfG2f2G1hPt+/iZSqRsNMjZMiK91tTYzqmjy?= =?iso-8859-1?Q?gMcjNtiTIKSGwYwvNZ3hSW/FECgnLGe12kKr8j+nQ11qGnvWDh/6oMxawR?= =?iso-8859-1?Q?F2vLa8JLfVLlP+R2cQQsTnhURQPIkvsQzSOOPvgNevq99hWKLkmE/3SSDu?= =?iso-8859-1?Q?2dywGo7jZvkcyP0yG0rmCSRbCxT2Fwh74foa5mZSppXaUXWiHaMrGDDAmt?= =?iso-8859-1?Q?PAVKy+QLFU4bEMG/TryomlTP+aiXEAvM8b5Hqx6VgJC9Vqc5hFXOiTGFJi?= =?iso-8859-1?Q?N0vMJJpUYTjSDUG2Aj0aUd9b2DIknq5xP9RXUViin1TBzYVeurwcNJGDHZ?= =?iso-8859-1?Q?zyI3Nzmd+vSD6wjX2gnGvGYG/NDPAhv0OURGB6jrtpq+BsmHhJgUIpZ1kN?= =?iso-8859-1?Q?rpOP6vw/3VMWkCZfJNIaCuF3FGozPmLE7YpI+uiBtXShTqRKkcnJULQL5y?= =?iso-8859-1?Q?3Yv4zrSGyAiLcrOjuIHM3odx3rRUPCPX2RrHUZdTx2sl896gQj1Rl1DBLU?= =?iso-8859-1?Q?fODz8J21UMGwxosK6RdtvWoKvGCKxqFNoAGA0qWSZKrIETw6Gm798rDYhD?= =?iso-8859-1?Q?VHB+4y5mG+P2nlHj3O4jnpUxOmy/BBupxE6A5UIJs+HLxdhF33Uuc1ZjaL?= =?iso-8859-1?Q?JMRwER9xmneETVxfCUgFUKbbC+y+IT0lk86BL+00X4WpW2E0CcsA+pcpDU?= =?iso-8859-1?Q?MzgPclm3gBonYdGFGJTSL9QWt72knCtpD0JuxKEXaz2WkU6ucHrqAVggGL?= =?iso-8859-1?Q?4EC78pvSsd9JkXSxFfLNgD8gpJ0IdVDlNhbxE4vVC6xI3owxhA4+Al3hno?= =?iso-8859-1?Q?Sj52knuL5mWPClRhzJjNF0lXCZ7nBEjyJArjEwABYHBFsxa0HXSc2/lrf0?= =?iso-8859-1?Q?B2LhtV8HZlmz0bdIXu3GEyrdg0elZC3qShQWcrlCGGhqoEugsfoTp5OI6n?= =?iso-8859-1?Q?3c1pkCgFUHBABZBlqPyuStvlhOWfv6T5UkpsdwAGeTjE1EqeGXQ3YgfgZs?= =?iso-8859-1?Q?vgRhAPkD625ELtuckrs6lqwOV3IkmDn0/ghQMeUVAjm20NiVotUG5yH8GG?= =?iso-8859-1?Q?WQV3P9DYzkVwjIgRzzgQl9XXJgGsDE/+ygcw46+F1UomWEcsuyh+teLTg6?= =?iso-8859-1?Q?40d5GqAMP/1MoONso9aUQKVS8lTR6FB4WGx+GyxcRjrK8WzsPxSVg=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 38f1503a-03df-4eae-a075-08d8ced79a90 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 21:54:27.8675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BLdbBKF7sI3lvIfOpxVEnYe4up4j29icgxzGgVy0rtLPYeXoxmT1zgDe6Lu8Bdoc/7xaOHvg43N2bsZhWfzkvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2487 X-Rspamd-Queue-Id: 4Dc9QF5PLVz4t8g X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=YNhzNTli; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.68 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.67.68:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.68:from]; SPAMHAUS_ZRD(0.00)[40.107.67.68:from:127.0.2.255]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.68:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:54:30 -0000 Alan Somers wrote:=0A= >I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD= =0A= >12.2-RELEASE server. Today, most of those clients' mounts hung, and their= =0A= >dmesg displayed "nfs: server XXX not responding, still trying".=0A= Usually these messages indicate a networking layer problem.=0A= Next time (or if it still happening), check basic network connectivity.=0A= Also, if any net interface does not handle TSO correctly for an RPC=0A= message near 64Kbytes in size (the nasty one is where the NFS RPC is=0A= less than 64K by less than 14bytes, so when the MAC layer header is=0A= prepended, the total exceed 64K), you can get "stuck" TCP connections.=0A= Most FreeBSD net chip drivers should be fixed for this, but I wouldn't be= =0A= surprised if there are some broken ones out there.=0A= --> Disabling TSO fixes the problem in this case.=0A= =0A= rick=0A= =0A= But one=0A= client kept running fine. nfsdumpstate on the server showed that that=0A= client, and that one only, had 2 delegations. It also had 1 OpenOwner, 1= =0A= Open, and the CB flags set. It was the only client that had CB set. On=0A= the theory that its delegation callbacks weren't working, I tried=0A= unmounting all of its NFS shares. That worked, but to my surprise=0A= nfsdumpstate showed no change! I could see that the lease time recorded in= =0A= /var/run/nfs-stablerestart was 120s, and I must've waited about 30m in all= =0A= before disabling delegations, unmounting everything, and returning to NFS= =0A= v3. So my questions are, what can cause a delegation to linger around long= =0A= after it should've expired, and what else can I do to debug this problem if= =0A= it recurs?=0A= =0A= -Alan=0A= _______________________________________________=0A= freebsd-fs@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A= =0A= From owner-freebsd-fs@freebsd.org Thu Feb 11 22:07:09 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36B7353828A for ; Thu, 11 Feb 2021 22:07:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dc9hs0zX8z4trP for ; Thu, 11 Feb 2021 22:07:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id r21so6625964otk.13 for ; Thu, 11 Feb 2021 14:07:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4SYtiu02bfavKqlsWkWA5VSYLaRC6C3ln3NcN2VGoh0=; b=hiPnlv0/TfCygn2pvPKB1nIQ7UHxAkygvUAe3CclqEgkUfmbEBo1C5Gy76XS1bRiLx W9/GiHLNumB6yOm+sHxAnR5cxi2z3xCSkny7df2vIL30gfAgKgGD8EJ1HBDotPRqyJE4 4vZT3K4SDdJn1gwGjXOGGidaZg+UnIkhQovatTUxASDpDwcZErUvTt92YogAvKqC7EqJ nezvtRko4Y+E5Ngkl/QE6qHBBYerCr0BjVWLcimWb1UCrIXquFTVcpWscxN0JJ1xX4J1 AdPSOUlXqGF8h44BLrazhWwdw1dyv7U9rHnWpweAVFZ8R0oKwck5B1LLDWK60C4jv7ew Wi1w== X-Gm-Message-State: AOAM531cd8DzN7EBBMTUGzsha4RL5kJMcDXd88MLdU0kDYu/j7u+zXNB kSiJmffTyos7YMuAJxozg2LlRaNBzC2CRGANfbk= X-Google-Smtp-Source: ABdhPJxTkHcZnrBs4Z8QFADKEgoPD/qq2KsI1ZcSUZ38GK84iS/PuNeUol6lOr/zIXg++RDBEFHGGOVd4ZRzDP9yNsI= X-Received: by 2002:a05:6830:18e6:: with SMTP id d6mr90155otf.251.1613081228077; Thu, 11 Feb 2021 14:07:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 11 Feb 2021 15:06:57 -0700 Message-ID: Subject: Re: NFS delegations don't expire after unmounting client To: Rick Macklem Cc: freebsd-fs X-Rspamd-Queue-Id: 4Dc9hs0zX8z4trP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:07:09 -0000 On Thu, Feb 11, 2021 at 2:54 PM Rick Macklem wrote: > Alan Somers wrote: > >I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeBSD > >12.2-RELEASE server. Today, most of those clients' mounts hung, and their > >dmesg displayed "nfs: server XXX not responding, still trying". > Usually these messages indicate a networking layer problem. > Next time (or if it still happening), check basic network connectivity. > Also, if any net interface does not handle TSO correctly for an RPC > message near 64Kbytes in size (the nasty one is where the NFS RPC is > less than 64K by less than 14bytes, so when the MAC layer header is > prepended, the total exceed 64K), you can get "stuck" TCP connections. > Most FreeBSD net chip drivers should be fixed for this, but I wouldn't be > surprised if there are some broken ones out there. > --> Disabling TSO fixes the problem in this case. In fact it is still happening. Basic network connectivity works. But tcpdump shows almost no network activity. Just a few keepalive packets of length 0-1. Based on the fact that unmount and even lsof hang on the client, I'm suspecting a Linux bug somewhere. -Alan From owner-freebsd-fs@freebsd.org Thu Feb 11 22:54:22 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42B165390C7 for ; Thu, 11 Feb 2021 22:54:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670085.outbound.protection.outlook.com [40.107.67.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcBlK1HVYz3DR6; Thu, 11 Feb 2021 22:54:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DrJ70BZVsqpWqaPAOoEeBxfRQ3qmFCRb7HRPGl0EPtwWLUqSg0PCap5QwBuham20o23mtLVM1qROefMEdV4RIVeQ/dnhsKYl7J+pFudQtKDR/RM7GhgRkmv3lwQgR0LZhG9HqBS58k5qepCEYgJoCTziyHxlXdU6byKTsfsHEdlFffgKLpHA8W7Lb9snm/KbsFJonHo3hyiRRLxvltmJ5gdCpQlI8I6TfqiHdxvBTgk0KQ236usEZPjcx3Vu9oYFdvQ51teuUov7aaHgJTekajx4qyrtGvTAWrK/QOZZEj/QocR5K/maYzCQNusU/hvMQTIeZzlCN56Ql/la7eaAsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gRsQdV2VgZY0Pzw4GyRn5IEvUrnxVh7dPbwdehLLMvY=; b=TLpxw2awy14HtryISxmhai5uWTkzUz9v/vlGrDbSwpn6nL8aLoOcwenq1w9mYXpfT9NXdUu3/rwb18I+brHzM/3mJ9C2HKEizHALvgCck/QvNdl4+dkO8wdnuIscYro36eZTpm9zszDCLtSXlPjlMfBSzkTsNQ3d041IwgogOCozFqO7vEbB/aAQ44iUejSOU5oSLBVT2UrIqBZaqIV8n1IVs/kXg1td0rPyQsNt+pSgH7vMCUOz/GNYI/0vEmt3WhN2JkcvG4IWTKAT21YVlv1os94c5Hj/BdOjd08QJ7B9uz2Zbwi8MKCUE8/wZ12Ru/4bxiPd4kDSFOXiYOETBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gRsQdV2VgZY0Pzw4GyRn5IEvUrnxVh7dPbwdehLLMvY=; b=Kz8AGfCEeUHvFUvBjMf8kfoQX4xL/gR5KNYEuZNq5xteBkPrLTHmUBVtlc7tTj73IYYBH5fpfs6seZ6OAJCqfP8e35DDc5xieMxNnP7lnuxiLweej0uKTMPIn+Tt70PIJlXTtKLZJ2khSitUbwFVg+h0G3AZSdw3pKHyc+EOtDd/x1i2Z2FcRpw//ZYyYZQ0Lm2M+co6EDrrX1WSxyMsI9jHxU2gas2FfaBj5+C4I5/yAK9/vsdKL5bPsNmWoPlqHVaYPgtQThWiRnyq+7dDsg182XDFx83sbJHCuif+daftIgyO4hTh+zkohNMF58+F549gsU9QJ74fgu4JP3ZFxw== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB4179.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:9::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.21; Thu, 11 Feb 2021 22:54:19 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a%7]) with mapi id 15.20.3825.030; Thu, 11 Feb 2021 22:54:19 +0000 From: Rick Macklem To: Alan Somers CC: freebsd-fs Subject: Re: NFS delegations don't expire after unmounting client Thread-Topic: NFS delegations don't expire after unmounting client Thread-Index: AQHXAKqojQBgScYUMUKehj4UI3CsMKpTfXiCgAAFn4CAAAqW9A== Date: Thu, 11 Feb 2021 22:54:19 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a3c46e2-dd88-4ffc-be21-08d8cedff74f x-ms-traffictypediagnostic: YQBPR0101MB4179: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aUFAIAfxt7zLYZhV7VsRiuaHXDEcc2fUSA5vMYteT1TNsZ3qppGRNhehZ/294hwVfOxZhQmH0XqAo/20JEr1RC2u7zUEwXVxGX4YwBKH8jVTHtpVeLSUwphK09yC/stJtvUzz6jpsajGHiuMKoVXqzsK0evl1rOfPyeBe+h/mPQUPWRsbBCnGet2F0cZzF2ZiLUrMOgiiDIe7QGOBSBPCmdchoiNPAEYQdle0wafKXKqljsHjDS7w+7vClajze/KrvLOZSbgQ0mRa8NNkM2rlAK6dKHw+Hi12iZzH3HXw/4yJmE/8NyQXeq6PVg4JgstE1nIYEL8esB4V6z7AaqkkaehE9rGsgHrICdGYdXli8IcVpLggR6zFTDiFatcs5dUQbrk36b6TyFmQU8st7+EiP2AFeouXLusoIdtHZeEH+e7KVT3uNGbvJr/TwG4tO07NpA4KHdNHrMPD+n5f/4jQfz7spwJEbBaJqRQR9ZfuUkaW9J0hQcFFAwL/iKaxnC43q+tUpRZ3pRWQkw3MAcEdErVhc5JK5XuDDpqw1zxZ5ts5Y3hcYmC+5Y3/HxJzssr x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(346002)(366004)(136003)(376002)(396003)(4326008)(478600001)(786003)(316002)(450100002)(66946007)(8936002)(2906002)(66476007)(186003)(9686003)(55016002)(86362001)(6506007)(76116006)(91956017)(5660300002)(52536014)(8676002)(33656002)(6916009)(66556008)(66446008)(71200400001)(7696005)(64756008)(83380400001)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?2/DUw3QOFEf4gY9hqy9GQr8lfsQTVZqwoi9kPjgpzvl3hipqyIZIqhdYAD?= =?iso-8859-1?Q?cCuUloq4VZ6pAzxGg/kDrB2AR2nRrQFfLt5nFLuU7Tqt1idwQAHDp7rJCc?= =?iso-8859-1?Q?kWh6smQsKREmmOToFnuatlY6E/YdaOvGfwWCbmm3JUblAlV9ON/vN4eCrF?= =?iso-8859-1?Q?yGG4StvrQQNEIaeVqNSpOm9YSZNsQqb2NfwoEr3boH6TZhbwfM19Nep3oJ?= =?iso-8859-1?Q?1a5Vtu4BkeaeftyCVkeaSRni4oUP7RrxEaMzVpnZpwIlgoAJrLjrOEE6XC?= =?iso-8859-1?Q?VSqjHMJy1uEoe8I/TgZbgEAH4kZ1IprTiFHvLKaSaIQF9h25g26AXgHBv2?= =?iso-8859-1?Q?wVIcdAQX3t7fD7Q92pSGOah7CJ3HHNX3G/AMHUCsJa2x+KsYqMhtFrtcUE?= =?iso-8859-1?Q?GOLknAl5KJBxQEdzfAcDg3OOX3aSJ6GVIxL8sKWR4sEwAgy+H4QA+yU2Ej?= =?iso-8859-1?Q?u7u6wMfWxYSr2Mz3L4Agm7pKn35jpKQ30lgcS1X2tDiJECD3iRfxoB6XKR?= =?iso-8859-1?Q?bEzA5s2vswFsmpqslZQWYuqDNLPXyeIxOwEmXXBtLs15d7Un9Zn8pp2Rdh?= =?iso-8859-1?Q?CC44uHM21BGGQRCexkmxJ93YCJhbGZZYarVAW6+tgga/c7387lZ8Rpx9/U?= =?iso-8859-1?Q?57+NwUEVcuJc374qb8JaKUo7NIPV1npFf5DKq8QaI8EJJqllkMb3aP3uv7?= =?iso-8859-1?Q?b2Nr/L1Q/homFznEHvDRii/3dy7LKJ7PZtltWXgEf053HSfNVUhcahQsMN?= =?iso-8859-1?Q?HhLpTazsqJ6Lj7XHnPk8Ncf24oCCziRM48/73pjfzpSJrWZQGPBjfZEXej?= =?iso-8859-1?Q?4BjamA3YYhxCAlzzXHgVcjP98swcHD1onxBtFgvadP3ZzpHWwQvzvQK1+D?= =?iso-8859-1?Q?kQzJ02CHB2sHNPiHNJn4cjF89MV5OnH1TV50SPpTIIyNFeb/rZnviA8f95?= =?iso-8859-1?Q?5L6jSVFIFnLmwp4ZrmWg9sR0idMGSsQQ1tTeNoiHwSU51o1znDqYjsNbw+?= =?iso-8859-1?Q?6TQfETrUGsYyHYzFhVHZJ8w6bvoSe/7NFIum5ckPBDaULU7E1qA6lkHRNG?= =?iso-8859-1?Q?eoupHVF3CdgcuVCNz+8o13iR5h5qnp3d7i8BwbF6RqsEaufEoHmXA2hK++?= =?iso-8859-1?Q?rEAENwRJaGozTlqezju9hUh6h1TQWfkADnusI+D3vS0xuDUo4blEvxfMmW?= =?iso-8859-1?Q?R5GzYPkstT9u4cikdqwDwUxEBT5lu4JN26ffuqp/KZ/PDlLn3F+n23tEWI?= =?iso-8859-1?Q?tlW+DyfEG7tHyZ6sI/WzlllO9CYT/4bjy71PVdqjf4cIt2+R7HLDifoOG3?= =?iso-8859-1?Q?kCsQ/lmb7Tdtkq9HzouANMcQqf3q/Lh5gF3UFgK+Y287bbzwMpEvxTgznG?= =?iso-8859-1?Q?QhBOrH5xDghogK6CKacv7BYOdoHiHxHwZRWqb3pE7EorPKny8IZQ0=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3a3c46e2-dd88-4ffc-be21-08d8cedff74f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 22:54:19.3953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PoZ7JHzm6tQ+vLsc9YAiyJAncorfhuXK/5bzFyY7se8UxwInFYnXY5X3LJMiOLdPruUImKmpK2010mdutUUTfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB4179 X-Rspamd-Queue-Id: 4DcBlK1HVYz3DR6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=Kz8AGfCE; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.85 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.67.85:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; SPAMHAUS_ZRD(0.00)[40.107.67.85:from:127.0.2.255]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.85:from]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.85:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:54:22 -0000 Alan Somers wrote:=0A= >On Thu, Feb 11, 2021 at 2:54 PM Rick Macklem wrote:=0A= >>Alan Somers wrote:=0A= >>>I have several Linux 5.9.15 clients mounting NFS 4.1 served from a FreeB= SD=0A= >>>12.2-RELEASE server. Today, most of those clients' mounts hung, and the= ir=0A= >>>dmesg displayed "nfs: server XXX not responding, still trying".=0A= >>Usually these messages indicate a networking layer problem.=0A= >>Next time (or if it still happening), check basic network connectivity.= =0A= >>Also, if any net interface does not handle TSO correctly for an RPC=0A= >>message near 64Kbytes in size (the nasty one is where the NFS RPC is=0A= >>less than 64K by less than 14bytes, so when the MAC layer header is=0A= >>prepended, the total exceed 64K), you can get "stuck" TCP connections.=0A= >>Most FreeBSD net chip drivers should be fixed for this, but I wouldn't be= =0A= >>surprised if there are some broken ones out there.=0A= >>--> Disabling TSO fixes the problem in this case.=0A= >=0A= >In fact it is still happening. Basic network connectivity works. But tcp= dump shows almost no network activity. Just >a few keepalive packets of le= ngth 0-1. Based on the fact that unmount and even lsof hang on the client,= I'm >suspecting a Linux bug somewhere.=0A= Yea, without a packet capture being done when the failure first occurs, it = is pretty hard=0A= to diagnose.=0A= There is some way to turn on debugging output in Linux NFS, but I've forgot= ten how to do it.=0A= =0A= As an aside, delegations are rarely useful and make the protocol more compl= ex,=0A= including the need for callbacks to work correctly (in NFSv4.1, they normal= ly=0A= use the same TCP connection as the regular RPCs).=0A= - You might just want to disable them on the server. (You must have set the= sysctl non-zero,=0A= since they are disabled by default).=0A= =0A= Have fun with it, rick=0A= =0A= -Alan=0A= From owner-freebsd-fs@freebsd.org Thu Feb 11 23:13:17 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BB0BE539A0C for ; Thu, 11 Feb 2021 23:13:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcC994lKMz3FJD for ; Thu, 11 Feb 2021 23:13:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A25405397A1; Thu, 11 Feb 2021 23:13:17 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A2194539A0B for ; Thu, 11 Feb 2021 23:13:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcC9947tCz3F6y for ; Thu, 11 Feb 2021 23:13:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 81B85199F1 for ; Thu, 11 Feb 2021 23:13:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11BNDHUj073255 for ; Thu, 11 Feb 2021 23:13:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11BNDH7J073254 for fs@FreeBSD.org; Thu, 11 Feb 2021 23:13:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Thu, 11 Feb 2021 23:13:17 +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 Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 23:13:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #1 from Rick Macklem --- I suppose the simple answer to this is "yes". The layer in NFS below the buffer cache does know "physical" (as returned by an NFS server) offset cookies, but then each buffer cache block is filled in (completely filled, which is why the full block is always returned) with "fake" UFS directory blocks. The d_off field could be filled in with the byte offset within the "logical block", but that would just break for lseek(), etc. The only case that work is an lseek() to the beginning of the block, because the NFS client maintains a cache of directory offset cookies, one for each block returned. I suppose the bug is in the man page, in that it does not state the NFS client as an exception. OpenBSD does not cache directory blocks in the server and, as such, can return d_off values that are the directory offset cookies that work on the NFS server. I have resisted making this change for FreeBSD, becuase it could have a major impact on performance in certain scenarios. The man page should probably note that only the libc calls opendir(3) should ever use getdirentries(2) for NFS mounts. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 23:19:23 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E501539664 for ; Thu, 11 Feb 2021 23:19:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcCJC0g5hz3FX2 for ; Thu, 11 Feb 2021 23:19:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 14E24539660; Thu, 11 Feb 2021 23:19:23 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1385653965F for ; Thu, 11 Feb 2021 23:19:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcCJB6z7nz3FS5 for ; Thu, 11 Feb 2021 23:19:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DE617198F5 for ; Thu, 11 Feb 2021 23:19:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11BNJM1R074357 for ; Thu, 11 Feb 2021 23:19:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11BNJMj3074356 for fs@FreeBSD.org; Thu, 11 Feb 2021 23:19:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Thu, 11 Feb 2021 23:19:23 +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 Some People X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 23:19:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #2 from Alan Somers --- I would be fine with that man page change. I'm not really sure why anybody would choose to use getdirentries over readdir, anyway. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 11 23:39:34 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B8D3253A09C for ; Thu, 11 Feb 2021 23:39:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcClV4hZ5z3GQf for ; Thu, 11 Feb 2021 23:39:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9F587539FBB; Thu, 11 Feb 2021 23:39:34 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9E0A4539FBA for ; Thu, 11 Feb 2021 23:39:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcClV3tdtz3GWZ for ; Thu, 11 Feb 2021 23:39:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 78840197F2 for ; Thu, 11 Feb 2021 23:39:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11BNdYEt082148 for ; Thu, 11 Feb 2021 23:39:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11BNdYjU082147 for fs@FreeBSD.org; Thu, 11 Feb 2021 23:39:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Thu, 11 Feb 2021 23:39: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 23:39:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #3 from Rick Macklem --- Ok. I think the best change would be to note that d_off =3D=3D 0 can be generated by certain file systems. such as NFS. I think a value of 0 for d_off is always meaningless and should be ignored. An offset =3D=3D 0 refers to beginning of directory and would never refer to a valid "next entry", I think? Feel free to update the man page, or I may get around to it someday. Now that I'm done with NFS over TLS, I am going to start to work on directory delegations. For the case of servers that present monotonically increasing offset cookies, more might be doable here. --> I plan on proposing an extension to NFSv4.2 which is a new attribute to indicate monotonically increasing directory offset cookies, because that is the only case where the NFS client can implement directory delegations. --> These allow a directory cache to be updated via callbacks with add/remove entry info. from a server. No one has implemented these, but they might be useful. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 01:26:54 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4CA8953EE88 for ; Fri, 12 Feb 2021 01:26:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcG7L1XScz3jdM for ; Fri, 12 Feb 2021 01:26:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 322F953EE86; Fri, 12 Feb 2021 01:26:54 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31F6153EAC3 for ; Fri, 12 Feb 2021 01:26:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcG7L0s9wz3jgc for ; Fri, 12 Feb 2021 01:26:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0CD3E1B26A for ; Fri, 12 Feb 2021 01:26:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11C1QrEf034745 for ; Fri, 12 Feb 2021 01:26:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11C1QrTh034744 for fs@FreeBSD.org; Fri, 12 Feb 2021 01:26:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253424] fusefs: statfs doesn't set f_iosize ("optimal transfer block size") Date: Fri, 12 Feb 2021 01:26:53 +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: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: asomers@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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 01:26:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253424 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Assignee|fs@FreeBSD.org |asomers@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 01:40:42 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BCEB953F219 for ; Fri, 12 Feb 2021 01:40:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcGRG4p7sz3k4q for ; Fri, 12 Feb 2021 01:40:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A4B8B53F217; Fri, 12 Feb 2021 01:40:42 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A481653EC67 for ; Fri, 12 Feb 2021 01:40:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcGRG4DDSz3k7L for ; Fri, 12 Feb 2021 01:40:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7FA3A1B855 for ; Fri, 12 Feb 2021 01:40:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11C1egZ7042036 for ; Fri, 12 Feb 2021 01:40:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11C1egwv042035 for fs@FreeBSD.org; Fri, 12 Feb 2021 01:40:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Fri, 12 Feb 2021 01:40:42 +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 Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 01:40:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #4 from Konstantin Belousov --- Isn't the real bug there, the long non-shortened read from getdirentries()? It probably somehow related to the EOF caching for NFS directories, but I did not analyzed it much. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 05:35:30 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3190544B1D for ; Fri, 12 Feb 2021 05:35:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcMfB0Dnjz4Rv0 for ; Fri, 12 Feb 2021 05:35:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id DB983544849; Fri, 12 Feb 2021 05:35:29 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3DDD544B85 for ; Fri, 12 Feb 2021 05:35:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcMf92j27z4S7Y for ; Fri, 12 Feb 2021 05:35:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A58E71E7C1 for ; Fri, 12 Feb 2021 05:35:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11C5ZSvc055474 for ; Fri, 12 Feb 2021 05:35:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11C5ZS2p055472 for fs@FreeBSD.org; Fri, 12 Feb 2021 05:35:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 05:35:28 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 05:35:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #8 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D8563de2f2799b2cb6f2f06e3c9dddd48d= ca2a986 commit 8563de2f2799b2cb6f2f06e3c9dddd48dca2a986 Author: Kirk McKusick AuthorDate: 2021-02-12 05:31:16 +0000 Commit: Kirk McKusick CommitDate: 2021-02-12 05:31:16 +0000 Fix bug 253158 - Panic: snapacct_ufs2: bad block - mksnap_ffs(8) crash The panic reported in 253158 arises because the /mnt/.snap/.factory snapshot allocated the last block in the filesystem. The snapshot code allocates the last block in the filesystem as a way of setting its length to be the size of the filesystem. Part of taking a snapshot is to remove all the earlier snapshots from the image of the newest snapshot so that newer snapshots will not claim the blocks of the earlier snapshots. The panic occurs when the new snapshot finds that both it and an earlier snapshot claim the same block. The fix is to set the size of the snapshot to be one block after the last block in the filesystem. This block can never be allocated since it is not a valid block in the filesystem. This extra block is used as a place to store the initial list of blocks that the snapshot has already copied and is used to avoid a deadlock in and speed up the ffs_copyonwrite() function. Reported by: Harald Schmalzbauer Tested by: Peter Holm PR: 253158 Sponsored by: Netflix sys/ufs/ffs/ffs_snapshot.c | 137 +++++++++++++++++++++++------------------= ---- 1 file changed, 70 insertions(+), 67 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 09:00:27 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AFA0A548A1E for ; Fri, 12 Feb 2021 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcSBg4RTGz4d8V for ; Fri, 12 Feb 2021 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 98613548A1D; Fri, 12 Feb 2021 09:00:27 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9826C548C0B for ; Fri, 12 Feb 2021 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcSBg3sF8z4dHV for ; Fri, 12 Feb 2021 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7382621316 for ; Fri, 12 Feb 2021 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11C90Ri9050519 for ; Fri, 12 Feb 2021 09:00:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11C90RW0050518 for fs@FreeBSD.org; Fri, 12 Feb 2021 09:00:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 09:00:27 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 09:00:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #9 from Harald Schmalzbauer --- Thank you very much for further analysis and fix. Unfortunately, this seems to introduce a new problem: /sbin/mksnap_ffs /.snap/.test2 /usr/sbin/fstyp /.snap/.test2 Repdiducable panic: Fatal trap 12: page fault while in kernel mode current process: fstyp #7 ... uiomove_fromphys+ #8 ... vn_io_fault_uiomove+ #9 ... ffs_read+ #10 ... VOP_READ_APV+ #11 ... vn_read+ #12 ... vn_io_doio+ #13 ... vn_io_fault1+ #14 ... vn_io_fault+ #15 ... dofileread+ #16 ... sys_read+ #17 ... amd64_syscall+ Unfortunately I can't test on debug environment currently, the crash happens with produtcion deployment tests without serial console, su just trinscribe= d a stacktrace snippet. Thanks, -harry --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 14:07:59 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1D3AB54E69A for ; Fri, 12 Feb 2021 14:07:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcb1V6q1Gz4tbP for ; Fri, 12 Feb 2021 14:07:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E3A1254E71E; Fri, 12 Feb 2021 14:07:58 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E36CD54E71D for ; Fri, 12 Feb 2021 14:07:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcb1V4S8Wz4tpl for ; Fri, 12 Feb 2021 14:07:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 89FCA24DC8 for ; Fri, 12 Feb 2021 14:07:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CE7wkO096594 for ; Fri, 12 Feb 2021 14:07:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CE7wts096593 for fs@FreeBSD.org; Fri, 12 Feb 2021 14:07:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Fri, 12 Feb 2021 14:07:58 +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 Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 14:07:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #5 from Rick Macklem --- I once committed a patch that got rid of the trailing empty dirent entries that fill out the block. (Each one is a strucr dirent of d_reclen =3D=3D 512 and d_fileno =3D=3D 0.) It broke the directory caching badly, such that there was a much higher miss ratio on the caching. I'll admit I cannot remember exactly how, but I do remember that I couldn't come up with a way to fix it, so I reverted the patch. It was bde@ who spotted the breakage. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 14:35:02 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C2ED54EFDB for ; Fri, 12 Feb 2021 14:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcbck3NGXz3CJF for ; Fri, 12 Feb 2021 14:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 73EB854EDD2; Fri, 12 Feb 2021 14:35:02 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 73AED54F184 for ; Fri, 12 Feb 2021 14:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcbck2nLHz3C3D for ; Fri, 12 Feb 2021 14:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 52DD025905 for ; Fri, 12 Feb 2021 14:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CEZ2QP013836 for ; Fri, 12 Feb 2021 14:35:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CEZ2u0013835 for fs@FreeBSD.org; Fri, 12 Feb 2021 14:35:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Fri, 12 Feb 2021 14:35:02 +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 Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 14:35:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #6 from Rick Macklem --- Just fyi, what I am looking at for the case where the directory offset cookie returned by the server is monotonically increasing is... Replacing uses ig gbincore() with a similar call the uses PCTRIE_LOOKUP_LE() instead of PCTRIE_LOOKUP(). This would allow the directory offset cookies to be used as keys for the block instead of the "logical byte offset" of the converted to UFS-like directory blocks. The problem is that there is no way to know if the directory offset cookies are monotonically increasing until you see them. (Linux does something where the client code checks for a non-monotonically increasing offset then disables the caching optimization if this happens. I am not yet sure if doing this will be practical for what I am starting to code.) I am planning on proposing a new attribute for NFSv4.2 to indicate whether or not the offsets are monotonically increasing, but that will take a long time to get adopted. Once keyed on directory offset cookies, I think the "short block caching issue might get fixed, since I think it was related to the "logical byte offset" of the next block changing when short directory blocks were returned. (Maybe this should be moved to a mailing list?) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 14:54:03 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1BA7C54F13C for ; Fri, 12 Feb 2021 14:54:03 +0000 (UTC) (envelope-from artem@artem.ru) Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (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 4Dcc2d67Gbz3D3k for ; Fri, 12 Feb 2021 14:54:01 +0000 (UTC) (envelope-from artem@artem.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=ZYACbt2k+ORFQf43kK/ExCmUzyNrknNuWieba5l+aho=; b=H8vdIvOEEgxx+/ZWNvfHLYHoLZMfU1fLD5whZ3Ol7JFwrx5W+Iflbf59RIEKr0T4MpIed+Pp1699j7CMRdpZ6iY9iURWF6EITZE00WHYIsjimx5RPRwRWsC+46qHrrN0E3rvHHG/DpmdxZJJU6GULr9loiNc7u/Z/dA1TTa/iEM=; Received: by smtp49.i.mail.ru with esmtpa (envelope-from ) id 1lAZpW-00027J-DW for freebsd-fs@freebsd.org; Fri, 12 Feb 2021 17:53:58 +0300 To: freebsd-fs@freebsd.org From: Artem Kuchin Subject: Reading a corrupted file on ZFS Message-ID: Date: Fri, 12 Feb 2021 17:53:58 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 Content-Language: ru X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD981647AC6901E234B76E96810B840B3DA78548B6B9C68F4E9182A05F53808504003978BC9505F44D4026CC7BE3BFF4CB571FA88AC88532C548F77518BA93D5592 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7798B95EC47D21699EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637F10563012BA5CCB0EA1F7E6F0F101C674E70A05D1297E1BBC6CDE5D1141D2B1C67E08EF29304ECA3D768253E77549E1FB4711D1618564BA89FA2833FD35BB23D9E625A9149C048EE9ECD01F8117BC8BEA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18C26CFBAC0749D213D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE9647ADFADE5905B17AAF5A6EB0CB4C2AD8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE3AD0E433DBF1FBFA3AD7EC71F1DB88427C4224003CC836476EA7A3FFF5B025636A7F4EDE966BC389F9E8FC8737B5C2249300D3B61E77C8D3B089D37D7C0E48F6CCF19DD082D7633A0E7DDDDC251EA7DABAAAE862A0553A39223F8577A6DFFEA7C565C1E6824D8037B43847C11F186F3C5E7DDDDC251EA7DABCC89B49CDF41148F8A2FA77B2B055C713C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356 X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A24A6D60772A99906F8E1CD14B953EB46D0F86482D78C2E1D7355D89D7DBCDD132 X-C1DE0DAB: 8BD88D57C5CADBC8B2710865C386751094C72BDDC9A8ED5CA3B1A56EE2B804F6B226C914C9968946695E9D90444CEC264DCC8C77FBA9901322D2CEDE4E95CF1BDBE8DEE28BC9005C095FFBCAB1CFE8AAD6CF32B5F8F9D404CD49BFA360A54A28485BB38274D1A144589120F7DAE46353205367B2BCC23E5B25C271FFF5A188D3BDAD6C7F3747799A X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D349A949488F6BF46DDFC2723D0A49A9354433D817D407CFBE4D57B716FC30DBC2C9CAC21CCD194643E1D7E09C32AA3244C6E8D4E16A79C0465F2AA69DAAB481E03E646F07CC2D4F3D83EB3F6AD6EA9203E X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojbL9S8ysBdXjPSTRnLtWeGNRXEJ9KhU56 X-Mailru-Sender: 0E9E14D9EC491FBAA791EF7E2263ACA3C1A2EA953E27C632F7D46E368A3DAE8BE38B3286BF0A6676ED68A1BC046237463DDE9B364B0DF2893588BD1191EC2D784A420497922026CACF2710667E7BD92C3CDA0F3B3F5B9367 X-Mras: Ok X-Rspamd-Queue-Id: 4Dcc2d67Gbz3D3k X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mail.ru header.s=mail3 header.b=H8vdIvOE; dmarc=none; spf=none (mx1.freebsd.org: domain of artem@artem.ru has no SPF policy when checking 94.100.177.109) smtp.mailfrom=artem@artem.ru X-Spamd-Result: default: False [-1.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[artem.ru]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.100.177.109:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.66)[0.657]; DKIM_TRACE(0.00)[mail.ru:+]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.100.177.109:from]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[94.100.177.109:from] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 14:54:03 -0000 I did a little experiment I have a mirror ZFS pool called ZDATA, i created a file and damanged the same byte in file in it on both disks. File has ABCDEF string. ZDATA ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0 ONLINE 0 0 1 ada1 ONLINE 0 0 0 destroy ZDATA on ada0 change A to Z on ada1 change A to Y reimport root@xigmanas:~# zpool status pool: ZDATA state: ONLINE scan: scrub repaired 24K in 0 days 00:03:01 with 0 errors on Fri Feb 12 16:48:46 2021 config: NAME STATE READ WRITE CKSUM ZDATA ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 errors: No known data errors Hmm. it repaired something. Read data from disks. ada0 - Z ada1 - Y so, that repair was not the rotten bytes. Now run scrub root@xigmanas:~# zpool status -v ZDATA pool: ZDATA state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see:http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 0 days 00:03:02 with 1 errors on Fri Feb 12 16:59:49 2021 config: NAME STATE READ WRITE CKSUM ZDATA ONLINE 0 0 1 mirror-0 ONLINE 0 0 2 ada0 ONLINE 0 0 2 ada1 ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: /data/DATASET1/test.file the data is still Z and Y, not sync-ed. I cannot read or write this file. This is bad. zfs set checksum=off ZDATA did not help, still cannot read or write the file. zpool clear -F ZDATA still cannot r/w the file Now i am stuck in worst situation that with UFS - i cannot read what's left of this file. I deleted the file and the scrubbed - error went away. But i lost the file. So, the question is how to read the file with an error ? I googled for 2 hours and still did not find a solution. Artem From owner-freebsd-fs@freebsd.org Fri Feb 12 15:06:39 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3EA554F162 for ; Fri, 12 Feb 2021 15:06:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DccKB5hf6z3D9n for ; Fri, 12 Feb 2021 15:06:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 6849D2110B3 for ; Fri, 12 Feb 2021 10:06:29 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 7618B1225F8 for ; Fri, 12 Feb 2021 10:06:31 -0500 (EST) Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: From: Karl Denninger Message-ID: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> Date: Fri, 12 Feb 2021 10:06:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070508000104050601010705" X-Rspamd-Queue-Id: 4DccKB5hf6z3D9n X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-fs] X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:06:39 -0000 This is a cryptographically signed message in MIME format. --------------ms070508000104050601010705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: base64 T24gMi8xMi8yMDIxIDA5OjUzLCBBcnRlbSBLdWNoaW4gd3JvdGU6DQo+IEkgZGlkIGEgbGl0 dGxlIGV4cGVyaW1lbnQNCj4NCj4gSSBoYXZlIGEgbWlycm9yIFpGUyBwb29sIGNhbGxlZCBa REFUQSwgaSBjcmVhdGVkIGEgZmlsZSBhbmQgZGFtYW5nZWQgDQo+IHRoZSBzYW1lIGJ5dGUg aW4gZmlsZSBpbiBpdCBvbiBib3RoIGRpc2tzLg0KPg0KPiBGaWxlIGhhcyBBQkNERUYgc3Ry aW5nLg0KPg0KPg0KPiDCoMKgwqDCoMKgwqDCoCBaREFUQcKgwqDCoMKgwqDCoCBPTkxJTkXC oMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAwDQo+IMKgwqDCoMKgwqDCoMKgwqDC oCBtaXJyb3ItMMKgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDAN Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhZGEwwqDCoMKgIE9OTElORcKgwqDCoMKgwqDC oCAwwqDCoMKgwqAgMMKgwqDCoMKgIDENCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhZGEx wqDCoMKgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDANCj4NCj4N Cj4gZGVzdHJveSBaREFUQQ0KPg0KPiBvbiBhZGEwIGNoYW5nZSBBIHRvIFoNCj4gb24gYWRh MSBjaGFuZ2UgQSB0byBZDQo+IHJlaW1wb3J0DQo+DQo+IHJvb3RAeGlnbWFuYXM6fiMgenBv b2wgc3RhdHVzDQo+IMKgIHBvb2w6IFpEQVRBDQo+IMKgc3RhdGU6IE9OTElORQ0KPiDCoCBz Y2FuOiBzY3J1YiByZXBhaXJlZCAyNEsgaW4gMCBkYXlzIDAwOjAzOjAxIHdpdGggMCBlcnJv cnMgb24gRnJpIEZlYiANCj4gMTIgMTY6NDg6NDYgMjAyMQ0KPiBjb25maWc6DQo+DQo+IMKg wqDCoMKgwqDCoMKgIE5BTUXCoMKgwqDCoMKgwqDCoCBTVEFURcKgwqDCoMKgIFJFQUQgV1JJ VEUgQ0tTVU0NCj4gwqDCoMKgwqDCoMKgwqAgWkRBVEHCoMKgwqDCoMKgwqAgT05MSU5FwqDC oMKgwqDCoMKgIDDCoMKgwqDCoCAwwqDCoMKgwqAgMA0KPiDCoMKgwqDCoMKgwqDCoMKgwqAg bWlycm9yLTDCoCBPTkxJTkXCoMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAwDQo+ IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYWRhMMKgwqDCoCBPTkxJTkXCoMKgwqDCoMKgwqAg MMKgwqDCoMKgIDDCoMKgwqDCoCAwDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYWRhMcKg wqDCoCBPTkxJTkXCoMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAwDQo+DQo+IGVy cm9yczogTm8ga25vd24gZGF0YSBlcnJvcnMNCj4NCj4gSG1tLiBpdCByZXBhaXJlZCBzb21l dGhpbmcuIFJlYWQgZGF0YSBmcm9tIGRpc2tzLg0KPiBhZGEwIC0gWg0KPiBhZGExIC0gWQ0K PiBzbywgdGhhdCByZXBhaXIgd2FzIG5vdCB0aGUgcm90dGVuIGJ5dGVzLg0KPg0KPiBOb3cg cnVuIHNjcnViDQo+DQo+IHJvb3RAeGlnbWFuYXM6fiMgenBvb2wgc3RhdHVzIC12IFpEQVRB DQo+IMKgIHBvb2w6IFpEQVRBDQo+IMKgc3RhdGU6IE9OTElORQ0KPiBzdGF0dXM6IE9uZSBv ciBtb3JlIGRldmljZXMgaGFzIGV4cGVyaWVuY2VkIGFuIGVycm9yIHJlc3VsdGluZyBpbiBk YXRhDQo+IMKgwqDCoMKgwqDCoMKgIGNvcnJ1cHRpb24uwqAgQXBwbGljYXRpb25zIG1heSBi ZSBhZmZlY3RlZC4NCj4gYWN0aW9uOiBSZXN0b3JlIHRoZSBmaWxlIGluIHF1ZXN0aW9uIGlm IHBvc3NpYmxlLsKgIE90aGVyd2lzZSByZXN0b3JlIHRoZQ0KPiDCoMKgwqDCoMKgwqDCoCBl bnRpcmUgcG9vbCBmcm9tIGJhY2t1cC4NCj4gwqDCoCBzZWU6aHR0cDovL2lsbHVtb3Mub3Jn L21zZy9aRlMtODAwMC04QSANCj4gPGh0dHA6Ly9pbGx1bW9zLm9yZy9tc2cvWkZTLTgwMDAt OEE+DQo+IMKgIHNjYW46IHNjcnViIHJlcGFpcmVkIDAgaW4gMCBkYXlzIDAwOjAzOjAyIHdp dGggMSBlcnJvcnMgb24gRnJpIEZlYiANCj4gMTIgMTY6NTk6NDkgMjAyMQ0KPiBjb25maWc6 DQo+DQo+IMKgwqDCoMKgwqDCoMKgIE5BTUXCoMKgwqDCoMKgwqDCoCBTVEFURcKgwqDCoMKg IFJFQUQgV1JJVEUgQ0tTVU0NCj4gwqDCoMKgwqDCoMKgwqAgWkRBVEHCoMKgwqDCoMKgwqAg T05MSU5FwqDCoMKgwqDCoMKgIDDCoMKgwqDCoCAwwqDCoMKgwqAgMQ0KPiDCoMKgwqDCoMKg wqDCoMKgwqAgbWlycm9yLTDCoCBPTkxJTkXCoMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKg wqDCoCAyDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYWRhMMKgwqDCoCBPTkxJTkXCoMKg wqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAyDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgYWRhMcKgwqDCoCBPTkxJTkXCoMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAy DQo+DQo+IGVycm9yczogUGVybWFuZW50IGVycm9ycyBoYXZlIGJlZW4gZGV0ZWN0ZWQgaW4g dGhlIGZvbGxvd2luZyBmaWxlczoNCj4NCj4gwqDCoMKgwqDCoMKgwqAgL2RhdGEvREFUQVNF VDEvdGVzdC5maWxlDQo+DQo+IHRoZSBkYXRhIGlzIHN0aWxsIFogYW5kIFksIG5vdCBzeW5j LWVkLg0KPg0KPiBJIGNhbm5vdCByZWFkIG9yIHdyaXRlIHRoaXMgZmlsZS4gVGhpcyBpcyBi YWQuDQo+DQo+IHpmcyBzZXQgY2hlY2tzdW09b2ZmIFpEQVRBDQo+DQo+IGRpZCBub3QgaGVs cCwgc3RpbGwgY2Fubm90IHJlYWQgb3Igd3JpdGUgdGhlIGZpbGUuDQo+DQo+IHpwb29sIGNs ZWFyIC1GIFpEQVRBDQo+DQo+IHN0aWxsIGNhbm5vdCByL3cgdGhlIGZpbGUNCj4NCj4gTm93 IGkgYW0gc3R1Y2sgaW4gd29yc3Qgc2l0dWF0aW9uIHRoYXQgd2l0aCBVRlMgLSBpIGNhbm5v dCByZWFkIHdoYXQncyANCj4gbGVmdCBvZiB0aGlzIGZpbGUuDQo+DQo+IEkgZGVsZXRlZCB0 aGUgZmlsZSBhbmQgdGhlIHNjcnViYmVkIC0gZXJyb3Igd2VudCBhd2F5LiBCdXQgaSBsb3N0 IHRoZSANCj4gZmlsZS4NCj4NCj4gU28sIHRoZSBxdWVzdGlvbiBpcyBob3cgdG8gcmVhZCB0 aGUgZmlsZSB3aXRoIGFuIGVycm9yID8gSSBnb29nbGVkIGZvciANCj4gMiBob3VycyBhbmQg c3RpbGwgZGlkIG5vdCBmaW5kIGEgc29sdXRpb24uDQo+DQo+DQo+IEFydGVtDQo+DQpXaXRo IHdoYXQgeW91IGRpZCBib3RoIGNvcGllcyBhcmUgZGFtYWdlZCBhbmQgbm9uLXJlcGFpcmFi bGUuDQoNCk5laXRoZXIgYmxvY2sgb24gdGhlIHR3byBtaXJyb3IgY29waWVzIGhhcyBhIGNv cnJlY3QgY2hlY2tzdW0gdGhlcmVmb3JlIA0KbmVpdGhlciBjb3B5IGlzIGdvb2Q7IGJvdGgg d2VyZSBkYW1hZ2VkICJhdCB0aGUgc2FtZSB0aW1lIi7CoCBUaGUgc3lzdGVtIA0Ka25vd3Mg dGhlIGZpbGUgaXMgY29ycnVwdCBhbmQgdGh1cyB0aGUgY29udGVudHMgYXJlIG5vdCB1c2Fi bGUsIGJ1dCBpdCANCmhhcyBubyB3YXkgdG8gZml4IGl0IGJlY2F1c2UgYm90aCBjb3BpZXMg YXJlIGRhbWFnZWQgd2l0aCBubyBtZWFucyBvZiANCmNvcnJlY3Rpb24uDQoNClRoZSBjb3Jy ZWN0IGFuc3dlciB0byB3aGF0IHRvIGRvIGlzIElNSE8gd2hhdCBaRlMgZG9lcy7CoCBUaGUg b25seSANCnNvbHV0aW9uIGluIHN1Y2ggYSBjYXNlIGlzIHRvIHJlc3RvcmUgZnJvbSBhIGJh Y2t1cC4NCg0KWW91ICpkZWZpbml0ZWx5KiBkbyBub3Qgd2FudCB0aGUgc3lzdGVtIHRvIHNp bGVudGx5IGxldCB5b3UgcHJvY2VlZCBpbiANCnN1Y2ggYW4gaW5zdGFuY2UgYmVjYXVzZSBu b3cgeW91IHdpbGwgKnByb3BhZ2F0ZSogdGhlIGRhbWFnZWQgZmlsZSANCndpdGhvdXQga25v d2luZyBpdCB3YXMgZGFtYWdlZCwgd2hpY2ggd2lsbCB0aGVuIHdpbmQgdXAgaW4geW91ciBi YWNrdXAgDQpjb3BpZXMuwqAgT3ZlciB0aW1lIGV2ZW4gd2l0aCBhIHJvYnVzdCBiYWNrdXAg c2NoZW1lIHRoaXMgd2lsbCBldmVudHVhbGx5IA0KbGVhZCB0byB5b3UgbG9zaW5nIGFsbCAi Z29vZCIgY29waWVzIG9mIHRoZSBmaWxlIHNpbmNlIHRoZSBiYWNrdXAgbWVkaWEgDQp3aWxs IGJlIHJvdGF0ZWQgYW5kIHVsdGltYXRlbHkgdGhlIGRhdGEgd2lsbCBiZSBwZXJtYW5lbnRs eSBsb3N0IHdpdGggbm8gDQptZWFucyBvZiByZWNvdmVyeS4NCg0KQmxvY2tpbmcgdGhlIHJl YWQgZm9yY2VzIHlvdSB0byBnZXQgdGhlIGdvb2QgY29weSBvZmYgYmFja3VwIG1lZGlhIGFu ZCANCnRodXMgcHJldmVudHMgdGhhdCBmcm9tIGhhcHBlbmluZy4NCg0KLS0gDQpLYXJsIERl bm5pbmdlcg0Ka2FybEBkZW5uaW5nZXIubmV0IDxtYWlsdG86a2FybEBkZW5uaW5nZXIubmV0 Pg0KL1RoZSBNYXJrZXQgVGlja2VyLw0KL1tTL01JTUUgZW5jcnlwdGVkIGVtYWlsIHByZWZl cnJlZF0vDQo= --------------ms070508000104050601010705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjEyMTUwNjMx WjBPBgkqhkiG9w0BCQQxQgRAQBLEpGu+RBFumKOBK5b6gjXvmB46aQ9SnTrWnaPPOwtvROYV iN1lwxmZl1dA/+aP3xjub7gIR7yulnEno3rD/TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBWv0ILXM47+dxR7mhyveEtEV+PEYyeavC1VGQbq2mF7zHp/XciVn2I03siP9EKaNSl lg1suQh4wwUjpJar6W7kl8+lYXSK8ai0KNjyE0UbjqlpR7AQXxltmgizVJWrl7jea50/0fui sD3wCXVeObX0fNcpSPsr29vjJcvqiKX3b6d525wR9Y+7BPvNbMbuyETQILs5zPZYSA2fuHBn u3mEh+SR8lwqA3A6Oz0stKKSJ+k5aK3q9XMXd41yXanwyx8QMtxOZLt9blf3qKQmQndsED0K IC0bYsGMJ8cd09dZZFyLirL1MdY4v1nxicqpd54dBxUPYC3yxcmj6cVXS/uW8Kt7nzZfQmi0 Wps+Cbtx9KhS3lfKs/H748mSASWs1plnYW0yxExeZCl91uKFwo6Og3dCprqtTXZhXdp2ZQuF QhPYx3gumdtsZevX7MoGMPiNF6OUbf7B/yKDlrV6Dri8KXiehjRd7eOfVWSNkUejNBybAHmR TgaT9lHDUOc+LijyxqIeSv1W3SdNwU1XX/wIxprjLP5RgkQ/+1RpoOIasixrFc3K9cTyzPhW aFTmrAn1SIwWnyD1lt/AKZFJTMElpJCywzhMx24NiGUqN7kigO4NQiUGTrl4NDv/foCAECoh 1SWMqPjR8NvYQFHm5zWeTUW7fUT93SSudqVpbfIp2wAAAAAAAA== --------------ms070508000104050601010705-- From owner-freebsd-fs@freebsd.org Fri Feb 12 15:35:42 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B140528306 for ; Fri, 12 Feb 2021 15:35:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dccyk11Z5z3G8B for ; Fri, 12 Feb 2021 15:35:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 22D93528305; Fri, 12 Feb 2021 15:35:42 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 229E954FC57 for ; Fri, 12 Feb 2021 15:35:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dccyk0R99z3GGQ for ; Fri, 12 Feb 2021 15:35:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F214C263C0 for ; Fri, 12 Feb 2021 15:35:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CFZfhM042477 for ; Fri, 12 Feb 2021 15:35:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CFZf6F042476 for fs@FreeBSD.org; Fri, 12 Feb 2021 15:35:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 252981] panic with ZFS encryption and QAT: VERIFY3(0 == spa_do_crypt_bad(... Date: Fri, 12 Feb 2021 15:35:42 +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: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:35:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252981 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #7 from Mark Johnston --- I think for 13.0 we should just modify ZFS to not use hardware crypto drive= rs.=20 Per comment 1 the OCF wrapper in ZFS is buggy with respect to asynchronous completions. Going forward there are at least three possible solutions: 1. Modify ZFS to use separate sessions for hardware and software crypto, and only use hardware crypto when ot !=3D DMU_OT_INTENT_LOG && ot !=3D DMU_OT_D= NODE in zio_do_crypto_data(). This side-steps the AAD problem. 2. Modify qat(4) to authenticate AAD and perform encryption/decryption in separate requests, passing intermediate hash state from the first request to the second. qat(4) can handle arbitrarily large GMAC requests. I'm not su= re how easy this is but I think it's possible. 3. Modify opencrypto to fall back to software crypto if the hardware can't handle the request for some reason. jhb suggested that this would be useful for other purposes, e.g., if one is decrypting small packets, where the CPU cost of handling the request in software is the same as the request setup c= ost in a hardware driver. This requires some thought around reordering of requ= ests within a session. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 15:42:02 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08435528347 for ; Fri, 12 Feb 2021 15:42:02 +0000 (UTC) (envelope-from artem@artem.ru) Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) (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 4Dcd610JGtz3GZP for ; Fri, 12 Feb 2021 15:42:00 +0000 (UTC) (envelope-from artem@artem.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=27ROgpLR072vLMiEawXr8LA67yw+H57z4rjNVOk0A6I=; b=b7BgdHYWvRv5HjVhDm095BBPBADMqZhs1XBG3KqBO4GVM/QQ65xh6XG6KbZ0CJW7clEGZFrAt+X33VZVaxiXhKyi1GogEiTTuSM0Zjonhictj/9eNnnI9/0DFUsNne1hGjGWKFnWDm+eTLt7ubb7p4zIE6TYtCcuwXGbbmMLHns=; Received: by smtp48.i.mail.ru with esmtpa (envelope-from ) id 1lAaZy-0004dc-5R; Fri, 12 Feb 2021 18:41:58 +0300 Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> From: Artem Kuchin Message-ID: <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> Date: Fri, 12 Feb 2021 18:41:57 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD981647AC6901E234BAEBD76BEDCA450D6CA8258D9A07F13E2182A05F53808504042C202BFF6A7F5EFC1CF29D78B70FAF2F25477CD72A92A0C4A8FF51FE07C07BC X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE766DBE83FD69AB645EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063737452AF4BFD067BF8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC4EAF506ED846764AA86AB2527FB00B9BC5224D05308E6884389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C07E7E81EEA8A9722B8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B64854413538E1713FCC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C2249A6C381CD31D6A0BC76E601842F6C81A12EF20D2F80756B5F7E9C4E3C761E06A776E601842F6C81A127C277FBC8AE2E8B8412D6D77F9351F23AA81AA40904B5D9DBF02ECDB25306B2B25CBF701D1BE8734AD6D5ED66289B5278DA827A17800CE798228CBAD4AC77F667F23339F89546C5A8DF7F3B2552694A6FED454B719173D6725E5C173C3A84C3FB9365559B687AC835872C767BF85DA2F004C906525384306FED454B719173D6462275124DF8B9C9D28595B116005B47574AF45C6390F7469DAA53EE0834AAEE X-C1DE0DAB: 0D63561A33F958A56807822B442F4AEF0420B99E11B11A47F4C3AABF95CE57C3D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75B869F6C56E712840410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D345DB600F8E858000F29145C9A2295E84EC4D27387380E4887FADB9A713C8EB8095AA6D80F735662D41D7E09C32AA3244C51BB9FCCC764DEAF0E2D91BB41C36408A95CA90A1D8AC565729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojtEL/kbq1PXHz+cM0iURIBA== X-Mailru-Sender: 0E9E14D9EC491FBAA791EF7E2263ACA34681680AFE6E11C5D7604E6DC8629E10E38B3286BF0A6676ED68A1BC046237463DDE9B364B0DF2893588BD1191EC2D784A420497922026CACF2710667E7BD92C3CDA0F3B3F5B9367 X-Mras: Ok X-Rspamd-Queue-Id: 4Dcd610JGtz3GZP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mail.ru header.s=mail3 header.b=b7BgdHYW; dmarc=none; spf=none (mx1.freebsd.org: domain of artem@artem.ru has no SPF policy when checking 94.100.177.108) smtp.mailfrom=artem@artem.ru X-Spamd-Result: default: False [-3.19 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[artem.ru]; SPAMHAUS_ZRD(0.00)[94.100.177.108:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.79)[-0.793]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.100.177.108:from]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[94.100.177.108:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:42:02 -0000 12.02.2021 18:06, Karl Denninger пишет: > On 2/12/2021 09:53, Artem Kuchin wrote: >> >> Now i am stuck in worst situation that with UFS - i cannot read >> what's left of this file. >> >> I deleted the file and the scrubbed - error went away. But i lost the >> file. >> >> So, the question is how to read the file with an error ? I googled >> for 2 hours and still did not find a solution. >> >> >> >> > With what you did both copies are damaged and non-repairable. > > Neither block on the two mirror copies has a correct checksum > therefore neither copy is good; both were damaged "at the same time".  > The system knows the file is corrupt and thus the contents are not > usable, but it has no way to fix it because both copies are damaged > with no means of correction. > > The correct answer to what to do is IMHO what ZFS does.  The only > solution in such a case is to restore from a backup. > > You *definitely* do not want the system to silently let you proceed in > such an instance because now you will *propagate* the damaged file > without knowing it was damaged, which will then wind up in your backup > copies.  Over time even with a robust backup scheme this will > eventually lead to you losing all "good" copies of the file since the > backup media will be rotated and ultimately the data will be > permanently lost with no means of recovery. > > Blocking the read forces you to get the good copy off backup media and > thus prevents that from happening. > I know what ZFS does and i damaged the same file in the same place on purpose. Question is: how to read what's left of it. Just for kicks, i don't have a backup, and i need to read what's left. It could be 1GB file with only one byte damaged and it is of crazy importance to me. So, how to bypass all the checks and make it read the file no matter what? Artem From owner-freebsd-fs@freebsd.org Fri Feb 12 15:54:36 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6174152817D for ; Fri, 12 Feb 2021 15:54:36 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 4DcdNW55y2z3HGh for ; Fri, 12 Feb 2021 15:54:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [217.246.52.33] (helo=fabiankeil.de) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lAalo-0003P8-Jn for freebsd-fs@freebsd.org; Fri, 12 Feb 2021 16:54:12 +0100 Date: Fri, 12 Feb 2021 16:52:16 +0100 From: Fabian Keil To: freebsd-fs@freebsd.org Subject: Re: Reading a corrupted file on ZFS Message-ID: <20210212165216.2f613482@fabiankeil.de> In-Reply-To: <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/WF4+NeBpfYbcLLlvN=cPbGm"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Rspamd-Queue-Id: 4DcdNW55y2z3HGh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 134.119.228.97) smtp.mailfrom=freebsd-listen@fabiankeil.de X-Spamd-Result: default: False [-2.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[134.119.228.97:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fabiankeil.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[134.119.228.97:from:127.0.2.255]; RWL_MAILSPIKE_POSSIBLE(0.00)[134.119.228.97:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[217.246.52.33:received]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34011, ipnet:134.119.228.0/24, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:54:36 -0000 --Sig_/WF4+NeBpfYbcLLlvN=cPbGm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Artem Kuchin wrote on 2021-02-12: > 12.02.2021 18:06, Karl Denninger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Blocking the read forces you to get the good copy off backup media and= =20 > > thus prevents that from happening. > > >=20 > I know what ZFS does and i damaged the same file in the same place on=20 > purpose. Question is: how to read what's left of it. Just for kicks, i=20 > don't have a backup, and i need to read what's left. It could be 1GB=20 > file with only one byte damaged and it is of crazy importance to me. So,= =20 > how to bypass all the checks and make it read the file no matter what? The patch from this PR adds a sysctl that allows to send corrupted data: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221909 Using the added sysctl you can send and receive the dataset and then read the corrupted file from the received dataset. Note that ZFS replaces corrupted blocks completely with the 0x'zfs badd bloc' pattern instead of returning the corrupted data as is, thus increasing the amount of corruption in case of simple bit flips to whole blocks. Fabian --Sig_/WF4+NeBpfYbcLLlvN=cPbGm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCYCakMQAKCRAFiohV/3dU nbgHAKCNE42Eg9A9NaTaxXcOHXoN6ovMUwCdFVizioAAGCAH3TBWr8Wwy5BjzCw= =vdJC -----END PGP SIGNATURE----- --Sig_/WF4+NeBpfYbcLLlvN=cPbGm-- From owner-freebsd-fs@freebsd.org Fri Feb 12 16:22:48 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 15E41528DF2 for ; Fri, 12 Feb 2021 16:22:48 +0000 (UTC) (envelope-from artem@artem.ru) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (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 4Dcf1307mHz3K0q for ; Fri, 12 Feb 2021 16:22:46 +0000 (UTC) (envelope-from artem@artem.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=v1KJgSXf6A/9ImyHgP4D4Nth41zyi5nZZN/EyDMZyg8=; b=cds4VC/X0w4y/JHlK1pD8E71vNm5SEUCJEcd1na/QxF4OLm0DljAvqNQdQ9MdRplP1YgsxhTDs0afw2JGEvoBEdycKENIueSvA+0q/n7GQ7RcHqUPZ3QhlZr7iO5093sZvKzD63e5COm3peEXvxCB7xWzho95riwLkNLvM/b5Nw=; Received: by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1lAbDP-0003hT-5a for freebsd-fs@freebsd.org; Fri, 12 Feb 2021 19:22:43 +0300 Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> From: Artem Kuchin Message-ID: <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> Date: Fri, 12 Feb 2021 19:22:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210212165216.2f613482@fabiankeil.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD981647AC6901E234BEAC4623CA173AF239537CEFAAFD1F814182A05F53808504028BF023574605706F5149E72AC5E6CF51BC03862E605979873832419281DFD85 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE788AD3E9728F968ABEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063748789019239639CB8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCCAA1E616DB7D7B67006D1561EAE396976C271223FDCEE1E2389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6E5E764EB5D94DBD4CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C2249A6C381CD31D6A0BC76E601842F6C81A12EF20D2F80756B5F7E9C4E3C761E06A776E601842F6C81A127C277FBC8AE2E8B8412D6D77F9351F23AA81AA40904B5D9DBF02ECDB25306B2B25CBF701D1BE8734AD6D5ED66289B5278DA827A17800CE75A9E79F66F1C28F367F23339F89546C5A8DF7F3B2552694A6FED454B719173D6725E5C173C3A84C3335407143AA9223635872C767BF85DA2F004C906525384306FED454B719173D6462275124DF8B9C9D28595B116005B47574AF45C6390F7469DAA53EE0834AAEE X-B7AD71C0: 2623F767319EFA42AC98609FCEE262F9192335DD689A58EBAE0174B7F1092AFB6832F36CAB5E1658F54B3B24D578727D X-C1DE0DAB: 0D63561A33F958A5599F3654C47C35FFBC7C6DF768D09F90FA687722D79ACF35D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75B869F6C56E712840410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F6CC1FD3366963368BCC3AE58132BD9C5EE804A7BD89E0B8C4A21DBCC66A862B6CE6BBB27F47B5A81D7E09C32AA3244C7D3B07382F924EEE51BF7F7C40BC6E8DE3D93501275E802F3EB3F6AD6EA9203E X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojtEL/kbq1PXHIc0MfyQ05bA== X-Mailru-Sender: 0E9E14D9EC491FBAA791EF7E2263ACA34AE573E1B9384DC1A8429F8B9C61AE32E38B3286BF0A6676ED68A1BC046237463DDE9B364B0DF2893588BD1191EC2D784A420497922026CACF2710667E7BD92C3CDA0F3B3F5B9367 X-Mras: Ok X-Rspamd-Queue-Id: 4Dcf1307mHz3K0q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mail.ru header.s=mail3 header.b=cds4VC/X; dmarc=none; spf=none (mx1.freebsd.org: domain of artem@artem.ru has no SPF policy when checking 94.100.177.92) smtp.mailfrom=artem@artem.ru X-Spamd-Result: default: False [-3.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[artem.ru]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.100.177.92:from:127.0.2.255]; DKIM_TRACE(0.00)[mail.ru:+]; NEURAL_HAM_SHORT(-0.98)[-0.985]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.100.177.92:from]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[94.100.177.92:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 16:22:48 -0000 12.02.2021 18:52, Fabian Keil пишет: > Artem Kuchin wrote on 2021-02-12: > >> 12.02.2021 18:06, Karl Denninger пишет: >>> Blocking the read forces you to get the good copy off backup media and >>> thus prevents that from happening. >>> >> I know what ZFS does and i damaged the same file in the same place on >> purpose. Question is: how to read what's left of it. Just for kicks, i >> don't have a backup, and i need to read what's left. It could be 1GB >> file with only one byte damaged and it is of crazy importance to me. So, >> how to bypass all the checks and make it read the file no matter what? > The patch from this PR adds a sysctl that allows to send corrupted data: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221909 > > Using the added sysctl you can send and receive the dataset and then > read the corrupted file from the received dataset. Note that ZFS replaces > corrupted blocks completely with the 0x'zfs badd bloc' pattern instead > of returning the corrupted data as is, thus increasing the amount of > corruption in case of simple bit flips to whole blocks. > > Fabian Arghh. That's not what i want. This is strange. In case of stupid old FS like FAT or even newer UFS i can dig into damaged file and collect as much data as possible, while newer ZFS does not provide tools to dig into data. That's was always my concern about ZFS. If something bad goes with FAT/NTFS and even UFS - there are tons of tools which can dissect the file system into bits so i can get as much as possible of what's left. In case of ZFS there are no tools that i know and even ZFS itself does not allow to get what left of normal data. This is frustrating. why..why.. From owner-freebsd-fs@freebsd.org Fri Feb 12 16:37:20 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2513452991E for ; Fri, 12 Feb 2021 16:37:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcfKq4Rs4z3Kvg for ; Fri, 12 Feb 2021 16:37:19 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 5EB362110B2 for ; Fri, 12 Feb 2021 11:37:16 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 6491F122B71 for ; Fri, 12 Feb 2021 11:37:18 -0500 (EST) Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> From: Karl Denninger Message-ID: <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> Date: Fri, 12 Feb 2021 11:37:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080601010705050507080003" X-Rspamd-Queue-Id: 4DcfKq4Rs4z3Kvg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.33 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.43)[-0.433]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-fs] X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 16:37:20 -0000 This is a cryptographically signed message in MIME format. --------------ms080601010705050507080003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2/12/2021 11:22, Artem Kuchin wrote: > 12.02.2021 18:52, Fabian Keil =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Artem Kuchin wrote on 2021-02-12: >> >>> 12.02.2021 18:06, Karl Denninger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> Blocking the read forces you to get the good copy off backup media a= nd >>>> thus prevents that from happening. >>>> >>> I know what ZFS does and i damaged the same file in the same place on= >>> purpose. Question is: how to read what's left of it. Just for kicks, = i >>> don't have a backup, and i need to read what's left. It could be 1GB >>> file with only one byte damaged and it is of crazy importance to me. = >>> So, >>> how to bypass all the checks and make it read the file no matter what= ? >> The patch from this PR adds a sysctl that allows to send corrupted dat= a: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221909 >> >> Using the added sysctl you can send and receive the dataset and then >> read the corrupted file from the received dataset. Note that ZFS=20 >> replaces >> corrupted blocks completely with the 0x'zfs badd bloc' pattern instead= >> of returning the corrupted data as is, thus increasing the amount of >> corruption in case of simple bit flips to whole blocks. >> >> Fabian > > Arghh. That's not what i want. This is strange. In case of stupid old=20 > FS like FAT or even newer UFS i can dig into damaged file and collect=20 > as much data as possible, while newer ZFS does not provide tools to=20 > dig into data. That's was always my concern about ZFS. If something=20 > bad goes with FAT/NTFS and even UFS - there are tons of tools which=20 > can dissect the file system into bits so i can get as much as possible = > of what's left. In case of ZFS there are no tools that i know and even = > ZFS itself does not allow to get what left of normal data. > > This is frustrating. why..why.. You created a synthetic situation that in the real world almost-never=20 exists (ONE byte modified in all copies in the same allocation block but = all other data in that block is intact and recoverable.) In almost-all actual cases of "bit rot" it's exactly that; random and by = statistics extraordinarily unlikely to hit all copies at once in the=20 same allocation block.=C2=A0 Therefore, ZFS can and does fix it; UFS or F= AT=20 silently returns the corrupted data, propagates it, and eventually=20 screws you down the road. The nearly-every-case situation in the real world where a disk goes=20 physically bad (I've had this happen *dozens* of times over my IT=20 career) results in the drive being unable to return the block at all;=20 you don't get all but the bad byte back, you get nothing for that block=20 and any attempt to "touch" it results in either a hard error coming back = with no data in the buffer or (if not a TLER device) a wildly-extended=20 timeout before an I/O error is returned with, again, no usable data in=20 the buffer.=C2=A0 On "old" winchester-style spinning media and even flopp= y=20 drives this resulted in an entire physical sector (usually 512 bytes)=20 being irretrievably lost.=C2=A0 In the case of a "modern" zoned or=20 advanced-format hard drive or an SSD the amount of data impacted and=20 unreadable is typically much larger than one sector; for an SDD it is=20 frequently *at least* a 4k block (which can and frequently does span=20 multiple files!) and for many instances of rotating rust it can be an=20 entire *track* if the servo data is where the fault lies which can be a=20 *huge* amount of data. The patch gives you all but one allocation block of data from ZFS, with=20 that one block effectively zeroed.=C2=A0 This is no worse than the usual = actual (not your synthesized test) impact of such a failure in a the=20 real world with other filesystems in virtually every instance where it=20 happens "in the wild." In short there are very, very few actual "in the wild" failures where=20 one byte is damaged and the rest surrounding that one byte is intact and = retrievable.=C2=A0 In most cases where an actual failure occurs the=20 unreadable data constitutes *at least* a physical sector. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080601010705050507080003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjEyMTYzNzE3 WjBPBgkqhkiG9w0BCQQxQgRAojSSPqWSKToURGHHABIi8Mnp6PROgkTJ8mTdEfYwMACbhbZF +eGC5d+Jpp1yq2cJuPeqI5j0EtylJjrgz72YLDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgChcAOaPOAnILJ42FOFKUyx/LMYY5cyHU3pjPAZmYX55rZZlyh/woZQQqAzd9qPtvrZ oXHDLAtWEh2h6ljzoXjueSAJQvVlg55v3ly2WvXU+AFp1+2roVMMeUMqeOmXNbVrP60dt0Yu M4+/ad/Pn8s9OgehB/wST0JoKh/oRy9lkkJEwv0wgNJTiliszovx/Xigne6amui117qEs3k1 QWiS84QSNIK1dTZjlTKihNrCD7iiWpFrf5JFabzOBT0ikbgkFRHs7x7Uvy4L2mCuQ0kDKxbC mBLgwx2xyQMw9yeWJOiJKedyYHQ7oLR/1VHLVNZ4qb5lSXUHJQ3Ke9+Z+RmgDY2jytMGCEXs E+uJqIkOg79H+p/49UfThjBMomtEqFoKtyiu3RkSyfoz3G8U/sbyNRDbQ30y3HboM/I71+Sr H8jlQfWWvxq7RBdKRU6L9ZY+5sWnO2rzeYVA1+fwR0l9ZKcBPGfvszEOPr3OPuKll0GBz28G B5gY3IrDpRKisTIBbSz2JCHlwOHj9FWWHLE8cI33rMJ4TE4UpZ0oSKNXivnunJ28P+hPDmTu YbgzvB046w+TbmU9TaSb0EgkWe7SNecC3YSNMXyJf9OElSg15dHBDE6X4EvbxBiWippeJOHL 5HwkSy0UVSzi61pdk9QtQwpLElI6wSqDFTffMSRPMgAAAAAAAA== --------------ms080601010705050507080003-- From owner-freebsd-fs@freebsd.org Fri Feb 12 18:26:50 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C044F52C15D for ; Fri, 12 Feb 2021 18:26:50 +0000 (UTC) (envelope-from artem@artem.ru) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (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 4Dchm941VJz3jgb for ; Fri, 12 Feb 2021 18:26:48 +0000 (UTC) (envelope-from artem@artem.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=q0x8MIxLXEt+PvCR0ZRxvdO/pl/QOdKnXnoZZP9eiyM=; b=Q65mvaW3ZOF5NS/9BS0G6Bpz4k5xwM4x+Hsd+feWkimRrwnoAdRRUQ+glg0nJU9eueZMWBnJizOkmkIGo+jDVN3GSsKh2JXbEe2j0x0OsNo+zR17V+YdvnCuqlz+PHEF4roP9Ysw9IB6q1a0kB+qALqedmIUQSDqXkQK/t1BsMw=; Received: by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1lAd9R-00035v-Sw for freebsd-fs@freebsd.org; Fri, 12 Feb 2021 21:26:46 +0300 Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> From: Artem Kuchin Message-ID: <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> Date: Fri, 12 Feb 2021 21:26:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD981647AC6901E234B663C574FBA2C95D46270E7B1163DBA8E182A05F538085040F1CEDBD3B86A42A6193482A14A167BB09288F1F6D503C09A0ABC74C5CED422AB X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7DB7B102DCB413779EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637B100969577675F2D8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCF9EC670273F5E627C2F49087E0EC2885AA1DC8F64F6E07B1389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C091DAD9F922AA71188941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6042F1592492B88C6CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C22492AA437DA6D0FD5573AA81AA40904B5D9CF19DD082D7633A078D18283394535A93AA81AA40904B5D98AA50765F7900637D2C6F5AE34F7A4E5EC76A7562686271EEC990983EF5C032935872C767BF85DA29E625A9149C048EE0A3850AC1BE2E735444A83B712AC01484AD6D5ED66289B524E70A05D1297E1BB35872C767BF85DA227C277FBC8AE2E8BDCE939D40DBB93CA75ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85D9B7C4F32B44FF57DB1D15339D2937A5BD9CCCA9EDD067B1EDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A5C7B56ED0BD56E4046116EA3521413FA66950C235509A2DACD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75B869F6C56E712840410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3455049D7B43D89D648BC0524BCE29F807F024EAAFCA46C5456D3CC815255EFBBF1C643457A317ABA21D7E09C32AA3244C9380642911FC89F1490C99C87E444C65E8FBBEFAE1C4874C3EB3F6AD6EA9203E X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojtEL/kbq1PXG1VcPKW9Xuyw== X-Mailru-Sender: 332320C0CE44B500FCA62DA34E843E9D26B4AD4F4D429112C6B6FF5922734A4F821176FCD32AD5350A1FD29A504278DEE66B5C1DBFD5D09D2FFF0A5F0DFA254CD0701747CC0EF98689F635B1FCB23A66AE208404248635DF X-Mras: Ok X-Rspamd-Queue-Id: 4Dchm941VJz3jgb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mail.ru header.s=mail3 header.b=Q65mvaW3; dmarc=none; spf=none (mx1.freebsd.org: domain of artem@artem.ru has no SPF policy when checking 94.100.177.103) smtp.mailfrom=artem@artem.ru X-Spamd-Result: default: False [-3.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[artem.ru]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.100.177.103:from:127.0.2.255]; DKIM_TRACE(0.00)[mail.ru:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.100.177.103:from]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[94.100.177.103:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 18:26:50 -0000 12.02.2021 19:37, Karl Denninger пишет: > On 2/12/2021 11:22, Artem Kuchin wrote: >> >> This is frustrating. why..why.. > > You created a synthetic situation that in the real world almost-never > exists (ONE byte modified in all copies in the same allocation block > but all other data in that block is intact and recoverable.) > I could be 1 GB file with ZFS wisth block size of 1MB and with rotten bits within the same 1MB of block on different disks. How i did it is not important, life is unpredictable, i'm not trying to avoid everything. The question is what to do when it happens. And currently the answer is - nothing. > In almost-all actual cases of "bit rot" it's exactly that; random and > by statistics extraordinarily unlikely to hit all copies at once in > the same allocation block.  Therefore, ZFS can and does fix it; UFS or > FAT silently returns the corrupted data, propagates it, and eventually > screws you down the road. In active fs you are right. But if this is a storage disk with movies and photos, then i can just checksum all files with a little script and recheck once in a while. So, for storage perposes i have all ZFS postitives and also can read as much data as i can. Because for long time storage it is more important to have ability read the data in any case. > > The nearly-every-case situation in the real world where a disk goes > physically bad (I've had this happen *dozens* of times over my IT > career) results in the drive being unable to *NEARLY* is not good enough for me. > return the block at all; You mix device blocks and ZFS block. As far as i remember default ZFS block for checksumming is 16K and for big files storage better to have it around 128K. > In short there are very, very few actual "in the wild" failures where > one byte is damaged and the rest surrounding that one byte is intact > and retrievable.  In most cases where an actual failure occurs the > unreadable data constitutes *at least* a physical sector. > "very very few" is enough for me to think about. One more thing. If you have one bad byte in a block of 16K and you have checksum and recalculate it then it is quite possible to just brute force every byte to match the checksum, thus restoring the data. If you have mirror with two different bytes then bute forcing is even ether, Somehow, ZFS slaps my hands and does not allow to be sure that i can restore data when i needed it and decide myself if it is okay or not. For long time storage of big files it now seems better to store it on UFS mirror, checksum each 512bytes blocks of files and store checksums separetelly and run monthly/weekly "scrub". This way i would sleep better. Artem From owner-freebsd-fs@freebsd.org Fri Feb 12 18:30:01 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5E81352C362 for ; Fri, 12 Feb 2021 18:30:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dchqs1xzgz3jn8 for ; Fri, 12 Feb 2021 18:30:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 42C2552C0D5; Fri, 12 Feb 2021 18:30:01 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4288052C0D4 for ; Fri, 12 Feb 2021 18:30:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dchqs1L6lz3jf9 for ; Fri, 12 Feb 2021 18:30:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 211155EB for ; Fri, 12 Feb 2021 18:30:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CIU17x029092 for ; Fri, 12 Feb 2021 18:30:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CIU1fS029091 for fs@FreeBSD.org; Fri, 12 Feb 2021 18:30:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 18:30:01 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 18:30:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #10 from Kirk McKusick --- (In reply to Harald Schmalzbauer from comment #9) Thanks for your report. I tried various versions of taking snapshots and running /usr/sbin/fstyp on them using the disk image that you originally posted. None of them trigger a panic. If you are able to create a disk image or a script that demonstrates the problem it would be most helpful. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 18:40:14 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 224FB52C8AC for ; Fri, 12 Feb 2021 18:40:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcj3f0J3Qz3k9K for ; Fri, 12 Feb 2021 18:40:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0A16A52C69A; Fri, 12 Feb 2021 18:40:14 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 09D4152CA02 for ; Fri, 12 Feb 2021 18:40:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcj3d6nGQz3kMv for ; Fri, 12 Feb 2021 18:40:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DBECBAA9 for ; Fri, 12 Feb 2021 18:40:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CIeDnw035182 for ; Fri, 12 Feb 2021 18:40:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CIeDvl035181 for fs@FreeBSD.org; Fri, 12 Feb 2021 18:40:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 18:40:14 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 18:40:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #11 from Harald Schmalzbauer --- (In reply to Kirk McKusick from comment #10) Hmmm, I'm applied your diff to stable/13. I'm not aware of any ffs related differences between main and stable/13. Do you have a stable/13 machine for testing? Here, it's just a matter of: mdmfs -s 100m 3 /mnt mksnap_ffs /mnt/.snap/test2 fstyp /mnt/.snap/test2 This panics stable/13 kernel from tady with 8563de2f2799 from main. Will double check diffs... Sorry for the hassle --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 18:52:10 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E144752CE2E for ; Fri, 12 Feb 2021 18:52:10 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcjKP71rxz3lFj for ; Fri, 12 Feb 2021 18:52:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f182.google.com with SMTP id y199so708713oia.4 for ; Fri, 12 Feb 2021 10:52:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h4DKuRrRdcKNNSuvbQYPe4BAKFQ3X5o1VTsWwE2MxyE=; b=V4hOMC+qIeYxc8q8oHQ0OYUXfeC6a08tf0XkPl2sUCEgwrfg1+cSii1vxRq4Nto8x5 7BVjzhrutbKt5X6rH3DJeNWFlipa+SGfdqrW0loC3HDkzFs0eDMq79Ry9j9l1LVjcoHS 7g9HZv5JpyMOiUmivxJrTUtTBDHc+6jwfYGf+cJ+nuGWlsYU+HCGl/He9jABrrVBzeA0 bbi2DyvvcbBO4z1ib26wz/VpLCnkT/+eq66J+vYt97gSZoTocr8Gr6QFGxtPD/T6KfF4 CsrtpYiNSs8sYdnY9v/jb/RKlgZbIl1vDR0jL6PoiSYs61bbSSuZGqm6D9bxPBr/p2PP 4PVA== X-Gm-Message-State: AOAM530fdvMhRWEwBihML65pMS/szRJP2TUUDnyg1ON6H5y84n9JVssP o5RO/lFYdckqbre16q4Q52bXiRgkjFtmHdhBJTjQoN0ITAs= X-Google-Smtp-Source: ABdhPJwhiQp8Y6POp3/xmrgze5j36OaUivMiyx7O9Vv5IbVopud/bbm1vHoDX8RtuDD1b3wwOsYHVY1UbzpXsQ7iPVI= X-Received: by 2002:aca:aacd:: with SMTP id t196mr605463oie.73.1613155928870; Fri, 12 Feb 2021 10:52:08 -0800 (PST) MIME-Version: 1.0 References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> In-Reply-To: <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> From: Alan Somers Date: Fri, 12 Feb 2021 11:51:57 -0700 Message-ID: Subject: Re: Reading a corrupted file on ZFS To: Artem Kuchin Cc: freebsd-fs X-Rspamd-Queue-Id: 4DcjKP71rxz3lFj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.98 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.182:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.167.182:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.182:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.182:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 18:52:10 -0000 On Fri, Feb 12, 2021 at 11:26 AM Artem Kuchin wrote: > 12.02.2021 19:37, Karl Denninger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On 2/12/2021 11:22, Artem Kuchin wrote: > >> > >> This is frustrating. why..why.. > > > > You created a synthetic situation that in the real world almost-never > > exists (ONE byte modified in all copies in the same allocation block > > but all other data in that block is intact and recoverable.) > > > I could be 1 GB file with ZFS wisth block size of 1MB and with rotten > bits within the same 1MB of block on different disks. How i did it is > not important, life is unpredictable, i'm not trying to avoid > everything. The question is what to do when it happens. And currently > the answer is - nothing. > > > > In almost-all actual cases of "bit rot" it's exactly that; random and > > by statistics extraordinarily unlikely to hit all copies at once in > > the same allocation block. Therefore, ZFS can and does fix it; UFS or > > FAT silently returns the corrupted data, propagates it, and eventually > > screws you down the road. > > In active fs you are right. But if this is a storage disk with movies > and photos, then i can just checksum all files with a little script and > recheck once in a while. So, for storage > > perposes i have all ZFS postitives and also can read as much data as i > can. Because for long time storage it is more important to have ability > read the data in any case. > > > > > > The nearly-every-case situation in the real world where a disk goes > > physically bad (I've had this happen *dozens* of times over my IT > > career) results in the drive being unable to > > > *NEARLY* is not good enough for me. > > > > return the block at all; > > > You mix device blocks and ZFS block. As far as i remember default ZFS > block for checksumming is 16K and for big files storage better to have > it around 128K. > > > > In short there are very, very few actual "in the wild" failures where > > one byte is damaged and the rest surrounding that one byte is intact > > and retrievable. In most cases where an actual failure occurs the > > unreadable data constitutes *at least* a physical sector. > > > "very very few" is enough for me to think about. > > One more thing. If you have one bad byte in a block of 16K and you have > checksum and recalculate it then it is quite possible to just brute > force every byte to match the checksum, thus restoring the data. > > If you have mirror with two different bytes then bute forcing is even > ether, > > Somehow, ZFS slaps my hands and does not allow to be sure that i can > restore data when i needed it and decide myself if it is okay or not. > > For long time storage of big files it now seems better to store it on > UFS mirror, checksum each 512bytes blocks of files and store checksums > separetelly and run monthly/weekly "scrub". This way i would sleep better= . > GOD NO. ZFS is really quite good at preserving your data integrity. For example, with your suggested scheme what would protect you from a corrupted checksum file? Nothing. In ZFS, the Merkle hash tree would detect such a thing. Karl is correct: the type of corruption you're worried about is almost non-existent in the real world. Why? LDPC coding, for one reason. For the last 10+ years, hard disks have encoded data using LDPC. Older hard disk encoding schemes, like Reed-Solomon encoding, stored the data in a format similar to RAID: as data + parity. That's why older ATA standards had a "READ LONG" command. But with LDPC, the "original" data does not exist anywhere on the platter. It gets transformed into a large codeword with data and parity intermingled. Physical damage will either be correctable (most likely), render the entire codeword illegible (less likely), or cause it to decode into completely wrong data (least likely). There simply isn't any way to randomly flip a single bit, once it's been written to the media. But if you really, really REALLY want to read blocks that have been deliberately corrupted, you can do it laboriously with zdb. Use zdb to show the dnode, which will include the record pointers for each block. You can decode those and extra the data from the disks with dd. The exact procedure is left as an exercise to the reader. -Alan From owner-freebsd-fs@freebsd.org Fri Feb 12 19:19:24 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABD2252D070 for ; Fri, 12 Feb 2021 19:19:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcjwr49YDz3mvf for ; Fri, 12 Feb 2021 19:19:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8D63252D994; Fri, 12 Feb 2021 19:19:24 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8D29052D92D for ; Fri, 12 Feb 2021 19:19:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcjwr3Sxyz3n19 for ; Fri, 12 Feb 2021 19:19:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 69ED6123A for ; Fri, 12 Feb 2021 19:19:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CJJObZ053817 for ; Fri, 12 Feb 2021 19:19:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CJJOP4053816 for fs@FreeBSD.org; Fri, 12 Feb 2021 19:19:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 19:19:24 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 19:19:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #12 from Harald Schmalzbauer --- (In reply to Harald Schmalzbauer from comment #11) To be precise, I didn't apply the commit (8563de2f2799) but the attachment here, which results in the following diff between main-patch and pr-patch: +++ /opt/deploy-tools/FreeBSD-src/stable_13/sys/ufs/ffs/ffs_snapshot.c=20 2021-02-12 20:05:44.560632000 +0100 @@ -532,7 +532,7 @@ * in the direct blocks, but we add the slop for them in case * they do not end up there. The snapshot list size may get * expanded by one because of an update of an inode block for - * an unlinked but still open files when it is expunged. + * an unlinked but still open file when it is expunged. * * Because the direct block pointers are always copied, they * are not added to the list. Instead ffs_copyonwrite() @@ -723,7 +723,7 @@ free(copy_fs, M_UFSMNT); copy_fs =3D NULL; } - KASSERT(error !=3D 0 || (error =3D=3D 0 && sn !=3D NULL && copy_fs = !=3D NULL), + KASSERT(error !=3D 0 || (sn !=3D NULL && copy_fs !=3D NULL), ("missing snapshot setup parameters")); /* * Resume operation on filesystem. To my limited knowledge, this can't be the root caus of my panic. stable/13 is missing two commits from kib@ for ffs_snapshot.c, but I'm quite sure that these don't affect the changes here. Compiling a kernel with verified sources and actual 8563de2f2799 applied... Meanwhile trying to find something I could run main on... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 15:36:46 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7DAB65282BF for ; Fri, 12 Feb 2021 15:36:46 +0000 (UTC) (envelope-from edvinas.radziavicius@gmail.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcczx64LSz3GRs for ; Fri, 12 Feb 2021 15:36:45 +0000 (UTC) (envelope-from edvinas.radziavicius@gmail.com) Received: by mail-lf1-x132.google.com with SMTP id f1so56522lfu.3 for ; Fri, 12 Feb 2021 07:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:savedfromemail:date:subject:importance:from:to :mime-version; bh=XK80WtdCUbNNarN/miRYuqdHeO5rZRpcToYEWtVslbU=; b=YXAUOFy/g/aEgd41Nl//Roy2fJdgtrnZ2rPlT/ced+BZaaBeyXgCGL+QHukKLa2crl ylNk6JJID1BfNwEG9186qTDKBv2YSY8ePBHuRZx+W/oKMdQrOWQWhF56IcqdxHhCjpgF EN1cG4exqkU1GdOVXE11im8M2vAnO4vCORqSZqUL2m5W9AVcFQNKvYAvL+7fRD5iUnbN z9eHT26lftDOK0F540d75mrMt8EsSEiw/t5QvkTKK2Nhe35EwWGyJOayadHd1HYIb/b9 RGZzoaK7JfmJNDwk4tD6T5YbIt4rT6Kdcajmik2zJQ5AYx4ux8nQGUZyp9/W0neH6H+l QrSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:savedfromemail:date:subject :importance:from:to:mime-version; bh=XK80WtdCUbNNarN/miRYuqdHeO5rZRpcToYEWtVslbU=; b=J7hr0f3DJypHwflBs4PCoTBPV4+aGxGJZElLLPOiI33plRPidZMNuBmzOkXlzJWukr YPOzse2nGuXpyZpMMVMknhjwLBNBvEuyF/COtNTa/y1OBjIw9S7NpggCh/FqD1qcEBDD TeiFSeU3TLW5ks5YiPvKtHKZH9jAt6aWOFdmor6nR+yJX7hPTbEQcXpNiJJXrQou11Py 2ChSvdu0T8QRAouyaEvc0/MrYCOwsIpRs5NszvAj4h9ntPQEUUwf1H3dmxW92Fo4rfma bcJcc1bbiwAqeGT9zni1084Vj7XqAOcCK0NjEmb1+fb5oeN6uwNDBpguRWcvjnerkOLl UIbQ== X-Gm-Message-State: AOAM5321fZvoImmvx2VJ3ztXxhv0Gnu63w7HtTXm2Jhr8L8iNrrSWi9Q 7iCdIkETnSNGtr/ZLLZ7zYMKNg8UJAbPRQ== X-Google-Smtp-Source: ABdhPJz6CMaY8GEgqRq68IUL/2d0obD5gD4y9dbtsCBKBibE7AKbkVmN5umQuGqJp0ImFEok0G3Cqw== X-Received: by 2002:a19:c792:: with SMTP id x140mr1923374lff.546.1613144203919; Fri, 12 Feb 2021 07:36:43 -0800 (PST) Received: from [192.168.0.50] ([46.251.53.47]) by smtp.gmail.com with ESMTPSA id n124sm1054713lfd.201.2021.02.12.07.36.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Feb 2021 07:36:43 -0800 (PST) Message-ID: <6026a08b.1c69fb81.492d2.3d56@mx.google.com> SavedFromEmail: edvinas.radziavicius@gmail.com Date: Fri, 12 Feb 2021 17:36:40 +0200 Subject: Re: Slow reboots due to ZFS cleanup in kern_shutdown() .. zio_fini() Importance: normal From: "edvinas.radziavicius" To: freebsd-fs@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Dcczx64LSz3GRs X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YXAUOFy/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of edvinasradziavicius@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=edvinasradziavicius@gmail.com X-Spamd-Result: default: False [2.85 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(3.75)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::132:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::132:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[0.997]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::132:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] X-Mailman-Approved-At: Fri, 12 Feb 2021 19:21:32 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 15:36:46 -0000 ScWhc2nFs3N0YSBpxaEgbWFubyBHYWxheHk= From owner-freebsd-fs@freebsd.org Fri Feb 12 19:35:01 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CC5C52E421 for ; Fri, 12 Feb 2021 19:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DckGs1wxsz3pQ3 for ; Fri, 12 Feb 2021 19:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 407C852E334; Fri, 12 Feb 2021 19:35:01 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 403F852E420 for ; Fri, 12 Feb 2021 19:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DckGs1HwDz3pMW for ; Fri, 12 Feb 2021 19:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1FC7214D7 for ; Fri, 12 Feb 2021 19:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CJZ14t061219 for ; Fri, 12 Feb 2021 19:35:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CJZ1Vc061218 for fs@FreeBSD.org; Fri, 12 Feb 2021 19:35:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 19:35:01 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 19:35:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #13 from Harald Schmalzbauer --- (In reply to Harald Schmalzbauer from comment #12) FreeBSD bosco.local 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-18097ee2f-dirty: Fri Feb 12 20:16:32 CET 2021=20=20=20=20 hes@preed.egn.mo1.omnilan.net:/usr/local/share/deploy-tools/obj/CoffeeLake-= stable_13/amd64.amd64/sys/CoffeeLake.bosco amd64 bosco:/usr/home/admin/#:3 mdmfs -s 100m 3 /mnt bosco:/usr/home/admin/#:4 mksnap_ffs /mnt/.snap/test2 bosco:/usr/home/admin/#:5 fstyp /mnt/.snap/test2 ssh dead due to crash... Will compile main for that machine, but this takes few hours. Can you confirm that the your machine doesn't panic with the 3 commands from above (note that I'm not running fstyp(8) against /dev/mdX but /mnt/.snap/t= est2 itself - this was a feasable way of determining the validity of a auto-dete= cted snapshot in my deploy/update chain) Thanks, -harry --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 19:49:05 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2224752E97C for ; Fri, 12 Feb 2021 19:49:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dckb41dwxz3qN5 for ; Fri, 12 Feb 2021 19:49:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id BCD312110B2 for ; Fri, 12 Feb 2021 14:49:00 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id D5FDF123982 for ; Fri, 12 Feb 2021 14:49:02 -0500 (EST) Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> From: Karl Denninger Message-ID: <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> Date: Fri, 12 Feb 2021 14:49:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050304070202000400010902" X-Rspamd-Queue-Id: 4Dckb41dwxz3qN5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 19:49:05 -0000 This is a cryptographically signed message in MIME format. --------------ms050304070202000400010902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2/12/2021 13:26, Artem Kuchin wrote: > 12.02.2021 19:37, Karl Denninger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On 2/12/2021 11:22, Artem Kuchin wrote: >>> >>> This is frustrating. why..why.. >> >> You created a synthetic situation that in the real world almost-never = >> exists (ONE byte modified in all copies in the same allocation block=20 >> but all other data in that block is intact and recoverable.) >> > I could be 1 GB file with ZFS wisth block size of 1MB and with rotten=20 > bits within the same 1MB of block on different disks. How i did it is=20 > not important, life is unpredictable, i'm not trying to avoid=20 > everything. The question is what to do when it happens. And currently=20 > the answer is - nothing. > The answer to a problem that does not present itself statistically=20 speaking in the real world is the last one you worry about.=C2=A0 Worry a= bout=20 all the other ones and cover them first. I have had literal *hundreds* of drives fail in my time in IT.=C2=A0 I us= ed=20 to go change them in office machines (IBM PCs and clones -- the original = ones) 2-3 times a week at one of our larger customers.=C2=A0 This was in = the=20 day of 2,7RLL encoding if you were lucky for capacity reasons (MFM if=20 not)..... yeah, that far back and before.=C2=A0 Of course when you have a= =20 building full of these things as they did they break on a fairly regular = basis and hopefully you've thought the implications of that out and how=20 to recover from it. The *least* disruptive failures were sector-sized and occasionally I'd=20 get the frantic phone call from some place that had no backups and was=20 utterly desperate because something like their master inventory file was = on that disk.=C2=A0 There were times I was able to recover it with a lot = of=20 work and luck but when it was truly hosed and no amount of being willing = to wait would get you one good read I was *never* able to narrow the=20 data loss down to less than one sector irrespective of what the customer = was willing to pay.=C2=A0 Ever.=C2=A0 It sure wasn't cheap having actual = recovery=20 done (the clean-room style places can do it too, but the same issue=20 applies there; gone is gone, like it or not.) Nowdays modern drives frequently claim they have 63 (or 255)=20 sectors/track but that's bollocks; their actual internal organization is = completely opaque beyond the firmware in the drive in no small part=20 because a larger circumference can hold more data bits in a given=20 encoding than a smaller one, so the physical sectors on a given track is = not constant.=C2=A0 Most modern "larger" disks have several *hundred* sec= tors=20 per physical track, in many cases they are physically 4k sectors and=20 loss of servo information can result in the entire track being=20 unrecoverable. As sizes go up so does the size of data at risk from a given event.=C2=A0= =20 It's inherent in complex encoding schemes; the more you encode in a=20 symbol the more you lose when the symbol is corrupted to the point it=20 cannot be recovered. 128kb is all you lost?=C2=A0 How quaint. >> In almost-all actual cases of "bit rot" it's exactly that; random and = >> by statistics extraordinarily unlikely to hit all copies at once in=20 >> the same allocation block.=C2=A0 Therefore, ZFS can and does fix it; U= FS=20 >> or FAT silently returns the corrupted data, propagates it, and=20 >> eventually screws you down the road. > > In active fs you are right. But if this is a storage disk with movies=20 > and photos, then i can just checksum all files with a little script=20 > and recheck once in a while. So, for storage > > perposes i have all ZFS postitives and also can read as much data as i = > can. Because for long time storage it is more important to have=20 > ability read the data in any case. > I do that now with ZFS.=C2=A0 In some cases (long-term online but=20 nearly-read/only "cool" storage that is spun down when not being=20 accessed) I have backups that are only mounted and verified once a=20 year.=C2=A0 Mount the backup volumes and scrub them, for this specific re= ason=20 -- to detect the very unlikely but possible chance that two bits will=20 get flipped in the identical checksummed domain (ZFS block size) on two=20 or more copies.=C2=A0 If it happens you're hosed and "cold" storage (disk= s in=20 a vault for a year) is where patrol scrubs are most-likely to miss it=20 because you're not doing them on a regular basis since the disks are=20 physically in a different place.=C2=A0 Those backups are for all intents = and=20 purposes a fire insurance policy. I've yet to need them but that doesn't mean I'll stop maintaining them.=C2= =A0=20 I've also yet to have one fail verification but I'm sure it'll=20 eventually happen; that's why THOSE are redundant too. >> >> The nearly-every-case situation in the real world where a disk goes=20 >> physically bad (I've had this happen *dozens* of times over my IT=20 >> career) results in the drive being unable to=20 > > *NEARLY* is not good enough for me. > Then make backups and make THOSE ZFS mirrors (which is what I do),=20 dismount them and put them in a second location.=C2=A0 That's what backup= s=20 are for and ZFS makes that pretty easy and efficient with snapshots and=20 send/receive.=C2=A0 ZFS also makes segmenting data into "live" (updated a= lot=20 and currently), "cool" (updated once in a while) and "online but cold"=20 (either R/O or close to it) and moving data from one classification to=20 another (which happens often over time) and that in turn allows you to=20 *easily* build a backup strategy that works for all of that and yet=20 doesn't involve trying to cart a petabyte around in your car to and from = the bank vault.=C2=A0 It also allows a snapshot capacity tailored to each= =20 requirement so an "oops" (as opposed to hardware failures) can be=20 trivially recovered from which is not easy to do with UFS at all. If you have a 0.001 (1 in a thousand) risk over some period of time and=20 and have a second copy off-site with the same risk the odds of both=20 failing at the same time by other than physical calamity that takes out=20 both locations are multiplicative. Increase your redundancy as required=20 until you're comfortable.=C2=A0 If "Tsar Bomba" gets dropped on my locati= on,=20 well..... :-) I've had the ugly and wildly-improbable nightmare scenario happen to me=20 in real life when I ran MCSNet -- a disk adapter that went insane=20 internally and scribbled on *every attached device* at once.=C2=A0 It=20 destroyed the data on ALL of them.=C2=A0 If I didn't have a backup I woul= d=20 have been *done* right there.=C2=A0 This was before ZFS and the pucker fa= ctor=20 on that was considerable. >> return the block at all;=20 > > You mix device blocks and ZFS block. As far as i remember default ZFS=20 > block for checksumming is 16K and for big files storage better to have = > it around 128K. No I don't.=C2=A0 A block is a block is a block; they're different sizes = depending on application and where in the stack of "things" between the=20 physical disk and the application doing the reading or writing. In some=20 cases I run small block sizes on ZFS, in others large block sizes.=C2=A0 = Depends on the workload.=C2=A0 But I have control of that; I have no cont= rol=20 over what the physical media does inside its firmware. In some cases its = idea of a "block" is small, in others its large, and in still others=20 (SSDs in particular) how big it is depends on which block.=C2=A0 Scramble= an=20 allocation table in an SSD's controller and frequently everything on the = drive is gone *at once.*=C2=A0 The scope of damage if you get an uncorrec= ted=20 error off a given media depends on many things (e.g. encoding in use,=20 the media's sector size, is the error in the data or is in the servo=20 information on the platter if the device is spinning rust, if it's an=20 SSD is the error in the data block or is it in the allocation/mapping=20 table storage, etc.) >> In short there are very, very few actual "in the wild" failures where = >> one byte is damaged and the rest surrounding that one byte is intact=20 >> and retrievable.=C2=A0 In most cases where an actual failure occurs th= e=20 >> unreadable data constitutes *at least* a physical sector. >> > "very very few" is enough for me to think about. Then keep backups and make sure THEY are redundant too.=C2=A0 Do patrol s= cans=20 (e.g. scrubs) on those on some reasonable basis so you are comfortable=20 that the backups are good. > > One more thing. If you have one bad byte in a block of 16K and you=20 > have checksum and recalculate it then it is quite possible to just=20 > brute force every byte to match the checksum, thus restoring the data. True.=C2=A0 But as I said across an unbelievable number of failures that = I've=20 seen in my close to 40 years doing this stuff I've yet to have *one*=20 instance in which a media failure took out less than at least one=20 physical sector of the device and if it does, I still have one more=20 error of the *same sort* that has to happen in the same logical block on = the other vdev of the mirror, otherwise it gets detected and fixed with=20 no harm and no foul.=C2=A0 I'm sure it's possible for me to get screwed b= ut=20 then again it's also possible for me to get hit by an asteroid while=20 getting my mail -- it's just statistically improbable to the point that=20 I don't worry about it very much. I'm a LOT more worried about a failure on enough *other* vdevs during a=20 resilver to lose redundancy AND data, which can really hose you. That is = a hell of a lot more-likely statistically and if it happens you better=20 have backups because that second failure, being unrelated to the first,=20 hoses you *hard*. > > If you have mirror with two different bytes then bute forcing is even=20 > ether, > > Somehow, ZFS slaps my hands and does not allow to be sure that i can=20 > restore data when i needed it and decide myself if it is okay or not. > > For long time storage of big files it now seems better to store it on=20 > UFS mirror, checksum each 512bytes blocks of files and store checksums = > separetelly and run monthly/weekly "scrub". This way i would sleep=20 > better. > For the love of God no.=C2=A0 For openers how do you detect a corrupted=20 checksum file and know it's *the file* as opposed to the data? There are good reasons to run UFS instead of ZFS in many cases but this=20 is definitely not one of them. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050304070202000400010902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjEyMTk0OTAx WjBPBgkqhkiG9w0BCQQxQgRAYtgRkui2lAaKtA9v25XS0jJDm7OZg8mKNd/WeMqwNdWTpanl CwoHRlIvpe/Xo96V8EiEaeDUd3Ge5KSSy6d8cDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBW09FJa7hvqQ0+8LWyV62ccGkpG0lv6EUl274OGaZ/eUMvLNiTTN/5TQvCNWNzOj5Y Fdw6euX4g64PV2zmvzNib8tlisYEUIAPTkAtuWSg0Jp9KYggO/PrqPmN5OE1FA13GF9BxE0M lfMdPwmUAelDcD76RPwNmvYZCT+PLejGhMZM3vN5dk/fsuRDwjUjWDoO1Q7fTq6/ePhvXtmB VuQBVnj3uvrNPTwaSdm4bdO1tax9oMQcAqoIfsdSUb6wEMIRDLln6LscIwBLnqZWCchnb+mw +znRTKTxE8pG1p8Pqg2dEeSdvA7xINDRMkQ3/c18I/5R+NyYsV2myIBAd1UYJMZyk6BoTlJ8 EMLVxGNYrCMczsY5DrMzMVChDSDod+6S8ePpPhKkpNy0y7+MWpvZSVd7aUcjFtH0S040L7PP 308FUTIeNNUpEFFihSGfoOG9acurplBPVZyGBAv/DVRAfjojl2Z7Bw4Caq84KCOq0GoNWXeJ h3EK83taC1fTnoGKDOh2+1846q8wTlqoVERd3zSmPDm+n2dlaSTV9VSFAzo89f2RZ+yicxc4 qU1Z8tlnMGa/AWoL/amxeK5ApnHyfRMauUVSzbPZU08bu/Kp3NfUkt2qFN4rLkP2Nf1GB6m/ 8D+HtjRZMbN+DuNmW3JzWDSf0hfStXyyoc4Z1IvgZgAAAAAAAA== --------------ms050304070202000400010902-- From owner-freebsd-fs@freebsd.org Fri Feb 12 20:16:57 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B167952FCA3 for ; Fri, 12 Feb 2021 20:16:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DclCF4QbHz3sKZ for ; Fri, 12 Feb 2021 20:16:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 95DF952FBBC; Fri, 12 Feb 2021 20:16:57 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 95A2552FBBB for ; Fri, 12 Feb 2021 20:16:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DclCF3gqLz3sN4 for ; Fri, 12 Feb 2021 20:16:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6CEFC1FE3 for ; Fri, 12 Feb 2021 20:16:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CKGvEd085300 for ; Fri, 12 Feb 2021 20:16:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CKGvBQ085299 for fs@FreeBSD.org; Fri, 12 Feb 2021 20:16:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 252981] panic with ZFS encryption and QAT: VERIFY3(0 == spa_do_crypt_bad(... Date: Fri, 12 Feb 2021 20:16: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: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 20:16:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252981 --- Comment #8 from John Baldwin --- I concur with changing 13 to only use software for now. The other solutions aren't going to be ready before 13.0. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 20:19:44 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23F7E52FD35 for ; Fri, 12 Feb 2021 20:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DclGS0MLhz3sY4 for ; Fri, 12 Feb 2021 20:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0C5F652FD34; Fri, 12 Feb 2021 20:19:44 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C29F52FA55 for ; Fri, 12 Feb 2021 20:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DclGR6tlNz3sSl for ; Fri, 12 Feb 2021 20:19:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DE3821FE4 for ; Fri, 12 Feb 2021 20:19:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CKJhYF086009 for ; Fri, 12 Feb 2021 20:19:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CKJhIO086008 for fs@FreeBSD.org; Fri, 12 Feb 2021 20:19:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 20:19:44 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 20:19:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #14 from Cy Schubert --- I've been able to reproduce this in a very recent 14-CURRENT in a VM. No du= mp though, the VM doesn't have the extra disk (yet). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 22:25:30 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E5C5653379E for ; Fri, 12 Feb 2021 22:25:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcp3Z614Jz4WY3 for ; Fri, 12 Feb 2021 22:25:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CC7C753380F; Fri, 12 Feb 2021 22:25:30 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CC402533889 for ; Fri, 12 Feb 2021 22:25:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcp3Z5N7Qz4WVp for ; Fri, 12 Feb 2021 22:25:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id ABA2A3DC9 for ; Fri, 12 Feb 2021 22:25:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CMPUHC053211 for ; Fri, 12 Feb 2021 22:25:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CMPUgt053210 for fs@FreeBSD.org; Fri, 12 Feb 2021 22:25:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 22:25: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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 22:25:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #15 from Kirk McKusick --- (In reply to Cy Schubert from comment #14) I just tried this test and cannot reproduce it: Script started on Fri Feb 12 14:23:53 2021 guest_13 # uname -a FreeBSD guest_13 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n244791-62374dfa0f0d: Fri Feb 12 14:11:34 UTC 2021=20=20=20=20 root@guest_13:/usr/src/git-freebsd/src/sys/amd64/compile/GENERIC amd64 guest_13 # mdmfs -s 100m 3 /mnt guest_13 # mksnap_ffs /mnt/.snap/test2 guest_13 # fstyp /mnt/.snap/test2 ufs guest_13 # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/gpt/rootfs 96446284 21825260 66905324 25% / devfs 1 1 0 100% /dev /dev/md3 98716 584 90236 1% /mnt guest_13 # exit Script done on Fri Feb 12 14:25:30 2021 Can you see what you are doing that is different than me to reproduce it? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 22:34:52 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 846B953367C for ; Fri, 12 Feb 2021 22:34:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcpGN35m1z4X3P for ; Fri, 12 Feb 2021 22:34:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 68A4D533C02; Fri, 12 Feb 2021 22:34:52 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 686CA53367B for ; Fri, 12 Feb 2021 22:34:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcpGN2NJXz4Wry for ; Fri, 12 Feb 2021 22:34:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 40D963D34 for ; Fri, 12 Feb 2021 22:34:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CMYqPT057267 for ; Fri, 12 Feb 2021 22:34:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CMYqjs057266 for fs@FreeBSD.org; Fri, 12 Feb 2021 22:34:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 22:34:52 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 22:34:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #16 from Konstantin Belousov --- Well, configure the crash dumps and get vmcore then. Put your kernel with debug symbols (kernel.full) and vmcore somewhere. Might be it would be easier wa= y to extract the information. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 12 22:59:21 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FB0C5349D7 for ; Fri, 12 Feb 2021 22:59:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcppd0CcVz4ZM5 for ; Fri, 12 Feb 2021 22:59:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 07328534A3C; Fri, 12 Feb 2021 22:59:21 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06F75534BC6 for ; Fri, 12 Feb 2021 22:59:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcppc6lVpz4ZKG for ; Fri, 12 Feb 2021 22:59:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D7CE744B3 for ; Fri, 12 Feb 2021 22:59:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11CMxKNm068664 for ; Fri, 12 Feb 2021 22:59:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11CMxKZb068663 for fs@FreeBSD.org; Fri, 12 Feb 2021 22:59:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Fri, 12 Feb 2021 22:59:20 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 22:59:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #17 from Cy Schubert --- I'll do that after $JOB tonight. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 00:12:14 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2BA9A53715C for ; Sat, 13 Feb 2021 00:12:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcrQk0rW2z4fyW; Sat, 13 Feb 2021 00:12:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 9EBD97645; Sat, 13 Feb 2021 00:12:13 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Fri, 12 Feb 2021 16:12:11 -0800 (PST) From: Don Lewis Subject: Re: Reading a corrupted file on ZFS To: Fabian Keil cc: freebsd-fs@freebsd.org In-Reply-To: <20210212165216.2f613482@fabiankeil.de> Message-ID: References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-5 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:12:14 -0000 On 12 Feb, Fabian Keil wrote: > Artem Kuchin wrote on 2021-02-12: >=20 >> 12.02.2021 18:06, Karl Denninger =DF=D8=E8=D5=E2: >=20 >> > Blocking the read forces you to get the good copy off backup media and= =20 >> > thus prevents that from happening. >> > >>=20 >> I know what ZFS does and i damaged the same file in the same place on=20 >> purpose. Question is: how to read what's left of it. Just for kicks, i= =20 >> don't have a backup, and i need to read what's left. It could be 1GB=20 >> file with only one byte damaged and it is of crazy importance to me. So,= =20 >> how to bypass all the checks and make it read the file no matter what? >=20 > The patch from this PR adds a sysctl that allows to send corrupted data: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221909 >=20 > Using the added sysctl you can send and receive the dataset and then > read the corrupted file from the received dataset. Note that ZFS replaces > corrupted blocks completely with the 0x'zfs badd bloc' pattern instead > of returning the corrupted data as is, thus increasing the amount of > corruption in case of simple bit flips to whole blocks. Compression, which defaults to being used, also will increase the amount of corruption. From owner-freebsd-fs@freebsd.org Sat Feb 13 00:38:05 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ACB34538733 for ; Sat, 13 Feb 2021 00:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcs0Y4K9Qz4jNn for ; Sat, 13 Feb 2021 00:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 924475386BB; Sat, 13 Feb 2021 00:38:05 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 92043538732 for ; Sat, 13 Feb 2021 00:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcs0Y3ffbz4jRM for ; Sat, 13 Feb 2021 00:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 70B505978 for ; Sat, 13 Feb 2021 00:38:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D0c5gk018817 for ; Sat, 13 Feb 2021 00:38:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D0c52X018816 for fs@FreeBSD.org; Sat, 13 Feb 2021 00:38:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 00:38: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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:38:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #18 from Cy Schubert --- slippy# kgdb /alt/vm64/root/usr/lib/debug/boot/kernel/kernel.debug vmcore.0 GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /alt/vm64/root/usr/lib/debug/boot/kernel/kernel.debug.= .. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x30 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff809feb04 stack pointer =3D 0x28:0xfffffe0097a84580 frame pointer =3D 0x28:0xfffffe0097a845c0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1154 (fstyp) trap number =3D 12 panic: page fault cpuid =3D 0 time =3D 1613173364 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0097a84= 230 vpanic() at vpanic+0x181/frame 0xfffffe0097a84280 panic() at panic+0x43/frame 0xfffffe0097a842e0 trap_fatal() at trap_fatal+0x387/frame 0xfffffe0097a84340 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0097a843a0 trap() at trap+0x27d/frame 0xfffffe0097a844b0 calltrap() at calltrap+0x8/frame 0xfffffe0097a844b0 --- trap 0xc, rip =3D 0xffffffff809feb04, rsp =3D 0xfffffe0097a84580, rbp = =3D 0xfffffe0097a845c0 --- pmap_map_io_transient() at pmap_map_io_transient+0x44/frame 0xfffffe0097a84= 5c0 pmap_copy_pages() at pmap_copy_pages+0xa7/frame 0xfffffe0097a84650 vn_io_fault_pgmove() at vn_io_fault_pgmove+0x99/frame 0xfffffe0097a84680 ffs_read() at ffs_read+0x2e7/frame 0xfffffe0097a84710 VOP_READ_APV() at VOP_READ_APV+0x1f/frame 0xfffffe0097a84730 vn_read() at vn_read+0x1ed/frame 0xfffffe0097a847b0 vn_io_fault_doio() at vn_io_fault_doio+0x43/frame 0xfffffe0097a84810 vn_io_fault1() at vn_io_fault1+0x2c4/frame 0xfffffe0097a84960 vn_io_fault() at vn_io_fault+0x1a4/frame 0xfffffe0097a849e0 dofileread() at dofileread+0x81/frame 0xfffffe0097a84a30 kern_preadv() at kern_preadv+0x62/frame 0xfffffe0097a84a70 sys_pread() at sys_pread+0x8a/frame 0xfffffe0097a84ac0 amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe0097a84bf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0097a84bf0 --- syscall (475, FreeBSD ELF64, sys_pread), rip =3D 0x2c0408fa, rsp =3D 0x7fffffffe258, rbp =3D 0x7fffffffe280 --- Uptime: 2m31s Dumping 163 out of 480 MB:..10%..20%..30%..40%..49%..59%..69%..79%..89%..98% __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(stru= ct pcpu, (kgdb) bt #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=3Dtextdump@entry=3D1) at /opt/src/git-src/sys/kern/kern_shutdown.c:399 #2 0xffffffff806b7b4b in kern_reboot (howto=3D260) at /opt/src/git-src/sys/kern/kern_shutdown.c:486 #3 0xffffffff806b7fd0 in vpanic (fmt=3D, ap=3D) at /opt/src/git-src/sys/kern/kern_shutdown.c:919 #4 0xffffffff806b7dd3 in panic (fmt=3D) at /opt/src/git-src/sys/kern/kern_shutdown.c:843 #5 0xffffffff80a0f6d7 in trap_fatal (frame=3D0xfffffe0097a844c0, eva=3D48) at /opt/src/git-src/sys/amd64/amd64/trap.c:915 #6 0xffffffff80a0f72f in trap_pfault (frame=3Dframe@entry=3D0xfffffe0097a8= 44c0, usermode=3Dfalse,=20 signo=3D, signo@entry=3D0x0, ucode=3D, ucode@entry=3D0x0) at /opt/src/git-src/sys/amd64/amd64/trap.c:732 #7 0xffffffff80a0ed8d in trap (frame=3D0xfffffe0097a844c0) at /opt/src/git-src/sys/amd64/amd64/trap.c:398 #8 #9 0xffffffff809feb04 in pmap_map_io_transient (page=3Dpage@entry=3D0xfffffe0097a845d0,=20 vaddr=3Dvaddr@entry=3D0xfffffe0097a84610, count=3Dcount@entry=3D2, can_fault=3Dcan_fault@entry=3D0) at /opt/src/git-src/sys/amd64/amd64/pmap.c:9979 #10 0xffffffff809fea17 in pmap_copy_pages (ma=3D0xfffffe0001312f00, a_offse= t=3D0,=20 mb=3D0xfffffe0097a7ca60, b_offset=3D0, xfersize=3Dxfersize@entry=3D3276= 8) at /opt/src/git-src/sys/amd64/amd64/pmap.c:7825 #11 0xffffffff807b4109 in vn_io_fault_pgmove (ma=3D0x0, offset=3D, offset@entry=3D0,=20 xfersize=3Dxfersize@entry=3D32768, uio=3Duio@entry=3D0xfffffe0097a848b0) at /opt/src/git-src/sys/kern/vfs_vnops.c:1513 #12 0xffffffff80937497 in ffs_read (ap=3D) at /opt/src/git-src/sys/ufs/ffs/ffs_vnops.c:789 #13 0xffffffff80a5264f in VOP_READ_APV (vop=3D0xffffffff80ce8588 ,=20 a=3Da@entry=3D0xfffffe0097a84760) at vnode_if.c:1050 #14 0xffffffff807b7c8d in VOP_READ (vp=3D0xfffff800065f65b8, uio=3D0xfffffe0097a848b0, ioflag=3D0,=20 cred=3D) at ./vnode_if.h:542 #15 vn_read (fp=3D0xfffff8000004d000, uio=3D0xfffffe0097a848b0, active_cred=3D0xfffff80007a66b00,=20 flags=3D, td=3D) at /opt/src/git-src/sys/kern/vfs_vnops.c:1027 #16 0xffffffff807b79f3 in vn_io_fault_doio (args=3Dargs@entry=3D0xfffffe009= 7a84970,=20 uio=3Duio@entry=3D0xfffffe0097a848b0, td=3D0xfffffe009781b100) at /opt/src/git-src/sys/kern/vfs_vnops.c:1174 #17 0xffffffff807b3a54 in vn_io_fault1 (vp=3D, uio=3Duio@entry=3D0xfffffe0097a84a80,=20 args=3Dargs@entry=3D0xfffffe0097a84970, td=3Dtd@entry=3D0xfffffe009781b= 100) at /opt/src/git-src/sys/kern/vfs_vnops.c:1342 #18 0xffffffff807b0fc4 in vn_io_fault (fp=3D, uio=3D0xfffffe0097a84a80,=20 active_cred=3D, flags=3D, td=3D) at /opt/src/git-src/sys/kern/vfs_vnops.c:1414 #19 0xffffffff807281f1 in fo_read (fp=3D0xfffff8000004d000, uio=3D0xfffffe0097a84a80, active_cred=3D0x2,=20 flags=3D-1750577984, td=3D0xfffffe009781b100) at /opt/src/git-src/sys/sys/file.h:330 #20 dofileread (td=3Dtd@entry=3D0xfffffe009781b100, fd=3Dfd@entry=3D3, fp=3D0xfffff8000004d000,=20 auio=3Dauio@entry=3D0xfffffe0097a84a80, offset=3D, offset@entry=3D20676608,=20 flags=3D, flags@entry=3D1) at /opt/src/git-src/sys/kern/sys_generic.c:369 #21 0xffffffff80727fc2 in kern_preadv (td=3D0xfffffe009781b100, fd=3D3,=20 auio=3Dauio@entry=3D0xfffffe0097a84a80, offset=3D20676608) at /opt/src/git-src/sys/kern/sys_generic.c:335 #22 0xffffffff80727eca in kern_pread (td=3D, fd=3D-175057969= 6, buf=3D,=20 nbyte=3D18446741877230685376, offset=3D0) at /opt/src/git-src/sys/kern/sys_generic.c:244 #23 sys_pread (td=3D0xfffffe0097a845d0, uap=3D) at /opt/src/git-src/sys/kern/sys_generic.c:226 #24 0xffffffff80a0ffdc in syscallenter (td=3D0xfffffe009781b100) at /opt/src/git-src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #25 amd64_syscall (td=3D0xfffffe009781b100, traced=3D0) at /opt/src/git-src/sys/amd64/amd64/trap.c:1156 #26 #27 0x000000002c0408fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe258 (kgdb)=20 (kgdb) p page[i] value has been optimized out (kgdb) p i $16 =3D (kgdb) p count $17 =3D 2 (kgdb) p page[0] $18 =3D (vm_page_t) 0xfffffe00005807e8 (kgdb) p page[1] $19 =3D (vm_page_t) 0x0 (kgdb)=20 (kgdb) up #10 0xffffffff809fea17 in pmap_copy_pages (ma=3D0xfffffe0001312f00, a_offse= t=3D0,=20 mb=3D0xfffffe0097a7ca60, b_offset=3D0, xfersize=3Dxfersize@entry=3D3276= 8) at /opt/src/git-src/sys/amd64/amd64/pmap.c:7825 7825 mapped =3D pmap_map_io_transient(pages, vaddr, 2, F= ALSE); (kgdb) p pages $20 =3D {0xfffffe00005807e8, 0x0} (kgdb) p vaddr $21 =3D {18446735277843750912, 18446735277723444664} (kgdb)=20 (kgdb) up #10 0xffffffff809fea17 in pmap_copy_pages (ma=3D0xfffffe0001312f00, a_offse= t=3D0,=20 mb=3D0xfffffe0097a7ca60, b_offset=3D0, xfersize=3Dxfersize@entry=3D3276= 8) at /opt/src/git-src/sys/amd64/amd64/pmap.c:7825 7825 mapped =3D pmap_map_io_transient(pages, vaddr, 2, F= ALSE); (kgdb) p pages $20 =3D {0xfffffe00005807e8, 0x0} (kgdb) p vaddr $21 =3D {18446735277843750912, 18446735277723444664} (kgdb)=20 (kgdb) l 7820 pages[0] =3D ma[a_offset >> PAGE_SHIFT]; 7821 b_pg_offset =3D b_offset & PAGE_MASK; 7822 pages[1] =3D mb[b_offset >> PAGE_SHIFT]; 7823 cnt =3D min(xfersize, PAGE_SIZE - a_pg_offset); 7824 cnt =3D min(cnt, PAGE_SIZE - b_pg_offset); 7825 mapped =3D pmap_map_io_transient(pages, vaddr, 2, F= ALSE); 7826 a_cp =3D (char *)vaddr[0] + a_pg_offset; 7827 b_cp =3D (char *)vaddr[1] + b_pg_offset; 7828 bcopy(a_cp, b_cp, cnt); 7829 if (__predict_false(mapped)) (kgdb) p pages[0] $22 =3D (vm_page_t) 0xfffffe00005807e8 (kgdb) p pages[1] $23 =3D (vm_page_t) 0x0 (kgdb) p b_offset $24 =3D 0 (kgdb) p a_offset $25 =3D 0 (kgdb) p ma[0] $26 =3D (vm_page_t) 0xfffffe00005807e8 (kgdb) p mb[0] $27 =3D (vm_page_t) 0x0 (kgdb)=20 Break time is over. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 00:51:17 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D94305387E7 for ; Sat, 13 Feb 2021 00:51:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcsHn5Yzvz4jj4 for ; Sat, 13 Feb 2021 00:51:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BEF5C5387E5; Sat, 13 Feb 2021 00:51:17 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEB755387E4 for ; Sat, 13 Feb 2021 00:51:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcsHn4z2zz4jks for ; Sat, 13 Feb 2021 00:51:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9DD165CF6 for ; Sat, 13 Feb 2021 00:51:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D0pH0i025293 for ; Sat, 13 Feb 2021 00:51:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D0pH5M025292 for fs@FreeBSD.org; Sat, 13 Feb 2021 00:51:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 00:51:17 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:51:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #19 from Konstantin Belousov --- (In reply to Cy Schubert from comment #18) For start, show locals from the frame 11. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 01:57:11 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 84C3B53A8D6 for ; Sat, 13 Feb 2021 01:57:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dctlq38mhz4nPY for ; Sat, 13 Feb 2021 01:57:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6C5AB53A8D5; Sat, 13 Feb 2021 01:57:11 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6C24B53AD25 for ; Sat, 13 Feb 2021 01:57:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dctlq2XFDz4nPX for ; Sat, 13 Feb 2021 01:57:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 49D4269BA for ; Sat, 13 Feb 2021 01:57:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D1vB5D056548 for ; Sat, 13 Feb 2021 01:57:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D1vBtK056547 for fs@FreeBSD.org; Sat, 13 Feb 2021 01:57:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 01:57:11 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 01:57:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #20 from Cy Schubert --- (kgdb) frame 11 #11 0xffffffff807b4109 in vn_io_fault_pgmove (ma=3D0x0, offset=3D, offset@entry=3D0,=20 xfersize=3Dxfersize@entry=3D32768, uio=3Duio@entry=3D0xfffffe0097a848b0) at /opt/src/git-src/sys/kern/vfs_vnops.c:1513 1513 pmap_copy_pages(ma, offset, td->td_ma, iov_base & PAGE_MASK, (kgdb) info args ma =3D 0x0 offset =3D xfersize =3D 32768 uio =3D 0xfffffe0097a848b0 (kgdb) info locals td =3D 0xfffffe009781b100 cnt =3D 32768 iov_base =3D 732655616 pgadv =3D (kgdb)=20 I'll build a GENERIC kernel for this VM. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 02:16:52 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BF9553B53E for ; Sat, 13 Feb 2021 02:16:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcvBW6lPqz4pGR for ; Sat, 13 Feb 2021 02:16:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E5B5D53B53D; Sat, 13 Feb 2021 02:16:51 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E577F53B80C for ; Sat, 13 Feb 2021 02:16:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcvBW65WNz4pLs for ; Sat, 13 Feb 2021 02:16:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C3DFF6BE1 for ; Sat, 13 Feb 2021 02:16:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D2Gp6l068573 for ; Sat, 13 Feb 2021 02:16:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D2Gpqo068572 for fs@FreeBSD.org; Sat, 13 Feb 2021 02:16:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 02:16: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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 02:16:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #21 from Konstantin Belousov --- (In reply to Cy Schubert from comment #20) And please show locals from the frame #12 (ffs_read). I hope that there are alive vars 'fs', 'ip', and 'bp'. For each of them I want to see their objects printed, i.e. p *fs p *ip p *bp --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 04:31:33 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E92F53E61F for ; Sat, 13 Feb 2021 04:31:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcy9w68Wyz3CsV for ; Sat, 13 Feb 2021 04:31:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id C212A53E53F; Sat, 13 Feb 2021 04:31:32 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1D3A53E53E for ; Sat, 13 Feb 2021 04:31:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcy9w4SVTz3CZS for ; Sat, 13 Feb 2021 04:31:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8AEBD10BE9 for ; Sat, 13 Feb 2021 04:31:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D4VWHM040991 for ; Sat, 13 Feb 2021 04:31:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D4VWxQ040990 for fs@FreeBSD.org; Sat, 13 Feb 2021 04:31:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 04:31:32 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 04:31:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #22 from Cy Schubert --- No joy. (kgdb) frame 12 #12 0xffffffff80f22e57 in ffs_read (ap=3D) at /opt/src/vm64/sys/ufs/ffs/ffs_vnops.c:789 789 error =3D vn_io_fault_pgmove(bp->b_pages, blkoffset, (kgdb) info args ap =3D (kgdb) info locals vp =3D uio =3D 0xfffffe00882928b0 ioflag =3D 0 ip =3D seqcount =3D 0 orig_resid =3D fs =3D bp =3D error =3D 0 bflag =3D 72 bytesinfile =3D lbn =3D nextlbn =3D size =3D 32768 blkoffset =3D 0 xfersize =3D 32768 (kgdb) p *fs value has been optimized out (kgdb) p *ip value has been optimized out (kgdb) p *bp value has been optimized out (kgdb)=20 We'll need to build a -O0 kernel. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 04:33:51 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6215B53E71D for ; Sat, 13 Feb 2021 04:33:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DcyDb1nkxz3D7y for ; Sat, 13 Feb 2021 04:33:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3D80153E71C; Sat, 13 Feb 2021 04:33:51 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D4B253E563 for ; Sat, 13 Feb 2021 04:33:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DcyDb10s2z3CkL for ; Sat, 13 Feb 2021 04:33:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1650D10CF3 for ; Sat, 13 Feb 2021 04:33:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D4Xpkw041521 for ; Sat, 13 Feb 2021 04:33:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D4XpO0041520 for fs@FreeBSD.org; Sat, 13 Feb 2021 04:33:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 04:33: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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 04:33:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #23 from Cy Schubert --- Next data point: The sample script only produces an error on a newly formatted filesystem. If newfs is performed followed by mksnap_ffs, then a reboot followed by fstyp, there is no panic. The panic only occurs when the fstyp is executed after mksnap_ffs but prior to a reboot. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 04:53:07 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C19C753F115 for ; Sat, 13 Feb 2021 04:53:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcyfq4j15z3F5h for ; Sat, 13 Feb 2021 04:53:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9F6AB53F21B; Sat, 13 Feb 2021 04:53:07 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F2F653EEB4 for ; Sat, 13 Feb 2021 04:53:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcyfq3xFHz3FDH for ; Sat, 13 Feb 2021 04:53:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7A28D10E52 for ; Sat, 13 Feb 2021 04:53:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D4r7aJ050673 for ; Sat, 13 Feb 2021 04:53:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D4r7Y1050672 for fs@FreeBSD.org; Sat, 13 Feb 2021 04:53:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 04:53:07 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 04:53:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #24 from Konstantin Belousov --- (In reply to Cy Schubert from comment #23) I think it is combination of the filesystem size and something that I do not currently quite understand in the ffs snapshot code that makes UFS_BALLOC() to return buffer of full block size, but only with the first page populated, instead of all 8 pages. The buffer should be pointed to by bp, and belongs to the vnode carrying the ip inode. So I want/need the data I asked for. Might be Kirk has an idea from the description above. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 04:56:46 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6DC7653F199 for ; Sat, 13 Feb 2021 04:56:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dcyl22Kklz3FDn for ; Sat, 13 Feb 2021 04:56:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 4E23353EEE6; Sat, 13 Feb 2021 04:56:46 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4DE9453EE70 for ; Sat, 13 Feb 2021 04:56:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dcyl21fKkz3FBk for ; Sat, 13 Feb 2021 04:56:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 28A1111505 for ; Sat, 13 Feb 2021 04:56:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D4ukjR051391 for ; Sat, 13 Feb 2021 04:56:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D4uke1051390 for fs@FreeBSD.org; Sat, 13 Feb 2021 04:56:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Sat, 13 Feb 2021 04:56:46 +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 Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 04:56:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #7 from Konstantin Belousov --- (In reply to Rick Macklem from comment #5) You mean, you trimmed the buffer itself? Could you please point out corresponding commits, the change that trimmed and the later revert? Can we keep the buffer alone, but stop returning too large result to usersp= ace. I.e. avoid zero entries. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 07:21:30 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E291543014 for ; Sat, 13 Feb 2021 07:21:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dd1y22TCkz3Nl6 for ; Sat, 13 Feb 2021 07:21:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 54DB4542C5C; Sat, 13 Feb 2021 07:21:30 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 549F2543013 for ; Sat, 13 Feb 2021 07:21:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dd1y21tvjz3NYn for ; Sat, 13 Feb 2021 07:21:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 342CD12E58 for ; Sat, 13 Feb 2021 07:21:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D7LUJ8028179 for ; Sat, 13 Feb 2021 07:21:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D7LUAQ028178 for fs@FreeBSD.org; Sat, 13 Feb 2021 07:21:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 07:21: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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 07:21:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #25 from Cy Schubert --- With -O0 -g. #12 0xffffffff8166a738 in ffs_read (ap=3D0xfffffe0087e5a598) at /opt/src/vm64/sys/ufs/ffs/ffs_vnops.c:789 789 error =3D vn_io_fault_pgmove(bp->b_pages, blkoffset, (kgdb) info args ap =3D 0xfffffe0087e5a598 (kgdb) info locals vp =3D 0xfffff8001cb0c1e8 ip =3D 0xfffff8000797f0a0 uio =3D 0xfffffe0087e5a728 fs =3D 0xfffffe0088551000 bp =3D 0xfffffe000132b480 lbn =3D 128 nextlbn =3D 129 bytesinfile =3D 17175707648 size =3D 32768 xfersize =3D 32768 blkoffset =3D 0 orig_resid =3D 16486400 bflag =3D 72 error =3D 0 ioflag =3D 0 seqcount =3D 0 (kgdb) p *fs $1 =3D {fs_firstfield =3D 0, fs_unused_1 =3D 0, fs_sblkno =3D 24, fs_cblkno= =3D 32, fs_iblkno =3D 40,=20 fs_dblkno =3D 5048, fs_old_cgoffset =3D 0, fs_old_cgmask =3D 0, fs_old_ti= me =3D 0, fs_old_size =3D 0,=20 fs_old_dsize =3D 0, fs_ncg =3D 27, fs_bsize =3D 32768, fs_fsize =3D 4096,= fs_frag =3D 8, fs_minfree =3D 8,=20 fs_old_rotdelay =3D 0, fs_old_rps =3D 0, fs_bmask =3D -32768, fs_fmask = =3D -4096, fs_bshift =3D 15,=20 fs_fshift =3D 12, fs_maxcontig =3D 32, fs_maxbpg =3D 4096, fs_fragshift = =3D 3, fs_fsbtodb =3D 3,=20 fs_sbsize =3D 4096, fs_spare1 =3D {0, 0}, fs_nindir =3D 4096, fs_inopb = =3D 128, fs_old_nspf =3D 0,=20 fs_optim =3D 0, fs_old_npsect =3D 0, fs_old_interleave =3D 0, fs_old_trac= kskew =3D 0, fs_id =3D {1613200563,=20 1688935920}, fs_old_csaddr =3D 0, fs_cssize =3D 4096, fs_cgsize =3D 327= 68, fs_spare2 =3D 0,=20 fs_old_nsect =3D 0, fs_old_spc =3D 0, fs_old_ncyl =3D 0, fs_old_cpg =3D 0= , fs_ipg =3D 80128,=20 fs_fpg =3D 160056, fs_old_cstotal =3D {cs_ndir =3D 0, cs_nbfree =3D 0, cs= _nifree =3D 0, cs_nffree =3D 0},=20 fs_fmod =3D 1 '\001', fs_clean =3D 0 '\000', fs_ronly =3D 0 '\000', fs_ol= d_flags =3D -128 '\200',=20 fs_fsmnt =3D "/mnt", '\000' , fs_volname =3D '\000' ,=20 fs_swuid =3D 0, fs_pad =3D 0, fs_cgrotor =3D 18, fs_ocsp =3D {0x0 },=20 fs_si =3D 0xfffff800042d7320, fs_old_cpc =3D 0, fs_maxbsize =3D 32768, fs= _unrefs =3D 0,=20 fs_providersize =3D 4194304, fs_metaspace =3D 6400, fs_sparecon64 =3D {0 = },=20 fs_sblockactualloc =3D 65536, fs_sblockloc =3D 65536, fs_cstotal =3D {cs_= ndir =3D 2, cs_nbfree =3D 507157,=20 cs_nifree =3D 2163451, cs_nffree =3D 21, cs_numclusters =3D 0, cs_spare= =3D {0, 0, 0}},=20 fs_time =3D 1613200585, fs_size =3D 4194304, fs_dsize =3D 4058631, fs_csa= ddr =3D 5048,=20 fs_pendingblocks =3D 0, fs_pendinginodes =3D 0, fs_snapinum =3D {4, 0 },=20 fs_avgfilesize =3D 16384, fs_avgfpdir =3D 64, fs_save_cgsize =3D 0, fs_mt= ime =3D 1613200569,=20 fs_sujfree =3D 0, fs_sparecon32 =3D {0 }, fs_ckhash =3D 2732082773, fs_metackhash =3D 7,=20 fs_flags =3D 512, fs_contigsumsize =3D 16, fs_maxsymlinklen =3D 120, fs_old_inodefmt =3D 0,=20 fs_maxfilesize =3D 2252349704110079, fs_qbmask =3D 32767, fs_qfmask =3D 4= 095, fs_state =3D 0,=20 fs_old_postblformat =3D 0, fs_old_nrpos =3D 0, fs_spare5 =3D {0, 0}, fs_m= agic =3D 424935705} (kgdb) p *ip $2 =3D {i_nextsnap =3D {tqe_next =3D 0x0, tqe_prev =3D 0xfffff80007220b10},= i_vnode =3D 0xfffff8001cb0c1e8,=20 i_ump =3D 0xfffff800063a0800, i_dquot =3D {0x0, 0x0}, i_un =3D {dirhash = =3D 0x0, snapblklist =3D 0x0},=20 dinode_u =3D {din1 =3D 0xfffff80006521600, din2 =3D 0xfffff80006521600}, = i_number =3D 4, i_flag =3D 1024,=20 i_effnlink =3D 1, i_count =3D 0, i_endoff =3D 0, i_diroff =3D 0, i_offset= =3D 0, i_nextclustercg =3D -1,=20 i_ea_area =3D 0x0, i_ea_len =3D 0, i_ea_error =3D 0, i_ea_refs =3D 0, i_s= ize =3D 17179901952,=20 i_gen =3D 466217878, i_flags =3D 2097152, i_uid =3D 0, i_gid =3D 5, i_mod= e =3D 33056, i_nlink =3D 1} (kgdb) p *bp $3 =3D {b_bufobj =3D 0xfffff8001cb0c2d0, b_bcount =3D 32768, b_caller1 =3D = 0x0,=20 b_data =3D 0xfffffe00450d4000 ,=20 b_error =3D 0, b_iocmd =3D 1, b_ioflags =3D 16, b_iooffset =3D 4194304, b= _resid =3D 0, b_iodone =3D 0x0,=20 b_ckhashcalc =3D 0x0, b_ckhash =3D 0, b_blkno =3D 8192, b_offset =3D 4194= 304, b_bobufs =3D { tqe_next =3D 0xfffffe0001320480, tqe_prev =3D 0xfffffe000132ba60}, b_vf= lags =3D 0,=20 b_qindex =3D 0 '\000', b_domain =3D 0 '\000', b_subqueue =3D 65535, b_fla= gs =3D 805306912, b_xflags =3D 2,=20 b_lock =3D {lock_object =3D {lo_name =3D 0xffffffff81b9a2a3 "bufwait", lo= _flags =3D 645070848,=20 lo_data =3D 0, lo_witness =3D 0xfffff8001fd6b580}, lk_lock =3D 18446741876973481472,=20 lk_exslpfail =3D 0, lk_timo =3D 0, lk_pri =3D 96}, b_bufsize =3D 32768, b_runningbufspace =3D 0,=20 b_kvasize =3D 0, b_dirtyoff =3D 0, b_dirtyend =3D 0,=20 b_kvabase =3D 0xfffffe00450d4000 ,=20 b_lblkno =3D 128, b_vp =3D 0xfffff8001cb0c1e8, b_rcred =3D 0x0, b_wcred = =3D 0x0, {b_freelist =3D { tqe_next =3D 0xffffffffffffffff, tqe_prev =3D 0xffffffffffffffff}, { b_pgiodone =3D 0xffffffffffffffff, b_pgbefore =3D -1, b_pgafter =3D -= 1}}, b_cluster =3D { cluster_head =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, cluster_entry = =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}}, b_npages =3D 8, b_dep =3D {lh_first =3D 0x0}, b_f= sprivate1 =3D 0x0,=20 b_fsprivate2 =3D 0x0, b_fsprivate3 =3D 0x0, b_io_tracking =3D {0xffffffff= 81af1ffc "getblkx",=20 0xffffffff81a62d1e "g_vfs_strategy", 0xffffffff81af0ca8 "g_io_request",= =20 0xffffffff81b81378 "g_io_check", 0xffffffff81ad975d "g_disk_start",=20 0xffffffff81aaa544 "biodone", 0xffffffff81b990e4 "g_io_deliver", 0xffffffff81aaa544 "biodone",=20 0xffffffff81adac85 "bufdone", 0x0 }, b_io_tcnt =3D 9,= =20 b_pages =3D 0xfffffe000132b6c0} (kgdb) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 09:11:49 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED29254642D for ; Sat, 13 Feb 2021 09:11:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dd4PK61qBz3l4Y for ; Sat, 13 Feb 2021 09:11:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CEA74546709; Sat, 13 Feb 2021 09:11:49 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CE67D54642C for ; Sat, 13 Feb 2021 09:11:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dd4PK5MYfz3l9Y for ; Sat, 13 Feb 2021 09:11:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A97BC1498D for ; Sat, 13 Feb 2021 09:11:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D9Bna0088530 for ; Sat, 13 Feb 2021 09:11:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D9BnHU088529 for fs@FreeBSD.org; Sat, 13 Feb 2021 09:11:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 09:11:49 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 09:11:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #26 from Harald Schmalzbauer --- (In reply to Cy Schubert from comment #23) Side note to the reboot-healing: Ever since OpenZFS import, destroying snapshots without rebooting after creation doesn't work anymore. A reboot = is required in order to be able to destroy OpenZFS snapshots. I'm aware that (Open)ZFS and ffs snapshots are completely different things,= but maybe this ffs-snapshot fix revealed a upper layer bug, which also causes t= he strange (Open)ZFS snapshot behaviour - most likely not, but wanted to menti= on.=20 Will file a different PR for the OpenZFS snapshot later...=20 Thanks for all your attention! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 09:19:22 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3249A5468B3 for ; Sat, 13 Feb 2021 09:19:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dd4Z20Xyxz3ll6 for ; Sat, 13 Feb 2021 09:19:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 12AAF5468B2; Sat, 13 Feb 2021 09:19:22 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 127545467E6 for ; Sat, 13 Feb 2021 09:19:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dd4Z174X8z3lZ6 for ; Sat, 13 Feb 2021 09:19:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E6301145D4 for ; Sat, 13 Feb 2021 09:19:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D9JLEM090366 for ; Sat, 13 Feb 2021 09:19:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D9JLHV090365 for fs@FreeBSD.org; Sat, 13 Feb 2021 09:19:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 09:19:22 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 09:19:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #27 from Konstantin Belousov --- (In reply to Cy Schubert from comment #25) This is not what I expected. But still, please show p bp->b_pages[0] ... p bp->b_pages[7] --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 09:45:08 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 13DB1547169 for ; Sat, 13 Feb 2021 09:45:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dd57l6xJYz3nFB for ; Sat, 13 Feb 2021 09:45:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id EAD4B547168; Sat, 13 Feb 2021 09:45:07 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA9AE5471BB for ; Sat, 13 Feb 2021 09:45:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dd57l4ycTz3nN6 for ; Sat, 13 Feb 2021 09:45:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9D6F3150D3 for ; Sat, 13 Feb 2021 09:45:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11D9j7nc006008 for ; Sat, 13 Feb 2021 09:45:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11D9j7bU006007 for fs@FreeBSD.org; Sat, 13 Feb 2021 09:45:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 09:45:07 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 09:45:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #28 from Konstantin Belousov --- I also want to see td->td_ma and td->td_ma_cnt. It would be useful to show td->td_ma[0] ... td->td_ma[td->td_ma_cnt - 1] as well. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 15:04:31 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 81C5252F794 for ; Sat, 13 Feb 2021 15:04:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdDDH34NHz4d6x for ; Sat, 13 Feb 2021 15:04:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6787552F4EA; Sat, 13 Feb 2021 15:04:31 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 674EA52F4E9 for ; Sat, 13 Feb 2021 15:04:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdDDH2RBGz4dBY for ; Sat, 13 Feb 2021 15:04:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 46C68191E3 for ; Sat, 13 Feb 2021 15:04:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DF4Vnv078299 for ; Sat, 13 Feb 2021 15:04:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DF4VD3078298 for fs@FreeBSD.org; Sat, 13 Feb 2021 15:04:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 15:04:31 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 15:04:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #29 from Cy Schubert --- (In reply to Harald Schmalzbauer from comment #26) Two points: 1. Please don't confuse one problem with another. ZFS snapshots is a totally different problem and should be a different PR. 2. I have no such problem with ZFS snapshots on 14-CURRENT. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 15:08:34 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BA0CC52F9EF for ; Sat, 13 Feb 2021 15:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdDJy4kQdz4dGS for ; Sat, 13 Feb 2021 15:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A02AA52F7D3; Sat, 13 Feb 2021 15:08:34 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9FEA152F834 for ; Sat, 13 Feb 2021 15:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdDJy44Xfz4dCv for ; Sat, 13 Feb 2021 15:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7F93319509 for ; Sat, 13 Feb 2021 15:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DF8Y3d079179 for ; Sat, 13 Feb 2021 15:08:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DF8YDO079178 for fs@FreeBSD.org; Sat, 13 Feb 2021 15:08:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 15:08: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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 15:08:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #30 from Cy Schubert --- (In reply to Konstantin Belousov from comment #27) Since building with -O0 -g, the panic now occurs in the bcopy() two stateme= nts before the reported panic. Again at frame 12: (kgdb) frame 12 #12 0xffffffff8166a738 in ffs_read (ap=3D0xfffffe0087e5a598) at /opt/src/vm64/sys/ufs/ffs/ffs_vnops.c:789 789 error =3D vn_io_fault_pgmove(bp->b_pages, blkoffset, (kgdb) p bp->b_pages[0] Cannot access memory at address 0xfffffdfff7529e58 (kgdb) p bp->b_pages[1] Cannot access memory at address 0xfffffdfff7529e60 (kgdb) p bp->b_pages[2] Cannot access memory at address 0xfffffdfff7529e68 (kgdb) p bp->b_pages[3] Cannot access memory at address 0xfffffdfff7529e70 (kgdb) p bp->b_pages[4] Cannot access memory at address 0xfffffdfff7529e78 (kgdb) p bp->b_pages[5] Cannot access memory at address 0xfffffdfff7529e80 (kgdb) p bp->b_pages[6] Cannot access memory at address 0xfffffdfff7529e88 (kgdb) p bp->b_pages[7] Cannot access memory at address 0xfffffdfff7529e90 (kgdb) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 15:16:54 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9C97C52FF02 for ; Sat, 13 Feb 2021 15:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdDVZ3h59z4dhJ for ; Sat, 13 Feb 2021 15:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 7BCB152FBCB; Sat, 13 Feb 2021 15:16:54 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A64C52FD88 for ; Sat, 13 Feb 2021 15:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdDVZ2kfwz4dn7 for ; Sat, 13 Feb 2021 15:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4C4731934A for ; Sat, 13 Feb 2021 15:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DFGsTq083474 for ; Sat, 13 Feb 2021 15:16:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DFGsCn083473 for fs@FreeBSD.org; Sat, 13 Feb 2021 15:16:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 15:16:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 15:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #31 from Cy Schubert --- (In reply to Konstantin Belousov from comment #28) Also at frame 12: (kgdb) down #11 0xffffffff812edca4 in vn_io_fault_pgmove (ma=3D0xfffffe000132b6c0, offs= et=3D0, xfersize=3D32768,=20 uio=3D0xfffffe0087e5a728) at /opt/src/vm64/sys/kern/vfs_vnops.c:1513 1513 pmap_cop (kgdb) p td->td_ma_cnt $3 =3D 4025 (kgdb) set $end=3Dtd->td_ma_cnt-1 (kgdb) set $i=3D0 (kgdb) while ($i<$end) >p td->td_ma[$i] >set $i=3D$i+1 >end $4 =3D (struct vm_page *) 0xfffffe0087e529f0 $5 =3D (struct vm_page *) 0xffffffff81207cc9 $6 =3D (struct vm_page *) 0xfffff8001fd65700 $7 =3D (struct vm_page *) 0xfffff8001fd6b580 $8 =3D (struct vm_page *) 0xfffffe0087e52a20 $9 =3D (struct vm_page *) 0x32010178eb $10 =3D (struct vm_page *) 0x30c00000000002e $11 =3D (struct vm_page *) 0x330101edbd $12 =3D (struct vm_page *) 0x104000100000032 $13 =3D (struct vm_page *) 0x350101edbd $14 =3D (struct vm_page *) 0x30c00010000002e $15 =3D (struct vm_page *) 0xffffffff81a9edbd $16 =3D (struct vm_page *) 0x11fd65900 $17 =3D (struct vm_page *) 0xfffff8001fd65a80 $18 =3D (struct vm_page *) 0xfffff8001fd65700 $19 =3D (struct vm_page *) 0x181207cc9 $20 =3D (struct vm_page *) 0xfffffe0087e52a70 $21 =3D (struct vm_page *) 0xffffffff81207cc9 $22 =3D (struct vm_page *) 0xfffff8001fd65a80 $23 =3D (struct vm_page *) 0xfffff8001fd65700 $24 =3D (struct vm_page *) 0xfffffe0087e52aa0 $25 =3D (struct vm_page *) 0xffffffff812078eb $26 =3D (struct vm_page *) 0x0 $27 =3D (struct vm_page *) 0xfffff8001fd65a80 $28 =3D (struct vm_page *) 0xfffff8001fd65700 $29 =3D (struct vm_page *) 0x100000000 $30 =3D (struct vm_page *) 0xfffffe0087e52e10 $31 =3D (struct vm_page *) 0xffffffff81206941 $32 =3D (struct vm_page *) 0xfffff800045b8200 $33 =3D (struct vm_page *) 0x0 $34 =3D (struct vm_page *) 0x4d887e52ae0 $35 =3D (struct vm_page *) 0xffffffff81aaa07a $36 =3D (struct vm_page *) 0x900000000 $37 =3D (struct vm_page *) 0xfffffe008853a700 $38 =3D (struct vm_page *) 0xfffffe0087e52b50 $39 =3D (struct vm_page *) 0xffffffff8111b784 <__mtx_assert+260> $40 =3D (struct vm_page *) 0xfffffe0087e52b10 $41 =3D (struct vm_page *) 0xfffffe008853a700 $42 =3D (struct vm_page *) 0x286 $43 =3D (struct vm_page *) 0x3201010286 $44 =3D (struct vm_page *) 0x104fe0000000058 $45 =3D (struct vm_page *) 0xffffffff81a9edbd $46 =3D (struct vm_page *) 0x10000002e $47 =3D (struct vm_page *) 0xfffff8001fd65900 $48 =3D (struct vm_page *) 0xfffff8001fd66c00 $49 =3D (struct vm_page *) 0x101015780 $50 =3D (struct vm_page *) 0xfffffe0087e52b60 $51 =3D (struct vm_page *) 0xffffffff81207cc9 $52 =3D (struct vm_page *) 0xfffff8001fd65900 $53 =3D (struct vm_page *) 0xfffff8001fd66c00 $54 =3D (struct vm_page *) 0xfffffe0087e52b90 $55 =3D (struct vm_page *) 0xffffffff812078eb $56 =3D (struct vm_page *) 0x0 $57 =3D (struct vm_page *) 0xfffff8001fd65900 $58 =3D (struct vm_page *) 0xfffff8001fd66c00 $59 =3D (struct vm_page *) 0x100000000 $60 =3D (struct vm_page *) 0xfffffe0087e52f00 $61 =3D (struct vm_page *) 0xffffffff81206941 --Type for more, q to quit, c to continue without paging--c $62 =3D (struct vm_page *) 0x0 $63 =3D (struct vm_page *) 0xfffff8001fd66300 $64 =3D (struct vm_page *) 0xfffff8001fd66c00 $65 =3D (struct vm_page *) 0x100000000 $66 =3D (struct vm_page *) 0xfffffe0087e52f30 $67 =3D (struct vm_page *) 0xffffffff81206941 $68 =3D (struct vm_page *) 0x4 $69 =3D (struct vm_page *) 0xfffffe008853a700 $70 =3D (struct vm_page *) 0x286 $71 =3D (struct vm_page *) 0x286 $72 =3D (struct vm_page *) 0xfffffe0087e52c10 $73 =3D (struct vm_page *) 0xffffffff81208f05 $74 =3D (struct vm_page *) 0x100013287e52c78 $75 =3D (struct vm_page *) 0xfffffe008853a700 $76 =3D (struct vm_page *) 0xfffffe0087e52f80 $77 =3D (struct vm_page *) 0xffffffff8120642b $78 =3D (struct vm_page *) 0xfffffe0087e52c40 $79 =3D (struct vm_page *) 0xffffffff81208f05 $80 =3D (struct vm_page *) 0xffffffff8275d850 $81 =3D (struct vm_page *) 0x286 $82 =3D (struct vm_page *) 0xfffffe0087e52d30 $83 =3D (struct vm_page *) 0xffffffff81208e5b $84 =3D (struct vm_page *) 0xfffffe0087e52d50 $85 =3D (struct vm_page *) 0x570101a700 $86 =3D (struct vm_page *) 0x104f8000000002e $87 =3D (struct vm_page *) 0xffffffff81a9edbd $88 =3D (struct vm_page *) 0x187e52fe0 $89 =3D (struct vm_page *) 0xfffff8001fd66b80 $90 =3D (struct vm_page *) 0xfffff8001fd65700 $91 =3D (struct vm_page *) 0x4d0101d858 $92 =3D (struct vm_page *) 0x30cfe000000002e $93 =3D (struct vm_page *) 0xffffffff81a9edbd $94 =3D (struct vm_page *) 0x11fd66b80 $95 =3D (struct vm_page *) 0xfffffe008853a700 $96 =3D (struct vm_page *) 0xfffffe0087e53020 $97 =3D (struct vm_page *) 0xffffffff8120642b $98 =3D (struct vm_page *) 0xfffffe0087e52ce0 $99 =3D (struct vm_page *) 0xffffffff81207cc9 $100 =3D (struct vm_page *) 0xfffff8001fd66680 $101 =3D (struct vm_page *) 0xfffff8001fd65700 $102 =3D (struct vm_page *) 0xfffffe0087e52d10 $103 =3D (struct vm_page *) 0xffffffff812078eb $104 =3D (struct vm_page *) 0x0 $105 =3D (struct vm_page *) 0xfffffe008853a700 $106 =3D (struct vm_page *) 0xfffffe0087e53070 $107 =3D (struct vm_page *) 0xffffffff8120642b $108 =3D (struct vm_page *) 0xfffffe0087e53080 $109 =3D (struct vm_page *) 0xffffffff81206941 $110 =3D (struct vm_page *) 0x30c00020000002e $111 =3D (struct vm_page *) 0xffffffff81a9edbd $112 =3D (struct vm_page *) 0x18275d850 $113 =3D (struct vm_page *) 0xfffff8001fd66680 $114 =3D (struct vm_page *) 0xfffff8001fd65700 $115 =3D (struct vm_page *) 0x181a9edbd $116 =3D (struct vm_page *) 0xfffffe0087e52d70 $117 =3D (struct vm_page *) 0xffffffff81207cc9 $118 =3D (struct vm_page *) 0xfffff8001fd66680 $119 =3D (struct vm_page *) 0xfffff8001fd65700 $120 =3D (struct vm_page *) 0xfffffe0087e52da0 $121 =3D (struct vm_page *) 0xffffffff812078eb $122 =3D (struct vm_page *) 0x0 $123 =3D (struct vm_page *) 0xfffff8001fd66680 $124 =3D (struct vm_page *) 0xfffff8001fd65700 $125 =3D (struct vm_page *) 0x4d01010000 $126 =3D (struct vm_page *) 0x104fe0000000032 $127 =3D (struct vm_page *) 0xffffffff81a9edbd $128 =3D (struct vm_page *) 0x187e52de0 $129 =3D (struct vm_page *) 0xfffff8001fd66680 $130 =3D (struct vm_page *) 0xfffff8001fd65900 $131 =3D (struct vm_page *) 0x11fd65900 $132 =3D (struct vm_page *) 0xfffffe0087e52df0 $133 =3D (struct vm_page *) 0xffffffff81207cc9 $134 =3D (struct vm_page *) 0xfffff8001fd66680 $135 =3D (struct vm_page *) 0xfffff8001fd65900 $136 =3D (struct vm_page *) 0xfffffe0087e52e20 $137 =3D (struct vm_page *) 0xffffffff812078eb $138 =3D (struct vm_page *) 0x0 $139 =3D (struct vm_page *) 0xfffff8001fd66680 $140 =3D (struct vm_page *) 0xfffff8001fd65900 $141 =3D (struct vm_page *) 0x100000000 $142 =3D (struct vm_page *) 0xfffffe0087e53190 $143 =3D (struct vm_page *) 0xffffffff81206941 $144 =3D (struct vm_page *) 0xfffffe0087e52e50 $145 =3D (struct vm_page *) 0xfffffe008853a700 $146 =3D (struct vm_page *) 0xfffff8001fd66c00 $147 =3D (struct vm_page *) 0x4d0101a700 $148 =3D (struct vm_page *) 0x30cfe000000002f $149 =3D (struct vm_page *) 0xffffffff81a9edbd $150 =3D (struct vm_page *) 0x18275d858 $151 =3D (struct vm_page *) 0xfffff8001fd66680 $152 =3D (struct vm_page *) 0xfffff8001fd65780 $153 =3D (struct vm_page *) 0x182814ac0 $154 =3D (struct vm_page *) 0xfffffe0087e52ea0 $155 =3D (struct vm_page *) 0xffffffff81207cc9 $156 =3D (struct vm_page *) 0xfffff8001fd66680 $157 =3D (struct vm_page *) 0xfffff8001fd65780 $158 =3D (struct vm_page *) 0xfffffe0087e52ed0 $159 =3D (struct vm_page *) 0xffffffff812078eb $160 =3D (struct vm_page *) 0x0 $161 =3D (struct vm_page *) 0xfffff8001fd66680 $162 =3D (struct vm_page *) 0xfffff8001fd65780 $163 =3D (struct vm_page *) 0x100000000 $164 =3D (struct vm_page *) 0xfffffe0087e53240 $165 =3D (struct vm_page *) 0xffffffff81206941 $166 =3D (struct vm_page *) 0xfffffe0087e52f10 $167 =3D (struct vm_page *) 0xffffffff812078eb $168 =3D (struct vm_page *) 0x0 $169 =3D (struct vm_page *) 0xfffff8001fd65a00 $170 =3D (struct vm_page *) 0xfffff8001fd65780 $171 =3D (struct vm_page *) 0x100000000 $172 =3D (struct vm_page *) 0xfffffe0087e53280 $173 =3D (struct vm_page *) 0xffffffff81206941 $174 =3D (struct vm_page *) 0x30cfe000000002f $175 =3D (struct vm_page *) 0xffffffff81a9edbd $176 =3D (struct vm_page *) 0x187e532a0 $177 =3D (struct vm_page *) 0xfffff8001fd66680 $178 =3D (struct vm_page *) 0xfffff8001fd65780 $179 =3D (struct vm_page *) 0x187e52f60 $180 =3D (struct vm_page *) 0xfffffe0087e52f70 $181 =3D (struct vm_page *) 0xffffffff81207cc9 $182 =3D (struct vm_page *) 0xfffff8001fd66680 $183 =3D (struct vm_page *) 0xfffff8001fd65780 $184 =3D (struct vm_page *) 0xfffffe0087e52fa0 $185 =3D (struct vm_page *) 0xffffffff812078eb $186 =3D (struct vm_page *) 0x0 $187 =3D (struct vm_page *) 0xfffff8001fd66680 $188 =3D (struct vm_page *) 0xfffff8001fd65780 $189 =3D (struct vm_page *) 0x100000000 $190 =3D (struct vm_page *) 0xfffffe0087e53310 $191 =3D (struct vm_page *) 0xffffffff81206941 $192 =3D (struct vm_page *) 0x30c1b540000002e $193 =3D (struct vm_page *) 0xffffffff81a9edbd $194 =3D (struct vm_page *) 0x18853a700 $195 =3D (struct vm_page *) 0xfffff8001fd65900 $196 =3D (struct vm_page *) 0xfffff8001fd65700 $197 =3D (struct vm_page *) 0x330101a700 $198 =3D (struct vm_page *) 0x30cfe000000002f $199 =3D (struct vm_page *) 0xffffffff81a9edbd $200 =3D (struct vm_page *) 0x11fd65900 $201 =3D (struct vm_page *) 0xfffff8001fd65980 $202 =3D (struct vm_page *) 0xfffff8001fd65780 $203 =3D (struct vm_page *) 0x181a9edbd $204 =3D (struct vm_page *) 0xfffffe0087e53030 $205 =3D (struct vm_page *) 0xffffffff81207cc9 $206 =3D (struct vm_page *) 0xfffff8001fd65980 $207 =3D (struct vm_page *) 0xfffff8001fd65780 $208 =3D (struct vm_page *) 0xfffffe0087e53060 $209 =3D (struct vm_page *) 0xffffffff812078eb $210 =3D (struct vm_page *) 0x0 $211 =3D (struct vm_page *) 0xfffff8001fd65980 $212 =3D (struct vm_page *) 0xfffff8001fd65780 $213 =3D (struct vm_page *) 0x3301010000 $214 =3D (struct vm_page *) 0x30cfe000000002f $215 =3D (struct vm_page *) 0xffffffff81a9edbd $216 =3D (struct vm_page *) 0x187e530a0 $217 =3D (struct vm_page *) 0xfffff8001fd65980 $218 =3D (struct vm_page *) 0xfffff8001fd65780 $219 =3D (struct vm_page *) 0x181a9edbd $220 =3D (struct vm_page *) 0xfffffe0087e530b0 $221 =3D (struct vm_page *) 0xffffffff81207cc9 $222 =3D (struct vm_page *) 0xfffff8001fd65980 $223 =3D (struct vm_page *) 0xfffff8001fd65780 $224 =3D (struct vm_page *) 0xfffffe0087e530e0 $225 =3D (struct vm_page *) 0xffffffff812078eb $226 =3D (struct vm_page *) 0x0 $227 =3D (struct vm_page *) 0xfffff8001fd65980 $228 =3D (struct vm_page *) 0xfffff8001fd65780 $229 =3D (struct vm_page *) 0xfffffe008853a700 $230 =3D (struct vm_page *) 0xfffffe0087e53450 $231 =3D (struct vm_page *) 0xffffffff8120642b $232 =3D (struct vm_page *) 0xfffff8001fd65780 $233 =3D (struct vm_page *) 0x100000000 $234 =3D (struct vm_page *) 0xfffffe0087e53470 $235 =3D (struct vm_page *) 0xffffffff81206941 $236 =3D (struct vm_page *) 0x286 $237 =3D (struct vm_page *) 0x0 $238 =3D (struct vm_page *) 0x4d887e53140 $239 =3D (struct vm_page *) 0xffffffff81aaa07a $240 =3D (struct vm_page *) 0x906073000 $241 =3D (struct vm_page *) 0xfffffe008853a700 $242 =3D (struct vm_page *) 0xfffffe0087e531b0 $243 =3D (struct vm_page *) 0xffffffff8111b784 <__mtx_assert+260> $244 =3D (struct vm_page *) 0xfffffe0087e53170 $245 =3D (struct vm_page *) 0xfffffe008853a700 $246 =3D (struct vm_page *) 0x286 $247 =3D (struct vm_page *) 0x2b01010286 $248 =3D (struct vm_page *) 0x30cfe00000001c7 $249 =3D (struct vm_page *) 0xffffffff81a9edbd $250 =3D (struct vm_page *) 0x100000000 $251 =3D (struct vm_page *) 0xfa01015580 $252 =3D (struct vm_page *) 0x104f80000000009 $253 =3D (struct vm_page *) 0xffffffff81a9edbd $254 =3D (struct vm_page *) 0x187e531c0 $255 =3D (struct vm_page *) 0xfffff8001fd6bd00 $256 =3D (struct vm_page *) 0xfffff8001fd64480 $257 =3D (struct vm_page *) 0x11fd72380 $258 =3D (struct vm_page *) 0xfffffe0087e531e0 $259 =3D (struct vm_page *) 0xffffffff81207cc9 $260 =3D (struct vm_page *) 0xfffff8001fd6bd00 $261 =3D (struct vm_page *) 0xfffff8001fd64480 $262 =3D (struct vm_page *) 0xfffffe0087e53210 $263 =3D (struct vm_page *) 0xffffffff812078eb $264 =3D (struct vm_page *) 0x0 $265 =3D (struct vm_page *) 0xfffff8001fd6bd00 $266 =3D (struct vm_page *) 0xfffff8001fd64480 $267 =3D (struct vm_page *) 0x100000000 $268 =3D (struct vm_page *) 0xfffffe0087e53580 $269 =3D (struct vm_page *) 0xffffffff81206941 $270 =3D (struct vm_page *) 0xfffffe0087e53590 $271 =3D (struct vm_page *) 0xffffffff81206b52 $272 =3D (struct vm_page *) 0x0 $273 =3D (struct vm_page *) 0x0 $274 =3D (struct vm_page *) 0x0 $275 =3D (struct vm_page *) 0xfffffe008853a700 $276 =3D (struct vm_page *) 0xfffffe0087e535c0 $277 =3D (struct vm_page *) 0xffffffff8120642b $278 =3D (struct vm_page *) 0x28271e4b8 $279 =3D (struct vm_page *) 0xffffffff8275d888 $280 =3D (struct vm_page *) 0xffffffff8275d850 $281 =3D (struct vm_page *) 0xfffffe0001002b40 $282 =3D (struct vm_page *) 0xffffffff8275d850 $283 =3D (struct vm_page *) 0xffffffff8275d888 $284 =3D (struct vm_page *) 0xfffffe0087e53390 $285 =3D (struct vm_page *) 0xffffffff81209bb9 $286 =3D (struct vm_page *) 0x0 $287 =3D (struct vm_page *) 0xfffffe008853a700 $288 =3D (struct vm_page *) 0xfffffe0087e53620 $289 =3D (struct vm_page *) 0xffffffff8120642b $290 =3D (struct vm_page *) 0xfffffe0087e532f0 $291 =3D (struct vm_page *) 0xffffffff816a3821 $292 =3D (struct vm_page *) 0xfffff8000793e000 $293 =3D (struct vm_page *) 0xfffff8000793ef30 $294 =3D (struct vm_page *) 0x100000286 $295 =3D (struct vm_page *) 0xffffffff8275d870 $296 =3D (struct vm_page *) 0xffffffff8275d850 $297 =3D (struct vm_page *) 0xfffffe0001003940 $298 =3D (struct vm_page *) 0xffffffff8275d850 $299 =3D (struct vm_page *) 0x0 $300 =3D (struct vm_page *) 0x4d887e53410 $301 =3D (struct vm_page *) 0xffffffff81aaa07a $302 =3D (struct vm_page *) 0x90361ffd8 $303 =3D (struct vm_page *) 0xfffffe008853a700 $304 =3D (struct vm_page *) 0xfffffe0087e533a0 $305 =3D (struct vm_page *) 0xffffffff8111b784 <__mtx_assert+260> $306 =3D (struct vm_page *) 0xfffffe0087e53360 $307 =3D (struct vm_page *) 0xfffffe008853a700 $308 =3D (struct vm_page *) 0x286 $309 =3D (struct vm_page *) 0x286 $310 =3D (struct vm_page *) 0xfffffe0087e53380 $311 =3D (struct vm_page *) 0xffffffff818ba265 $312 =3D (struct vm_page *) 0x0 $313 =3D (struct vm_page *) 0x286 $314 =3D (struct vm_page *) 0xfffffe0087e533a0 $315 =3D (struct vm_page *) 0xfa0101a1c2 $316 =3D (struct vm_page *) 0x104000000000009 $317 =3D (struct vm_page *) 0xffffffff81a9edbd $318 =3D (struct vm_page *) 0x187e53410 $319 =3D (struct vm_page *) 0xfffff8001fd6bd00 $320 =3D (struct vm_page *) 0xfffff8001fd64480 $321 =3D (struct vm_page *) 0x100000000 $322 =3D (struct vm_page *) 0xfffffe0087e533e0 $323 =3D (struct vm_page *) 0xffffffff81207cc9 $324 =3D (struct vm_page *) 0xfffff8001fd6bd00 $325 =3D (struct vm_page *) 0xfffff8001fd64480 $326 =3D (struct vm_page *) 0xfffffe0087e53410 $327 =3D (struct vm_page *) 0xffffffff812078eb $328 =3D (struct vm_page *) 0x0 $329 =3D (struct vm_page *) 0xfffff8001fd6bd00 $330 =3D (struct vm_page *) 0xfffff8001fd64480 $331 =3D (struct vm_page *) 0x100000000 $332 =3D (struct vm_page *) 0xfffffe0087e53780 $333 =3D (struct vm_page *) 0xffffffff81206941 $334 =3D (struct vm_page *) 0xfffffe0087e53790 $335 =3D (struct vm_page *) 0xffffffff8120642b $336 =3D (struct vm_page *) 0x282 $337 =3D (struct vm_page *) 0xfffffe008853a700 $338 =3D (struct vm_page *) 0xffffffff8231b6f8 $339 =3D (struct vm_page *) 0xffffffff8275d858 $340 =3D (struct vm_page *) 0xffffffff8275d850 $341 =3D (struct vm_page *) 0xfffffe008853a850 $342 =3D (struct vm_page *) 0x4f987e53480 $343 =3D (struct vm_page *) 0xffffffff81ba5917 $344 =3D (struct vm_page *) 0x286 $345 =3D (struct vm_page *) 0x286 $346 =3D (struct vm_page *) 0xfffffe0087e534a0 $347 =3D (struct vm_page *) 0xffffffff81208f05 $348 =3D (struct vm_page *) 0xfffffe0087e534b0 $349 =3D (struct vm_page *) 0x286 $350 =3D (struct vm_page *) 0xfffffe0087e53590 $351 =3D (struct vm_page *) 0xffffffff81208e5b $352 =3D (struct vm_page *) 0x100000000000000 $353 =3D (struct vm_page *) 0xfffffe008853a700 $354 =3D (struct vm_page *) 0xfffff8001fd64480 $355 =3D (struct vm_page *) 0xfffff8001fd6bd00 $356 =3D (struct vm_page *) 0xfffffe0087e53580 $357 =3D (struct vm_page *) 0xffffffff823204e8 $358 =3D (struct vm_page *) 0xffffffff8275d870 $359 =3D (struct vm_page *) 0xffffffff8275d858 $360 =3D (struct vm_page *) 0x0 $361 =3D (struct vm_page *) 0xfffff80015b1eca8 $362 =3D (struct vm_page *) 0xffffffff8275d850 $363 =3D (struct vm_page *) 0x0 $364 =3D (struct vm_page *) 0xfffffe0087e53580 $365 =3D (struct vm_page *) 0xfffffe008853a700 $366 =3D (struct vm_page *) 0xfffffe0087e53590 $367 =3D (struct vm_page *) 0xffffffff8111b784 <__mtx_assert+260> $368 =3D (struct vm_page *) 0xfffff80015b15b78 $369 =3D (struct vm_page *) 0xfffffe008853a700 $370 =3D (struct vm_page *) 0x4 $371 =3D (struct vm_page *) 0xfffffe008853a700 $372 =3D (struct vm_page *) 0xfffff80015b1eca8 $373 =3D (struct vm_page *) 0xfffffe008853a700 $374 =3D (struct vm_page *) 0xfffffe0087e535d0 $375 =3D (struct vm_page *) 0xffffffff82e1f530 $376 =3D (struct vm_page *) 0x2387e535e0 $377 =3D (struct vm_page *) 0xffffffff82e1f530 $378 =3D (struct vm_page *) 0xfffffe0087e535d0 $379 =3D (struct vm_page *) 0xffffffff83010300 $380 =3D (struct vm_page *) 0xffffffff83010384 $381 =3D (struct vm_page *) 0xffffffff83010384 $382 =3D (struct vm_page *) 0xffffffff83010300 $383 =3D (struct vm_page *) 0xffffffff83010300 $384 =3D (struct vm_page *) 0xfffffe0088542120 $385 =3D (struct vm_page *) 0xfffffe008853ae00 $386 =3D (struct vm_page *) 0xffffffff83010384 $387 =3D (struct vm_page *) 0xffffffff83010300 $388 =3D (struct vm_page *) 0xcc9d0e7c19f5a875 $389 =3D (struct vm_page *) 0xfffffe0087e53628 $390 =3D (struct vm_page *) 0xffffffff818d9d7d $391 =3D (struct vm_page *) 0x1cb1a000 $392 =3D (struct vm_page *) 0x1cb19000 $393 =3D (struct vm_page *) 0x82e1f0d8 $394 =3D (struct vm_page *) 0xfffffe0088542120 $395 =3D (struct vm_page *) 0xfffffe008853ae00 $396 =3D (struct vm_page *) 0x1cb1a000 $397 =3D (struct vm_page *) 0x1 $398 =3D (struct vm_page *) 0xffffffff826b3df0 $399 =3D (struct vm_page *) 0xfffffe0087e53698 $400 =3D (struct vm_page *) 0xffffffff818d9f3e $401 =3D (struct vm_page *) 0x1 $402 =3D (struct vm_page *) 0xfffffe0088542170 $403 =3D (struct vm_page *) 0x0 $404 =3D (struct vm_page *) 0x0 $405 =3D (struct vm_page *) 0xffffffff826b3da0 $406 =3D (struct vm_page *) 0xffffffff826b3da0 $407 =3D (struct vm_page *) 0x82e1f0c0 $408 =3D (struct vm_page *) 0xfffffe0088542120 $409 =3D (struct vm_page *) 0xffffffff826b3da0 $410 =3D (struct vm_page *) 0xfffffe008853ae00 $411 =3D (struct vm_page *) 0xffffffff826b3da0 $412 =3D (struct vm_page *) 0xcc9d0e7c19f5a875 $413 =3D (struct vm_page *) 0xfffffe0087e53770 $414 =3D (struct vm_page *) 0xffffffff818a6d61 $415 =3D (struct vm_page *) 0xffffffff811a488f $416 =3D (struct vm_page *) 0x87e53720 $417 =3D (struct vm_page *) 0xffffffff00000b68 $418 =3D (struct vm_page *) 0xffffffff82e1f0c0 $419 =3D (struct vm_page *) 0xffffffff82e1f0c0 $420 =3D (struct vm_page *) 0xffffffff82e1f0c0 $421 =3D (struct vm_page *) 0xffffffff8271e4a0 $422 =3D (struct vm_page *) 0xffffffff8271e4b8 $423 =3D (struct vm_page *) 0xffffffff8271e4a0 $424 =3D (struct vm_page *) 0xffffffff8271e4b8 $425 =3D (struct vm_page *) 0xffffffff8271e4a0 $426 =3D (struct vm_page *) 0x8b687e53770 $427 =3D (struct vm_page *) 0xffffffff81aaa07a $428 =3D (struct vm_page *) 0x15b15670 $429 =3D (struct vm_page *) 0xffffffff8271e4b8 $430 =3D (struct vm_page *) 0xffffffff82e1f0c0 $431 =3D (struct vm_page *) 0xfffffe008853ae00 $432 =3D (struct vm_page *) 0xfffffe008853a700 $433 =3D (struct vm_page *) 0xffffffff82e1f0c0 $434 =3D (struct vm_page *) 0xfffffe0087e53770 $435 =3D (struct vm_page *) 0xffffffff81209011 $436 =3D (struct vm_page *) 0x3b18853a920 $437 =3D (struct vm_page *) 0xffffffff81a6f73a $438 =3D (struct vm_page *) 0xffffffff8275d850 $439 =3D (struct vm_page *) 0xcc9d0e7c19f5a875 $440 =3D (struct vm_page *) 0xfffffe0087e53820 $441 =3D (struct vm_page *) 0xffffffff8117b79c $442 =3D (struct vm_page *) 0x0 $443 =3D (struct vm_page *) 0xffffffff81a6f73a $444 =3D (struct vm_page *) 0x39f00000000 $445 =3D (struct vm_page *) 0xffffffff818ba17d $446 =3D (struct vm_page *) 0x286 $447 =3D (struct vm_page *) 0xfffffe008853a700 $448 =3D (struct vm_page *) 0x7fff267f7fff267f $449 =3D (struct vm_page *) 0x1f62434487 $450 =3D (struct vm_page *) 0x1f62434487 $451 =3D (struct vm_page *) 0x1f62302e93 $452 =3D (struct vm_page *) 0x1f62302e93 $453 =3D (struct vm_page *) 0x1f62302e93 $454 =3D (struct vm_page *) 0xfffff80015b03c00 $455 =3D (struct vm_page *) 0xfffff80015b15670 $456 =3D (struct vm_page *) 0xfffff80015b15688 $457 =3D (struct vm_page *) 0xfffff80015b15528 $458 =3D (struct vm_page *) 0x2aa15b15828 $459 =3D (struct vm_page *) 0xfffffe008853a700 $460 =3D (struct vm_page *) 0x1f62434487 $461 =3D (struct vm_page *) 0x1315f4 $462 =3D (struct vm_page *) 0xfffffe0087e53a70 $463 =3D (struct vm_page *) 0xffffffff810da63d $464 =3D (struct vm_page *) 0x1542b10 $465 =3D (struct vm_page *) 0x0 $466 =3D (struct vm_page *) 0xfffff80015b03c00 $467 =3D (struct vm_page *) 0x0 $468 =3D (struct vm_page *) 0x0 $469 =3D (struct vm_page *) 0x0 $470 =3D (struct vm_page *) 0x27400000000 $471 =3D (struct vm_page *) 0xffffffff00000000 $472 =3D (struct vm_page *) 0x0 $473 =3D (struct vm_page *) 0x8853a700 $474 =3D (struct vm_page *) 0x0 $475 =3D (struct vm_page *) 0xffffffff81a86df6 $476 =3D (struct vm_page *) 0x26000000000 $477 =3D (struct vm_page *) 0x23e00000000 $478 =3D (struct vm_page *) 0x0 $479 =3D (struct vm_page *) 0xffffffff81b45f39 $480 =3D (struct vm_page *) 0x0 $481 =3D (struct vm_page *) 0x2 $482 =3D (struct vm_page *) 0x0 $483 =3D (struct vm_page *) 0xfffffe008853a700 $484 =3D (struct vm_page *) 0xfffffe0087e53960 $485 =3D (struct vm_page *) 0xffffffff811f56c5 $486 =3D (struct vm_page *) 0x282 $487 =3D (struct vm_page *) 0xfffffe008853a700 $488 =3D (struct vm_page *) 0xfffffe0087e53900 $489 =3D (struct vm_page *) 0x19f5a875 $490 =3D (struct vm_page *) 0xffffffff81a86df6 $491 =3D (struct vm_page *) 0x0 $492 =3D (struct vm_page *) 0xffffffff81a86df6 $493 =3D (struct vm_page *) 0xffffebb8 $494 =3D (struct vm_page *) 0x0 $495 =3D (struct vm_page *) 0xfff80015b15528 $496 =3D (struct vm_page *) 0x0 $497 =3D (struct vm_page *) 0x0 $498 =3D (struct vm_page *) 0xfffffe000000016b $499 =3D (struct vm_page *) 0xfffff80015b15528 $500 =3D (struct vm_page *) 0xfffffe0087e53c00 $501 =3D (struct vm_page *) 0xfffffe008853a700 $502 =3D (struct vm_page *) 0xfffffe0087e53bd0 $503 =3D (struct vm_page *) 0x818ed218 $504 =3D (struct vm_page *) 0x15b $505 =3D (struct vm_page *) 0x155 $506 =3D (struct vm_page *) 0xffffffff81a86df6 $507 =3D (struct vm_page *) 0x8853a700 $508 =3D (struct vm_page *) 0x155 $509 =3D (struct vm_page *) 0x155 $510 =3D (struct vm_page *) 0x0 $511 =3D (struct vm_page *) 0xffffffff81b45f39 $512 =3D (struct vm_page *) 0x0 $513 =3D (struct vm_page *) 0x0 $514 =3D (struct vm_page *) 0x12c00000000 $515 =3D (struct vm_page *) 0xfffffe008853a700 $516 =3D (struct vm_page *) 0xfffffe0087e53a60 $517 =3D (struct vm_page *) 0x0 $518 =3D (struct vm_page *) 0x1fffe0087e53aa0 $519 =3D (struct vm_page *) 0xffffffff810daa97 $520 =3D (struct vm_page *) 0x100 $521 =3D (struct vm_page *) 0xfffff80015b15530 $522 =3D (struct vm_page *) 0xfffff80015b15528 $523 =3D (struct vm_page *) 0xfffff8000606ac00 $524 =3D (struct vm_page *) 0x0 $525 =3D (struct vm_page *) 0xfffff80004067b80 $526 =3D (struct vm_page *) 0x100000000 $527 =3D (struct vm_page *) 0x388540958 $528 =3D (struct vm_page *) 0xfffffe0088540860 $529 =3D (struct vm_page *) 0x88540860 $530 =3D (struct vm_page *) 0xfffffe0087e53a80 $531 =3D (struct vm_page *) 0x0 $532 =3D (struct vm_page *) 0xfffffe0087e53c00 $533 =3D (struct vm_page *) 0xfffff80015b15528 $534 =3D (struct vm_page *) 0x0 $535 =3D (struct vm_page *) 0xfffffe008853a700 $536 =3D (struct vm_page *) 0xfffffe0087e53aa0 $537 =3D (struct vm_page *) 0xffffffff810d8d86 $538 =3D (struct vm_page *) 0xfffffe0087e53c00 $539 =3D (struct vm_page *) 0x15b15528 $540 =3D (struct vm_page *) 0xfffffe008853aae8 $541 =3D (struct vm_page *) 0xfffffe008853a700 $542 =3D (struct vm_page *) 0xfffffe0087e53b40 $543 =3D (struct vm_page *) 0xffffffff818ef396 $544 =3D (struct vm_page *) 0x202 $545 =3D (struct vm_page *) 0x100000000000202 $546 =3D (struct vm_page *) 0x0 $547 =3D (struct vm_page *) 0xffffffff818ba265 $548 =3D (struct vm_page *) 0x0 $549 =3D (struct vm_page *) 0x202 $550 =3D (struct vm_page *) 0xfefe000000000c $551 =3D (struct vm_page *) 0x15b15528 $552 =3D (struct vm_page *) 0x0 $553 =3D (struct vm_page *) 0x80035ef0d $554 =3D (struct vm_page *) 0xfffff80015b15528 $555 =3D (struct vm_page *) 0xfffffe008853a700 $556 =3D (struct vm_page *) 0x100000000000000 $557 =3D (struct vm_page *) 0x0 $558 =3D (struct vm_page *) 0xffffffff82310c50 $559 =3D (struct vm_page *) 0xfffffe008853aad8 $560 =3D (struct vm_page *) 0xfffff80015b15528 $561 =3D (struct vm_page *) 0xfffffe008853a700 $562 =3D (struct vm_page *) 0xfffffe0087e53bf0 $563 =3D (struct vm_page *) 0xffffffff818eea9b $564 =3D (struct vm_page *) 0x43882e1f0c0 $565 =3D (struct vm_page *) 0xffffffff81b51bb6 $566 =3D (struct vm_page *) 0xfffffe0087e53cc0 $567 =3D (struct vm_page *) 0xffffffff82202798 $568 =3D (struct vm_page *) 0xfffffe0087e53bf0 $569 =3D (struct vm_page *) 0xffffffff810e2ad9 $570 =3D (struct vm_page *) 0xfffffe0087e53c00 $571 =3D (struct vm_page *) 0x42500000000 $572 =3D (struct vm_page *) 0xcc9d0e7c19f5a875 $573 =3D (struct vm_page *) 0x0 $574 =3D (struct vm_page *) 0xcc9d0e7c19f5a875 $575 =3D (struct vm_page *) 0x3 $576 =3D (struct vm_page *) 0x7fffffffec98 $577 =3D (struct vm_page *) 0x0 $578 =3D (struct vm_page *) 0x7fffffffec78 $579 =3D (struct vm_page *) 0x3 $580 =3D (struct vm_page *) 0xfffffe0087e53bf0 $581 =3D (struct vm_page *) 0xffffffff818ee188 $582 =3D (struct vm_page *) 0x0 $583 =3D (struct vm_page *) 0xfffffe008853a700 $584 =3D (struct vm_page *) 0x7fffffffeba0 $585 =3D (struct vm_page *) 0xffffffff818ade0e $586 =3D (struct vm_page *) 0x0 $587 =3D (struct vm_page *) 0x1 $588 =3D (struct vm_page *) 0x2251ff $589 =3D (struct vm_page *) 0x21a032 $590 =3D (struct vm_page *) 0xffffffffffffdf70 $591 =3D (struct vm_page *) 0x80024f120 $592 =3D (struct vm_page *) 0x1 $593 =3D (struct vm_page *) 0x7fffffffeb18 $594 =3D (struct vm_page *) 0x7fffffffeba0 $595 =3D (struct vm_page *) 0x1 $596 =3D (struct vm_page *) 0x1 $597 =3D (struct vm_page *) 0x7fffffffec98 $598 =3D (struct vm_page *) 0x0 $599 =3D (struct vm_page *) 0x0 $600 =3D (struct vm_page *) 0x3 $601 =3D (struct vm_page *) 0x1b00130000000c $602 =3D (struct vm_page *) 0x7fffffffebb8 $603 =3D (struct vm_page *) 0x3b003b00000001 $604 =3D (struct vm_page *) 0x2 $605 =3D (struct vm_page *) 0x8003e13fa $606 =3D (struct vm_page *) 0x43 $607 =3D (struct vm_page *) 0x206 $608 =3D (struct vm_page *) 0x7fffffffeaa8 $609 =3D (struct vm_page *) 0x3b $610 =3D (struct vm_page *) 0x37f $611 =3D (struct vm_page *) 0x0 $612 =3D (struct vm_page *) 0x0 $613 =3D (struct vm_page *) 0xffff00001f80 $614 =3D (struct vm_page *) 0x0 $615 =3D (struct vm_page *) 0x0 $616 =3D (struct vm_page *) 0x0 $617 =3D (struct vm_page *) 0x0 $618 =3D (struct vm_page *) 0x0 $619 =3D (struct vm_page *) 0x0 $620 =3D (struct vm_page *) 0x0 $621 =3D (struct vm_page *) 0x0 $622 =3D (struct vm_page *) 0x0 $623 =3D (struct vm_page *) 0x0 $624 =3D (struct vm_page *) 0x0 $625 =3D (struct vm_page *) 0x0 $626 =3D (struct vm_page *) 0x0 $627 =3D (struct vm_page *) 0x0 $628 =3D (struct vm_page *) 0x0 $629 =3D (struct vm_page *) 0x0 $630 =3D (struct vm_page *) 0x0 $631 =3D (struct vm_page *) 0x0 $632 =3D (struct vm_page *) 0x7fffffffd8ef $633 =3D (struct vm_page *) 0x7fffffffd8ee $634 =3D (struct vm_page *) 0x0 $635 =3D (struct vm_page *) 0x0 $636 =3D (struct vm_page *) 0x0 $637 =3D (struct vm_page *) 0x0 $638 =3D (struct vm_page *) 0xc0c0c0c0 $639 =3D (struct vm_page *) 0x0 $640 =3D (struct vm_page *) 0x0 $641 =3D (struct vm_page *) 0x0 $642 =3D (struct vm_page *) 0x0 $643 =3D (struct vm_page *) 0x0 $644 =3D (struct vm_page *) 0x0 $645 =3D (struct vm_page *) 0x0 $646 =3D (struct vm_page *) 0x0 $647 =3D (struct vm_page *) 0x0 $648 =3D (struct vm_page *) 0x0 $649 =3D (struct vm_page *) 0x0 $650 =3D (struct vm_page *) 0x0 $651 =3D (struct vm_page *) 0x0 $652 =3D (struct vm_page *) 0x0 $653 =3D (struct vm_page *) 0x0 $654 =3D (struct vm_page *) 0x0 $655 =3D (struct vm_page *) 0x0 $656 =3D (struct vm_page *) 0x0 $657 =3D (struct vm_page *) 0x0 $658 =3D (struct vm_page *) 0x0 $659 =3D (struct vm_page *) 0x0 $660 =3D (struct vm_page *) 0x0 $661 =3D (struct vm_page *) 0x0 $662 =3D (struct vm_page *) 0x0 $663 =3D (struct vm_page *) 0x0 $664 =3D (struct vm_page *) 0x0 $665 =3D (struct vm_page *) 0x0 $666 =3D (struct vm_page *) 0x0 $667 =3D (struct vm_page *) 0x0 $668 =3D (struct vm_page *) 0x0 $669 =3D (struct vm_page *) 0x0 $670 =3D (struct vm_page *) 0x0 $671 =3D (struct vm_page *) 0x0 $672 =3D (struct vm_page *) 0x0 $673 =3D (struct vm_page *) 0x0 $674 =3D (struct vm_page *) 0x3 $675 =3D (struct vm_page *) 0x0 $676 =3D (struct vm_page *) 0x0 $677 =3D (struct vm_page *) 0x0 $678 =3D (struct vm_page *) 0x0 $679 =3D (struct vm_page *) 0x0 $680 =3D (struct vm_page *) 0x0 $681 =3D (struct vm_page *) 0x0 $682 =3D (struct vm_page *) 0x0 $683 =3D (struct vm_page *) 0x0 $684 =3D (struct vm_page *) 0x0 $685 =3D (struct vm_page *) 0x0 $686 =3D (struct vm_page *) 0x0 $687 =3D (struct vm_page *) 0x0 $688 =3D (struct vm_page *) 0x0 $689 =3D (struct vm_page *) 0x0 $690 =3D (struct vm_page *) 0x0 $691 =3D (struct vm_page *) 0x0 $692 =3D (struct vm_page *) 0x0 $693 =3D (struct vm_page *) 0x0 $694 =3D (struct vm_page *) 0x0 $695 =3D (struct vm_page *) 0x0 $696 =3D (struct vm_page *) 0x0 $697 =3D (struct vm_page *) 0x0 $698 =3D (struct vm_page *) 0x0 $699 =3D (struct vm_page *) 0x0 $700 =3D (struct vm_page *) 0x0 $701 =3D (struct vm_page *) 0x0 $702 =3D (struct vm_page *) 0x0 $703 =3D (struct vm_page *) 0x0 $704 =3D (struct vm_page *) 0x0 $705 =3D (struct vm_page *) 0x0 $706 =3D (struct vm_page *) 0x0 $707 =3D (struct vm_page *) 0x0 $708 =3D (struct vm_page *) 0x0 $709 =3D (struct vm_page *) 0x0 $710 =3D (struct vm_page *) 0x0 $711 =3D (struct vm_page *) 0x0 $712 =3D (struct vm_page *) 0x0 $713 =3D (struct vm_page *) 0x0 Cannot access memory at address 0xfffffe0087e54000 (kgdb) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 16:10:57 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CF3CD530EBB for ; Sat, 13 Feb 2021 16:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdFhx58gLz4ghD for ; Sat, 13 Feb 2021 16:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id AEB0C531200; Sat, 13 Feb 2021 16:10:57 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE6F1530EB9 for ; Sat, 13 Feb 2021 16:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdFhx4Q3jz4ghC for ; Sat, 13 Feb 2021 16:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 884EE19F54 for ; Sat, 13 Feb 2021 16:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DGAvri010446 for ; Sat, 13 Feb 2021 16:10:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DGAvWU010445 for fs@FreeBSD.org; Sat, 13 Feb 2021 16:10:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Sat, 13 Feb 2021 16:10: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 Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 16:10:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #8 from Rick Macklem --- r283330, reverted by r291117 I believe the caching story was roughly (assuming an 8K block size). - NFS VOP_READDIR() would read the first block at logical offset 0 and then a read-ahead at logical offset 8K. --> If the readdir reply only filled 6K, it would set the b_bcount to 6K When getdents() or read() did the next read, it would ask for a block at 6K and the read-ahead block in the cache would be missed. Now if someone (I'll not volunteering right now) were to add code above the VOP_READDIR() in getdirentries()/getdents() that skipped over the dirents with d_fileno =3D=3D 0 but still advanced f_offset past them, then I think that would be ok (no change in NFS behaviour). Also, you could get rid of the similar code in ufs_readdir(), which would be nice for the NFS server, since the behaviour of ufs_readdir() would return to "subsequent directory offsets do not change when entrie(s) are deleted. --> With this property, doing readdir(), unlink() in a loop works over NFS. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 16:51:19 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3115A531DE0 for ; Sat, 13 Feb 2021 16:51:19 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdGbW0kn4z4jkJ; Sat, 13 Feb 2021 16:51:19 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f0ef900f88d5cfe3b39a25c.dip0.t-ipconnect.de [IPv6:2003:cd:5f0e:f900:f88d:5cfe:3b39:a25c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9EA72F63B; Sat, 13 Feb 2021 16:51:18 +0000 (UTC) (envelope-from se@freebsd.org) To: Karl Denninger , freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> From: Stefan Esser Subject: Re: Reading a corrupted file on ZFS Message-ID: <225e4da5-79ec-a57a-90e5-35989e6484d5@freebsd.org> Date: Sat, 13 Feb 2021 17:51:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uHKKMmNIODgVzi0bd1D7Ukk51iUrmlja9" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 16:51:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uHKKMmNIODgVzi0bd1D7Ukk51iUrmlja9 Content-Type: multipart/mixed; boundary="UPHcda4tR7pyN952ebyyHhwS9xDi1jfGI"; protected-headers="v1" From: Stefan Esser To: Karl Denninger , freebsd-fs@freebsd.org Message-ID: <225e4da5-79ec-a57a-90e5-35989e6484d5@freebsd.org> Subject: Re: Reading a corrupted file on ZFS References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> In-Reply-To: <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> --UPHcda4tR7pyN952ebyyHhwS9xDi1jfGI Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Am 12.02.21 um 20:49 schrieb Karl Denninger: > On 2/12/2021 13:26, Artem Kuchin wrote: >> 12.02.2021 19:37, Karl Denninger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> On 2/12/2021 11:22, Artem Kuchin wrote: >>>> >>>> This is frustrating. why..why.. >>> >>> You created a synthetic situation that in the real world almost-never= =20 >>> exists (ONE byte modified in all copies in the same allocation block = >>> but all other data in that block is intact and recoverable.) >>> >> I could be 1 GB file with ZFS wisth block size of 1MB and with rotten = >> bits within the same 1MB of block on different disks. How i did it is = >> not important, life is unpredictable, i'm not trying to avoid=20 >> everything. The question is what to do when it happens. And currently = >> the answer is - nothing. >> > The answer to a problem that does not present itself statistically=20 > speaking in the real world is the last one you worry about.=C2=A0 Worry= about=20 > all the other ones and cover them first. True for some kinds of real world, false for others. I have a number of older 2 TB drives and use 2 of them to store DVB transport stream data, for later processing. They are not mirrored and the data format assumes that the transmission is not perfect. I have noticed that some of these files have been lost due to bad sectors, and while this would not be a problem on UFS, ZFS thinks I should not trust the file at all, despite 99,9999% of it being perfectly usable. (A fraction of the TS data is extracted from these files and stored as PS data on a ZFS RAID, where it will be safe and I never lost a file.) There are other applications that do not care for all data to be perfectly conserved (I know of some) and where using a mirrored setup configuration would just be a waste of money. Not everybody operates a data center with a large drive farm that holds data worth magnitudes more than the hardware cost (in which case the cost of redundancy is well justified). A solution could be to use UFS for files that should be readable (or recoverable with a tool) after single sector failures. But why should I have to mix UFS for such data with ZFS for the rest of the system (and I know you very well that these two do not mix too well if both are put under simultaneous high load). Therefore: There are valid reasons to not have redundancy and still not loose a large file of data for single bad block of a non-redundant (e.g striped for performance) ZPOOL/ZFS. Regards, STefan --UPHcda4tR7pyN952ebyyHhwS9xDi1jfGI-- --uHKKMmNIODgVzi0bd1D7Ukk51iUrmlja9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmAoA4IFAwAAAAAACgkQR+u171r99USa mgf/Yp8uDF4C8g33eRB0HuRjkOiY4rkgjPgY9xPdBi9WwnIfxfeJd9s4xTrmKlSdtEXaDukC0BZ/ K8oRZmtcAOo1XidluL5dP8BIJQzhewwxIv5JcFjQlcbNBEqxy7D4YYnzIEs1tebM60BajWkY1Y8M cS3GCvxVRAgmCLMWtUG+WIV0bsrv3TosJTRWMfugaEjUzn5lbvtKDWk6YEAMj2NMtqaF6zWT+KsX PClwuyiX9waAzR2YAQMMywJnQWrzZt0Ape5gW0ZdyUno1Y6asCe8ApsHSxNED2z3O2lGh/6h5Iml Ipp9BehNJ9LLPNqlhRPGOrMlJ15E4/UThJyfTVKm0g== =SjJL -----END PGP SIGNATURE----- --uHKKMmNIODgVzi0bd1D7Ukk51iUrmlja9-- From owner-freebsd-fs@freebsd.org Sat Feb 13 16:54:10 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BAC4D532041 for ; Sat, 13 Feb 2021 16:54:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdGfp4pmHz4kFp; Sat, 13 Feb 2021 16:54:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id E03EC2110B2; Sat, 13 Feb 2021 11:54:01 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id E44791278FC; Sat, 13 Feb 2021 11:54:03 -0500 (EST) Subject: Re: Reading a corrupted file on ZFS To: Stefan Esser , freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> <225e4da5-79ec-a57a-90e5-35989e6484d5@freebsd.org> From: Karl Denninger Message-ID: <3aeb9d42-f69d-1f4c-b1f5-74dd4d28578c@denninger.net> Date: Sat, 13 Feb 2021 11:54:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <225e4da5-79ec-a57a-90e5-35989e6484d5@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040701040105020602070909" X-Rspamd-Queue-Id: 4DdGfp4pmHz4kFp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 16:54:10 -0000 This is a cryptographically signed message in MIME format. --------------ms040701040105020602070909 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2/13/2021 11:51, Stefan Esser wrote: > Am 12.02.21 um 20:49 schrieb Karl Denninger: >> On 2/12/2021 13:26, Artem Kuchin wrote: >>> 12.02.2021 19:37, Karl Denninger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> On 2/12/2021 11:22, Artem Kuchin wrote: >>>>> >>>>> This is frustrating. why..why.. >>>> >>>> You created a synthetic situation that in the real world=20 >>>> almost-never exists (ONE byte modified in all copies in the same=20 >>>> allocation block but all other data in that block is intact and=20 >>>> recoverable.) >>>> >>> I could be 1 GB file with ZFS wisth block size of 1MB and with=20 >>> rotten bits within the same 1MB of block on different disks. How i=20 >>> did it is not important, life is unpredictable, i'm not trying to=20 >>> avoid everything. The question is what to do when it happens. And=20 >>> currently the answer is - nothing. >>> >> The answer to a problem that does not present itself statistically=20 >> speaking in the real world is the last one you worry about.=C2=A0 Worr= y=20 >> about all the other ones and cover them first. > > True for some kinds of real world, false for others. > > I have a number of older 2 TB drives and use 2 of them to store > DVB transport stream data, for later processing. They are not > mirrored and the data format assumes that the transmission is not > perfect. I have noticed that some of these files have been lost > due to bad sectors, and while this would not be a problem on UFS, > ZFS thinks I should not trust the file at all, despite 99,9999% > of it being perfectly usable. (A fraction of the TS data is > extracted from these files and stored as PS data on a ZFS RAID, > where it will be safe and I never lost a file.) > > There are other applications that do not care for all data to be > perfectly conserved (I know of some) and where using a mirrored > setup configuration would just be a waste of money. > > Not everybody operates a data center with a large drive farm that > holds data worth magnitudes more than the hardware cost (in which > case the cost of redundancy is well justified). > > > A solution could be to use UFS for files that should be readable > (or recoverable with a tool) after single sector failures. > > But why should I have to mix UFS for such data with ZFS for the > rest of the system (and I know you very well that these two do > not mix too well if both are put under simultaneous high load). > > > Therefore: There are valid reasons to not have redundancy and > still not loose a large file of data for single bad block of a > non-redundant (e.g striped for performance) ZPOOL/ZFS. > > Regards, STefan > That's what the patch does -- it allows you to read the file but the=20 known-bad blocks will be "blanked" (marked that it's no good.) Perhaps that sysctl should be part of the system generally, but you CAN=20 do it the hard way with zdb even without it although it's a SERIOUS pain = in the neck. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040701040105020602070909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjEzMTY1NDAz WjBPBgkqhkiG9w0BCQQxQgRA1Vr62JgMY+6TXXlIQ08qPBhl6LMdzwHH38Q4snzWzk1Rtu9p 3E0EO9g8lsbhtB4Dy6OIw8JBQYvfSxrXYXaIETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCHInT2Ax4YnnXxzJxtexLnI4dsFCsjSIaPbwuFnjSfRB2DnNQmeuAawt+3vJWn5yqU APWz6I15EJfoTa5T1eQ9y+Kv9NWP8dtmlRB8YEdx5JDcLo91KDQR3vwtFkvsoS42T6iymIsm 2yuYLGuaf+qiaBRUA9WcU+7NMAc6sKy7Hsa7IO0lc3wUdVj/x5VDG+L83vHZ+0FELZnDncjV OwUqpSqMXapBXQ6Pu+2jO6kRp8pV4hYnUbgm2iezoNWytHZGyhxwCfvVJOzk3rEyzgemAlfo gBdTVheYue3CuHyfJm7Xw0pzvXvwGFrnI5YA6OoqU0zFwJB/qvA+8fR4kHw5i3kLa/kxOyQM /t8RUhdoUijNxFXollQRDUDcbPvv9DztpJUCawI8L5XRAimkeslyrC1ePtOqjKPJBQ6gPjQ4 0hJ9djvRZYbFAP3/YEZk92sX6b3y5fMMpTqRvvH/TL4vlMYNs1OM9UTdsR9FFtYztDSiVtAt GPu9bRGni8XpowK+zqF+C5vR6CY69PDEXFazw0kAyH2UoFjxIndJospQ9qOSgwvhze8ZBpa+ ZWcUNJMj6Zk8k2TBvzejmoAqBVppwz2CZ6wuPc4Bn7MXDQW9fm9dt+gx+ou7yqbBeeW4gyy9 zznwCQ6PwHaAr2Bh9wFiDMoAVjo4yPD+ktjNAdubSAAAAAAAAA== --------------ms040701040105020602070909-- From owner-freebsd-fs@freebsd.org Sat Feb 13 17:38:17 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B2C08533A43 for ; Sat, 13 Feb 2021 17:38:17 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from smtp.simplesystems.org (smtp.simplesystems.org [65.66.246.90]) (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 4DdHdj3Yljz4nGd; Sat, 13 Feb 2021 17:38:17 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from scrappy.simplesystems.org (scrappy.simplesystems.org [65.66.246.73]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id 11DHcA4B001940; Sat, 13 Feb 2021 11:38:10 -0600 (CST) Date: Sat, 13 Feb 2021 11:38:10 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@scrappy.simplesystems.org To: Stefan Esser cc: freebsd-fs@freebsd.org Subject: Re: Reading a corrupted file on ZFS In-Reply-To: <225e4da5-79ec-a57a-90e5-35989e6484d5@freebsd.org> Message-ID: References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> <2f82f113-9ca1-99a9-a433-89e3ae5edcbe@denninger.net> <2bf4f69c-9d5d-5ff9-0daa-c87515437ca3@artem.ru> <5aa03138-1dc8-5a9c-1be6-d47ed22fc0cf@denninger.net> <225e4da5-79ec-a57a-90e5-35989e6484d5@freebsd.org> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Sat, 13 Feb 2021 11:38:10 -0600 (CST) X-Rspamd-Queue-Id: 4DdHdj3Yljz4nGd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 17:38:17 -0000 On Sat, 13 Feb 2021, Stefan Esser wrote: > > I have a number of older 2 TB drives and use 2 of them to store > DVB transport stream data, for later processing. They are not > mirrored and the data format assumes that the transmission is not > perfect. I have noticed that some of these files have been lost > due to bad sectors, and while this would not be a problem on UFS, > ZFS thinks I should not trust the file at all, despite 99,9999% > of it being perfectly usable. (A fraction of the TS data is > extracted from these files and stored as PS data on a ZFS RAID, > where it will be safe and I never lost a file.) If simple bad sectors is a problem for you on zfs, then try setting the the filesystem 'copies' property to a value higher than one before writing the file. This does use more space but does not require additional devices. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt From owner-freebsd-fs@freebsd.org Sat Feb 13 19:45:14 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E129538FB5 for ; Sat, 13 Feb 2021 19:45:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdLSB15Kqz3FKk for ; Sat, 13 Feb 2021 19:45:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 25644538FB4; Sat, 13 Feb 2021 19:45:14 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 252A6538FB3 for ; Sat, 13 Feb 2021 19:45:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdLSB0QCfz3FQS for ; Sat, 13 Feb 2021 19:45:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EFBE31CA68 for ; Sat, 13 Feb 2021 19:45:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DJjDpn020637 for ; Sat, 13 Feb 2021 19:45:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DJjDtU020636 for fs@FreeBSD.org; Sat, 13 Feb 2021 19:45:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Sat, 13 Feb 2021 19:45:14 +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 Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 19:45:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #9 from Konstantin Belousov --- (In reply to Rick Macklem from comment #8) I think these are different things. In NFS nfsrpc_readdirplus(), there is special code just to fill the incoming buffer with empty dirents (now I found it). I mean the bloc near the end, under the comment 'Add extra empty records to any remaining DIRBLKSIZ chunks.' There is nothing comparable to that in UFS. As I understand, you are complaining about UFS code which skips empty dirents (by checking d_ino =3D=3D 0 and ju= mping to nextentry). But there is no code to fabricate dummy dirents at the end to fill up to the end of uio. Why this code is needed for NFS? To fill the buffer, so that the situation you described with 6K/8K skew cannot occur? Also, I do not think that the code to skip empty dirents from UFS can be li= fted to VFS layer. Problem is that VOP_READDIR() has to do uiomove()s itself, so the skip must occur in VOP. Would it be useful if UFS know that ufs_readdir() is called by NFS server a= nd avoided skip? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 19:49:30 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EB9BE5390D3 for ; Sat, 13 Feb 2021 19:49:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdLY668kFz3FXf for ; Sat, 13 Feb 2021 19:49:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D352A53907A; Sat, 13 Feb 2021 19:49:30 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D31D3538FF4 for ; Sat, 13 Feb 2021 19:49:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdLY65Q6Fz3FXd for ; Sat, 13 Feb 2021 19:49:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id ACE641CF9F for ; Sat, 13 Feb 2021 19:49:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DJnU45021174 for ; Sat, 13 Feb 2021 19:49:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DJnUeH021173 for fs@FreeBSD.org; Sat, 13 Feb 2021 19:49:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Sat, 13 Feb 2021 19:49:31 +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: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 19:49:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #32 from Konstantin Belousov --- (In reply to Cy Schubert from comment #30) You do understand that this is not useful. I give up, unless somebody either provides the image where fstyp on the snap panics the system, or kernel.debug+vmcore (with vfs_vnops.c and ffs_vnops.c compiled with -O0). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 20:28:14 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 49D6153A29D for ; Sat, 13 Feb 2021 20:28:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdMPp1Rmdz3Ht9 for ; Sat, 13 Feb 2021 20:28:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2FC5F539FBF; Sat, 13 Feb 2021 20:28:14 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F8CA53A233 for ; Sat, 13 Feb 2021 20:28:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdMPp0ltJz3Ht8 for ; Sat, 13 Feb 2021 20:28:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0D57A1D90D for ; Sat, 13 Feb 2021 20:28:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DKSEZk042717 for ; Sat, 13 Feb 2021 20:28:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DKSDtv042716 for fs@FreeBSD.org; Sat, 13 Feb 2021 20:28:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Sat, 13 Feb 2021 20:28:14 +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 Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 20:28:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #10 from Konstantin Belousov --- (In reply to Konstantin Belousov from comment #9) Like this, untested. diff --git a/sys/ufs/ufs/ufs_vnops.c b/sys/ufs/ufs/ufs_vnops.c index 301c583291d1..bfdc16a1df72 100644 --- a/sys/ufs/ufs/ufs_vnops.c +++ b/sys/ufs/ufs/ufs_vnops.c @@ -2391,11 +2391,23 @@ ufs_readdir(ap) error =3D EIO; break; } - if (offset < startoffset || dp->d_ino =3D=3D 0) + if (offset < startoffset) goto nextentry; + + /* + * In case of NFS server calling us, do not + * skip empty entries, since this keeps + * offsets consistent. + */ + if (cookies =3D=3D NULL && dp->d_ino =3D=3D 0) + goto nextentry; + dstdp.d_fileno =3D dp->d_ino; dstdp.d_reclen =3D GENERIC_DIRSIZ(&dstdp); - bcopy(dp->d_name, dstdp.d_name, dstdp.d_namlen); + if (dp->d_ino =3D=3D 0) + bzero(dp->d_name, dstdp.d_namlen); + else + bcopy(dp->d_name, dstdp.d_name, dstdp.d_namlen); /* NOTE: d_off is the offset of the *next* entry. */ dstdp.d_off =3D offset + dp->d_reclen; dirent_terminate(&dstdp); --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Feb 13 23:08:32 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A57CA53EE8C for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdQym45l6z3jCd for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8CAD953EE8B; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C79653ECA7 for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdQym3WWkz3j01 for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 67B891F73C for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DN8W2P022990 for ; Sat, 13 Feb 2021 23:08:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DN8W4q022989 for fs@FreeBSD.org; Sat, 13 Feb 2021 23:08:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Sat, 13 Feb 2021 23:08:32 +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 Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 23:08:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #11 from Rick Macklem --- Ok, so now I see that stripping of d_ino =3D=3D 0 entries must be done below the VOP_READDIR(). When I did r283330 to get rid of the creation of d_ino =3D=3D 0 entries to fill up the block being filled in the buffer cache, I did not adjust uio_offset to indicate the offset of the next block. --> For my 6K/8K case, I could have advanced uio_offset by 8K even though it filled 6K into the buffer cache block. That might have made the caching work? I'll give that a try. --> It helps that read(2) is no longer expected to read directories. man getdirentries should be fixed for the d_off =3D=3D 0 case. I'll come up with a man page patch and stick it on phabricator, because filling in d_off needs some thought for NFS. There may be some cases where the server's directory offset cookie can be used. Ignore trying to revert the change done to UFS in r252438, since the stripping cannot be done above the VOP_READDIR(). Unless both UFS and ZFS had the property that removal of an entry in a directory does not change other directory offsets, it is not worth worrying about. --> It also implies that d_ino =3D=3D 0 dirents will be passed to user space which is not really intended now? At least that's my opinion. (And, yes, it was an aside and a separate issue.) --=20 You are receiving this mail because: You are the assignee for the bug.=