David Holland dholland-t...@netbsd.org wrote:
At least one of the things you've forgotten right up front is that if
a filesystem server process tips over, the first thing you need to do
is run fsck... and be prepared to cope with fsck failing.
I was thinking about it in the context of
Mouse mo...@rodents-montreal.org wrote:
This could be useful in other contexts, from post-unmount cleanup in
general to auto-remount of non-puffs filesystems. Perhaps it's
appropriate to add vfsctl(2), with an option which can set a run this
on unmount command? Or maybe a wait for unmount
On Sun, 12 Feb 2012, Emmanuel Dreyfus wrote:
David Holland dholland-t...@netbsd.org wrote:
At least one of the things you've forgotten right up front is that if
a filesystem server process tips over, the first thing you need to do
is run fsck... and be prepared to cope with fsck failing.
I
Stephen Borrill net...@precedence.co.uk wrote:
However, this wouldn't fix the
problem that one tends to netbsd-iscsi-initiator in conjunction with
vnd(4) which copes _really_ badly with the backing file going away. Or
would the proposed active vnode recycling sort this?
That was my idea,
On Sun, Feb 12, 2012 at 07:12:25AM +0100, Emmanuel Dreyfus wrote:
I thought that we could respawn a crashed userland filesystem, lookup
all active vnodes again, and redo all operations failed at crash time.
That way a crashed filesystem would just cause a delay in ongoing
operations, but it
Thomas Klausner w...@netbsd.org wrote:
Please also consider the problem that it might be a persistent problem,
i.e. crash immediately or quite soon again.
Sure, we can stop respawn when repeating too often, just like we do for
getty.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
On Sun, Feb 12, 2012 at 10:37:01AM +0100, Emmanuel Dreyfus wrote:
At least one of the things you've forgotten right up front is that if
a filesystem server process tips over, the first thing you need to do
is run fsck... and be prepared to cope with fsck failing.
I was thinking about
One of the benefits of userland filesystems is that a bug in a
filesystem will just crash the filesystem, not the whole kernel. But a
crashed filesystem causes an unmount, and leaves the system non fully
functionnal.
I thought that we could respawn a crashed userland filesystem, lookup
all active
Of course the feature would be broken in some cases, but we could
make the thing optional using a vfs.puffs.respawn sysctl, which would
contain a colon-separated mount points subjected to respawn.
What happens if a mount point contains a colon?
More to the point, I think this puts the
On Sun, 12 Feb 2012 01:02:38 -0500 (EST)
Mouse mo...@rodents-montreal.org wrote:
Of course the feature would be broken in some cases, but we could
make the thing optional using a vfs.puffs.respawn sysctl, which would
contain a colon-separated mount points subjected to respawn.
What
Mouse mo...@rodents-montreal.org wrote:
Of course the feature would be broken in some cases, but we could
make the thing optional using a vfs.puffs.respawn sysctl, which would
contain a colon-separated mount points subjected to respawn.
What happens if a mount point contains a colon?
Is there any way it could be set as an option at mount time?
The problem is that mount(8) passes the options verbatim to
/sbin/mount_xxx, which is supposed to start the xxx filesystem. The
filesystem will parse the options on its own before passing
appropriate flags to mount(2). We have no
On Sun, Feb 12, 2012 at 07:12:25AM +0100, Emmanuel Dreyfus wrote:
One of the benefits of userland filesystems is that a bug in a
filesystem will just crash the filesystem, not the whole kernel. But a
crashed filesystem causes an unmount, and leaves the system non fully
functionnal.
I
13 matches
Mail list logo
