From owner-freebsd-fs@freebsd.org Wed Aug 5 16:06:38 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1CCA137A471 for ; Wed, 5 Aug 2020 16:06:38 +0000 (UTC) (envelope-from codeblue@inbox.lv) Received: from shark2.inbox.lv (shark2.inbox.lv [194.152.32.82]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BMGhY15qsz3WpM for ; Wed, 5 Aug 2020 16:06:36 +0000 (UTC) (envelope-from codeblue@inbox.lv) Received: from shark2.inbox.lv (localhost [127.0.0.1]) by shark2-out.inbox.lv (Postfix) with ESMTP id DC5EA3BFE6 for ; Wed, 5 Aug 2020 19:06:33 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shark2-in.inbox.lv (Postfix) with ESMTP id CF1233BFCA for ; Wed, 5 Aug 2020 19:06:33 +0300 (EEST) Received: from shark2.inbox.lv ([127.0.0.1]) by localhost (shark2.inbox.lv [127.0.0.1]) (spamfilter, port 35) with ESMTP id 0-3T6FQcz3VB for ; Wed, 5 Aug 2020 19:06:33 +0300 (EEST) Received: from mail.inbox.lv (pop1 [127.0.0.1]) by shark2-in.inbox.lv (Postfix) with ESMTP id 7D97A3BE3B for ; Wed, 5 Aug 2020 19:06:33 +0300 (EEST) Received: from [10.0.0.2] (bzq-109-65-93-146.red.bezeqint.net [109.65.93.146]) (Authenticated sender: codeblue@inbox.lv) by mail.inbox.lv (Postfix) with ESMTPA id 1C7303D980D for ; Wed, 5 Aug 2020 19:06:32 +0300 (EEST) Subject: Re: zfs scrub enable by default To: freebsd-fs References: <105090343.294898.1596586694925.JavaMail.zimbra@gray.id.au> <1327e123-35df-1e27-af7a-7225dae91a21@inbox.lv> From: John Long Message-ID: <71d447e6-3f18-319a-ec98-9e35feec3180@inbox.lv> Date: Wed, 5 Aug 2020 16:06:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: OK X-ESPOL: EZeEAiZdhRs1tcGiSfBh5uDgxtaxV1krujuJvbBJlW4g1r7As9drdmqLEofxGAa/bg== X-Rspamd-Queue-Id: 4BMGhY15qsz3WpM X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[inbox.lv:s=30062014]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[194.152.32.82:from]; R_SPF_ALLOW(-0.20)[+ip4:194.152.32.82:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; NEURAL_HAM_LONG(-1.03)[-1.030]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[inbox.lv:dkim]; RECEIVED_SPAMHAUS_PBL(0.00)[109.65.93.146:received]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[inbox.lv:+]; DMARC_POLICY_ALLOW(-0.50)[inbox.lv,quarantine]; NEURAL_HAM_SHORT(-1.07)[-1.068]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12993, ipnet:194.152.32.0/23, country:LV]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[194.152.32.82:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:06:38 -0000 On 05/08/2020 15:24, Alan Somers wrote: > On Wed, Aug 5, 2020 at 9:22 AM John Long via freebsd-fs > > wrote: > > On 05/08/2020 13:15, Bob Friesenhahn wrote: > > On Tue, 4 Aug 2020, Karl Denninger wrote: > > > >> Let me give you two allegedly "degenerate" cases that are > actually not > >> degenerate at all. > >> > >> 1. A laptop or workstation.  It is backed up.  It uses ZFS because > >> it's faster, and I can establish a filesystem for some project very > >> easily and quickly, it's segregated, I can work on it and > destroy it > >> trivially when done.  I can set quotas on that, etc.  If I want to > >> move its mountpoint, I can trivially do so. And so on.  Note > that here > >> there is no redundancy at all; no raidZx, no mirroring, etc.  I'm > >> merely using it for convenience. > > > > Did you remember to set copies=2 or copies=3 for zfs filesystems > where > > you hope not to experience data loss?  It needs to be set as soon as > > possible since it only applies to new files.  This is a way to > get more > > media redundancy, although the whole drive may fail. > > Does copies=n actually create n-1 additional physical copies or is it > copy-on-write, or something else yet? > > /jl > > > Yes, copies=3 will actually create 3 physical copies of the data > somewhere.  It's basically mirroring at the DMU layer, rather than the > block layer. > -Alan Thanks, I figured that must be the case but I thought it was better ask. So is it correct that aside from a single disk vdev, it would be a bad practice to specify additional copies? How does dedup deal with it? /jl