NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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: Sat, 26 Oct 2019 00:40:18 +0200

 On 25.10.2019 18:40, 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 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 happ=
 en
 >  >  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 corrupte=
 d,
 >  >  not something trapped on division by 0 (or other anomaly).
 >  >
 >  >  I'm also against "oops" Linux kernel behavior, but probably remounti=
 ng
 >  >  to read/only with a warning to run fsck is reasonable. But if we com=
 pare
 >
 >  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 no=
 w.
 >
 >  Letting a server run with a filesystem remounted R/O just lead
 >  to more data loss.
 >
 
 
 OK, so the goals shall be:
 
 1. reject mount(2) without kernel crash
 2. panic on broken fs in operation
 3. get fsck(8) functional on corrupted image
 
 Thank you for the feedback.
 
 >  --
 >  Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 >       NetBSD: 26 ans d'experience feront toujours la difference
 >  --
 >
 >
 


Home | Main Index | Thread Index | Old Index