[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>
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=
> 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=
> 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=
> > > corrupted. No linux-like degraded mode please
> > >
> > Deliberate panic on broken FS is OK for those who want it, but rando=
> > 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=
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
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.
Main Index |
Thread Index |