From owner-freebsd-fs@freebsd.org Sun Mar 3 21:01:49 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DA3F1519E8E for ; Sun, 3 Mar 2019 21:01:49 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B8CC46C09D for ; Sun, 3 Mar 2019 21:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7CBF41519E8B; Sun, 3 Mar 2019 21:01:48 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FA461519E8A for ; Sun, 3 Mar 2019 21:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A93B86C08F for ; Sun, 3 Mar 2019 21:01:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id DD26B3E72 for ; Sun, 3 Mar 2019 21:01:46 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x23L1kQL027697 for ; Sun, 3 Mar 2019 21:01:46 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x23L1kfC027685 for fs@FreeBSD.org; Sun, 3 Mar 2019 21:01:46 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201903032101.x23L1kfC027685@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, 3 Mar 2019 21:01:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 21:01:49 -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 4 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Mar 3 18:57:14 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D25881514A83 for ; Sun, 3 Mar 2019 18:57:13 +0000 (UTC) (envelope-from will@jagels.us) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A40D8EA78 for ; Sun, 3 Mar 2019 18:57:12 +0000 (UTC) (envelope-from will@jagels.us) Received: by mail-it1-x12d.google.com with SMTP id f186so3192160ita.0 for ; Sun, 03 Mar 2019 10:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jagels-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pf/j5uom0GmpgGll55ah8T7zbEMENfTT0uk++fBKTP4=; b=ijj0TxaWKFtWieAbQoob2PNTrjZ4OK4JZkwWqvej17qRiaupxKI9Po9UWZ3mJGAHIr tQM7U6CiInXIoddGYELwZlwZJHQwkuElWXOBYkehAblmbJazDh0TmBn2VWvEobqW3/VD B0IPZQaBW9f2hlTyHU5BA0OvCaHDmkmYX5NN2eWpF8vPddFMRb8WERc09Jq34sUZZZLh KCUsx6gYfd/dz1cjeQTP7ZLbNwxNENjmueWTEvwNU2KsftVnxkN1QXutAH0eS8FELCff S6CZpt9YD2ycAEqVEjvq47/FuTgzGmDCWtDcP8z00Z+pxz9fZeDUXSbzO4x5D+L5uwd+ bDgw== 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; bh=pf/j5uom0GmpgGll55ah8T7zbEMENfTT0uk++fBKTP4=; b=X2NpZfVJJr1+B6p740Ywn8hhTK/87ZMrgy/XfdMIhsh+edfKW27qCCQk1OD9Xhjxf9 ZXigjjAZva2eg9QjyHrJ4voCjpo6ggUp5A+oQUdX7U9uzcO4piHWLlKoGHExDqBbhZ49 7Y/d3o3DtQpmxWLwbCNchlXaQ0Ne1uxM1NdkVMYoh0wqv2RZi/oNqfUiDBwm4RN74pst gzvisLZjGudTgmPXemkxr577P/6dn4LrChsEwKulaE2DBtIzmz6jILmml1vBlbI5zFV3 ZgGoI2W+VyMmRokRMtqbsH3mit13lkq2lec0B4Lf+pr978pgRZPgWFt0nAg2uyXiMl7U vU5A== X-Gm-Message-State: APjAAAV2Iwn6aOXvJDWV/5vrXAt7HAjeKQcfz2RWUqvugxrIGWvpJy1B nE6COUrUYQQJWiGbZAYCj0s8HNanZPfRRMMvggdIqyK5RCZt7w== X-Google-Smtp-Source: APXvYqy0moZeBoybm1pmccpwnXXEyomEHhzVO/oJsepFxUzNtuuAuOZ4UNyicNxOIgYz+i1fbYS668KpM0b3Xur6Ez0= X-Received: by 2002:a24:7a85:: with SMTP id a127mr9247558itc.46.1551639431249; Sun, 03 Mar 2019 10:57:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: William Jagels Date: Sun, 3 Mar 2019 18:57:00 +0000 Message-ID: Subject: Re: Possible deadlock with nfsd To: freebsd-fs@freebsd.org X-Rspamd-Queue-Id: 1A40D8EA78 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=jagels-us.20150623.gappssmtp.com header.s=20150623 header.b=ijj0TxaW; dmarc=pass (policy=none) header.from=jagels.us; spf=pass (mx1.freebsd.org: domain of will@jagels.us designates 2607:f8b0:4864:20::12d as permitted sender) smtp.mailfrom=will@jagels.us X-Spamd-Result: default: False [-6.37 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[jagels-us.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.68)[ip: (-8.58), ipnet: 2607:f8b0::/32(-2.70), asn: 15169(-2.04), country: US(-0.07)]; DKIM_TRACE(0.00)[jagels-us.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[jagels.us,none]; RCVD_IN_DNSWL_NONE(0.00)[d.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; FORGED_SENDER(0.30)[william@jagels.us,will@jagels.us]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[william@jagels.us,will@jagels.us]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 18:57:14 -0000 Missed one part, I also apply these tunables after boot: sysctl vfs.zfs.top_maxinflight=128 sysctl vfs.zfs.delay_min_dirty_percent=96 sysctl vfs.zfs.vdev.write_gap_limit=16384 sysctl vfs.zfs.dirty_data_sync=12348030976 sysctl vfs.zfs.dirty_data_max=12884901888 On Sun, Mar 3, 2019 at 6:53 PM William Jagels wrote: > Hi, > > I've been running into something (4 or so occurrences) that locks up my > system and forces a hard reset. Generally it happens when something has > been writing a lot over nfs, though sometimes it's happened while I wasn't > around. I tried a few commands that do i/o, and they get blocked in > various states: > > (dd read file from pool) load: 0.37 cmd: dd 91214 [vq->vq_lock] 64.87r > 0.00u 0.01s 0% 2160k > (sync) load: 0.20 cmd: csh 92333 [buf_hash_table.ht_locks[i].ht_lock] > 5.58r 0.00u 0.00s 0% 4548k > (zfs unmount) load: 0.08 cmd: zfs 93685 [ds->ds_opening_lock] 4.69r 0.00u > 0.00s 0% 4060k > > I was able to capture some results of procstat -kk -a, those are attached. > > Other info: > # uname -a > FreeBSD freenas.jagels.us 11.2-STABLE FreeBSD 11.2-STABLE #0 > r325575+3b66a34f3aa(HEAD): Thu Feb 14 13:40:20 EST 2019 > root@nemesis.tn.ixsystems.com:/freenas-releng/freenas/_BE/objs/freenas-releng/freenas/_BE/os/sys/FreeNAS.amd64 > amd64 > > Motherboard: Gigabyte GA-7PESH2 (using the onboard LSI SAS controllers) > Cpu: 2x E5-2660 v2 HT disabled > Storage: 6x WD-80EMAZ 4x WD20EARX 1x SanDisk SDSSDA120G > 2x WDS500G2X0C-00L350 > > Attached dmidecode/sysctl information as well. I'll be happy to provide > additional information as needed. > > Thanks, > Will > From owner-freebsd-fs@freebsd.org Sun Mar 3 16:51:54 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A85D9151121C for ; Sun, 3 Mar 2019 16:51:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 34D948B48F for ; Sun, 3 Mar 2019 16:51:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EA5D2151121B; Sun, 3 Mar 2019 16:51:53 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D652A151121A for ; Sun, 3 Mar 2019 16:51:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D52E8B485 for ; Sun, 3 Mar 2019 16:51:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 9DF161878 for ; Sun, 3 Mar 2019 16:51:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x23GpqH7029121 for ; Sun, 3 Mar 2019 16:51:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x23GpqwK029120 for fs@FreeBSD.org; Sun, 3 Mar 2019 16:51: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 223491] fsck_ufs: Directory XXXX name not found Date: Sun, 03 Mar 2019 16:51:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: wosch@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_file_loc 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 16:51:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223491 Wolfram Schneider changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://reviews.freebsd.org | |/D19437 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Mar 4 22:08:35 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27AAB1524C47 for ; Mon, 4 Mar 2019 22:08:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ADA2E8B212 for ; Mon, 4 Mar 2019 22:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6C8CA1524C45; Mon, 4 Mar 2019 22:08:34 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59E701524C44 for ; Mon, 4 Mar 2019 22:08:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8D5C8B20B for ; Mon, 4 Mar 2019 22:08:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 34B6811DA1 for ; Mon, 4 Mar 2019 22:08:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x24M8XVO019122 for ; Mon, 4 Mar 2019 22:08:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x24M8XJi019121 for fs@FreeBSD.org; Mon, 4 Mar 2019 22:08:33 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 235775] [FUSE]: Reuse cached attributes, when available and valid Date: Mon, 04 Mar 2019 22:08: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 22:08:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235775 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: asomers Date: Mon Mar 4 22:07:34 UTC 2019 New revision: 344785 URL: https://svnweb.freebsd.org/changeset/base/344785 Log: fuse(4): add tests for CREATE, OPEN, READLINK, SETATTR and SYMLINK The new SETATTR tests deal with already-open files. PR: 235775 PR: 236231 Sponsored by: The FreeBSD Foundation Changes: projects/fuse2/tests/sys/fs/fuse/Makefile projects/fuse2/tests/sys/fs/fuse/create.cc projects/fuse2/tests/sys/fs/fuse/mockfs.hh projects/fuse2/tests/sys/fs/fuse/open.cc projects/fuse2/tests/sys/fs/fuse/readlink.cc projects/fuse2/tests/sys/fs/fuse/setattr.cc projects/fuse2/tests/sys/fs/fuse/symlink.cc --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Mar 4 23:15:40 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C50681526A3E for ; Mon, 4 Mar 2019 23:15:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 542FC8DA85 for ; Mon, 4 Mar 2019 23:15:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0ABAF1526A3B; Mon, 4 Mar 2019 23:15:40 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC9871526A3A for ; Mon, 4 Mar 2019 23:15:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A2B18DA83 for ; Mon, 4 Mar 2019 23:15:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 937BA12811 for ; Mon, 4 Mar 2019 23:15:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x24NFc91090346 for ; Mon, 4 Mar 2019 23:15:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x24NFcfw090345 for fs@FreeBSD.org; Mon, 4 Mar 2019 23:15:38 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 160790] [fusefs] [panic] VPUTX: negative ref count with FUSE Date: Mon, 04 Mar 2019 23:15:37 +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: 8.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 23:15:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D160790 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org CC| |asomers@FreeBSD.org --- Comment #7 from Pedro F. Giffuni --- Assign to fs (again) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Mar 4 23:36:45 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4629F152717D for ; Mon, 4 Mar 2019 23:36:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CC8A88E5DC for ; Mon, 4 Mar 2019 23:36:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8D009152717C; Mon, 4 Mar 2019 23:36:44 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A414152717B for ; Mon, 4 Mar 2019 23:36:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1418C8E5D8 for ; Mon, 4 Mar 2019 23:36:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5B01B12B05 for ; Mon, 4 Mar 2019 23:36:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x24NahOL029992 for ; Mon, 4 Mar 2019 23:36:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x24NahFx029991 for fs@FreeBSD.org; Mon, 4 Mar 2019 23:36: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 160790] [fusefs] [panic] VPUTX: negative ref count with FUSE Date: Mon, 04 Mar 2019 23:36:43 +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: 8.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not Enough Information X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 23:36:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D160790 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |Not Enough Information --- Comment #8 from Conrad Meyer --- Is this reproducible on head or recent FreeBSD? Can you provide a list of steps to encounter the panic from a vanilla freebsd installation? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Mar 5 09:26:57 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EC2715218C8 for ; Tue, 5 Mar 2019 09:26:57 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E15A889D5 for ; Tue, 5 Mar 2019 09:26:56 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ot1-f67.google.com with SMTP id n71so6838526ota.10 for ; Tue, 05 Mar 2019 01:26:56 -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 :content-transfer-encoding; bh=5BSfxPz+QpITUc5KvNJnkGhj9vSpRT1QD8014Q+8feQ=; b=htYyPQxOWRn1fLxjKmZhEcFDLrvb/jB4BigeYOr3u2vOlZRJvbhCLv3fKCZfZETeXq Ks3Dbg4kxDKXr3PSu/DZCqRz7yRztPyQ6/tNG1cUYHENhSmSfI1cA8iGaOHIw2C5fjyB hJVKFM/cEosjXkO2aeRc6sg7lWe2C+TVmw7erbtI3E51qQZk74nqeBCJsL/NVrPrcuyr GnNiPQQeNstuOej7YjZKJVcHapS+YQof7xrt8mPNiutMHuUNvKqu3CwdGGxKlP/pWObH PHOVljFIzUEDWcZnArhvpcdRMdj1nsM0NJmbdCudTBItMIU2p2YjiXbJSeKV8OgrIfIK QQpQ== X-Gm-Message-State: APjAAAXlxG1Zd8d1SXp+c1GncegVj7ZDLU5EuEh/NThK281DlFDiiAXv 8plk+7YU3XKpU/iXI2vHh8YgpR4NqU72KS7GgerfSrAs X-Google-Smtp-Source: APXvYqz6uq6Vri9Mha1AuzcbDcJp7sLDHAZKulU9O7VseabWlTfNmSgVNNrK2m19Y8HcHCePz3y51Ff5/me02XImyxM= X-Received: by 2002:a05:6830:1193:: with SMTP id u19mr341469otq.221.1551778014814; Tue, 05 Mar 2019 01:26:54 -0800 (PST) MIME-Version: 1.0 From: Edward Napierala Date: Tue, 5 Mar 2019 09:26:43 +0000 Message-ID: Subject: 'td' vs sys/fs/nfsserver/ To: FreeBSD FS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4E15A889D5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of etnapierala@gmail.com designates 209.85.210.67 as permitted sender) smtp.mailfrom=etnapierala@gmail.com X-Spamd-Result: default: False [-3.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.62)[-0.619,0]; RCVD_IN_DNSWL_NONE(0.00)[67.210.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[trasz@freebsd.org,etnapierala@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[trasz@freebsd.org,etnapierala@gmail.com]; IP_SCORE(-1.19)[ipnet: 209.85.128.0/17(-3.84), asn: 15169(-2.04), country: US(-0.07)]; TO_DOM_EQ_FROM_DOM(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 09:26:57 -0000 Hello. As many of you know, right now, throughout the kernel, there=E2=80=99s the =E2=80=98td=E2=80=99 argument being passed over and ove= r, even though we have a cheap way of accessing it by using =E2=80=98curthread=E2=80=99. = That=E2=80=99s suboptimal for obvious reasons. It can=E2=80=99t be fixed =E2=80=98just li= ke that=E2=80=99, as it would introduce a lot of code churn, and also possible bugs in case we miss a case where the =E2=80=98td=E2=80=99 is not equal to curth= read. So, here's the big picture: this is what I'm _not_ intending to do at this point. What I do intend doing is to go and try to fix it in a single kernel component, the NFS server. The idea: drop the =E2=80=98td=E2=80=99 argumen= t (in case of NFS server it=E2=80=99s usually spelled =E2=80=98p=E2=80=99 due to = historical reasons) where it=E2=80=99s unused, which turns out to be quite often, and otherwise push =E2=80=98td=E2=80=99 down, function by function, so that whe= n you review it it=E2=80=99s obvious that it=E2=80=99s equal to curthread. There= are three reasons to do this: first, it makes it very obvious that the=E2=80=A8td passed to various VOPs it calls is indeed always curthread, and makes it easier to do the change described in the previous paragraph, should someone try it. Second=E2=80=A6 well, it=E2=80=99s a cle= anup: the NFS code passes it everywhere, and in many cases it's not used at all. Third, and this is the man reason: it=E2=80=99s a good way to test the idea of pushing td down layer by layer without touching any APIs that are not local to the NFS server, to see if it works, and if it doesn't annoy people to much. =E2=80=A8=E2=80=A8=E2=80=A8So, since I= =E2=80=99ve been asked to discuss it in public first: what do you guys think? From owner-freebsd-fs@freebsd.org Tue Mar 5 15:33:26 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E46171504FEF for ; Tue, 5 Mar 2019 15:33:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3F2936FDFD; Tue, 5 Mar 2019 15:33:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x25FWeGf044927 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Mar 2019 17:32:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x25FWeGf044927 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x25FWeU7044926; Tue, 5 Mar 2019 17:32:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Mar 2019 17:32:40 +0200 From: Konstantin Belousov To: Edward Napierala Cc: FreeBSD FS Subject: Re: 'td' vs sys/fs/nfsserver/ Message-ID: <20190305153240.GB2492@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 15:33:26 -0000 On Tue, Mar 05, 2019 at 09:26:43AM +0000, Edward Napierala wrote: > Hello. As many of you know, right now, throughout the kernel, > there’s the ‘td’ argument being passed over and over, even though > we have a cheap way of accessing it by using ‘curthread’. That’s > suboptimal for obvious reasons. It can’t be fixed ‘just like that’, > as it would introduce a lot of code churn, and also possible bugs > in case we miss a case where the ‘td’ is not equal to curthread. > So, here's the big picture: this is what I'm _not_ intending > to do at this point. > > What I do intend doing is to go and try to fix it in a single kernel > component, the NFS server. The idea: drop the ‘td’ argument (in > case of NFS server it’s usually spelled ‘p’ due to historical > reasons) where it’s unused, which turns out to be quite often, and > otherwise push ‘td’ down, function by function, so that when you > review it it’s obvious that it’s equal to curthread. There are > three reasons to do this: first, it makes it very obvious that > the
td passed to various VOPs it calls is indeed always curthread, > and makes it easier to do the change described in the previous > paragraph, should someone try it. Second… well, it’s a cleanup: > the NFS code passes it everywhere, and in many cases it's not used > at all. Third, and this is the man reason: it’s a good way to test > the idea of pushing td down layer by layer without touching any > APIs that are not local to the NFS server, to see if it works, and > if it doesn't annoy people to much. 


So, since I’ve been asked to > discuss it in public first: what do you guys think? Lets put aside the importance of the problem. I find the selection of the component to remove the 'td' argument somewhat strange. It is on top of the VFS stack, so any VOPs or other VFS functions calls taking 'td' would require insertion of many curthread()s. Why not start from the bottom ? I believe that looking at all in-tree filesystems and deciding which VOPs and VFS_XXX methods do not need td because they do not use it, would give more useful approach. After td is elminated from VOPs which do not need it, it should be rather uncontended to eleminate td from corresponding callers of them. From owner-freebsd-fs@freebsd.org Tue Mar 5 18:25:58 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2401C150C1B3 for ; Tue, 5 Mar 2019 18:25:58 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B333380EE5 for ; Tue, 5 Mar 2019 18:25:57 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ot1-f66.google.com with SMTP id q24so8316326otk.0 for ; Tue, 05 Mar 2019 10:25:57 -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:content-transfer-encoding; bh=Eu+PYv+TwN8sqWpwBtbQGSeF2gDjC+fgZ0hOeySc/hc=; b=PoJZhB8NVBSgLF5Ci65NWMq9rNXNe7/z7U6iutEksazy6whAXdWL41A2EXG0afqTzE oGEIkpyBq5LVpheaBIacssYMvITEelPxVUAgTrkdQckXdCHLGmOPjMJ52DA/qQKttNj9 afcWOvitwZeBn7u1P2OjFQvcArHqA+IdVgGn2ZPk/17NAXUYcyOCkqhtkG4UzSG3RFev TrQmS7LfepfkvMETO/j3m20JbsB8v/v3kCRBXjPEsmwU+h7RAgg2jY+Q5LjF8t7jJG8V C+fu43ffCzX4DAgg5uosggbZa+b5s7RjzMcp0l/4lS5YZ0W8zHXy8NKkKcq819ry44Fd Va5Q== X-Gm-Message-State: APjAAAWc8SONPW9xLRv+YCkLciP953inHTg+D6jPw0RqFhpbpFgBBGa7 ZF2AzI5Q0UysIitFDSwiHGfT1P9TJ7p7+6D/Lgw= X-Google-Smtp-Source: APXvYqyu6lz/QmMAFw+q9hizXFPkM49O+qBqWTnjpYCoMjdSR9Gg/luHYpHjNET6aBXT/t5jnGMPETBYT4zT5Ffg9Ag= X-Received: by 2002:a9d:7dcd:: with SMTP id k13mr1698352otn.205.1551809908718; Tue, 05 Mar 2019 10:18:28 -0800 (PST) MIME-Version: 1.0 References: <20190305153240.GB2492@kib.kiev.ua> In-Reply-To: <20190305153240.GB2492@kib.kiev.ua> From: Edward Napierala Date: Tue, 5 Mar 2019 18:18:17 +0000 Message-ID: Subject: Re: 'td' vs sys/fs/nfsserver/ To: Konstantin Belousov Cc: FreeBSD FS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B333380EE5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.978,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 18:25:58 -0000 wt., 5 mar 2019 o 15:33 Konstantin Belousov napisa=C5= =82(a): > > On Tue, Mar 05, 2019 at 09:26:43AM +0000, Edward Napierala wrote: > > Hello. As many of you know, right now, throughout the kernel, > > there=E2=80=99s the =E2=80=98td=E2=80=99 argument being passed over and= over, even though > > we have a cheap way of accessing it by using =E2=80=98curthread=E2=80= =99. That=E2=80=99s > > suboptimal for obvious reasons. It can=E2=80=99t be fixed =E2=80=98jus= t like that=E2=80=99, > > as it would introduce a lot of code churn, and also possible bugs > > in case we miss a case where the =E2=80=98td=E2=80=99 is not equal to c= urthread. > > So, here's the big picture: this is what I'm _not_ intending > > to do at this point. > > > > What I do intend doing is to go and try to fix it in a single kernel > > component, the NFS server. The idea: drop the =E2=80=98td=E2=80=99 arg= ument (in > > case of NFS server it=E2=80=99s usually spelled =E2=80=98p=E2=80=99 due= to historical > > reasons) where it=E2=80=99s unused, which turns out to be quite often, = and > > otherwise push =E2=80=98td=E2=80=99 down, function by function, so that= when you > > review it it=E2=80=99s obvious that it=E2=80=99s equal to curthread. T= here are > > three reasons to do this: first, it makes it very obvious that > > the=E2=80=A8td passed to various VOPs it calls is indeed always curthre= ad, > > and makes it easier to do the change described in the previous > > paragraph, should someone try it. Second=E2=80=A6 well, it=E2=80=99s a= cleanup: > > the NFS code passes it everywhere, and in many cases it's not used > > at all. Third, and this is the man reason: it=E2=80=99s a good way to = test > > the idea of pushing td down layer by layer without touching any > > APIs that are not local to the NFS server, to see if it works, and > > if it doesn't annoy people to much. So, since I=E2=80=99ve been asked = to > > discuss it in public first: what do you guys think? > > Lets put aside the importance of the problem. > > I find the selection of the component to remove the 'td' argument somewha= t > strange. It is on top of the VFS stack, so any VOPs or other VFS functio= ns > calls taking 'td' would require insertion of many curthread()s. Why not > start from the bottom ? > > I believe that looking at all in-tree filesystems and deciding which VOPs > and VFS_XXX methods do not need td because they do not use it, would give > more useful approach. After td is elminated from VOPs which do not need > it, it should be rather uncontended to eleminate td from corresponding > callers of them. At the bottom of the call stack the thread pointer usually gets used... eventually. Yes, that means we might end up accessing curthread several times. But I'd expect it to be still much cheaper[1] to just use curthread there, at the bottom, instead of passing the td over five or ten levels of function calls to get there; not to mention more readable. Also, there's a common pattern of filesystem functions calling global functions, which in turn back into filesystem (eg ufs_accessx -> VOP_GETACL -> ufs_getacl -> vn_extattr_get -> VOP_GETEXTATTR etc), which means doing it step by step would introduce a lot of KPI changes, which is not something I'd like to do. Remember when we talked about it on IRC some... ten years ago? I'm not sure, but I think it was you. I've asked if the 'td' argument, I think it was about the td argument to VOPs in general, was always equal to curthread. And the answer was "probably". This means I can't just safely ignore it and use curthread when I need it. I mean, sure I can, but it might bite me in the end. So the safe way is to just keep passing it over and over again, everywhere, in newly written code. And thus the top-down approach. Doing cleanup at the top first, even without actually changing the public kernel KPIs, means the 'probably' turns into 'yes', and in the new code I can stop passing it over and over. 1. Where "much cheaper" means "it's unmeasurable anyway". From owner-freebsd-fs@freebsd.org Tue Mar 5 18:39:24 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E68B150CCD7 for ; Tue, 5 Mar 2019 18:39:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BDD0581E14 for ; Tue, 5 Mar 2019 18:39:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7D810150CCD5; Tue, 5 Mar 2019 18:39:23 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BF67150CCD4 for ; Tue, 5 Mar 2019 18:39:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CDE281E12 for ; Tue, 5 Mar 2019 18:39:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5201A1D149 for ; Tue, 5 Mar 2019 18:39:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x25IdMI4017127 for ; Tue, 5 Mar 2019 18:39:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x25IdMlT017124 for fs@FreeBSD.org; Tue, 5 Mar 2019 18:39: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 216391] [fusefs] fs mounted with option default_permission + allow_other not doing permission check as expected Date: Tue, 05 Mar 2019 18:39:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE 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: asomers@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 18:39:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216391 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- 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 Tue Mar 5 19:59:59 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D49B1511159 for ; Tue, 5 Mar 2019 19:59:59 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 6F1B786015; Tue, 5 Mar 2019 19:59:58 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id x25K8d4Z011653; Tue, 5 Mar 2019 12:08:39 -0800 (PST) (envelope-from mckusick@mckusick.com) Message-Id: <201903052008.x25K8d4Z011653@chez.mckusick.com> From: Kirk McKusick To: Edward Napierala Subject: Re: 'td' vs sys/fs/nfsserver/ cc: FreeBSD FS X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Edward Napierala message dated "Tue, 05 Mar 2019 09:26:43 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11651.1551816519.1@chez.mckusick.com> Date: Tue, 05 Mar 2019 12:08:39 -0800 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Rspamd-Queue-Id: 6F1B786015 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [0.37 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[mckusick@mckusick.com]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.52)[-0.518,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mckusick.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.32)[0.325,0]; IP_SCORE(-0.26)[ip: (-0.19), ipnet: 70.36.128.0/19(-0.09), asn: 46375(-0.94), country: US(-0.07)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: chez.mckusick.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[235.157.36.70.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.07)[-0.065,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:46375, ipnet:70.36.128.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 19:59:59 -0000 Let me give a brief historical perspective on how we ended up with td getting passed nearly everywhere. It arose in the early 1980's as I was leading an effort to get rid of kernel global user area. The state of a process was stored in its process entry and its user structure. The state needed only when the process was running was stored in the user structure. State needed when the process was not running was stored in the process structure. Thus the user structure could be swapped out when the process was idle. The idea was to keep the process structure as small as possible. On each context switch, the process' user structure was brought into memory if it had been swapped out and then mapped to the global kernel "u" variable. One of the fields in the user structure was u_error. So functions returned an error by setting u.u_error. If the kernel needed to do an internal I/O operation (say read the contents of a directory block to find an entry), it would need to save u.u_error, do the I/O, check u.u_error to find out if it succeeded, then restore u.u_error. Our goal was to get rid of the user structure. So we made a sweep over the entire kernel to get rid of uses of u.u_* accesses. For u.u_error we changed functions so that they always returned errors. Many of the fields that now appear in the uio structure were in the user area. So we gathered them together to define the uio structure and passed a pointer to a uio structure to functions that needed to use it. Finding out the current process was done using u.u_procp. We eliminated this by passing the process pointer in as one of the parameters to each system call. Once we moved to threads, the pointer to the process was changed to be a pointer to the thread. Most of these changes were correct and carry over nicely to today. In retrospect, the passing of the thread was not the right approach. It becomes a parameter to near every call and is often just a passthrough. So, if I had a time machine and could go back, I would have dropped the idea of passing the process pointer and just stuck with usng then curproc(), now curthread(). So, this is a long-winded way of saying that purging the passing of td seems like a reasonable idea though one has to ask if the cost in code churn is worth the effort. Kirk McKusick From owner-freebsd-fs@freebsd.org Wed Mar 6 00:07:45 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03937151CA30 for ; Wed, 6 Mar 2019 00:07:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670049.outbound.protection.outlook.com [40.107.67.49]) (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 6D20C8F93B; Wed, 6 Mar 2019 00:07:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YT1PR01MB3546.CANPRD01.PROD.OUTLOOK.COM (10.255.43.212) by YT1PR01MB3578.CANPRD01.PROD.OUTLOOK.COM (10.255.43.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Wed, 6 Mar 2019 00:07:40 +0000 Received: from YT1PR01MB3546.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9ce:7a38:abef:5660]) by YT1PR01MB3546.CANPRD01.PROD.OUTLOOK.COM ([fe80::e9ce:7a38:abef:5660%5]) with mapi id 15.20.1665.020; Wed, 6 Mar 2019 00:07:40 +0000 From: Rick Macklem To: Edward Napierala , Kirk McKusick CC: FreeBSD FS Subject: Re: 'td' vs sys/fs/nfsserver/ Thread-Topic: 'td' vs sys/fs/nfsserver/ Thread-Index: AQHU0484IgosFClobEKcx0Ji1ruvHqX9uIcS Date: Wed, 6 Mar 2019 00:07:40 +0000 Message-ID: References: , <201903052008.x25K8d4Z011653@chez.mckusick.com> In-Reply-To: <201903052008.x25K8d4Z011653@chez.mckusick.com> 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: 125edd8a-2514-4240-ad5f-08d6a1c7bf9a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:YT1PR01MB3578; x-ms-traffictypediagnostic: YT1PR01MB3578: x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; YT1PR01MB3578; 23:QnhrKwYvlWvjoaGoN+nL5FR8ufjY0s6Vw0mGAxp?= =?iso-8859-1?Q?Gjgt/ZFtB3gfhNqqSglFiFF6RfmlAzpDpIEYM9HgMSDwrTTZzhwph23kmA?= =?iso-8859-1?Q?qM+RzzGvQ3OPXCftboku3AO+pISllj9M7Oj0i+ZG0/NDsxa8YwljJlJyER?= =?iso-8859-1?Q?Bsr+9r8nchAt+EtlgSigktO+4RqLv+TJgIiHvlWxTwYn2quIMzJ+B287FQ?= =?iso-8859-1?Q?uEEXZ4RPG+cc5EM2juJBXbxaGStqroiqedDnE8UqcKSd7tzwUpwAFkhr1E?= =?iso-8859-1?Q?HESL7AyBem0saIFs2+QQRCKmCOCWWPS22EKvqL2XItKQXuQmWvzeszXj0B?= =?iso-8859-1?Q?xh5g8CRMYJ+ItblvhXuiI0qS8tKDocC0HWva5GYsZges6BL2+ZB8qusOzR?= =?iso-8859-1?Q?ZqAPX7XbrcjPf8rzbKG3/beQZ8UMlq4sv1vrndFb7J0aP918gbrRoAKgW/?= =?iso-8859-1?Q?WxyBFmXvmKbG1q3Jmf6ObZFudEMrXgob3b9ZR4lzyoMCkG10xYUjqMs2f2?= =?iso-8859-1?Q?FA540FLVzNXmjC46wL2KnLxqeRTym0k2t1+snhBeLNglsj2dL6SHW28+XU?= =?iso-8859-1?Q?QD82QjPuo8gwJsM6gvejAehsMdn4MIOVYwZoPcIN0/rgA5T0B52VraXwXR?= =?iso-8859-1?Q?Brvq3/cW4o4hW0y7aTa/Fb86e6rRux19rJGwPsDSyL3aLKb5eiSzfjp3HM?= =?iso-8859-1?Q?UM+khY46REHvp6dG75PpeJtmh2Mu1NeYlPloySV7RmurpVY7KMfTfqmfA0?= =?iso-8859-1?Q?HFnbCYFj0x0qZr7GuyFHsDalMaly6rq3EfwZwturQFMfUt+be3G2qUcmXl?= =?iso-8859-1?Q?nnAQ4R1hULR3xtIf+WvxeBNxzCVF17u+cqCgQafws8aut/Vbzf+uorsPJQ?= =?iso-8859-1?Q?sV+RdaAnhiuX+4SZP9AsnGC3IvuGt882L9RbIBWmlXPfyhSX3aBFd0yCF2?= =?iso-8859-1?Q?9v48WmIMDOCVbjXPf8zAW/wg5Yy6j0kvLgqfK2lxmTSmgcy1FvCDP/HCkp?= =?iso-8859-1?Q?SD43CHZ4xyWa7fJyheYUp4t3v0a9OUUmIGX8WYjgfFRrZjdbovoYNZQtrO?= =?iso-8859-1?Q?QUeEh9244ESo4HURzGaRyxIQdicoYM3kFDY3vtE15BY7Sb7v40ue5CNWAx?= =?iso-8859-1?Q?j8n7X3JZuZxFZABVaSAouXCOCkce2EmH3cWuXjG/umALpcRxhUHfHXtESP?= =?iso-8859-1?Q?I3bBlD+e8kt?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(346002)(136003)(39860400002)(199004)(189003)(53936002)(446003)(476003)(11346002)(305945005)(102836004)(186003)(46003)(316002)(786003)(33656002)(229853002)(106356001)(97736004)(74316002)(105586002)(6246003)(7696005)(76176011)(6506007)(68736007)(486006)(74482002)(81156014)(4326008)(8936002)(4744005)(81166006)(6436002)(2906002)(5660300002)(8676002)(71190400001)(71200400001)(25786009)(99286004)(55016002)(14454004)(9686003)(110136005)(86362001)(478600001)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:YT1PR01MB3578; H:YT1PR01MB3546.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HuPlSNlmTSR7m8CtyF0WHqEti8V6bIEIPqrAAJaQL4zY0kFl3hBPdicxRn0NL9fN8hCakSyil6Do7Cm0Be63WH7YmdRdKj4Me1bI5zEAhaWhuktuEK+39JCflfrt97ZAjUJztMhPDr0sdtdq4oxXI0QLpmSbpY+2xxqwj56nECtS3XaPWIEdRJbDeAGDwCd5mBPjNiMax230vDWM/chhZRUwbDEgsvfBUheeDbkguTZD+MfRQMbLGMrhwxxw9Xal7nhqLAdL0Nb9sRsbxO+XySvSXoY8HY2ku84Rdr89K6kMZ5A8r0ima1ikhJRnKRctsCel1/N5/37BOvwp0o2v7GyUVv0t3Iso/KbL6NIYl3kqimnUmkus17V/z4pPu2C9lEqHXRHBS60kJQAuqNZiEYTDk8YaW5nqdeCYxMW/IUo= 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-Network-Message-Id: 125edd8a-2514-4240-ad5f-08d6a1c7bf9a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 00:07:40.3151 (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-Transport-CrossTenantHeadersStamped: YT1PR01MB3578 X-Rspamd-Queue-Id: 6D20C8F93B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.49 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.08 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.87)[-0.866,0]; RCVD_IN_DNSWL_NONE(0.00)[49.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-0.90)[ipnet: 40.64.0.0/10(-2.24), asn: 8075(-2.20), country: US(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 00:07:45 -0000 Kirk McKusick wrote: [interesting historical background snipped. And, yes, I do recall "u" being= at 56K.] >So, this is a long-winded way of saying that purging the passing >of td seems like a reasonable idea though one has to ask if the >cost in code churn is worth the effort. My main concern is that this will make MFC'ng more difficult, but I can liv= e with that. (I was hoping to avoid reviewing all these rather trivial edits, but it doe= sn't look like I can. I tried pointing out I wasn't the "maintainer", but I don't th= ink that got me "off the hook".;-) rick From owner-freebsd-fs@freebsd.org Wed Mar 6 03:33:57 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD07415244BD for ; Wed, 6 Mar 2019 03:33:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 586C470AE1 for ; Wed, 6 Mar 2019 03:33:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 15B0615244B5; Wed, 6 Mar 2019 03:33:57 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 045A415244B4 for ; Wed, 6 Mar 2019 03:33:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5908E70AD6 for ; Wed, 6 Mar 2019 03:33:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 9DBF820C5 for ; Wed, 6 Mar 2019 03:33:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x263XtGY079663 for ; Wed, 6 Mar 2019 03:33:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x263Xtb6079662 for fs@FreeBSD.org; Wed, 6 Mar 2019 03:33:55 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 236220] ZFS vnode deadlock on zfs_mknode Date: Wed, 06 Mar 2019 03:33:55 +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.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 03:33:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236220 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 Wed Mar 6 12:18:24 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 487761511379 for ; Wed, 6 Mar 2019 12:18:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CEC5F8AE35 for ; Wed, 6 Mar 2019 12:18:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8DA071511373; Wed, 6 Mar 2019 12:18:23 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AD2C1511372 for ; Wed, 6 Mar 2019 12:18:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15FF28AE2F for ; Wed, 6 Mar 2019 12:18:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 531956F31 for ; Wed, 6 Mar 2019 12:18:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x26CIMUn099558 for ; Wed, 6 Mar 2019 12:18:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x26CIMmW099550 for fs@FreeBSD.org; Wed, 6 Mar 2019 12:18: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 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Date: Wed, 06 Mar 2019 12:18: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ben.rubson@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 12:18:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235774 --- Comment #2 from Ben RUBSON --- As stated in bug 230258, there are 2 workarounds to this : - use FUSE direct_io mount option - sysctl vfs.fuse.data_cache_mode =3D 0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 6 12:47:10 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56AE01513E41 for ; Wed, 6 Mar 2019 12:47:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DA1078C0EB for ; Wed, 6 Mar 2019 12:47:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 885361513E40; Wed, 6 Mar 2019 12:47:09 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76BBC1513E3F for ; Wed, 6 Mar 2019 12:47:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DBE38C0E7 for ; Wed, 6 Mar 2019 12:47:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 21BCC73AF for ; Wed, 6 Mar 2019 12:47:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x26Cl8nG017102 for ; Wed, 6 Mar 2019 12:47:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x26Cl72F017098 for fs@FreeBSD.org; Wed, 6 Mar 2019 12:47:08 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 236220] ZFS vnode deadlock on zfs_mknode Date: Wed, 06 Mar 2019 12:47:08 +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.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avg@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 12:47:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236220 --- Comment #9 from Andriy Gapon --- (In reply to ncrogers from comment #8) No idea, unfortunately. It might not even be related to ZFS, but some other= fs type that you might be using (e.g. nullfs). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 6 13:25:26 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC068151604C for ; Wed, 6 Mar 2019 13:25:26 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E2DA8D57E; Wed, 6 Mar 2019 13:25:23 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from outgoing.leidinger.net (p5B165932.dip0.t-ipconnect.de [91.22.89.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 90E9969E; Wed, 6 Mar 2019 14:25:19 +0100 (CET) Received: from [192.168.1.32] (unknown [192.168.1.32]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id D482531DF; Wed, 6 Mar 2019 14:25:16 +0100 (CET) From: Alexander Leidinger To: Kirk McKusick , Edward Napierala CC: FreeBSD FS Date: Wed, 06 Mar 2019 14:25:16 +0100 Message-ID: <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> In-Reply-To: <201903052008.x25K8d4Z011653@chez.mckusick.com> References: <201903052008.x25K8d4Z011653@chez.mckusick.com> Subject: Re: 'td' vs sys/fs/nfsserver/ MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1551878720; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6jWnz0EXmouN5pERcdC4AgSfgpaN/vb2+4WnYTpTI5A=; b=EquJYjquMu3faNavjqhrvacJk10NQXfkBCGIkjkj1IH/23GKRjjcpniiHvlgitD6yehB/v HCid9Q06l/a7oAO2xHp2mHwDV1Xz972Au5JWf2QcVUbzNMRd4r4gOgwrz0+wW/PBBD3yWC kuL2QZ1yjjZCPq0hwr57v+YV+yPR6DlRp0aBkJ+XkW/TwTAwN+RiMKjcM1sFRFtXAyGuPp Yen8ah7HbURyIkn0MdL0Tr75Tj12eIbapN1xjePifCEakUAKwKggEqtd2c3oNVCZNnhwB/ AabwNv3T0xDRE4Q8sAbJNVrhJiQOrD4sd6sP0xYej+2HZ8IS5hXpDA2EB+ybpA== ARC-Seal: i=1; s=outgoing-alex; d=leidinger.net; t=1551878720; a=rsa-sha256; cv=none; b=myF3OelcfO80+hpUitFCCY4cqdHETpN1gOigeJZH0bvOJk7Nc3ZhyZJifbPmN1ASYC0vDf XLsrBt8f+AIJlgJizwl0gt7ejS2Pa/ODnWjsjOO4cuXQ8VvrydEbBtlVSJXbOUWfTZp6ZW 9lnz2J6FU7YnMMo9pCmiylz48VMQnbyVb1K83qQvXESIZiCmFJOMrRRw580LMS+h/OKkHl McUbCCUqnIGOwyO8/8xGbyRrBNDt7XOJJ5YpDKmXt0heSo5zvIeIA9lrwPk8XhZH/KrZEJ NBYDzVHBaBLg3+au93GIAlHyAR4xZMpYLqXQ3HdZWmuQYDnCQOZCcmL4YSHeUw== ARC-Authentication-Results: i=1; mailgate.Leidinger.net; auth=pass smtp.auth=netchild@leidinger.net smtp.mailfrom=Alexander@Leidinger.net X-Rspamd-Queue-Id: 7E2DA8D57E X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[Leidinger.net,quarantine]; MX_GOOD(-0.01)[mailgate.Leidinger.net]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-3.71)[ip: (-9.79), ipnet: 2a00:1828::/32(-4.88), asn: 34240(-3.86), country: DE(-0.01)]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; ARC_ALLOW(-1.00)[i=1]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[50.89.22.91.zen.spamhaus.org : 127.0.0.10] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 13:25:27 -0000 Hi, About code churn: - Does it matter for an end user if the code repo gets bigger? - Will there be an (indirect) benefit for an end user (like code which is more easy to understand and as such less bugs while changing something or more people willing to touch/improve/extend)? - How many developers mirror the repo and are at the same time space limited? = Does it matter for us developers? - How many developers are network transfer limited and what is the amount of expected change compared to a clang / openssl /.... import? - At which "churn-factor" does it not make sense anymore (and why)? To make it explicit what my intend is with those questions: I suggest to look at real numbers and quality, instead of expectations and feelings. Bye, Alexander. -- Send from a mobile device, please forgive brevity and misspellings. Am 5. März 2019 21:04:10 schrieb Kirk McKusick : > Let me give a brief historical perspective on how we ended up with > td getting passed nearly everywhere. It arose in the early 1980's > as I was leading an effort to get rid of kernel global user area. > > The state of a process was stored in its process entry and its user > structure. The state needed only when the process was running was > stored in the user structure. State needed when the process was not > running was stored in the process structure. Thus the user structure > could be swapped out when the process was idle. The idea was to keep > the process structure as small as possible. On each context switch, > the process' user structure was brought into memory if it had been > swapped out and then mapped to the global kernel "u" variable. > > One of the fields in the user structure was u_error. So functions > returned an error by setting u.u_error. If the kernel needed to do > an internal I/O operation (say read the contents of a directory > block to find an entry), it would need to save u.u_error, do the > I/O, check u.u_error to find out if it succeeded, then restore > u.u_error. > > Our goal was to get rid of the user structure. So we made a sweep > over the entire kernel to get rid of uses of u.u_* accesses. For > u.u_error we changed functions so that they always returned errors. > > Many of the fields that now appear in the uio structure were in the > user area. So we gathered them together to define the uio structure > and passed a pointer to a uio structure to functions that needed > to use it. > > Finding out the current process was done using u.u_procp. We > eliminated this by passing the process pointer in as one of the > parameters to each system call. Once we moved to threads, the > pointer to the process was changed to be a pointer to the thread. > > Most of these changes were correct and carry over nicely to today. > In retrospect, the passing of the thread was not the right approach. > It becomes a parameter to near every call and is often just a > passthrough. So, if I had a time machine and could go back, I > would have dropped the idea of passing the process pointer and > just stuck with usng then curproc(), now curthread(). > > So, this is a long-winded way of saying that purging the passing > of td seems like a reasonable idea though one has to ask if the > cost in code churn is worth the effort. > > Kirk McKusick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Wed Mar 6 14:50:40 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FEA11519A03 for ; Wed, 6 Mar 2019 14:50:40 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 BC68490022; Wed, 6 Mar 2019 14:50:39 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x26EoVLA055638 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Mar 2019 16:50:34 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x26EoVLA055638 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x26EoVoL055637; Wed, 6 Mar 2019 16:50:31 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Wed, 6 Mar 2019 16:50:31 +0200 From: Konstantin Belousov To: Alexander Leidinger Cc: Kirk McKusick , Edward Napierala , FreeBSD FS Subject: Re: 'td' vs sys/fs/nfsserver/ Message-ID: <20190306145031.GC2492@kib.kiev.ua> References: <201903052008.x25K8d4Z011653@chez.mckusick.com> <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 14:50:40 -0000 On Wed, Mar 06, 2019 at 02:25:16PM +0100, Alexander Leidinger via freebsd-fs wrote: > Hi, > > About code churn: > - Does it matter for an end user if the code repo gets bigger? > - Will there be an (indirect) benefit for an end user (like code which is > more easy to understand and as such less bugs while changing something or > more people willing to touch/improve/extend)? Why does it matter how this affects end users ? > - How many developers mirror the repo and are at the same time space > limited? = Does it matter for us developers? Why does it matter at all? > - How many developers are network transfer limited and what is the amount > of expected change compared to a clang / openssl /.... import? > - At which "churn-factor" does it not make sense anymore (and why)? Repo churn is a situation where developers get significant amount of mail with changes that they must read, but which does not change functionality. The changes must be read to understand the current state of the code after the change, to see that there is no un-intentional or bad intentional chunks despite the the commit message. Vcs blame becomes harder to use after the churn because to get down to the interesting change for the part of the code, you must skip a lot of no-op commits (and before skipping, reader needs to ensure that the commits are no-op). Same for vcs log. Then, when you found older change that is interesting, it does not matches the current code state due to churn above it. Repo churn invalidates any out-of-tree patches or development trees and requires efforts to re-merge. Lets ignore MFC for a moment. These are basics why huge style changes alone, or large set of trivial non-functional changes cause lot of backpressure. Look at libexec/rtld-elf for the canonical example of code breaking several important style(9) rules which are not corrected because that would cause churn. It should be obvious for anybody actively working with the code. > > > To make it explicit what my intend is with those questions: I suggest to > look at real numbers and quality, instead of expectations and feelings. Good luck measuring frustration. > > > Bye, > Alexander. > > > -- > Send from a mobile device, please forgive brevity and misspellings. > > Am 5. März 2019 21:04:10 schrieb Kirk McKusick : > > > Let me give a brief historical perspective on how we ended up with > > td getting passed nearly everywhere. It arose in the early 1980's > > as I was leading an effort to get rid of kernel global user area. > > > > The state of a process was stored in its process entry and its user > > structure. The state needed only when the process was running was > > stored in the user structure. State needed when the process was not > > running was stored in the process structure. Thus the user structure > > could be swapped out when the process was idle. The idea was to keep > > the process structure as small as possible. On each context switch, > > the process' user structure was brought into memory if it had been > > swapped out and then mapped to the global kernel "u" variable. > > > > One of the fields in the user structure was u_error. So functions > > returned an error by setting u.u_error. If the kernel needed to do > > an internal I/O operation (say read the contents of a directory > > block to find an entry), it would need to save u.u_error, do the > > I/O, check u.u_error to find out if it succeeded, then restore > > u.u_error. > > > > Our goal was to get rid of the user structure. So we made a sweep > > over the entire kernel to get rid of uses of u.u_* accesses. For > > u.u_error we changed functions so that they always returned errors. > > > > Many of the fields that now appear in the uio structure were in the > > user area. So we gathered them together to define the uio structure > > and passed a pointer to a uio structure to functions that needed > > to use it. > > > > Finding out the current process was done using u.u_procp. We > > eliminated this by passing the process pointer in as one of the > > parameters to each system call. Once we moved to threads, the > > pointer to the process was changed to be a pointer to the thread. > > > > Most of these changes were correct and carry over nicely to today. > > In retrospect, the passing of the thread was not the right approach. > > It becomes a parameter to near every call and is often just a > > passthrough. So, if I had a time machine and could go back, I > > would have dropped the idea of passing the process pointer and > > just stuck with usng then curproc(), now curthread(). > > > > So, this is a long-winded way of saying that purging the passing > > of td seems like a reasonable idea though one has to ask if the > > cost in code churn is worth the effort. > > > > Kirk McKusick > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Wed Mar 6 16:27:10 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7EE3151D5E8 for ; Wed, 6 Mar 2019 16:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 79A33930E0 for ; Wed, 6 Mar 2019 16:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3A482151D5E7; Wed, 6 Mar 2019 16:27:09 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28FD0151D5E6 for ; Wed, 6 Mar 2019 16:27:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB5E9930DB for ; Wed, 6 Mar 2019 16:27:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 00DCC93AE for ; Wed, 6 Mar 2019 16:27:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x26GR71Y018430 for ; Wed, 6 Mar 2019 16:27:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x26GR7iU018429 for fs@FreeBSD.org; Wed, 6 Mar 2019 16:27: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 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Date: Wed, 06 Mar 2019 16:27:06 +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: cem@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 16:27:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235774 --- Comment #3 from Conrad Meyer --- (In reply to Ben RUBSON from comment #2) > As stated in bug 230258, there are 2 workarounds to this : > - use FUSE direct_io mount option > - sysctl vfs.fuse.data_cache_mode =3D 0 Makes sense to me =E2=80=94 both have the effect of preventing data caching= :-). There will be a performance impact depending on your workload. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 6 17:18:35 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A488151EFCB for ; Wed, 6 Mar 2019 17:18:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A7F3194CC9 for ; Wed, 6 Mar 2019 17:18:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6396F151EFCA; Wed, 6 Mar 2019 17:18:34 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2574B151EFC9 for ; Wed, 6 Mar 2019 17:18:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AC0E94CC5 for ; Wed, 6 Mar 2019 17:18:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E27D69AE8 for ; Wed, 6 Mar 2019 17:18:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x26HIWVh052653 for ; Wed, 6 Mar 2019 17:18:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x26HIWdg052652 for fs@FreeBSD.org; Wed, 6 Mar 2019 17:18: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 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Date: Wed, 06 Mar 2019 17:18:33 +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: cem@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 17:18:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235774 --- Comment #4 from Conrad Meyer --- I think fuse's IO_DIRECT path is a mess. Really all IO should go through t= he buffer cache, and B_DIRECT and ~B_CACHE are just flags that control the buffer's lifetime once the operation is complete. Removing the "direct" backends entirely (except as implementation details of strategy()) would simplify and correct the caching logic. Looking at UFS; it really only has a non-bufcache "rawread" path that uses pbufs (and flushes all dirty bufs on the vnode first!). There is no equiva= lent for O_DIRECT writes. And ffs_rawread basically duplicates the ordinary read path for extremely limited cases (single iov, must be sector sized/aligned, etc) =E2=80=94 it's unclear to me why it exists. ffs_write() just uses the ordinary buf cache, paying attention to ioflag & IO_DIRECT and using vfs_bio_set_flags(, ioflag) to propagate it to b_flags & B_DIRECT. (B_DIRECT causes the buffer to be released immediately when it is freed, instead of being cached.) I think we should probably learn from UFS for FUSE's IO modes: 1. Keep and enable the direct_io option, for users who truly want to bypass= the buf cache entirely. Preferably this is a per-mountpoint option rather than= a global, but that is an orthogonal enhancement. Confusingly, this is distin= ct from opening a file O_DIRECT. Maybe the sysctl/option can be renamed. "raw io?" 2. Do not actually use the "direct" paths in FUSE outside of global direct_= io mode (or a future MP-specific always-direct mode). 3. A caveat here is: FUSE filesystems (?)don't have a native sector/block s= ize, but the buf cache is in block units. And, we translate O_WRONLY opens into FUSE FUFH_WRONLY opens. So there will be some trickiness in partial block writes with a O_WRONLY handle when the block is not in cache. Today that is sidestepped by invoking direct mode, but shouldn't be. Anyway, this is all future cleanup ideas for this area. For the more limit= ed scope of fixing just this PR, we can probably draw inspiration from ffs_rawread_sync(). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Mar 6 17:26:04 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3E201520A6B for ; Wed, 6 Mar 2019 17:26:04 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8441F954EC; Wed, 6 Mar 2019 17:26:04 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ot1-f43.google.com with SMTP id m1so11462567otf.5; Wed, 06 Mar 2019 09:26:04 -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=2cSbwx0Yua2fGe5qLHYoyzXwEyp+qhmk9hsVslK0RQA=; b=hC7bzKqqYyAw/wkfHpL/ZWMBCGgxQjQ/VQOBal8fU6alVI1oawlZXTQL0oXuaOVOce GRsLcBIgc0d4JxRZsFis5VoV8URQUWLxzUptOKVeO5dstFXgFUvOmxYCkE8MaMMkSfCQ M/c5kT2Dr9ZQ0Q2aX7G4iZ13yZVI09nxHNetd9ayls2vj/oQIYFHsHR0ZHROrxhZjtgM ooIH/4H+uCBjOJVPcxF0OPOrYDeSxMsV2Nq4HLOYf7YPJDw+i2tLB2C3URNnEJhEY6d3 nunlGJ6WNKYYnTAkHgGoxFDXXZI5RUCIFrkNNwB0o72pLgcBn4pCahl9lv9ksi9/6s0u lp1Q== X-Gm-Message-State: APjAAAXCsTTnlMNblvaX59UrloXreqIlms0DHw5QY3vle7qm/MAypnvz p9rfZNvVld06+vvg6AjyMOUOvxs01xI3NqfZg1CkIw== X-Google-Smtp-Source: APXvYqzjyAG/InMVCWePq+ppCLN3orT6MqsjnWlnEed7bC4Vn7ZQ1FC3HU2ncP++9BodPkhwNSYlob6cfDomLtcx4yk= X-Received: by 2002:a05:6830:1193:: with SMTP id u19mr5035898otq.221.1551893157803; Wed, 06 Mar 2019 09:25:57 -0800 (PST) MIME-Version: 1.0 References: <201903052008.x25K8d4Z011653@chez.mckusick.com> <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> <20190306145031.GC2492@kib.kiev.ua> In-Reply-To: <20190306145031.GC2492@kib.kiev.ua> From: Edward Napierala Date: Wed, 6 Mar 2019 17:25:46 +0000 Message-ID: Subject: Re: 'td' vs sys/fs/nfsserver/ To: Konstantin Belousov Cc: Alexander Leidinger , Kirk McKusick , FreeBSD FS Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8441F954EC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.86 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.86)[-0.858,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 17:26:04 -0000 On Wed, 6 Mar 2019 at 14:50, Konstantin Belousov wrote: > > On Wed, Mar 06, 2019 at 02:25:16PM +0100, Alexander Leidinger via freebsd-fs wrote: [..] > > To make it explicit what my intend is with those questions: I suggest to > > look at real numbers and quality, instead of expectations and feelings. > Good luck measuring frustration. We can try to estimate it, though. Actually removing the 'td' argument throughout the kernel would not only introduce code churn (which is a valid concern of course), but it would create one huge merge conflict (or, if spread over time, a series of merge conflicts) for literally everyone. That's a lot of frustration. On the other hand, I'd expect cleaning up the top of the stack to make it easy to stop passing the td in newly written code - by making it very clear, and perhaps assertable, that for a given KPI it's always equal to curthread - to be more acceptable. It would also make it possible, in future, to remove the td in selected places, where it eg causes a stack spill. From owner-freebsd-fs@freebsd.org Wed Mar 6 17:52:22 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BA641521CB8 for ; Wed, 6 Mar 2019 17:52:22 +0000 (UTC) (envelope-from daveb@spectralogic.com) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2B10796973; Wed, 6 Mar 2019 17:52:17 +0000 (UTC) (envelope-from daveb@spectralogic.com) Received: from [67.219.246.97] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.us-east-1.aws.symcld.net id FF/22-15745-2C8008C5; Wed, 06 Mar 2019 17:52:02 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRWlGSWpSXmKPExsVyQG4fv+5BjoY Yg+03zC0mvepktzj2+CebA5PHjE/zWQIYo1gz85LyKxJYMx79n81SMEu64u7CPtYGxjdSXYyc HGwCWhI9Sw6zdDFycIgIhElsumAOEhYWkJRYueMJO0RYSuLWWjuQsIiAnsTMKz9YQGwWARWJY 30v2EBsXgFniWm//jGC2EICGxglnvdlg9icAi4SR3bPZgKxGQXEJL6fWgNmMwuIS9x6Mh/Mlh AQkFiy5zwzhC0q8fLxP1aQtcwCmhLrd+lDlNtL7N7SzwphK0pM6X7IDrFWUOLkzCcsExgFZyG ZOguhexaS7llIumch6V7AyLqK0SypKDM9oyQ3MTNH19DAQNfQ0EjXQNfI0EgvsUo3Sa+0WDc1 sbhE11AvsbxYr7gyNzknRS8vtWQTIzAGUgoYruxgXLc0/RCjJAeTkihv5ev6GCG+pPyUyozE4 oz4otKc1OJDjDIcHEoSvJ/ZGmKEBItS01Mr0jJzgNEIk5bg4FES4V0GkuYtLkjMLc5Mh0idYt TleHvw+VxmIZa8/LxUKXHeiexARQIgRRmleXAjYInhEqOslDAvIwMDgxBPQWpRbmYJqvwrRnE ORiVhXjaQKTyZeSVwm14BHcEEdMSUk/UgR5QkIqSkGhhrL226eeQM02Y5M8452qyLPZS4Pwj2 T4n1jFP6VFUQ8C7n5hW7CfteWHI6LDGfxbnx4r9pJyx8nZRkA2xyNVqfpnAfL7kn+rT0sEj31 CNB7v+/cDGW311wYM6BM6837w1l3s9+svz6zzvcmRG/rae9M5h7Xe6Syx6+y1Kv0wNzNC7e2C EeJSOrxFKckWioxVxUnAgASS4bqQcDAAA= X-Env-Sender: daveb@spectralogic.com X-Msg-Ref: server-5.tower-381.messagelabs.com!1551894721!4819885!1 X-Originating-IP: [192.30.190.15] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30190 invoked from network); 6 Mar 2019 17:52:01 -0000 Received: from unknown (HELO mail.spectralogic.com) (192.30.190.15) by server-5.tower-381.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 6 Mar 2019 17:52:01 -0000 From: Dave Baukus To: Andriy Gapon , "freebsd-fs@freebsd.org" Subject: Re: zdb question Thread-Topic: zdb question Thread-Index: AQHUz23RmtUpsFpFjku+sH3Ro99Bag== Date: Wed, 6 Mar 2019 17:51:24 +0000 Message-ID: <788595da-73d5-dc50-5a94-3a11b2acc294@spectralogic.com> References: <7115e017-f9d1-452b-93d7-e2dbcf67618d@spectralogic.com> <94cf983c-c049-090c-c9ea-76b25e8036b9@FreeBSD.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <0E681813A1132D4388E9E737419778F1@spectralogic.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Rspamd-Queue-Id: 2B10796973 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of daveb@spectralogic.com designates 67.219.246.5 as permitted sender) smtp.mailfrom=daveb@spectralogic.com X-Spamd-Result: default: False [-1.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.219.240.0/20]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[spectralogic.com]; NEURAL_HAM_LONG(-0.93)[-0.931,0]; NEURAL_SPAM_SHORT(0.75)[0.747,0]; NEURAL_HAM_MEDIUM(-0.98)[-0.975,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.05)[ipnet: 67.219.246.0/23(-0.11), asn: 26282(-0.06), country: US(-0.07)]; MX_GOOD(-0.01)[cluster4a.us.messagelabs.com,cluster4.us.messagelabs.com,cluster4a.us.messagelabs.com,cluster4.us.messagelabs.com,cluster4a.us.messagelabs.com,cluster4.us.messagelabs.com,cluster4a.us.messagelabs.com,cluster4.us.messagelabs.com,cluster4a.us.messagelabs.com,cluster4.us.messagelabs.com,cluster4a.us.messagelabs.com,cluster4.us.messagelabs.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[5.246.219.67.list.dnswl.org : 127.0.3.0]; MIME_BASE64_TEXT(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:26282, ipnet:67.219.246.0/23, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 17:52:22 -0000 T24gMy80LzE5IDk6NDkgQU0sIERhdmUgQmF1a3VzIHdyb3RlOg0KPiBPbiAzLzEvMTkgMzowMSBB TSwgQW5kcml5IEdhcG9uIHdyb3RlOg0KVGhhbmtzIGZvciB5b3VyIGlucHV0Lg0KPj4gT24gMjgv MDIvMjAxOSAxNTo1OSwgRGF2ZSBCYXVrdXMgd3JvdGU6DQo+Pj4gSWYgb25lIHVzZXMgemRiIC1S IDxwb29sIG5hbWU+IDxkdmE+IHRvIHJlYWQgdGhlIGNvbnRlbnRzIG9mIGV2ZXJ5IGRpc2sgYmxv Y2sNCj4+PiBhc3NvY2lhdGVkIHdpdGggdGhlIERWQSBpbiBhIHJhaWR6MiBwb29sIHRoZW4gZG9l cyBvbmUgZXhwZWN0IHRoZQ0KPj4+IGR1bXAgb2YgZWFjaCBEVkEgdG8gYmUgdGhlIGV4YWN0IFVT RVIgV1JJVFRFTiBjb250ZW50cyBvZiB0aGUgZmlsZSA/DQo+PiBJIHRoaW5rIHNvOyBvbiBhIGNv bmRpdGlvbiB0aGF0IHRoZSBEVkEgcmVmZXJzIHRvIHRoZSBmaWxlJ3MgZGF0YSBibG9jayAoTDAp Lg0KPj4NCj4+PiBPciBkb2VzIHRoaXMgdXNhZ2Ugb2YgemRiIHB1bGwgaW4gdGhlIHJhaWR6MiBj aGVja3N1bSBibG9ja3MgYW5kL29yIHBhZGRpbmcgPw0KPj4+IExvb2tpbmcgYXQgdGhlIGNvZGUs IEkgZG9uJ3QgdGhpbmsgc28uDQo+Pj4NCj4+PiBJIGFzayBiZWNhdXNlIEkgaGF2ZSBhIGZpbGUg b2Yga25vd24gY29udGVudHMgKGV2ZXJ5IGJ5dGUgd2FzIHdyaXR0ZW4gYXMgMHg0MiA9PSAnQicp LA0KPj4+IGFuZCBpZiBJIGV4ZWN1dGUgdGhlIHNjcmlwdCBiZWxvdyBhbmQgcmVkaXJlY3QgdGhl IG91dHB1dCB0byBhIGZpbGUgdGhlbg0KPj4+IHRoZSBjb250ZW50cyBvZiB0aGUgb3V0cHV0IGZp bGUgaGFzIGNodW5rcyBvZiBub24tQiBjaGFyYWN0ZXJzLg0KPj4+DQo+Pj4gRm9yIGV4YW1wbGU6 DQo+Pj4NCj4+PiBPZmZzZXQgMzAwMDAwLCBEVkEgMTo5ZjA4ZTJmZjAwMDoxMjAwMDANCj4+IEhv dyBkaWQgeW91IGNvbWUgdXAgd2l0aCB0aGlzIERWQT8NCj4+IEFyZSB5b3Ugc3VyZSBhYm91dCB0 aGUgc2l6ZSBjb21wb25lbnQ/DQpBbGwgRFZBcyB3ZXJlIGZyb20gemRiIHRoZSBvdXRwdXQgb2bC oCB6ZGIgLWRkZGRkZMKgIDxvYmogc2V0PiA8b2JqIGlkPg0KQWxsIERWQXMgZXhhbWluZWQgd2Vy ZSBMMCBEVkFzIGFuZCB0aGUgc2l6ZSBpcyBjb3JyZWN0IChJIGFzc3VtZSBhcyB0aGUNCnNpemUg Y29tZXMgZnJvbSB6ZGIgLWRkZGRkKS4NClRoZSBwb29sIGhhcyBhIHJlY29yZCBzaXplIG9mIDFN Lg0KDQpJJ2xsIGhhdmUgdG8gZGlnIGludG8gaXQgd2hlbiB0aW1lIGFsbG93cyAuLi4NCg0KPg0K Pj4+IEZvdW5kIHZkZXYgdHlwZTogcmFpZHoNCj4+Pg0KPj4+IDE6OWYwOGUyZmYwMDA6MTIwMDAw DQo+Pj4gICDCoMKgwqDCoMKgwqDCoMKgwqAgMCAxIDIgMyA0IDUgNiA3wqDCoCA4IDkgYSBiIGMg ZCBlIGbCoCAwMTIzNDU2Nzg5YWJjZGVmDQo+Pj4gMDEwMDAwOsKgIDAxMDAwMzIxYjYwZDAwMDDC oCAwYWZiMmY5MzFkODA1MTAwwqAgLi4uLiEuLi4uUS4uLi8uLg0KPj4+IDAxMDAxMDrCoCAwMmFj MjExYzAwMDIwZjAwwqAgMDBlMjAwMDY4MDExMDAzMcKgIC4uLi4uIS4uMS4uLi4uLi4NCj4+PiAw MTAwMjA6wqAgMzkzNDVmNTg2NTZjNjk2NsKgIDBmMDAxMzM0MzIyZTM2MznCoCBmaWxlWF80OTk2 LjI0Li4uDQo+Pj4gMDEwMDMwOsKgIDA1MDA0MGNiMWYwYzAwMDLCoCAwMjAyMGMwMDNhMzUzNTJm wqAgLi4uLi5ALi4vNTU6Li4uLg0KPj4+IDAxMDA0MDrCoCAzODIyMDUwMDQwZWExZjAwwqAgMjEw YzAwMDIwZjAwMjEzNsKgIC4uLkAuLiI4NiEuLi4uLiENCj4+Pg0KPj4+IC0tLS0tDQo+Pj4NCj4+ PiBXaGVyZWFzIEkgZXhwZWN0IGV2ZXJ5IERWQSBjaHVuayB0byBsb29rIGxpa2U6DQo+Pj4NCj4+ PiBPZmZzZXQgMCwgRFZBIDE6OWYwOGUwYmYwMDA6MTIwMDAwDQo+Pj4gRm91bmQgdmRldiB0eXBl OiByYWlkeg0KPj4+DQo+Pj4gMTo5ZjA4ZTBiZjAwMDoxMjAwMDANCj4+PiAgIMKgwqDCoMKgwqDC oMKgwqDCoCAwIDEgMiAzIDQgNSA2IDfCoMKgIDggOSBhIGIgYyBkIGUgZsKgIDAxMjM0NTY3ODlh YmNkZWYNCj4+PiAwMDAwMDA6wqAgNDI0MjQyNDI0MjQyNDI0MsKgIDQyNDI0MjQyNDI0MjQyNDLC oCBCQkJCQkJCQkJCQkJCQkJCDQo+Pj4gMDAwMDEwOsKgIDQyNDI0MjQyNDI0MjQyNDLCoCA0MjQy NDI0MjQyNDI0MjQywqAgQkJCQkJCQkJCQkJCQkJCQg0KPj4+IDAwMDAyMDrCoCA0MjQyNDI0MjQy NDI0MjQywqAgNDI0MjQyNDI0MjQyNDI0MsKgIEJCQkJCQkJCQkJCQkJCQkINCj4+PiAwMDAwMzA6 wqAgNDI0MjQyNDI0MjQyNDI0MsKgIDQyNDI0MjQyNDI0MjQyNDLCoCBCQkJCQkJCQkJCQkJCQkJC DQo+Pj4gMDAwMDQwOsKgIDQyNDI0MjQyNDI0MjQyNDLCoCA0MjQyNDI0MjQyNDI0MjQywqAgQkJC QkJCQkJCQkJCQkJCQg0KPj4+DQo+Pj4gLS0tLQ0KPj4+DQo+Pj4gT24gdGhlIG90aGVyIGhhbmQs IGlmIEkgdXNlIGEgc2ltcGxlIHByb2dyYW0gdG8gcmVhZCB0aGUgZmlsZSBhbmQgdmVyaWZ5IHRo YXQgZXZlcnkgYnl0ZQ0KPj4+IGlzIDB4NDIgdGhlbiBubyBlcnJvcnMgYXJlIHJlcG9ydGVkLg0K Pj4+DQo+Pj4gV2hhdCBnaXZlcyA/DQo+Pj4gQW0gSSBtaXN1c2luZyB6ZGIgPw0KPj4gUGVyaGFw cy4NCj4+DQo+DQo= From owner-freebsd-fs@freebsd.org Wed Mar 6 21:31:57 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF99215280F2 for ; Wed, 6 Mar 2019 21:31:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B46B571A3A for ; Wed, 6 Mar 2019 21:31:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 6D3DC15280F1; Wed, 6 Mar 2019 21:31:56 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4838A15280EF for ; Wed, 6 Mar 2019 21:31:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670041.outbound.protection.outlook.com [40.107.67.41]) (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 BB0A871A29; Wed, 6 Mar 2019 21:31:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM (52.132.89.15) by QB1PR01MB3410.CANPRD01.PROD.OUTLOOK.COM (52.132.87.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Wed, 6 Mar 2019 21:31:50 +0000 Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::89d1:c1e9:cb2:3e66]) by QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::89d1:c1e9:cb2:3e66%3]) with mapi id 15.20.1665.021; Wed, 6 Mar 2019 21:31:50 +0000 From: Rick Macklem To: "bugzilla-noreply@freebsd.org" , "fs@FreeBSD.org" Subject: Re: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Thread-Topic: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() Thread-Index: AQHU1ECgXfJCGSEOt0KosKRIiQNXUKX/HJja Date: Wed, 6 Mar 2019 21:31:50 +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: e6bcda7a-53d9-4278-a408-08d6a27b24d0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:QB1PR01MB3410; x-ms-traffictypediagnostic: QB1PR01MB3410: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; QB1PR01MB3410; 23:ye5B7+dpwGG2nntxqxHyEtvYJmnw8QBH06xJa?= =?Windows-1252?Q?AB8AoHRB31xI/HcFGyr+nYuuL5Z8IKqN8L1U9/ss58j+LN4UAyVXxRiJ?= =?Windows-1252?Q?Wqj4R1wAYDRrZfVHPjuVZ2zvYTXwx1+sjZr3E2/a4Y+R47BE2P7PJZFy?= =?Windows-1252?Q?rUmsE/QYXehgpZvaJJgBK94irG3+4pK2xgaLt7vRVVAI92nwcAMutxp1?= =?Windows-1252?Q?T/KuwCHYz3Zxv5ZfKXDYRV0pgdkGzvKr21/xY6Y9zL8VEh9qc4w0fmPT?= =?Windows-1252?Q?vvNUsdPT+95M7m3owWdt29RD2yf8XisbfB7m1jnF+qqip5bdbLrVeuWV?= =?Windows-1252?Q?nBlJPnnu0kduFq09Go+e38wECA9WSER7IiR+vuew0I2lEaGtdih48Ddu?= =?Windows-1252?Q?JO/sa2Vu8qkEYhKppU2Xd63C2bc+rcYsn6NykDjw6Ex+RONvzMmntdlB?= =?Windows-1252?Q?8VKlk5vMeEcrxupJtor44VYwzxdXRUqMFJA6jbwXVm++6wLUdZ1jieEx?= =?Windows-1252?Q?w2GJvxbUUl7/SRBnYhw+6+ya9L90V+Ii542G0MMzW5qpEJ5sCJTndFbB?= =?Windows-1252?Q?V+sEZli7c1dLNkeDJGiZfXOQWr6fGIaCKrEuKlGXY+z2lwQA0jITSP1P?= =?Windows-1252?Q?cNBDSinbxrGR/9HhkMOIrMBicEOUt0bVAOkKnRZEfekQYafzp5jMrR3C?= =?Windows-1252?Q?9dKvVkISW1W3cThD6FvYdSkYX5RQCcLwPpPOxOqky1QQxuy3EZV3NwgW?= =?Windows-1252?Q?oUNLTdL67RsR5TsvpOP+OmuI0CqQ14c29evJiWQKZYuS/lRnJlXq7nZe?= =?Windows-1252?Q?yMEIAyeFOlOAGmf6fDamfC5k4PM+C+Qf4b/HaZav5cPoUrQvhgXBY6jo?= =?Windows-1252?Q?V6S0BoFT5gmsiznls4t6KvLfSEikrYFx104hURGihaAxc+XfIytyfqr5?= =?Windows-1252?Q?dKDYVuO6x0UgUyNG7Ke8xQ3BQogG81/sJdkJ3fSLE4+e4WvV+yfxWp4T?= =?Windows-1252?Q?dNxT46KREenldJPtc4coxyo+4xuNWjTXckkvFeihHMuBbERbZ2HAep0K?= =?Windows-1252?Q?wDJXQ7iPQnu99X6Ih5Yy4aSFsYJK0pSVw+gFz6eb9WC2pePGCyn+QODa?= =?Windows-1252?Q?dbDNSa4n5Qx9HXbr1FiK8BN0CF1YHdb8or3AaHRK5s1C11bss0hemGE1?= =?Windows-1252?Q?8abVt2YO2phTGCvNITQETbFMiahTm7+f5j9jCos6E7QGNpE2XPP5ZFai?= =?Windows-1252?Q?5hTppEsUdTLCaL5lzy96mkGcXo7o9HKAjiZO2o=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(376002)(366004)(396003)(136003)(199004)(189003)(52314003)(2906002)(99286004)(74316002)(7696005)(102836004)(9686003)(33656002)(6436002)(316002)(97736004)(305945005)(6506007)(55016002)(786003)(6246003)(76176011)(81156014)(53936002)(229853002)(14454004)(81166006)(8676002)(86362001)(186003)(46003)(486006)(71190400001)(478600001)(106356001)(446003)(105586002)(25786009)(11346002)(5660300002)(68736007)(2501003)(476003)(8936002)(71200400001)(110136005)(450100002)(74482002)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3410; H:QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0fcdidLaoqxRnPk5Z8vzhpuTCId+2h1QhHJPsRP0DbGoxf+R2dto6wuOdB5LMAknTkShP+qOKMZqvOxP6etIrbn1D/Z8VYsp/iC3FVlwylBnCkquWbN1zw6bVW8lL4pXc6l/7Sa9HLxYux1sU5L8wd0SAlp/0lKRvaBM9TPio/IHoETDng3nhfRlg++vUi5rY1dnWBlxPPYrs21e/ypCe9cT87u8n9LT7WpSDOVc4H8bLit7TiuPNKiwBvFbxSI8iXDIfXSm1/5H4T4ovRVz7XqPlMRZ6i4XJRb0Dy5jiYohhgHUkWMEpkEzUoC1NZP7lCNgh6WBbTpJB4pqo8ND+uIjk/L92q8OUZQSHJDZX6LTSkvm3IP0cbtqaD22pcgcns2xK+6cr6cwhgpR2xzuXZyIYsU/kXZ0pGiXg+Ru3RY= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: e6bcda7a-53d9-4278-a408-08d6a27b24d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 21:31:50.0943 (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-Transport-CrossTenantHeadersStamped: QB1PR01MB3410 X-Rspamd-Queue-Id: BB0A871A29 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 21:31:57 -0000 --- Comment #4 from Conrad Meyer --- >I think fuse's IO_DIRECT path is a mess. Really all IO should go through = the >buffer cache, and B_DIRECT and ~B_CACHE are just flags that control the >buffer's lifetime once the operation is complete. Removing the "direct" >backends entirely (except as implementation details of strategy()) would >simplify and correct the caching logic. Hmm, I'm not sure that I agree that all I/O should go through the buffer ca= che, in general. (I won't admit to knowing the fuse code well enough to comment specifically on it.) There is a code path on the NFS client that bypasses the buffer cache for O= _DIRECT, but it isn't enabled by default, so I doubt many use it. (It is enabled via= a sysctl which defaults to 0.) I can see an argument for enabling it, since having the NFS (or FUSE) clien= t do a large amount of writing to a file can flood the buffer cache and avoiding t= his for the case where the client won't be reading the file would be nice. What I am not sure is whether O_DIRECT is a good indicator of "doing a lot = of writing that won't be read back". >Looking at UFS; it really only has a non-bufcache "rawread" path that uses >pbufs (and flushes all dirty bufs on the vnode first!). There is no equiv= alent >for O_DIRECT writes. And ffs_rawread basically duplicates the ordinary re= ad >path for extremely limited cases (single iov, must be sector sized/aligned= , >etc) =97 it's unclear to me why it exists. > >ffs_write() just uses the ordinary buf cache, paying attention to ioflag & >IO_DIRECT and using vfs_bio_set_flags(, ioflag) to propagate it to b_flags= & >B_DIRECT. (B_DIRECT causes the buffer to be released immediately when it = is >freed, instead of being cached.) > >I think we should probably learn from UFS for FUSE's IO modes: > >1. Keep and enable the direct_io option, for users who truly want to bypas= s the >buf cache entirely. Preferably this is a per-mountpoint option rather tha= n a >global, but that is an orthogonal enhancement. Confusingly, this is disti= nct >from opening a file O_DIRECT. Maybe the sysctl/option can be renamed. "r= aw >io?" > >2. Do not actually use the "direct" paths in FUSE outside of global direct= _io >mode (or a future MP-specific always-direct mode). > >3. A caveat here is: FUSE filesystems (?)don't have a native sector/block = size, >but the buf cache is in block units. And, we translate O_WRONLY opens int= o >FUSE FUFH_WRONLY opens. So there will be some trickiness in partial block >writes with a O_WRONLY handle when the block is not in cache. Today that = is >sidestepped by invoking direct mode, but shouldn't be. > >Anyway, this is all future cleanup ideas for this area. For the more limi= ted >scope of fixing just this PR, we can probably draw inspiration from >ffs_rawread_sync(). rick From owner-freebsd-fs@freebsd.org Wed Mar 6 21:49:02 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36FB51528B54 for ; Wed, 6 Mar 2019 21:49:02 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 92B167277F for ; Wed, 6 Mar 2019 21:49:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 531C81528B52; Wed, 6 Mar 2019 21:49:01 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B9A21528B51 for ; Wed, 6 Mar 2019 21:49:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com [209.85.166.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B03A272774; Wed, 6 Mar 2019 21:48:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f174.google.com with SMTP id z131so12023075itf.5; Wed, 06 Mar 2019 13:48:57 -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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=cP1E0h/PXcIA92G8kvw/AB34PxT7HNTWFUBWEWGsZ/o=; b=P8cnn/bXKEJR73WlrppMgG7/J+Jp9bCTmwXXvP5+rQ09kALyeIj0KmSwwJpPoDqOZN 7Nkonu8yT3G5EWWE6v0RRtReGqsHt5SIju9jy9KDEbvf2jMAs610nJ+PtSDecQuTz7EW d3lTMvsvk6PboU2aztfn4VbOsL/3c3OwVirHvSyCdNVCTm5at3j93X0GVNIY+g2Y4i1j xOhS4mU+ekmHPFK93iUxDk+SWj095n5zqXueVWQ4A8/3gOeeKlNRmhEAUSkhKu+GG67X yyDVPtoQWHuSTy2PTVejor17CGn6cftmSZoN3s7YCk7MVdBQfUqPQ9pjyzCumWnZHq/E pCMw== X-Gm-Message-State: APjAAAVE7UAe1hrQyctONtdLGlZml8dJdlUxb+BhpWY1lUmyqj4cUqUd KS9ekVmKVGkqU91UKL3wxHC6wLQO X-Google-Smtp-Source: APXvYqyHyDIji4Q6QEdDDKjf8qEINd9H19GLx+zywSu7LzX2Ll/2f7L6bRiWv4UoAH8kv9f3Frcdiw== X-Received: by 2002:a24:f6c6:: with SMTP id u189mr3276086ith.6.1551908931276; Wed, 06 Mar 2019 13:48:51 -0800 (PST) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id r15sm947657ioc.75.2019.03.06.13.48.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 13:48:50 -0800 (PST) Received: by mail-it1-f172.google.com with SMTP id z124so12601367itc.2; Wed, 06 Mar 2019 13:48:50 -0800 (PST) X-Received: by 2002:a24:bdcc:: with SMTP id x195mr3433026ite.149.1551908930748; Wed, 06 Mar 2019 13:48:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 6 Mar 2019 13:48:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() To: Rick Macklem Cc: "bugzilla-noreply@freebsd.org" , "fs@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B03A272774 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 21:49:02 -0000 Hi Rick, On Wed, Mar 6, 2019 at 1:32 PM Rick Macklem wrote: > > --- Comment #4 from Conrad Meyer --- > >I think fuse's IO_DIRECT path is a mess. Really all IO should go throug= h the > >buffer cache, and B_DIRECT and ~B_CACHE are just flags that control the > >buffer's lifetime once the operation is complete. Removing the "direct" > >backends entirely (except as implementation details of strategy()) would > >simplify and correct the caching logic. > > Hmm, I'm not sure that I agree that all I/O should go through the buffer = cache, > in general. (I won't admit to knowing the fuse code well enough to commen= t > specifically on it.) The scope of the bug and comment you've replied to is just FUSE IO. > =E2=80=A6 having the NFS (or FUSE) client do a > large amount of writing to a file can flood the buffer cache and avoiding= this > for the case where the client won't be reading the file would be nice. > What I am not sure is whether O_DIRECT is a good indicator of "doing a lo= t of > writing that won't be read back". This is the known failure mode of LRU cache policies plus finite cache size plus naive clients. It's not specific to any particular filesystem. You can either enlarge your LRU cache to incorporate the entire working set size, incorporate frequency of access in eviction policy, or have smart clients provide hints (e.g., POSIX_FADV_DONTNEED). O_DIRECT -> IO_DIRECT -> B_DIRECT is already used as a hint in the bufcache to release bufs/pages aggressively. Best, Conrad From owner-freebsd-fs@freebsd.org Thu Mar 7 05:23:40 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09DEF151399E for ; Thu, 7 Mar 2019 05:23:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1E58F0C1 for ; Thu, 7 Mar 2019 05:23:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 16EB61513999; Thu, 7 Mar 2019 05:23:39 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB5611513996 for ; Thu, 7 Mar 2019 05:23:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8CA8F0BC; Thu, 7 Mar 2019 05:23:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id C0ED23D9D68; Thu, 7 Mar 2019 16:23:27 +1100 (AEDT) Date: Thu, 7 Mar 2019 16:23:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Conrad Meyer cc: Rick Macklem , "bugzilla-noreply@freebsd.org" , "fs@FreeBSD.org" Subject: Re: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() In-Reply-To: Message-ID: <20190307150927.L932@besplex.bde.org> References: MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=hF2rLc1pAAAA:8 a=6I5d2MoRAAAA:8 a=Oy4Sub0-Cv8Slzy_KP8A:9 a=Amr6LLl0Bs5_1y-f:21 a=sPFHcxzROKv6JPlr:21 a=45ClL6m2LaAA:10 a=O9OM7dhJW_8Hj9EqqvKN:22 a=IjZwj45LgO3ly-622nXo:22 X-Rspamd-Queue-Id: 0C8CA8F0BC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.90)[-0.897,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 05:23:40 -0000 [bugzilla kills replies, but is in the Cc list twice] On Wed, 6 Mar 2019, Conrad Meyer wrote: > On Wed, Mar 6, 2019 at 1:32 PM Rick Macklem wrote: >> >> --- Comment #4 from Conrad Meyer --- >>> I think fuse's IO_DIRECT path is a mess. Really all IO should go throu= gh the >>> buffer cache, and B_DIRECT and ~B_CACHE are just flags that control the >>> buffer's lifetime once the operation is complete. Removing the "direct= " >>> backends entirely (except as implementation details of strategy()) woul= d >>> simplify and correct the caching logic. >> >> Hmm, I'm not sure that I agree that all I/O should go through the buffer= cache, >> in general. (I won't admit to knowing the fuse code well enough to comme= nt >> specifically on it.) > > The scope of the bug and comment you've replied to is just FUSE IO. > >> =E2=80=A6 having the NFS (or FUSE) client do a >> large amount of writing to a file can flood the buffer cache and avoidin= g this >> for the case where the client won't be reading the file would be nice. >> What I am not sure is whether O_DIRECT is a good indicator of "doing a l= ot of >> writing that won't be read back". > > This is the known failure mode of LRU cache policies plus finite cache > size plus naive clients. It's not specific to any particular > filesystem. You can either enlarge your LRU cache to incorporate the > entire working set size, incorporate frequency of access in eviction > policy, or have smart clients provide hints (e.g., > POSIX_FADV_DONTNEED). O_DIRECT -> IO_DIRECT -> B_DIRECT is already > used as a hint in the bufcache to release bufs/pages aggressively. It is mostly a failue with naive clients. Some are so naive that they even trust the implementation of O_DIRECT to be any good. Here the naive client is mostly FUSE. I fixed this in the md device using POSIX_FADV_DONTNEED and an optional new caching option that turns this off. Clients above md can still get slowness by using block sizes too different from the block sizes (if any) used by the backing storage, but unlike IO_DIRECT, POSIX_FADV_DONTNEED is only a hint and it only discards full blocks from the buffer cache for file systems that use the buffer cache. zfs doesn't use the buffer cache and most of posix_fadvise(2) including all of POSIX_FADV_DONTNEED is just a stub that has no effect for it. zfs also doesn't support IO_DIRECT, so the attempted pessimizations from using IO_DIRECT for md had no effect. ffs has a fairly bad implementation of IO_DIRECT. For writing, it does the write using the buffer cache and then kills the buffer. The result for full blocks is the same as for a normal write followed by POSIX_FADV_DONTNEED. The result for a partial block is to kill the buffer while POSIX_FADV_DONTNEED would keep it. For reading, it does much the same unless the optional DIRECTIO option is configured. Then the buffer cache is not used at all. This seems to make no significant difference when all i/o is direct. Normal methods using 1 buffer at a time won't thrash the buffer cache. Rawread uses a pbuf and pbufs are a more limited resource with more primitive management, so it might actually be slower. zfs also doesn't support DIRECTIO. md used to use IO_DIRECT only for reading. With vnode backing on ffs, only reading with the same block size as ffs was reasonably efficient. IO_DIRECT prevents normal clustering even without DIRECTIO, so large block sizes in md were not useful (ffs splits them up), and small block sizes were very small. E.g., with 512-blocks in the client above md and 32K-blocks in ffs, reading 32K in the client 512 bytes at a time uses 64 reads of the same 32K-block in ffs. Caching in the next layer of storage is usually no so bad, but it takes a lot of CPU and a large iops in all layers to do 64 times as many i/o's. Now the ffs block is kept until it is all read, so this only takes a lot of CPU and a large iops in layers between md and ffs, but iops there is only limited by CPU (including memory). md didn't use IO_DIRECT for writing, since it considered that to be too slow. But it was at worst only about 3 times slower than what md did. md also didn't use any clustering, and it normally doesn't use async writes (this is an unusable configuration option, since async writes can hang), so it got much the same slowness as sync mounts in ffs. The factor of 3 slowness is from having to do a read-modify-write to write partial blocks. This gave most of the disadvantages of not using the buffer cache, but still gave double-caching. Now writes in md are cached 1 block at a time and double-caching is avoided for file systems that support POSIX_FADV_DONTNEED. Even non-naive clients like md have a hard time managing the block sizes. E.g., to work as well as possible, md would first need to understand that POSIX_FADV_DONTNEED is not supported by some file systems and supply workarounds. In general, the details of the caching policies and current cache state in the lower layer(s) would have to be understood. Even posix_fadvise(2) doesn't understand much of that. It is only implemented at the vfs level where the details are not known except indirectly by their effect on the buffer and object caches. There is also some confusion and bugs involving *DONTNEED and *NOREUSE: - vop_stdadvise() only supports POSIX_FADVISE_DONTNEED. I does nothing for the stronger hint POSIX_FADVISE_NOREUSE. - posix_advise() knows about this bug and converts POSIX_FADVISE_NOREUSE into POSIX_FADVISE_DONTNEED. - ffs IO_DIRECT wants NOREUSE semantics (to kill the buffer completely). It gets this by not using VOP_ADVISE(), but using the buffer cache. - the buffer cache has the opposite confusion and bugs. It supports B_NOREUSE but not B_DONTNEED. IO_DIRECT is automatically converted to B_NOREUSE when ffs releases the buffer. This is how ffs kills the buffer without know the details. - my initial fixes for md did more management that would have worked with NOREUSE semantics. md wants to kill the buffer too, but only when it is full. I found that the DONTNEED semantics as implemented in vop_stadadvise() worked just as well. But there is a problem with random small i/o's. My initial fixes wanted to kill even small buffers when the next i/o is not contiguous. But this prevents caching when caching is especially needed (it is only sequential i/o's where the data is expected to not be needed again). posix_fadvise and vop_stadadvise() have even less idea how to handle random i/o's. I think they just don't free partial blocks. Bruce Bruce From owner-freebsd-fs@freebsd.org Thu Mar 7 09:24:58 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 681BE1526B61 for ; Thu, 7 Mar 2019 09:24:58 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBFAF72AD1 for ; Thu, 7 Mar 2019 09:24:57 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B16566F.dip0.t-ipconnect.de [91.22.86.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id E8F9CF65 for ; Thu, 7 Mar 2019 10:24:54 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 7740D3243 for ; Thu, 7 Mar 2019 10:24:52 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.15.2/8.14.4/Submit) id x279Oqma052156 for freebsd-fs@freebsd.org; Thu, 7 Mar 2019 10:24:52 +0100 (CET) (envelope-from Alexander@leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@leidinger.net using -f Received: from IO.Leidinger.net (IO.Leidinger.net [192.168.1.11]) by webmail.leidinger.net (Horde Framework) with HTTPS; Thu, 07 Mar 2019 10:24:52 +0100 Date: Thu, 07 Mar 2019 10:24:52 +0100 Message-ID: <20190307102452.Horde.LIPQtoTN3klZVA6iTMOmtYl@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-fs@freebsd.org Subject: Re: 'td' vs sys/fs/nfsserver/ References: <201903052008.x25K8d4Z011653@chez.mckusick.com> <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> <20190306145031.GC2492@kib.kiev.ua> In-Reply-To: <20190306145031.GC2492@kib.kiev.ua> User-Agent: Horde Application Framework 5 Accept-Language: de,en Content-Type: multipart/signed; boundary="=_gev7OHDv8lFVJl6l7UZ4FGu"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1551950695; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V6pP4CzqMMFDwBkb2k+LcvfqZ7T6wVXd+vHMg0Op+PU=; b=0iDuNmrilTLdX1pj/eiqtg3nCTDFMrQlghaa0wsT7GpCnbn/z9reho3nZSa+4OOC6jwwH2 mAGHajknkVt4tRqt/zuHfUb52+c4NOQTI5FGPZBeUg00lQRJaYhU32V4AvDqtlUpQD1CQJ B1X28L12QuhjKz12nF85LszxB3CRfRsAllHMCAptF3sFWhbyFuzxnEvETQ5TlRGyxPEkRZ qdfF1fbj2afp21mMT7QmKgjeQ+eiJ0qdu+1apd2tEiGKjwW0vKp5iSWI+X1gcBNe7X76h0 srqxqomYF79/EadQFvJ+PDr5VfczbvpBI7XrDG0jK3ezyFjDulqGZamJ7/c17g== ARC-Seal: i=1; s=outgoing-alex; d=leidinger.net; t=1551950695; a=rsa-sha256; cv=none; b=k5XVf9OSVLKNo7br9vPLXl/a6yXmSvnzfbgAJYzrfW79g8EYlA4SV5V8olrbTr+h5YvNDn QMRqm2YvrTI85wHQXauMLTrw/x0NU8T76qQ6oc4qjeiT5n+v5oo6dpxQcQ2O0BwaRF1baD tjFn7kAVvgp47/f7Dfj0tbRC6f9DCNhrO+yZdWGHcjr2u/r9oTgm2bqj8eEfeUkUXQN3Ht O4r1p03I8SXVMiP/Xrxcm4xLph++sKMcF+OktIm8f2rAcqBgV5Awwhdi4iOjsJRJtaUvXj JkrSxB8pSB3oeeGC3QGZ1BFBl9P2gePg2wd9NjpfvX7sZjDVoq9i9D2n2wBjyA== ARC-Authentication-Results: i=1; mailgate.Leidinger.net; auth=pass smtp.auth=netchild@leidinger.net smtp.mailfrom=Alexander@leidinger.net X-Rspamd-Queue-Id: DBFAF72AD1 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:24:58 -0000 This message is in MIME format and has been PGP signed. --=_gev7OHDv8lFVJl6l7UZ4FGu Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Konstantin Belousov (from Wed, 6 Mar 2019=20=20 16:50:31=20+0200): > On Wed, Mar 06, 2019 at 02:25:16PM +0100, Alexander Leidinger via=20=20 >=20freebsd-fs wrote: >> Hi, >> >> About code churn: >> - Does it matter for an end user if the code repo gets bigger? >> - Will there be an (indirect) benefit for an end user (like code which = is >> more easy to understand and as such less bugs while changing something o= r >> more people willing to touch/improve/extend)? > Why does it matter how this affects end users ? We're not making changes for the sake of making changes. We make=20=20 changes=20to improve something. And in the end, users are the ones who=20= =20 shall=20benefit from improvements (be it directly by bug fixing / new=20=20 features,=20or indirectl by code quality improvements which prevent some=20= =20 bugs=20in the future). >> - How many developers mirror the repo and are at the same time space >> limited? =3D Does it matter for us developers? > Why does it matter at all? It was one of the points people complained about in the past in such=20=20 situations. >>=20 - How many developers are network transfer limited and what is the am= ount >> of expected change compared to a clang / openssl /.... import? >> - At which "churn-factor" does it not make sense anymore (and why)? > Repo churn is a situation where developers get significant amount > of mail with changes that they must read, but which does not change > functionality. The changes must be read to understand the current state > of the code after the change, to see that there is no un-intentional or > bad intentional chunks despite the the commit message. > > Vcs blame becomes harder to use after the churn because to get down to > the interesting change for the part of the code, you must skip a lot > of no-op commits (and before skipping, reader needs to ensure that the > commits are no-op). Same for vcs log. > > Then, when you found older change that is interesting, it does not > matches the current code state due to churn above it. > > Repo churn invalidates any out-of-tree patches or development trees > and requires efforts to re-merge. You basically say that code-refactoring is a no-go. > Lets ignore MFC for a moment. > > These are basics why huge style changes alone, or large set of trivial > non-functional changes cause lot of backpressure. Look at libexec/rtld-e= lf > for the canonical example of code breaking several important style(9) > rules which are not corrected because that would cause churn. In this thread we are not talking about style changes. To my=20=20 understanding=20we are talking about code-refactoring which is supposed=20= =20 to=20lead to - be more easy understanding for people new to the code (and we want=20= =20 to=20attract new people in general, right?), - a faster understanding for those people which had theirs hands=20=20 already=20in there but didn't had a look at it for a long time, - a simpler interface, and even - some clarity about the inner workings which is not available now=20=20 (I=20refer to the "is td always currthread" question). I fully agree to prevent code churn in terms of style changes. I do not agree to code-refactoring is a no-go (it may depending on the=20= =20 situation...=20IMO it should be more "yes to code-refactoring unless"=20=20 instead=20of "no to code-refactoring unless"). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_gev7OHDv8lFVJl6l7UZ4FGu Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJcgONkAAoJEBINsJsD+NiGe9EP/0J+0MrAHg71oFZE7ty7EraM TKnchtMJZGp0VzS7IR2quYF34bmTwZkH5j3kYLOeIiDiXnlS2a5lNlm1TeuO+zp/ T097DCfA/vHYka3Y9pApoVhlI5lxzQUCLEsIuB1jZRB6mV6RDZgYx2PXdaVrDGFb xtJBN+xXFYvqn+DEAnv9AHPjeys8MoUCpgZmCn0ZOCMPd3BWJdfX1PI4d89J3elr 8IhxOW1ZW06/V7cBaPEFXYoN1zuw4LjR99tP+HyChprG4dIIrCFYrYP0scQEyrP+ oNOBNPLt6NA/17SaF2pYiCkdvkaM/TQWPgH5Ho3Gu+Ah1PS9shJaKSz3A39bLjjp OS7d4uSbmPPvih9sDGrKH0OIEM+S7257QmLA+nZplK9pIGRT2afJBBEGMnDuO7IZ 3J2/JWz8ZphgCR2v0weUXidgyT/uqKJpY4qLKObwIXk5G90ffCAH0KM4kCgDLyo3 fBwEp3jTZF9Ndidq7viLKy3dcYyOstirOJ83qILQAeBJT1kHgxktSpjVcaNM/Zzv 3tpR0pZWfONgTFqEIvzZ4ktYttpLHOGPBdvj1Gd5Vvtx9EclCcFX5JrEaZxKftMA /rfDae096XE+IYDwSZBXPEfMGKmAVFGNRG88dyg/VZd+K6VnDuhrgsjZBoEXvvRK GBmX0eZXkyenNDLNvq/z =h+lR -----END PGP SIGNATURE----- --=_gev7OHDv8lFVJl6l7UZ4FGu-- From owner-freebsd-fs@freebsd.org Thu Mar 7 10:50:19 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 612161529E93 for ; Thu, 7 Mar 2019 10:50:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 82DE57652F for ; Thu, 7 Mar 2019 10:50:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x27AoBAd045338 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 12:50:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x27AoBAd045338 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x27AoBrJ045337; Thu, 7 Mar 2019 12:50:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Mar 2019 12:50:11 +0200 From: Konstantin Belousov To: Alexander Leidinger Cc: freebsd-fs@freebsd.org Subject: Re: 'td' vs sys/fs/nfsserver/ Message-ID: <20190307105011.GI2492@kib.kiev.ua> References: <201903052008.x25K8d4Z011653@chez.mckusick.com> <169532d2770.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> <20190306145031.GC2492@kib.kiev.ua> <20190307102452.Horde.LIPQtoTN3klZVA6iTMOmtYl@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190307102452.Horde.LIPQtoTN3klZVA6iTMOmtYl@webmail.leidinger.net> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 10:50:19 -0000 On Thu, Mar 07, 2019 at 10:24:52AM +0100, Alexander Leidinger via freebsd-fs wrote: > Quoting Konstantin Belousov (from Wed, 6 Mar 2019 > 16:50:31 +0200): > > > On Wed, Mar 06, 2019 at 02:25:16PM +0100, Alexander Leidinger via > > freebsd-fs wrote: > >> Hi, > >> > >> About code churn: > >> - Does it matter for an end user if the code repo gets bigger? > >> - Will there be an (indirect) benefit for an end user (like code which is > >> more easy to understand and as such less bugs while changing something or > >> more people willing to touch/improve/extend)? > > Why does it matter how this affects end users ? > > We're not making changes for the sake of making changes. We make > changes to improve something. And in the end, users are the ones who > shall benefit from improvements (be it directly by bug fixing / new > features, or indirectl by code quality improvements which prevent some > bugs in the future). > > >> - How many developers mirror the repo and are at the same time space > >> limited? = Does it matter for us developers? > > Why does it matter at all? > > It was one of the points people complained about in the past in such > situations. > > >> - How many developers are network transfer limited and what is the amount > >> of expected change compared to a clang / openssl /.... import? > >> - At which "churn-factor" does it not make sense anymore (and why)? > > Repo churn is a situation where developers get significant amount > > of mail with changes that they must read, but which does not change > > functionality. The changes must be read to understand the current state > > of the code after the change, to see that there is no un-intentional or > > bad intentional chunks despite the the commit message. > > > > Vcs blame becomes harder to use after the churn because to get down to > > the interesting change for the part of the code, you must skip a lot > > of no-op commits (and before skipping, reader needs to ensure that the > > commits are no-op). Same for vcs log. > > > > Then, when you found older change that is interesting, it does not > > matches the current code state due to churn above it. > > > > Repo churn invalidates any out-of-tree patches or development trees > > and requires efforts to re-merge. > > You basically say that code-refactoring is a no-go. I did not said even close to what you are trying to put into my mouth. > > > Lets ignore MFC for a moment. > > > > These are basics why huge style changes alone, or large set of trivial > > non-functional changes cause lot of backpressure. Look at libexec/rtld-elf > > for the canonical example of code breaking several important style(9) > > rules which are not corrected because that would cause churn. > > In this thread we are not talking about style changes. To my > understanding we are talking about code-refactoring which is supposed > to lead to > - be more easy understanding for people new to the code (and we want > to attract new people in general, right?), > - a faster understanding for those people which had theirs hands > already in there but didn't had a look at it for a long time, > - a simpler interface, and even > - some clarity about the inner workings which is not available now > (I refer to the "is td always currthread" question). The change is not a refactoring by any common definition of the term, it is minor functional adjustment. Its benefits are questionable (this is why that discussion started at all), while effect in the changed lines count is huge. Bringing 'improvements for users', 'code clarity', 'refactoring' into the thread is so much disproportionate that I am really impressed despite my experience with reading powerpoint slides. > > I fully agree to prevent code churn in terms of style changes. > I do not agree to code-refactoring is a no-go (it may depending on the > situation... IMO it should be more "yes to code-refactoring unless" > instead of "no to code-refactoring unless"). > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From owner-freebsd-fs@freebsd.org Thu Mar 7 16:02:58 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E8271501E9B for ; Thu, 7 Mar 2019 16:02:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 86DBA8C650 for ; Thu, 7 Mar 2019 16:02:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3DDE91501E94; Thu, 7 Mar 2019 16:02:57 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C6AE1501E92 for ; Thu, 7 Mar 2019 16:02:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE5A18C64A for ; Thu, 7 Mar 2019 16:02:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1C25116416 for ; Thu, 7 Mar 2019 16:02:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x27G2tWA071246 for ; Thu, 7 Mar 2019 16:02:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x27G2tB1071245 for fs@FreeBSD.org; Thu, 7 Mar 2019 16:02:55 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 236357] [zfs] kernel panic on 12-STABLE Date: Thu, 07 Mar 2019 16:02:55 +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.0-STABLE X-Bugzilla-Keywords: panic 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:02:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236357 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 Mar 7 22:29:09 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36FC315282DD for ; Thu, 7 Mar 2019 22:29:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C4EF575F03 for ; Thu, 7 Mar 2019 22:29:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 853E215282DC; Thu, 7 Mar 2019 22:29:08 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7292A15282DB for ; Thu, 7 Mar 2019 22:29:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B1E175F01 for ; Thu, 7 Mar 2019 22:29:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 4462A19B8E for ; Thu, 7 Mar 2019 22:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x27MT7wB062919 for ; Thu, 7 Mar 2019 22:29:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x27MT74L062918 for fs@FreeBSD.org; Thu, 7 Mar 2019 22:29: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 236357] [zfs] kernel panic on 12-STABLE Date: Thu, 07 Mar 2019 22:29:06 +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.0-STABLE X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 22:29:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236357 --- Comment #1 from Andriy Gapon --- (In reply to Sergey Anokhin from comment #0) Are you using ECC RAM? I suspect that you might have a memory corruption. Compare: > fault virtual address =3D 0xfffff80282bf3401 to > itx=3D0xfffff80182bf3400 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Mar 7 22:48:26 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06E101528A66 for ; Thu, 7 Mar 2019 22:48:26 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 7F3D1769AA for ; Thu, 7 Mar 2019 22:48:25 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id x27Mv66I067345; Thu, 7 Mar 2019 14:57:07 -0800 (PST) (envelope-from mckusick@mckusick.com) Message-Id: <201903072257.x27Mv66I067345@chez.mckusick.com> From: Kirk McKusick To: Alexander Leidinger , freebsd-fs@freebsd.org Subject: Re: 'td' vs sys/fs/nfsserver/ X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: <20190307105011.GI2492@kib.kiev.ua> Comments: In-reply-to Konstantin Belousov message dated "Thu, 07 Mar 2019 12:50:11 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67343.1551999426.1@chez.mckusick.com> Date: Thu, 07 Mar 2019 14:57:06 -0800 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Rspamd-Queue-Id: 7F3D1769AA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 22:48:26 -0000 Code refactoring takes (nearly) duplicate code from two or usually more places and puts it in a single function. Code refactoring is nearly always a useful thing to do. It increases reliability because a bug fix in the new function corrects the problem in all the places that the code was previously located. It also concentrates the functionality in a single place which makes understanding easier. Reducing the complexity of a function by removing an unneeded, unused, or duplicate parameter can make the code more comprehensible. That is the point that is being raised here where the 'td' parameter is to be removed because the 'curthread()' routine can be used to get its value where it is needed. Changes of this sort also makes understanding easier. The tradeoff in making these changes are the number of lines of code that are affected. The more lines that are affected and the more files that have changes, the higher the cost and the more developers that are affected. Changes that are all contained within a single file are almost always worth the cost. Code refactoring typically provides greater benefit than reducing the parameters to a function, so can be justified across more lines and files. In the case of eliminating 'td', the cost is thousands of lines of changes in a substantial number of files in the kernel. Nearly every developer would be affected by a change that would have just a small benefit. IMO, the benefit is not even remotely worth the cost. Kirk McKusick From owner-freebsd-fs@freebsd.org Fri Mar 8 00:15:50 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 603A3152C143 for ; Fri, 8 Mar 2019 00:15:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EA4AD818DF for ; Fri, 8 Mar 2019 00:15:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A3CBD152C142; Fri, 8 Mar 2019 00:15:49 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FB0E152C140 for ; Fri, 8 Mar 2019 00:15:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25794818DD for ; Fri, 8 Mar 2019 00:15:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 596471AB64 for ; Fri, 8 Mar 2019 00:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x280FmhS016182 for ; Fri, 8 Mar 2019 00:15:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x280FmMQ016174 for fs@FreeBSD.org; Fri, 8 Mar 2019 00:15:48 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 208691] "panic: ffs_valloc: dup alloc" as soon as UFS root partition is mounted Date: Fri, 08 Mar 2019 00:15:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jwb@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 00:15:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208691 Jason W. Bacon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwb@freebsd.org --- Comment #7 from Jason W. Bacon --- I just hit this on a laptop that was running with a completely dead battery= for a while and went down hard a couple times due to a touchy power connector. It would boot fine but always panic within an hour. Manual "fsck -fy" resolved it - thanks for posting the workaround. As for long-term solutions, it possible to quickly determine if a filesyste= m is still dirty after an "fsck -p", and automatically fall back to a full fsck = when necessary? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Mar 8 07:43:53 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53E24153560E for ; Fri, 8 Mar 2019 07:43:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D4DF88F934 for ; Fri, 8 Mar 2019 07:43:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8B77B153560C; Fri, 8 Mar 2019 07:43:52 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D63153560B for ; Fri, 8 Mar 2019 07:43:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03A618F930 for ; Fri, 8 Mar 2019 07:43:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 493731EC31 for ; Fri, 8 Mar 2019 07:43:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x287hpif004850 for ; Fri, 8 Mar 2019 07:43:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x287hpZ3004849 for fs@FreeBSD.org; Fri, 8 Mar 2019 07:43: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 236379] [FUSE] fuse(4) writes from aio(4) don't set the fuse_out_header.pid field correctly Date: Fri, 08 Mar 2019 07:43:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:43:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236379 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 Fri Mar 8 07:47:53 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E745E1535765 for ; Fri, 8 Mar 2019 07:47:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4568FA7E for ; Fri, 8 Mar 2019 07:47:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 39D771535764; Fri, 8 Mar 2019 07:47:52 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26FDD1535763 for ; Fri, 8 Mar 2019 07:47:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EB738FA7D for ; Fri, 8 Mar 2019 07:47:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id DA26E1EC37 for ; Fri, 8 Mar 2019 07:47:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x287lo9E008998 for ; Fri, 8 Mar 2019 07:47:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x287loRj008997 for fs@FreeBSD.org; Fri, 8 Mar 2019 07:47:50 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 236357] [zfs] kernel panic on 12-STABLE Date: Fri, 08 Mar 2019 07:47:50 +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.0-STABLE X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: admin@5034.ru 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:47:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236357 --- Comment #2 from Sergey Anokhin --- (In reply to Andriy Gapon from comment #1) This is test machine without ecc ram. In this case it's hard to say for sure 100%. Memtests were passed. I suppose if the problem is in memory, then the error should be floating, right? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Mar 8 10:03:32 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C1E71538863 for ; Fri, 8 Mar 2019 10:03:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ECEAC6D62E for ; Fri, 8 Mar 2019 10:03:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AC31E1538862; Fri, 8 Mar 2019 10:03:31 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99A3D1538861 for ; Fri, 8 Mar 2019 10:03:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D1E06D627 for ; Fri, 8 Mar 2019 10:03:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 512C5CE for ; Fri, 8 Mar 2019 10:03:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x28A3UQB095721 for ; Fri, 8 Mar 2019 10:03:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x28A3Uv6095717 for fs@FreeBSD.org; Fri, 8 Mar 2019 10:03:30 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 223491] fsck_ufs: Directory XXXX name not found Date: Fri, 08 Mar 2019 10:03:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug 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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 10:03:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223491 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: wosch Date: Fri Mar 8 10:03:16 UTC 2019 New revision: 344922 URL: https://svnweb.freebsd.org/changeset/base/344922 Log: explain ``fsck -f'' more in detail PR: 223491 Approved by: mckusick, 0mp, imp Differential Revision: https://reviews.freebsd.org/D19437 Changes: head/sbin/fsck/fsck.8 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Mar 8 14:46:12 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B0C0150738F for ; Fri, 8 Mar 2019 14:46:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF9F764E8 for ; Fri, 8 Mar 2019 14:46:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D3ED8150738E; Fri, 8 Mar 2019 14:46:11 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1316150738C for ; Fri, 8 Mar 2019 14:46:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A56B764E6 for ; Fri, 8 Mar 2019 14:46:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 80C13297F for ; Fri, 8 Mar 2019 14:46:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x28EkA07095100 for ; Fri, 8 Mar 2019 14:46:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x28EkALn095099 for fs@FreeBSD.org; Fri, 8 Mar 2019 14:46: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 236379] [FUSE] fuse(4) writes from aio(4) don't set the fuse_out_header.pid field correctly Date: Fri, 08 Mar 2019 14:46:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: asomers@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.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 14:46:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236379 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|fs@FreeBSD.org |asomers@FreeBSD.org --- Comment #1 from Alan Somers --- Oops, I missed self-assigning this one. Sorry linimon. --=20 You are receiving this mail because: You are the assignee for the bug.=