From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10045 invoked from network); 4 Feb 2021 16:34:39 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 4 Feb 2021 16:34:39 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A50599C9DD; Fri, 5 Feb 2021 02:34:38 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E92F79C7CB; Fri, 5 Feb 2021 02:33:10 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="JSKx6anY"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 31FA09C7CB; Fri, 5 Feb 2021 02:33:09 +1000 (AEST) Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) by minnie.tuhs.org (Postfix) with ESMTPS id 932909C0A7 for ; Fri, 5 Feb 2021 02:33:08 +1000 (AEST) Received: by mail-oo1-f43.google.com with SMTP id x23so901977oop.1 for ; Thu, 04 Feb 2021 08:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6lydT82SO9V4JiF21vz5O/d6zVmX/G4IHpyK9JKvm0k=; b=JSKx6anYVQaHf2Jz5ts3lbqVifbFZJIpa7ARiArP+N5mXlOzBqw49d2XqASlQHGuvi tmdOqT6dxOmmWuGI41EnFMyLVWx1bPvA5tu6S8o8V4hYxFsSwpTRxlD/cZ9pLkMzP/5c Rw8XT2SzUYcNJni6xIRWvHEDxPiSpzJk54n/5LopsY6XTNwCnzR2GD5yCDUtcWnC/mz0 krfaG1XlzjaxFYK8AtEEiRqCYvu0BaXExBmkrl970c/EvwXaaXRqo8lbpWiqXO1AD1+m P62FrgE4kAsJr0/q5dqXsYiHPVHYw6bLyvcCWu/h/ldgxwP418zgnizYwS/6rCgM787x wcLw== 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=6lydT82SO9V4JiF21vz5O/d6zVmX/G4IHpyK9JKvm0k=; b=hQWSajpf6gf9yOsDtrqLy7cCvEBZhhXa9nVPOWTTuakqk6kNOL+yQ+cvMQvtevPFXs +5zBgb31fVdP/cg9a1NKpRF1XvomGS4/56JK/dKS/cZ0n0ySEIriPdwHEVazVIn5ex1q pMyEBKRndtT8yvKvqfEI75yr6xD8De/tYz9ET8SgdHZmWzcJUTZIpY3/6cUe0hh9j7mE Ekpk1S2Fy1vu1yaZNya7sC3SCqrkeO2C4m4/rp1f/L2EoDtyI9pVCy6QGUIXQQKyKClf YrQ2BH7NA+C0HQoZ+BPhPMS9XETWENhtciLpjwsyvWYZ5cT0dRVYWulMj6yM/VCFqI4O d08Q== X-Gm-Message-State: AOAM532c9fSy+jIeOY5xn7AwKO/oj5ggj1VJTwsEGxiOixCquNvlRrtq Cy3BChr5A8caDeUY1+M7Dnd28PwElRuRXIhYwio= X-Google-Smtp-Source: ABdhPJzeN0ZV4G7t3gRvQWewmWej4ibGbGp58oiMdAWx3EE/4Sa/JVYxxJoFEeBxImCHhgBUpv1hcT4H/8XoTXx2o20= X-Received: by 2002:a4a:e383:: with SMTP id l3mr268978oov.78.1612456387744; Thu, 04 Feb 2021 08:33:07 -0800 (PST) MIME-Version: 1.0 References: <202101301950.10UJoWeA456408@darkstar.fourwinds.com> <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210131022500.GU4227@mcvoy.com> <9504e27d-d976-9681-6b97-aa87d124fc43@gmail.com> In-Reply-To: <9504e27d-d976-9681-6b97-aa87d124fc43@gmail.com> From: Dan Cross Date: Thu, 4 Feb 2021 11:32:31 -0500 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="00000000000035169205ba85422f" Subject: Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000035169205ba85422f Content-Type: text/plain; charset="UTF-8" On Thu, Feb 4, 2021 at 10:47 AM Will Senn wrote: > [snip] > > In response to the negative vibes around ZFS. [snip] > I think the discordance is around the semantics ZFS's implementation implies. Larry's point about mmap() vs a buffer cache is entirely valid; it took lots of people heroic amounts of work worthy of Greek sagas to bridge the difference between the original buffer and VM page caches, but ZFS says, "meh. too much work; not worth it." The practical implication of that is that memory mapped IO (via `mmap`) is no longer coherent with file IO (via `open`/`close`/`read`/`write`) without lots of work that both degrades performance and add complexity. The question that a lot of folks who use ZFS regularly ask is, "does that matter?" And perhaps it doesn't: if I've got a file server sitting there serving NFS, do I care what it's kernel is doing? As long as it's saturating the network and disks, and it's reliable...not really. (Incidentally, that was kind of the philosophy behind the original plan9 file server kernel...as I heard the story, the rate of change of the plan9 kernel proper was too high, so Ken split off the file server portion into its own, special-purpose kernel, and it stayed like that for ~20 years). Similarly, if I'm on the local machine and the required coherence code is there and largely works, then again, perhaps as a consumer of the filesystem, I just don't care. After all, one can still get work done, and ZFS has a bunch of other features that make it very attractive, right? In particular, it's very good at NOT losing my data, kernel purity be damned. On the other hand, if we're discussing OS design and implementation, (re)splitting the VM and buffer caches is a poor decision. One might well ask, "why?" and the answer may be, "because it adds significant complexity to the kernel." This to me seems like the crux of the disagreement. Satisfied users of ZFS might legitimately ask, "who cares?" and one might respond, "kernel maintainers." If the kernel is mostly transparent as far as a particular use case goes, though, then I can see why one would bulk at the suggestion that this matters. If one is concerned with the design and implementation of kernels, I could see why one would care very much. Like many things, it's a matter of perspective. - Dan C. --00000000000035169205ba85422f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 4, 2021 at 10:47 AM Will Senn= <will.senn@gmail.com> wro= te:
[snip]

