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 thinkin
Thomas Klausner 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
m...@netbsd.org
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 i
Stephen Borrill 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, indeed: you restart t
On Sun, 12 Feb 2012, Emmanuel Dreyfus wrote:
David Holland 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 t
Mouse 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" operation?
We could
David Holland 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 glusterfs, where obviously
yo
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.
>
>> 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
Mouse 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?
Then you have serious
On Sun, 12 Feb 2012 01:02:38 -0500 (EST)
Mouse 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
> 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 infor
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
13 matches
Mail list logo
