I'll commit this, unless anyone disagrees.
Index: ffs_vfsops.c
===
RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.299
diff -u -r1.299 ffs_vfsops.c
--- ffs_vfsops.c24 May 2014 16:34:04 - 1.299
Le 20/10/2014 18:48, Maxime Villard a écrit :
Le 20/10/2014 18:23, David Holland a écrit :
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
I think the sanity check should be:
Index: ffs_vfsops.c
===
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
[...]
With a broken superblock the kernel will read far beyond the allocated
area, which mostly means it will crash.
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
Date: Mon, 20 Oct 2014 17:46:06 +0200
From: Manuel Bouyer bou...@antioche.eu.org
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
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
I think the sanity check should be:
Index: ffs_vfsops.c
===
RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.299
diff -u -r1.299
In article 20141020154606.ga10...@asim.lip6.fr,
Manuel Bouyer bou...@antioche.eu.org wrote:
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
[...]
With a broken superblock the kernel will read far beyond the allocated
area, which mostly means it will crash.
Sure. There's lot of
On Mon, Oct 20, 2014 at 03:58:45PM +, Taylor R Campbell wrote:
Date: Mon, 20 Oct 2014 17:46:06 +0200
From: Manuel Bouyer bou...@antioche.eu.org
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
Le 20/10/2014 18:23, David Holland a écrit :
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
I think the sanity check should be:
Index: ffs_vfsops.c
===
RCS file:
In article 20141020155832.ea8ae60...@jupiter.mumble.net,
Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote:
Date: Mon, 20 Oct 2014 17:46:06 +0200
From: Manuel Bouyer bou...@antioche.eu.org
Sure. There's lot of other ways to crash the kernel with a broken ffs.
In this
Manuel Bouyer bou...@antioche.eu.org writes:
On Mon, Oct 20, 2014 at 03:58:45PM +, Taylor R Campbell wrote:
Date: Mon, 20 Oct 2014 17:46:06 +0200
From: Manuel Bouyer bou...@antioche.eu.org
Sure. There's lot of other ways to crash the kernel with a broken ffs.
In this
On Mon, Oct 20, 2014 at 04:57:19PM +, paul_kon...@dell.com wrote:
I disagree.
There?s a principle of networking product design, which is that you are never
allowed to crash due to external input. If you receive an invalid packet,
you can complain about it and say the sender is broken,
On Mon, Oct 20, 2014 at 01:10:58PM -0400, Greg Troxel wrote:
[...]
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
Manuel Bouyer bou...@antioche.eu.org wrote:
On Mon, Oct 20, 2014 at 03:58:45PM +, Taylor R Campbell wrote:
Date: Mon, 20 Oct 2014 17:46:06 +0200
From: Manuel Bouyer bou...@antioche.eu.org
Sure. There's lot of other ways to crash the kernel with a broken
ffs. In this
Martin Husemann mar...@duskware.de writes:
On Mon, Oct 20, 2014 at 07:48:31PM +0100, Mindaugas Rasiukevicius wrote:
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.
Manuel Bouyer bou...@antioche.eu.org 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
On Mon, Oct 20, 2014 at 08:44:21PM +0100, Mindaugas Rasiukevicius wrote:
Huh? If your use case is a single / partition for everything then sure.
I don't but other are equally important.
I can actually extend my statement: the system should not crash neither
in a case of corrupt file system
bou...@antioche.eu.org (Manuel Bouyer) writes:
definitively not. I want a panic.
Definitely an administrative decision then. You could make it a
mount option :)
mlel...@serpens.de (Michael van Elst) wrote:
rm...@netbsd.org (Mindaugas Rasiukevicius) writes:
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;
When a single node
Michael van Elst writes:
bou...@antioche.eu.org (Manuel Bouyer) writes:
definitively not. I want a panic.
Definitely an administrative decision then. You could make it a
mount option :)
indeed.
istr that solaris has onerror=panic|remount|unmount|...? option.
.mrg.
Yes, you con configure that on a zpool:
failmode YES wait | continue | panic
This is relevant for SAN disks for instance, where you don´t
necessarily want to crash the server when a disk becomes temporary
unavailable.
2014-10-21 2:44 GMT+02:00 matthew green
rm...@netbsd.org (Mindaugas Rasiukevicius) writes:
In my use case, a broken filesystem is usually a sign of an unnoticed
hardware or software error and the best reaction to recover is to
panic (and throw the data away, the machines have only temporary
data). Continuing with a read-only
m...@eterna.com.au (matthew green) writes:
Michael van Elst writes:
bou...@antioche.eu.org (Manuel Bouyer) writes:
definitively not. I want a panic.
Definitely an administrative decision then. You could make it a
mount option :)
indeed.
istr that solaris has
Definitely an administrative decision then. You could make it a
mount option :)
indeed.
istr that solaris has onerror=panic|remount|unmount|...? option.
Same for Linux.
But before you can make it a mount option, the filesystem code
must be able to handle the cases without panic
23 matches
Mail list logo
