The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah <>
To: Jon Steinhart <>
Cc: The Unix Heretics Society mailing list <>
Subject: Re: [TUHS] Is it time to resurrect the original dsw (delete with switches)?
Date: Sun, 29 Aug 2021 20:36:37 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Chances are your disk has a URE 1 in 10^14 bits ("enterprise" disks
may have a URE of 1 in 10^15). 10^14 bit is about 12.5TB. For 16TB
disks you should use at least mirroring, provided some day you'd want
to fill up the disk. And a machine with ECC RAM (& trust but verify!).
I am no fan of btrfs but these are the things I'd consider for any FS.
Even if you have done all this, consider the fact that disk mortality
has a bathtub curve.

I use FreeBSD + ZFS so I'd recommend ZFS (on Linux).

ZFS scrub works in background on an active system. Similarly resilvering
(thought things slow down). On my original zfs filesystem I replaced
all the 4 disks twice. I have been using zfs since 2005 and it has rarely
required any babysitting. I reboot it when upgrading to a new release or
applying kernel patches. "backups" via zfs send/recv of snapshots.

> On Aug 29, 2021, at 3:12 PM, Jon Steinhart <> wrote:
> I recently upgraded my machines to fc34.  I just did a stock
> uncomplicated installation using the defaults and it failed miserably.
> Fc34 uses btrfs as the default filesystem so I thought that I'd give it
> a try.  I was especially interested in the automatic checksumming because
> the majority of my storage is large media files and I worry about bit
> rot in seldom used files.  I have been keeping a separate database of
> file hashes and in theory btrfs would make that automatic and transparent.
> I have 32T of disk on my system, so it took a long time to convert
> everything over.  A few weeks after I did this I went to unload my
> camera and couldn't because the filesystem that holds my photos was
> mounted read-only.  WTF?  I didn't do that.
> After a bit of poking around I discovered that btrfs SILENTLY remounted the
> filesystem because it had errors.  Sure, it put something in a log file,
> but I don't spend all day surfing logs for things that shouldn't be going
> wrong.  Maybe my expectation that filesystems just work is antiquated.
> This was on a brand new 16T drive, so I didn't think that it was worth
> the month that it would take to run the badblocks program which doesn't
> really scale to modern disk sizes.  Besides, SMART said that it was fine.
> Although it's been discredited by some, I'm still a believer in "stop and
> fsck" policing of disk drives.  Unmounted the filesystem and ran fsck to
> discover that btrfs had to do its own thing.  No idea why; I guess some
> think that incompatibility is a good thing.
> Ran "btrfs check" which reported errors in the filesystem but was otherwise
> useless BECAUSE IT DIDN'T FIX ANYTHING.  What good is knowing that the
> filesystem has errors if you can't fix them?
> Near the top of the manual page it says:
> Warning
>   Do not use --repair unless you are advised to do so by a developer
>   or an experienced user, and then only after having accepted that
>   no fsck successfully repair all types of filesystem corruption. Eg.
>   some other software or hardware bugs can fatally damage a volume.
> Whoa!  I'm sure that operators are standing by, call 1-800-FIX-BTRFS.
> Really?  Is a ploy by the developers to form a support business?
> Later on, the manual page says:
>   --repair
>       enable the repair mode and attempt to fix problems where possible
> 	    Note there’s a warning and 10 second delay when this option
> 	    is run without --force to give users a chance to think twice
> 	    before running repair, the warnings in documentation have
> 	    shown to be insufficient
> Since when is it dangerous to repair a filesystem?  That's a new one to me.
> Having no option other than not being able to use the disk, I ran btrfs
> check with the --repair option.  It crashed.  Lesson so far is that
> trusting my data to an unreliable unrepairable filesystem is not a good
> idea.  Since this was one of my media disks I just rebuilt it using ext4.
> Last week I was working away and tried to write out a file to discover
> that /home and /root had become read-only.  Charming.  Tried rebooting,
> but couldn't since btrfs filesystems aren't checked and repaired.  Plugged
> in a flash drive with a live version, managed to successfully run --repair,
> and rebooted.  Lasted about 15 minutes before flipping back to read only
> with the same error.
> Time to suck it up and revert.	Started a clean reinstall.  Got stuck
> because it crashed during disk setup with anaconda giving me a completely
> useless big python stack trace.  Eventually figured out that it was
> unable to delete the btrfs filesystem that had errors so it just crashed
> instead.  Wiped it using dd; nice that some reliable tools still survive.
> Finished the installation and am back up and running.
> Any of the rest of you have any experiences with btrfs?  I'm sure that it
> works fine at large companies that can afford a team of disk babysitters.
> What benefits does btrfs provide that other filesystem formats such as
> ext4 and ZFS don't?  Is it just a continuation of the "we have to do
> everything ourselves and under no circumstances use anything that came
> from the BSD world" mentality?
> So what's the future for filesystem repair?  Does it look like the past?
> Is Ken's original need for dsw going to rise from the dead?
> In my limited experience btrfs is a BiTteR FileSystem to swallow.
> Or, as Saturday Night Live might put it:  And now, linux, starring the
> not ready for prime time filesystem.  Seems like something that's been
> under development for around 15 years should be in better shape.
> Jon

-- Bakul

  parent reply	other threads:[~2021-08-30  3:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
2021-08-30 13:06 Norman Wilson
2021-08-30 14:42 ` Theodore Ts'o
2021-08-30 18:08   ` Adam Thornton
2021-08-30 16:46 ` Arthur Krewat

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).