hi,
> On Fri, Feb 10, 2012 at 11:20:38AM +, YAMAMOTO Takashi wrote:
>> is it safe to release exec_lock?
and how about p_reflock?
>
> Good catch - I'll defer the release untill the child has done it's rw_enter().
it would deadlock if in the mean time another thread does rw_enter(WRITER)
on
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
On Sat, Feb 11, 2012 at 11:39:33PM +, David Holland wrote:
> There are, however, at least three possible things there's currently
> no open flags for.
>
> (1) search/lookup on a directory, as described;
POSIX defines an O_SEARCH for this.
> (2) execute on an (executable) regular file;
POSI
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
