From: firstname.lastname@example.org (Norman Wilson) To: email@example.com Subject: Re: [TUHS] Is it time to resurrect the original dsw (delete with switches)? Date: Mon, 30 Aug 2021 09:06:03 -0400 (EDT) [thread overview] Message-ID: <20210830130603.A7D4C640CC6@lignose.oclsc.org> (raw) Not to get into what is soemthing of a religious war, but this was the paper that convinced me that silent data corruption in storage is worth thinking about: http://www.cs.toronto.edu/~bianca/papers/fast08.pdf A key point is that the character of the errors they found suggests it's not just the disks one ought to worry about, but all the hardware and software (much of the latter inside disks and storage controllers and the like) in the storage stack. I had heard anecdotes long before (e.g. from Andrew Hume) suggesting silent data corruption had become prominent enough to matter, but this paper was the first real study I came across. I have used ZFS for my home file server for more than a decade; presently on an antique version of Solaris, but I hope to migrate to OpenZFS on a newer OS and hardware. So far as I can tell ZFS in old Solaris is quite stable and reliable. As Ted has said, there are philosophical reasons why some prefer to avoid it, but if you don't subscribe to those it's a fine answer. I've been hearing anecdotes since forever about sharp edges lurking here and there in BtrFS. It does seem to be eternally unready for production use if you really care about your data. It's all anecdotes so I don't know how seriously to take it, but since I'm comfortable with ZFS I don't worry about it. Norman Wilson Toronto ON PS: Disclosure: I work in the same (large) CS department as Bianca Schroeder, and admire her work in general, though the paper cited above was my first taste of it.
next reply other threads:[~2021-08-30 13:07 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-30 13:06 Norman Wilson [this message] 2021-08-30 14:42 ` Theodore Ts'o 2021-08-30 18:08 ` Adam Thornton 2021-08-30 16:46 ` Arthur Krewat -- strict thread matches above, loose matches on Subject: below -- 2021-08-29 22:12 Jon Steinhart 2021-08-29 23:09 ` Henry Bent 2021-08-30 3:14 ` Theodore Ts'o 2021-08-30 13:55 ` Steffen Nurpmeso 2021-08-30 9:14 ` John Dow via TUHS 2021-08-29 23:57 ` Larry McVoy 2021-08-30 1:21 ` Rob Pike 2021-08-30 3:46 ` Theodore Ts'o 2021-08-30 23:04 ` Bakul Shah 2021-09-02 15:52 ` Jon Steinhart 2021-09-02 16:57 ` Theodore Ts'o 2021-08-30 3:36 ` Bakul Shah 2021-08-30 11:56 ` Theodore Ts'o 2021-08-30 22:35 ` Bakul Shah 2021-08-30 15:05 ` Steffen Nurpmeso 2021-08-31 13:18 ` Steffen Nurpmeso 2021-08-30 21:38 ` Larry McVoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210830130603.A7D4C640CC6@lignose.oclsc.org \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [TUHS] Is it time to resurrect the original dsw (delete with switches)?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).