Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes: > On Mon, Oct 20, 2014 at 03:58:45PM +0000, Taylor R Campbell wrote: >> Date: Mon, 20 Oct 2014 17:46:06 +0200 >> From: Manuel Bouyer <bouyer%antioche.eu.org@localhost> >> >> Sure. There's lot of other ways to crash the kernel with a broken ffs. >> In this specific case it's OK to return an error, but in the general >> case I prefer to have the kernel panic when an inconsistency is >> detected in ffs, than return an error and try to continue running with >> a bogus filesystem. >> >> Continuing to run with a bogus file system is no good, but panicking >> the kernel is worse. If the kernel takes any drastic action beyond >> merely returning an error, it should remount the file system >> read-only. > > definitively not. I want a panic. If the filesystsem is corrupted something > has gone really wrong and you can't trust the running system any more. > And there are cases where returning EROFS is worse than panicing (e.g. > a NFS server). The basic issue here is that there are two use cases: The FFS file system in question is /, or /usr, or something else that the operator deems Wicked Important. The FFS file syste is on some random removable media that someone just wants to access. The desires, while each is reasonabl, are totally different. I would suggest a new filesystem option (perhaps "poe" for panic on error, with a nod to Dr. Strangelove) that causes detection of consistency errors to panic rather than error. Then people can turn it on for filesystems that are so critical that they prefer a panic.
Attachment:
pgpurpMGx6Iyf.pgp
Description: PGP signature