[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....
Commiserations.
-rob
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