[TUHS] Is it time to resurrect the original dsw (delete with switches)?

Rob Pike robpike at gmail.com
Mon Aug 30 11:21:29 AEST 2021

Do you even have input switches and HALT/CONT switches? I don't think so....



On Mon, Aug 30, 2021 at 9:58 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Sun, Aug 29, 2021 at 03:12:16PM -0700, Jon Steinhart wrote:
> > 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.
> I give them credit for remounting read-only when seeing errors, they may
> have gotten that from BitKeeper.  When we opened a history file, if we
> encountered any errors we opened the history file in read only mode so
> if it worked enough you could see your data, great, but don't write on
> top of bad data.
> > Although it's been discredited by some, I'm still a believer in "stop and
> > fsck" policing of disk drives.
> Me too.  Though with a 32TB drive (I'm guessing rotating media), that's
> going to take a long time.   If I had a drive that big, I'd divide it
> into managable chunks and mount them all under /drive/{a,b,c,d,e...}
> so that when something goes wrong you don't have to check the whole
> 32TB.
> > 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?
> That's a stretch, they are just trying to not encourage you to make a
> mess.
> I sent Linus an email to find out where btrfs is, I'll report back when
> he replies.
> --lm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210830/0a410575/attachment.htm>

More information about the TUHS mailing list