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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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

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%netbsd.org@localhost,
        lawrence_danna%apple.com@localhost
Subject: Re: kern/54647: panic: ffs_newvnode: dup alloc ino=2782620
Date: Fri, 25 Oct 2019 18:39:15 +0200

 On Fri, Oct 25, 2019 at 03:55:01PM +0000, Kamil Rytarowski wrote:
 >  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.
 
 It if can happen at mount time then sure, it's the best option
 
 >  
 >  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
 
 no, it's not. I've got enough trouble with this linux behavior to
 know that it makes things worse. A corrupted FS during operation is
 a sign that something very bad happened, and we should stop anything now.
 
 Letting a server run with a filesystem remounted R/O just lead
 to more data loss.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --