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, NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12305 invoked from network); 4 Feb 2021 16:53:14 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 4 Feb 2021 16:53:14 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 3E7049C9F5; Fri, 5 Feb 2021 02:53:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CF1059CA67; Fri, 5 Feb 2021 02:51:51 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="q2V0CdJp"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id F40F79C893; Fri, 5 Feb 2021 02:49:24 +1000 (AEST) Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) by minnie.tuhs.org (Postfix) with ESMTPS id DB5739C0A7 for ; Fri, 5 Feb 2021 02:49:23 +1000 (AEST) Received: by mail-oo1-f42.google.com with SMTP id u7so920119ooq.0 for ; Thu, 04 Feb 2021 08:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gbRaxPPYBsa2v7KVl9ro8A2EgKwfOpgGNhWO2xFKnBE=; b=q2V0CdJpPuH05kFA6j1/IAgRw9CTZd0ml1E00osf5ek5IETYeECENH+7+St6mmAois fC70MiYDZoLjcXx2Z813+d8Geiy20SqXzQvtE65a07jVS3U59+O3vjPhWFneH6U4wVqS HuSgY0sDPHyQT5vj+bVmYItsWQ41YgyV5ohSv7CyxBQ7EV7FG7j1lFMWfO83pfeByB1e uLiVgZnC5HLNjAkqFESqwaBAXIjK1VfWIowATEKtmKqg3X5lE6+itHA/2PZIXKMc2L4T MLSEtSb2Ml+4VFdnzM5mIjDkpewsM7EKDOLxoMh7lw4WLrlIGuAEeglbbbc7BRQFxvsa UKtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gbRaxPPYBsa2v7KVl9ro8A2EgKwfOpgGNhWO2xFKnBE=; b=ZlCtaWB+YP0U2k78ZXCt+3RTEHzQ6WUg+lO1MC8CscPpui2khCHMRUFGsdQ5yiq9KR KcYjyJPGFIxsLVlSMy0k+CkMr9l1Ksf81MoOynsLFcMrhETU6v5q1tOXgwbdTbeXOoBI J4FnBOAcJfbsIB3G5PGyifoc7lA7CaFc0FNFSQuE9/esjvFajMciKaW/7Y41IMgKB6O4 ZCNUKJw1N2AjBmndfBxnBMzNqAw4nKrsRgl1U6Eue4Axiyt2YaTQXShaLfUsrmdLIqPf QDNKfWNCRUQ8CVZkvWUjJrwGg81N29pNC51M62akJLdohcy01yOjU9rWkoBGlv1SCgcv eVww== X-Gm-Message-State: AOAM530LjIa+NEr4E3VEjbcYVEs3vHlUV+7mHzItt4HantD1eQhgnJEi +IbIhu36m0cbsUnb6qx2N8Xsp1tZclO5YQ== X-Google-Smtp-Source: ABdhPJwimQqD+5BAnkccrNINPQGfN7Go4X9VkpBeP/VmHNx/xS6IZ/54uImQV7S3l9AwdTfmZcO/6g== X-Received: by 2002:a4a:e936:: with SMTP id a22mr282395ooe.91.1612457362963; Thu, 04 Feb 2021 08:49:22 -0800 (PST) Received: from terra.local ([2001:49d0:142:1500:1d21:45cf:6041:b6a8]) by smtp.gmail.com with ESMTPSA id n30sm1239235otj.42.2021.02.04.08.49.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Feb 2021 08:49:22 -0800 (PST) To: Dan Cross 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> From: Will Senn Message-ID: <48c18873-a536-d2e5-04cd-f5c581901726@gmail.com> Date: Thu, 4 Feb 2021 10:49:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36509F56A4AD883B8AA0D5F6" Content-Language: en-US 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" This is a multi-part message in MIME format. --------------36509F56A4AD883B8AA0D5F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/4/21 10:32 AM, Dan Cross wrote: > 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. > Thanks for the comments, Dan. I see your point. I was thinking as a user/admin. In this light, I'll admit that I'm not an expert on the internals and say that I can only imagine the breadth of design tradeoffs that were contemplated and the many decisions that were made when coming up with ZFS. I'm glad somebody thought through them, and worked through them, though. So I could consume their work, Frankensteinian though it may be. Now, if somebody would only get it working properly in Linux (boot environments included), or even get BTRFS to be more realiable, I'd be a happy camper, at least for a while :). --------------36509F56A4AD883B8AA0D5F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/4/21 10:32 AM, Dan Cross wrote:
On Thu, Feb 4, 2021 at 10:47 AM Will Senn <will.senn@gmail.com> 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.

Thanks for the comments, Dan. I see your point. I was thinking as a user/admin. In this light, I'll admit that I'm not an expert on the internals and say that I can only imagine the breadth of design tradeoffs that were contemplated and the many decisions that were made when coming up with ZFS. I'm glad somebody thought through them, and worked through them, though. So I could consume their work, Frankensteinian though it may be. Now, if somebody would only get it working properly in Linux (boot environments included), or even get BTRFS to be more realiable, I'd be a happy camper, at least for a while :).

--------------36509F56A4AD883B8AA0D5F6--