Manuel Bouyer <[email protected]> wrote: > On Mon, Oct 20, 2014 at 07:48:31PM +0100, Mindaugas Rasiukevicius wrote: > > > 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). > > > > Disagree. The kernel should remount the file system in read-only mode. > > > > Perhaps we can debate what to do with corrupted / when the system is > > booting, but for other cases (especially hot-plug or external disks) > > I certainly do not expect a crash. > > I do, it's the only sane thing to do if the systen did write bogus > data to the disk and notice it later. Remounting in read-only mode > on a server with active services running doens't do anything good > (I know because linux servers do this. A panic and reboot is a much > better behavior).
Huh? If your use case is a single / partition for everything then sure. I can actually extend my statement: the system should not crash neither in a case of corrupt file system nor a disk failure (which may or may not lead to corrupt file system). If I have a system with an array of disks and one of them fails, a crash would take down the whole node. When many terabytes of data suddenly disappear people get unhappy; it usually costs quite a bit of money too. So, how about making only the *failed* segment of data unavailable? In many cases this is suitable and desirable; consider distributed systems (you have redundancy) or caches (where I can just discard the corrupted data segment and refetch it from the origin). Meanwhile, I can replace the failed disk and/or rebuild the corrupt file system while experiencing only a limited disruption. > If the corrupted filesystem is from a corrupted USB key then not panicing > is probably better; but 1) USB keys usually don't have ffs on them 2) > In such case it would be better to run the filesystem code in userland > anyway. So now you make an assumption about file systems used on USB sticks? That does not matter. Somebody can create a USB stick with manually handcrafted superblock to crash your machine or maybe even exploit it. To me, that constitutes a security vulnerability. -- Mindaugas