In response to the negative vibes around ZFS. [snip]
<= br>
I think the discordance is around the semantics ZFS's imp= lementation implies. Larry's point about mmap() vs a buffer cache is en= tirely valid; it took lots of people heroic amounts of work worthy of Greek= sagas to bridge the difference between the original buffer and VM page cac= hes, but ZFS says, "meh. too much work; not worth it." The practi= cal implication of that is that memory mapped IO (via `mmap`) is no longer = coherent with file IO (via `open`/`close`/`read`/`write`) without lots of w= ork that both degrades performance and add complexity.

=
The question that a lot of folks who use ZFS regularly ask is, "d= oes that matter?" And perhaps it doesn't: if I've got a file s= erver sitting there serving NFS, do I care what it's kernel is doing? A= s long as it's saturating the network and disks, and it's reliable.= ..not really. (Incidentally, that was kind of the philosophy behind the ori= ginal plan9 file server kernel...as I heard the story, the rate of change o= f the plan9 kernel proper was too high, so Ken split off the file server po= rtion into its own, special-purpose kernel, and it stayed like that for ~20= years). Similarly, if I'm on the local machine and the required cohere= nce code is there and largely works, then again, perhaps as a consumer of t= he filesystem, I=C2=A0just don't care. After all, one can still get wor= k done, and ZFS has a bunch of other features that make it very attractive,= right? In particular, it's very good at NOT losing my data, kernel pur= ity be damned.

On the other hand, if we're dis= cussing OS design and implementation, (re)splitting the VM and buffer cache= s is a poor decision. One might well ask, "why?" and the answer m= ay be, "because it adds significant complexity to the kernel." Th= is to me seems like the crux of the disagreement. Satisfied users of ZFS mi= ght legitimately ask, "who cares?" and one might respond, "k= ernel maintainers." If the kernel is mostly transparent as far as a pa= rticular use case goes, though, then I can see why one would bulk at the su= ggestion that this matters. If one is concerned with the design and impleme= ntation of kernels, I could see why one would care very much.
Like many things, it's a matter of perspective.
<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--00000000000035169205ba85422f--