Date: Thu, 02 May 2019 00:06:33 +1000 From: Michelle Sullivan <michelle@sorbs.net> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: ZFS... Message-ID: <165446da-7b9a-26a3-e92f-41095382232e@sorbs.net> In-Reply-To: <713FB681-94F6-4F3A-AC69-417362D29B6E@gromit.dlib.vt.edu> References: <30506b3d-64fb-b327-94ae-d9da522f3a48@sorbs.net> <CAOtMX2gf3AZr1-QOX_6yYQoqE-H%2B8MjOWc=eK1tcwt5M3dCzdw@mail.gmail.com> <56833732-2945-4BD3-95A6-7AF55AB87674@sorbs.net> <3d0f6436-f3d7-6fee-ed81-a24d44223f2f@netfence.it> <17B373DA-4AFC-4D25-B776-0D0DED98B320@sorbs.net> <70fac2fe3f23f85dd442d93ffea368e1@ultra-secure.de> <70C87D93-D1F9-458E-9723-19F9777E6F12@sorbs.net> <CAGMYy3tYqvrKgk2c==WTwrH03uTN1xQifPRNxXccMsRE1spaRA@mail.gmail.com> <5ED8BADE-7B2C-4B73-93BC-70739911C5E3@sorbs.net> <d0118f7e-7cfc-8bf1-308c-823bce088039@denninger.net> <2e4941bf-999a-7f16-f4fe-1a520f2187c0@sorbs.net> <CAOtMX2gOwwZuGft2vPpR-LmTpMVRy6hM_dYy9cNiw%2Bg1kDYpXg@mail.gmail.com> <34539589-162B-4891-A68F-88F879B59650@sorbs.net> <CAOtMX2iB7xJszO8nT_KU%2BrFuSkTyiraMHddz1fVooe23bEZguA@mail.gmail.com> <576857a5-a5ab-eeb8-2391-992159d9c4f2@denninger.net> <A7928311-8F51-4C72-839C-C9C2BA62C66E@sorbs.net> <713FB681-94F6-4F3A-AC69-417362D29B6E@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Mather wrote: > On Apr 30, 2019, at 8:14 PM, Michelle Sullivan <michelle@sorbs.net> > wrote: > >> >> >> Michelle Sullivan >> http://www.mhix.org/ >> Sent from my iPad >> >>> On 01 May 2019, at 01:15, Karl Denninger <karl@denninger.net> wrote: >>> >>> >>> IMHO non-ECC memory systems are ok for personal desktop and laptop >>> machines where loss of stored data requiring a restore is acceptable >>> (assuming you have a reasonable backup paradigm for same) but not for >>> servers and *especially* not for ZFS storage. I don't like the >>> price of >>> ECC memory and I really don't like Intel's practices when it comes to >>> only enabling ECC RAM on their "server" class line of CPUs either >>> but it >>> is what it is. Pay up for the machines where it matters. >> >> And the irony is the FreeBSD policy to default to zfs on new installs >> using the complete drive.. even when there is only one disk available >> and regardless of the cpu or ram class... with one usb stick I have >> around here it attempted to use zfs on one of my laptops. > > > ZFS has MUCH more to recommend it than just the "self-healing" > properties discussed in this thread. Its pooled storage model, good > administration and snapshot/clone support (enabling features such as > boot environments) make it preferable over UFS as a default file > system. You can even gain the benfits of self-healing (for silent > data corruption) for single-drive systems via "copies=2" or "copies=3" > on file sets. > > >> Damned if you do, damned if you don’t comes to mind. > > > Not really. Nobody is forcing anyone only to use ZFS as a choice of > file system. As you say above, it is a default (a very sensible one, > IMHO, but even then, it's not really a default). If you believe ZFS > is not right for you, do a UFS installation instead. > > BTW, I disagree that you need top-notch server-grade hardware to use > ZFS. Its design embodies the notion of being distrustful of the > hardware on which it is running, and it is targeted to be able to > survive consumer hardware (as has been pointed out elsewhere in this > thread), e.g., HBAs without BBUs. > > I am using ZFS on a Raspberry Pi with an external USB drive. How's > that for server-grade hardware? :-) > Was I drunk posting again? I thought others were advocating that server grade hardware was suitable for ZFS and if you are using consumer grade, you get what you pay for and dont blame ZFS etc.. This is an interesting issue... 2 thoughts of mind... ZFS safe to use on COnsumer hardware or not? ECC necessary or not? "The data on disk is always right" or not? .. it can't be all of the above by the very nature of the arguments that all seem to be against me, but not against each other... even though they are directly in conflict (and I have seen this on other ZFS lists... usually just before or after the justification for no 'FSCK for ZFS' (which after looking deeply into how ZFS works, I mostly agree with - which I stated earlier) - though a 'ZFS walk' tool may be the compromise that satisfies those who believe that an FSCK should be available and usually have no idea why it probably can never happen.... I will point out that someone from this thread messaged me this: https://www.klennet.com/zfs-recovery/default.aspx - which seems to be exactly what I'm talking about - a 'zfs walk' sorta told however... it's winblows only ... but if it does what it says on the packet.. this would probably be the missing link that would appease most ZFS detractors and people like me - who think ZFS is good for those with server grade hardware, but really not a good idea for the general linux user... :) (*waits for the flames*) -- Michelle Sullivan http://www.mhix.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?165446da-7b9a-26a3-e92f-41095382232e>