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.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23882 invoked from network); 27 Feb 2021 08:55:16 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 27 Feb 2021 08:55:16 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 971BD9CA8F; Sat, 27 Feb 2021 18:55:09 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0620393DC1; Sat, 27 Feb 2021 18:54:27 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id AFC4C93DC1; Sat, 27 Feb 2021 18:54:24 +1000 (AEST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by minnie.tuhs.org (Postfix) with ESMTPS id 122CC93D30 for ; Sat, 27 Feb 2021 18:54:24 +1000 (AEST) Received: by mail-pf1-f177.google.com with SMTP id 201so7893161pfw.5 for ; Sat, 27 Feb 2021 00:54:24 -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=GJOSNrmXqv2IdO3HnJfUi9pUty20RLq0Hdck10FDF8A=; b=oMkCsFCipaRrKVwMWAAcfB72X/Hy4XzhOqunEVTfOwHYglObnX9yuFlgMJbbNhWFzP KlVatzu2rKAI9cMXs4cL9lLG1SKEKVhN5Xproe1xk5MsEGuyCmpFQnWi2ciNKj6tI6LR RlE+fQszgh9I73owy4Vlvx6/p8MEU/Y9nbhJyA8LT1MkTSm4VHsMoAjbrZeVP8p5prXo 0O72V8ZPoaRU2hIC7lXc9CfaQbFR8Sqsh4OQmej0jG6FUjg8UNxGvlh5M/q8x6RzPph/ W+vXQY9KmUQUNyuMU0/BQG61Tp6YgFndBL5t8WhchaCYAtBqPFx/2o963/287+VRdJ4A 3BKQ== X-Gm-Message-State: AOAM531Ofj66PCQVCf3un6CGeTkJZ+oCb+TwhBtDUDoyMQT6MjAulONU p5FEExfQDPrA69+09vs7XpuAXz7EmyVdT+qAEouJPDy8szg= X-Google-Smtp-Source: ABdhPJxHt4lJjPiEotG/Auk7fE6+uVPe04t5aovFQd1JJ9rBxg13qEedE+1AtSBAQRxElP+srn2Q18JCRUFsoJFXndM= X-Received: by 2002:a63:1c08:: with SMTP id c8mr6243340pgc.228.1614416063343; Sat, 27 Feb 2021 00:54:23 -0800 (PST) MIME-Version: 1.0 References: <20210130222854.GN4227@mcvoy.com> <20210130231119.GA33905@eureka.lemis.com> <20210131022500.GU4227@mcvoy.com> <9504e27d-d976-9681-6b97-aa87d124fc43@gmail.com> <20210206025553.GY13701@mcvoy.com> In-Reply-To: <20210206025553.GY13701@mcvoy.com> From: Stuart Remphrey Date: Sat, 27 Feb 2021 16:54:11 +0800 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="000000000000f9b11e05bc4d87e1" 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: The Eunuchs Hysterical Society , Rico Pajarola Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000f9b11e05bc4d87e1 Content-Type: text/plain; charset="UTF-8" Hi Larry et al, Just curious about this: was there any feedback from Jeff Bonwick and/or Bill Moore re the ARC -vs- page cache? Or would any of the design notes document the reasoning behind the decision? Surely it must have come up and been justified or got an exception in the Solaris architecture review (SARC "20 Q's", wasn't it called?) Since AFAICS it affected Solaris O/S interface (former-)guarantees. Although those notes are probably lost / inaccessible now... There's also the monthly OpenZFS leadership meeting, Matt Ahrens et al are in there: I wonder if they would have access to some of the original reasoning; how it was justified / why it was permitted. Dave, btw: check out the high-level structure of ZFS metadata -- every block is checksummed, and the checksum kept in the parent block (i.e. *not* kept together), applicable for both data and metadata blocks, and at least two copies are kept of metadata (but you can request more depending on your paranoia, see also "ditto" blocks). Compression is optional at the filesystem level (not held at the pool aka volume level; a pool may contain multiple filesystems), when compression is enabled if affects future created files, same if unset or changed to another algorithm; the filesystem handles a mix of files (blocks, even; I forget offhand) existing with various or no compression. Rgds, Stuart. On Sat, 6 Feb 2021 at 10:56, Larry McVoy wrote: > On Fri, Feb 05, 2021 at 06:22:32PM -0800, Rico Pajarola wrote: > > On Fri, Feb 5, 2021 at 12:51 PM Dave Horsfall wrote: > > > Thanks; I'd heard that ZFS was a compressed file system, so I stopped > > > right there (I had lots of experience in recovering from corrupted > RK05s, > > > and didn't need any more trouble). > > > > > That's funny, for me this is the main reason to use ZFS... What really > sets > > ZFS apart from everything else is the lack of trouble and its resilience > to > > failures. > > I'm gonna call Bill tomorrow and get his take again, that's Bill Moore > one of the two main guys who did ZFS. > > This whole thread is sort of silly. There are the users of ZFS who love > it for what it does for them. I have no argument with them. Then there > are the much smaller, depressingly so, group of people who care about OS > design that think ZFS took a step backwards. > > I think Dennis might have stepped in here, if he was still with us, and > had some words. > > I think Dennis would have brought us back to lets talk about the kernel > and what is right. ZFS is useful, no doubt, but it is not right from > a kernel guy's point of view. > > I miss Dennis. > --000000000000f9b11e05bc4d87e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Larry et al,

Just curious about this= : was there any feedback from Jeff Bonwick and/or Bill Moore re the ARC -vs= - page cache?

Or would any of the design notes document the reasonin= g behind the decision?
Surely it must have come up and been justified o= r got an exception in the Solaris architecture review (SARC "20 Q'= s", wasn't it called?) Since AFAICS it affected Solaris O/S interf= ace (former-)guarantees. Although those notes are probably lost / inaccessi= ble now...


There's also the mon= thly OpenZFS leadership meeting, Matt Ahrens et al are in there: I wonder i= f they would have access to some of=C2=A0the original reasoning; how it was= justified / why it was permitted.


= Dave, btw: check out the high-level structure of ZFS metadata -- every bloc= k is checksummed, and the checksum kept=C2=A0in the parent block (i.e. *not= * kept together), applicable for both data and metadata blocks, and at leas= t two copies are kept of metadata (but you can request more depending on yo= ur paranoia, see also "ditto" blocks). Compression is optional at= the filesystem level (not held at the pool aka volume level; a pool may co= ntain multiple filesystems), when compression is enabled if affects future = created files, same if unset or changed to another algorithm; the filesyste= m handles a mix of files (blocks, even; I forget offhand) existing with var= ious or no compression.

Rgds, Stuart.

On Sat, 6 Feb 2021 at 10:56, Larry McVoy <lm@mcvoy.com> wrote:
On Fri, Feb 05, 2021 at 06:22:32PM -0800, Ric= o Pajarola wrote:
> On Fri, Feb 5, 2021 at 12:51 PM Dave Horsfall <dave@horsfall.org> wrote:
> > Thanks; I'd heard that ZFS was a compressed file system, so I= stopped
> > right there (I had lots of experience in recovering from corrupte= d RK05s,
> > and didn't need any more trouble).
> >
> That's funny, for me this is the main reason to use ZFS... What re= ally sets
> ZFS apart from everything else is the lack of trouble and its resilien= ce to
> failures.=C2=A0

I'm gonna call Bill tomorrow and get his take again, that's Bill Mo= ore
one of the two main guys who did ZFS.

This whole thread is sort of silly.=C2=A0 There are the users of ZFS who lo= ve
it for what it does for them.=C2=A0 I have no argument with them.=C2=A0 The= n there
are the much smaller, depressingly so, group of people who care about OS design that think ZFS took a step backwards.

I think Dennis might have stepped in here, if he was still with us, and
had some words.

I think Dennis would have brought us back to lets talk about the kernel
and what is right.=C2=A0 ZFS is useful, no doubt, but it is not right from<= br> a kernel guy's point of view.

I miss Dennis.
--000000000000f9b11e05bc4d87e1--