From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id dc2068bb for ; Tue, 27 Aug 2019 01:00:01 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 76B4F9BB71; Tue, 27 Aug 2019 11:00:00 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 37E019BB94; Tue, 27 Aug 2019 10:59:30 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=kilonet.net header.i=@kilonet.net header.b="Qa3JhB9Z"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2280A9B4F3; Tue, 27 Aug 2019 10:59:08 +1000 (AEST) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) by minnie.tuhs.org (Postfix) with ESMTPS id 246DE9B4F2 for ; Tue, 27 Aug 2019 10:59:07 +1000 (AEST) Received: from medusa.kilonet.net ([72.69.11.97]) by :SMTPAUTH: with ESMTPA id 2PpBio1JKa7Ad2PpCivsPx; Mon, 26 Aug 2019 17:59:06 -0700 Received: from [199.89.231.101] (ender.kilonet.net [199.89.231.101]) by medusa.kilonet.net (8.14.8/8.15.1) with ESMTP id x7R0x50L002249; Mon, 26 Aug 2019 20:59:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kilonet.net; s=default; t=1566867545; bh=SH8KKvd7fD9H5uADZ+nNV/KhXBEaGrf8n9WT2+5oOWc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Qa3JhB9Z7JMaQwSLNh+WlyV2ixBt6/7IMW1v2Xc+x09BKd/zS6r8l/Sqy8O85KhFk 3RIZjqeuCRejE6QU64N8ryk3JYHJlrZ8NODZ0iT5xpNbAUCss0/2VGavu8ZVKLHxWp Us3b7BLV+t6Sy115q8C0gJOdkL/9GTkqVzR+s+ps= To: Larry McVoy References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> From: Arthur Krewat Message-ID: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> Date: Mon, 26 Aug 2019 20:59:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190827003013.GS13570@mcvoy.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfIestoa6H0/iq/ydPIw99GIIJZRGCdxLwpsuey2/mvTUtI6SfYDPqQjUUzr2axQUJ+XAIQSXbzB3HuKzfNbjn46f/aZMJBqfphstV1Xp8nx5gMkVzgr5 eE6KReQ2n+Zd4611pJ3TfwwlVSbe1I3aXyipvTwn2kg/crXrqgLnWyEYrU9NqDE2FpfCj4zRZU8xlw== Subject: Re: [TUHS] If not Linux, then what? 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@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8/26/2019 8:30 PM, Larry McVoy wrote: > > I really don't understand the love for ZFS. I hired Bonwick and I > hired Moore, I had high expectations but they were all dashed when I > realized ZFS doesn't use the page cache. That's so crazy busted I lost > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > At the risk of going off-topic: From a system-administration standpoint, and data-integrity standpoint, ZFS was a huge step forward. In my humble opinion ;) Besides the obvious (to me) benefits of adding mount points, adjusting volume sizes, and all the other things that ZFS does, I have yet to find any mainstream filesystem (if you can call ZFS "just" a filesystem) that guarantees data integrity. I have an office server, that contains a lot of source code and archived data that I depend on religiously. I do copious backups to LTO tapes as well as an off-site Amazon EC2 instance. Within the recent past few years, I had an issue with a Dell MD Raid array where ZFS was complaining about checksum errors on a certain disk. Data was being corrupted on the fly. It seems that the writes were being corrupted, not reads. Thankfully, it was on a RAIDZ2 volume, where it could correct the corruption. The corruption in question was on files that are dated back to the early 90's. Stopping bit-rot in it's tracks, ZFS has done me well. As for what mmap() doesn't do right, I started using memory mapped files back in the early 80s on VMS on a VAX-11/780 when I and a colleague were converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding your dislike for mmap() but please, enlighten me. It was my understanding at the time that it was akin to swapping/virtual-memory using an MMU. The difference was that instead of using the main paging area, the kernel would use an actual file.  Why would mmap() be a bad thing, when it's hooked into the kernel, and possibly hardware, at such a low point? art k.