Date: Wed, 5 Aug 2020 16:06:29 +0000 From: John Long <codeblue@inbox.lv> To: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: zfs scrub enable by default Message-ID: <71d447e6-3f18-319a-ec98-9e35feec3180@inbox.lv> In-Reply-To: <CAOtMX2i7QffwdOxPLSk6H5a-xstYyr4qzLP4-djzEEtHVqYBJQ@mail.gmail.com> References: <cca34d1a-1892-41ec-ce45-84865100c6e1@FreeBSD.org> <CAJjvXiEXEdAFXpXkGvt4fymA17kNdp6XkZV5taGKLoP2GvMHbw@mail.gmail.com> <d1b580da-1539-5fc9-f7a3-3f013bba4ef3@FreeBSD.org> <CANCZdfq2PneFvB4rnz2iGu5srFFFjs8N=7FwRO3DYjosESWXtQ@mail.gmail.com> <CAGuotKD0mCS3KmMA-EGL1uH_fByYOhMKbPVDoTdB8dg5kC-u9g@mail.gmail.com> <105090343.294898.1596586694925.JavaMail.zimbra@gray.id.au> <alpine.GSO.2.20.2008042010300.10299@scrappy.simplesystems.org> <e5e7a916-4da2-6467-1616-1b1a75f32509@denninger.net> <alpine.GSO.2.20.2008050808330.10299@scrappy.simplesystems.org> <1327e123-35df-1e27-af7a-7225dae91a21@inbox.lv> <CAOtMX2i7QffwdOxPLSk6H5a-xstYyr4qzLP4-djzEEtHVqYBJQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/08/2020 15:24, Alan Somers wrote: > On Wed, Aug 5, 2020 at 9:22 AM John Long via freebsd-fs > <freebsd-fs@freebsd.org <mailto:freebsd-fs@freebsd.org>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71d447e6-3f18-319a-ec98-9e35feec3180>