From: Brad Spencer <brad@anduin.eldar.org>
To: Dave Horsfall <dave@horsfall.org>
Cc: tuhs@tuhs.org
Subject: Re: [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?)
Date: Fri, 05 Feb 2021 19:21:08 -0500 [thread overview]
Message-ID: <xon8s826o7f.fsf@anduin.eldar.org> (raw)
In-Reply-To: <alpine.BSF.2.21.9999.2102060736590.70858@aneurin.horsfall.org> (message from Dave Horsfall on Sat, 6 Feb 2021 07:50:17 +1100 (EST))
Dave Horsfall <dave@horsfall.org> writes:
> On Thu, 4 Feb 2021, Will Senn wrote:
>
>> ZFS needn't be compressed, and I don't generally do compression or
>> encryption unless required by law, so I can't speak from personal
>> experience on those use cases (others, far more experienced can). I do
>> know that it's truly a pain to recover from issues with either.
>
> [...]
>
> Thanks; I'd heard that ZFS was a compressed file system, so I stopped
> right there (I had lots of experience in recovering from corrupted RK05s,
> and didn't need any more trouble).
[snip]
I have some real world experience with ZFS and bad blocks. As mentioned
by others, compression is not required, but it would not matter too
much. ZFS is somewhat odd in that you can mount and use a damaged
filesystem without too much trouble and recover anything possible. A
real example (and to keep it a TUHS topic), we had an older Solaris 10
Sparc at the $DAYJOB about two years ago that developed bad blocks on
the drive (ZFS detected this for us). Not a surprise given the age of
the system, being 6 to 8 years old at the time, we replaced the drive
without issue and started a re-silver (ZFS's version of fsck and raid
rebuild) and during that re-silver another drive developed block errors.
This was a RAIDZ1 set up, so having two drives go out at the same time
would cause something to be lost. If it were another RAID variant, it
would probably have been fatal. What ZFS did was told us exactly which
file was effected by the bad block and the system kept going, no
unmounts, reboots or down time. We replaced the second drive and the
only problem we had was a single lost file. Compression would not have
changed this situation much, except perhaps making the problem a bit
bigger, we may have lost two files or something. I have another example
with a Sun NFS appliance that runs under the covers Solaris 11 that
developed multiple drive fails. In the end, we estimated that around
40% or so of the multi terabyte filesystem was damaged. It was possible
to still use the appliance and we were able to get a lot off of it as it
continued to function as best as it could you just could not access the
files that had bad blocks in them. ZFS has honestly been amazing in the
face of the problems I have seen.
--
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
next prev parent reply other threads:[~2021-02-06 0:32 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 11:10 [TUHS] Favorite unix design principles? Tyler Adams
2021-01-25 12:32 ` Steve Nickolas
2021-01-26 2:06 ` M Douglas McIlroy
2021-01-26 2:53 ` Steve Nickolas
2021-01-26 10:22 ` Tyler Adams
2021-01-26 12:26 ` John P. Linderman
2021-01-26 15:23 ` Clem Cole
2021-01-26 16:00 ` Niklas Karlsson
2021-01-26 16:13 ` Adam Thornton
[not found] ` <CAKH6PiXKjksEpQOMMMQTbcsMvX2thz3WzqjoRWJAsXnZ4Eq_iQ@mail.gmail.com>
2021-01-30 19:01 ` Tyler Adams
2021-01-30 19:50 ` Jon Steinhart
2021-01-30 20:06 ` Tyler Adams
2021-01-30 21:28 ` Clem Cole
2021-01-30 21:42 ` Dave Horsfall
2021-01-30 21:45 ` Tyler Adams
2021-01-30 22:31 ` Larry McVoy
2021-01-30 22:28 ` Larry McVoy
2021-01-30 23:11 ` [TUHS] FreeBSD behind the times? (was: Favorite unix design principles?) Greg 'groggy' Lehey
2021-01-30 23:17 ` Larry McVoy
2021-01-30 23:22 ` Warner Losh
2021-01-30 23:31 ` [TUHS] [SPAM] " Larry McVoy
2021-01-30 23:37 ` Jon Steinhart
2021-01-30 23:54 ` Larry McVoy
2021-01-31 12:23 ` [TUHS] [SPAM] Re: FreeBSD behind the times? Dermot Tynan
2021-01-31 0:00 ` [TUHS] [SPAM] Re: FreeBSD behind the times? (was: Favorite unix design principles?) Bakul Shah
2021-02-09 2:15 ` [TUHS] " Will Senn
2021-02-09 2:16 ` Will Senn
2021-02-09 2:30 ` Greg 'groggy' Lehey
2021-01-31 0:39 ` Steve Nickolas
2021-01-31 1:47 ` Will Senn
2021-01-31 2:25 ` Larry McVoy
2021-01-31 2:52 ` Will Senn
2021-01-31 3:00 ` Larry McVoy
2021-01-31 3:06 ` Will Senn
2021-01-31 3:32 ` John Cowan
2021-02-04 5:43 ` Dave Horsfall
2021-02-04 6:10 ` Angus Robinson
2021-02-04 7:46 ` Andy Kosela
2021-02-04 22:25 ` Dave Horsfall
2021-02-04 15:45 ` Will Senn
2021-02-04 16:03 ` Henry Bent
2021-02-04 16:32 ` Dan Cross
2021-02-04 16:49 ` Will Senn
2021-02-04 17:46 ` Larry McVoy
2021-02-04 18:41 ` Bakul Shah
2021-02-04 22:28 ` George Michaelson
2021-02-04 22:41 ` Bakul Shah
2021-02-05 0:33 ` Larry McVoy
2021-02-05 5:17 ` Bakul Shah
2021-02-05 14:18 ` Larry McVoy
2021-02-05 18:16 ` Warner Losh
2021-02-05 18:21 ` ron minnich
2021-02-06 0:03 ` Bakul Shah
2021-02-06 2:06 ` Dan Cross
2021-02-06 3:01 ` Bakul Shah
2021-02-06 1:18 ` John Gilmore
2021-02-06 1:43 ` joe mcguckin
2021-02-06 1:55 ` Bakul Shah
2021-02-05 20:50 ` Dave Horsfall
2021-02-06 0:21 ` Brad Spencer [this message]
2021-02-06 2:22 ` Rico Pajarola
2021-02-06 2:55 ` Larry McVoy
2021-02-06 3:07 ` Will Senn
2021-02-27 8:54 ` Stuart Remphrey
2021-02-06 4:55 ` John Cowan
2021-02-04 7:46 ` Chris Torek
2021-02-04 15:47 ` Will Senn
2021-02-11 21:01 ` Angel M Alganza
2021-01-30 23:09 ` [TUHS] Favorite unix design principles? John Cowan
2021-01-30 23:22 ` Jon Steinhart
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=xon8s826o7f.fsf@anduin.eldar.org \
--to=brad@anduin.eldar.org \
--cc=dave@horsfall.org \
--cc=tuhs@tuhs.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).