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=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17824 invoked from network); 4 Feb 2021 22:28:47 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 4 Feb 2021 22:28:47 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 804409BC29; Fri, 5 Feb 2021 08:28:45 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AED869BA45; Fri, 5 Feb 2021 08:28:27 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=algebras-org.20150623.gappssmtp.com header.i=@algebras-org.20150623.gappssmtp.com header.b="W8jthxNl"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id DEA3C9BA45; Fri, 5 Feb 2021 08:28:25 +1000 (AEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by minnie.tuhs.org (Postfix) with ESMTPS id A03019BA40 for ; Fri, 5 Feb 2021 08:28:24 +1000 (AEST) Received: by mail-pf1-f182.google.com with SMTP id b145so3019973pfb.4 for ; Thu, 04 Feb 2021 14:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=LQ/0SC7T0e+ZSvp0w34BQ/O0d+GQ2iRQJ/epjohnOWc=; b=W8jthxNldP3xRRh94npEczaRZTIZ1r5o+GhKJ4ztWgMWreV6jXPbpST0BxAY7oBvPc KSYG78UTVotNB/plimqMMX0+NtcjCglR2Y+SIWroCaYHvX9msjH5mySmbZGyIjxPaLkR Fdp64NeDufq+Kn3TLjcHYs+FmnXn8iXlFQB/GK3iNL6g/YZ8pwQN3BEqb3EESTGpeVhu A0G7Ojced8ljYKaz4rgPS3kozG8QTUqyIabG2WHRiqv6cDduBlPEV6eDCuDLZjEBEI09 FwVEbljKzvxSpz1Bu+RYIhMe7g4VquPWo3rzHB34a/YD7ckWt6AaTr3Ek5aKxYgrLX3h AQAA== 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:content-transfer-encoding; bh=LQ/0SC7T0e+ZSvp0w34BQ/O0d+GQ2iRQJ/epjohnOWc=; b=YcPwMkNzcDY3+tbHfsuLJ8kBq+W92jwl6dTnD0Lhm3bL5Zein1ahCsgydm5ZZxvSzB M9QGIQ2DnWUDxc6rG1CxEG5pWMYLG3y9JDRH1UXp7qsdTpE0/knOSgm0Y/skuEoOxCrw +zpNGcdoqacJagGd6OY6UNR2kcNIYSRWZ9zXcPkNKLCEbHuLrSa8weV9N8moUBQ5uwIm 58SgTxeDSPIye0RMbhoQOgT8tbWJFbiUK9/fUF35bRGSzpTup4ZALZ1r3IpfKnKnHoVl j9MGLhaqYAb/U9rLt9VmrnsTuFyR2jLtixPRi5ZLky8OI9QW/NNqx2IIe8xHFkwfdzkh zjqw== X-Gm-Message-State: AOAM5317/9ej3KuRix3qaiBRQp7tIznG2/2Zyy10bgPoTEnBCU/tHZtH +O1N3Y+r3icTOO6+iT46rGR1CKBT2+ytxjBk0gn3NXyX01E= X-Google-Smtp-Source: ABdhPJz7eVbOPnJ7TiNcV/0SQXRual0sj2RDmMrn3Ag+gKG1wTb+JOpILZ7yxXSAE5oRASsi+02c429ALPRMsyMbmHc= X-Received: by 2002:a63:f34f:: with SMTP id t15mr1107957pgj.239.1612477703520; Thu, 04 Feb 2021 14:28:23 -0800 (PST) MIME-Version: 1.0 References: <46DC5B33-1F08-4DAE-ACAC-4318DB1498DA@iitbombay.org> In-Reply-To: <46DC5B33-1F08-4DAE-ACAC-4318DB1498DA@iitbombay.org> From: George Michaelson Date: Fri, 5 Feb 2021 08:28:12 +1000 Message-ID: To: TUHS main list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" snapshots of FS state existed for years before ZFS/BTRFS did it, because FS journaling existed. The underlying model of COW forking of the inodes and a journal were all there. What ZFS did, and what Docker does, and snap does, and flatpack does, is package things in a way which make modalities for use for modern sysadmin "just work" I don't recall seeing a backup model built on UFS+journalling with an integrated command tooling to do what zfs snapshot; zfs send | zfs receive does as an incremental copy mechanism. I'm not trying to disrespect the prior art, if there was a good packaging, I probably missed it. ZFS made this "yea, I get it now" for a lot of people. I think ZFS is fine. I have adopted it wholesale in the work context for the last 15+ years and at home for about a year. The FUD around minimum memory for ARC is a misunderstanding of an Oracle document "back then" and you can run ZFS on rPi class systems fine, if you can accept some lumpy paging and VM behaviour, and if you don't enable compression which burns the ARC. (you need the extent of memory to deal with things a lot more) -And there are modern OpenZFS docs which patiently explain this stuff. Zsys is going to get better. This means rollback from systems update under Ubuntu snaps and things, will get better. It will be a lot less risky to do significant upgrade on systems. -Think about Android and the two-root model of updating the passive root in the background, so the new OS is live across a reboot without having the spinning beachball of upgrade on your phone, or analogues of the "keep this setting or go back" model WIndows does, and Windows has had OS snapshots for a long time now, and offers "undo that major update" models to users: people expect this. I also think ZFS was a godsend for getting over the smart RAID card mistakes of the past. I HAVE lost data with these puppies. I've moved multi TB fs between FreeBSD and Linux and back again (with care) under ZFS, and you can't do that with Apples FS, or EXT3 with anything like the same confidence. Really? I like UUID. UUID are a godsend, for making things have unique, but asynchronously generated identity, so when you move them and mix them, you can stop worrying about device/bus order and simply re-create them as they were defined semantically. ZFS does this too: zfs import is leveraging what UUID does for you. Basically Larry, I think you are kindof wrong. These alumni of yours did what all kids should do: they ran ahead. Did they scrape their knees doing it? Sure. But if they don't try things their teachers say are bad, how do they advance the art? If we'd listened to Eddy Dijkstra, we'd never have got BGP: He said it couldn't scale, even though it was based on his own work. -G On Fri, Feb 5, 2021 at 4:41 AM Bakul Shah wrote: > > On Feb 4, 2021, at 8:34 AM, Dan Cross wrote: > > > > On the other hand, if we're discussing OS design and implementation, (r= e)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, "k= ernel maintainers." If the kernel is mostly transparent as far as a particu= lar use case goes, though, then I can see why one would bulk at the suggest= ion that this matters. If one is concerned with the design and implementati= on of kernels, I could see why one would care very much. > > Largely agree; though the complexity battle has long been lost. On multip= le fronts. Many of us are happy to use such complex systems for their ease = of use or their feature set but wouldn=E2=80=99t want to maintain these sys= tems! > > I have used ZFS since 2005 and largely happy with it. Replaced all the di= sks twice. Moved the same set of disks to a new machine. etc. Features: che= ap and fast snapshots, send/receive, clone, adding disks, checksummed block= s, redundancy etc. The dedup impl. is suboptimal so I don't use it. No idea= if they considered using a bloom filter and a cache to reduce memory use. = If a new FS came along with a similar set of features and a simpler, better= integrated implementation, I'd switch. > >