Re: kern/54647: panic: ffs_newvnode: dup alloc ino=2782620

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR kern/54647; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/54647: panic: ffs_newvnode: dup alloc ino=2782620
Date: Fri, 25 Oct 2019 17:54:01 +0200

 On 25.10.2019 16:55, Manuel Bouyer wrote:
 > The following reply was made to PR kern/54647; it has been noted by GNAT=
 S.
 >
 > From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs@netb=
 sd.org,
 >         lawrence_danna%apple.com@localhost
 > Subject: Re: kern/54647: panic: ffs_newvnode: dup alloc ino=3D2782620
 > Date: Fri, 25 Oct 2019 16:52:59 +0200
 >
 >  On Fri, Oct 25, 2019 at 09:50:02AM +0000, Kamil Rytarowski wrote:
 >  >  >  This should be a mount option. I *want* a panic if the filesystem=
  is
 >  >  >  corrupted. No linux-like degraded mode please
 >  >  >
 >  >
 >  >  Deliberate panic on broken FS is OK for those who want it, but rando=
 m
 >  >  crashes for bugs like division by 0 in the kernel is not.
 >
 >  If the division by 0 is because the FS is corrupted then it is OK for m=
 e.
 >
 
 Personally, I would like to see rejection of mount. What should happen
 during operation is another affair and there is enough prior work on the
 mounting stage.
 
 I'm fine with panic on error as a tunable option.
 
 Cprri[ted FS should trigger a meaningful message that FS is corrupted,
 not something trapped on division by 0 (or other anomaly).
 
 I'm also against "oops" Linux kernel behavior, but probably remounting
 to read/only with a warning to run fsck is reasonable. But if we compare
 to Linux, it's very difficult to panic the kernel on corrupted XFS. I
 experienced enough FS panics on NetBSD so I desire the same quality.