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 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 >