tech-kern archive

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

Re: FFS: wrong superblock check ~> crash



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



Home | Main Index | Thread Index | Old Index