From nobody Wed May 19 14:24:13 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7565A86E652 for ; Wed, 19 May 2021 14:24:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlZqx2p6Fz3L0V for ; Wed, 19 May 2021 14:24:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3EA2B14614 for ; Wed, 19 May 2021 14:24:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14JEODAn063903 for ; Wed, 19 May 2021 14:24:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14JEOD7g063902 for fs@FreeBSD.org; Wed, 19 May 2021 14:24:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 251363] use unionfs as a disk-cache for NFS [feature] Date: Wed, 19 May 2021 14:24:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251363 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org --- Comment #21 from Rick Macklem --- A lack of any cache consistency guarantees is a major limitation and I tend to agree with Kirk that this should not be recommended practice. If it works for you, that's fine, but others would not understand the limitations of not having cache consistency and that would probably result in bug reports related to it. When I wrote the packrats code, cache consistency was maintained by the NFSv4 delegation. Although the code basically worked (I had not written the recovery code needed after a client reboot), I left the bits to rot because I did not think it was widely useful. I may eventually revisit that, since I can see cases where it could be useful. My intent was to handle laptops mounting through wifi/wan connections better, since those are often high latency connections. I suspect that some of your performance improvement is a result of the lack of cache consistency. For example, flushing of all written data to the server upon close(2) can be a big performance hit, but is required for close->open consistency. --> I honestly do not know how the Linux fscache code works, but I suspect that some variant of cache consistency is maintained by it. Another issue is that the comment in the bugs section of the mount_unionfs man page still applies (and is in caps). I don't know the details w.r.t. how unionfs is broken, but if it were easy to fix, someone would have done so. I do know that people report issues w.r.t. using unionfs on an NFS mount and I simply point out to them that it is broken. It does not make much sense to implement a new feature on top of a broken one, imho. kib@ is probably the only person who knows what the breakage in unionfs is and what needs to be done to fix it. rick ps: I don't think comments like "the one and only" are appreciated in the context you used it. --=20 You are receiving this mail because: You are the assignee for the bug.=