hi,
> Forced unmounts will most likely panic the kernel. The main problem is
> other threads running a vnode operation when we come to clean and
> reclaim an active vnode and therefore change its operation vector and
> destroy the file system private data without locking or synchronisation.
>
>
hi,
> Hello,
> while working on nfs performance issues with overquota writes (which
> turned out to be a ffs issue), I came up with the attached patch.
> What this does it, for nfs over TCP, restrict a socket buffer processing
> to a single thread (right now, all pending requests are processed
> b
On Apr 27, 3:15am, David Laight wrote:
} On Tue, Dec 04, 2012 at 10:17:23PM -0800, John Nemeth wrote:
} >
} > We use ISC's DHCP server. As third party software, it is designed
} > to be portable to many systems. BPF is a fairly portable interface,
} > thus a reasonable interface for it to
On Wed, Dec 05, 2012 at 12:56:27PM -0500, Thor Lancelot Simon wrote:
> On Wed, Dec 05, 2012 at 08:29:23AM -0800, Chuck Silvers wrote:
> >
> >
> > and the top few entries from that with a portion of your dd test are:
...
dtrace outputs counts with the smallest numbers first,
so the most interesti
Date: Thu, 6 Dec 2012 08:23:07 +0100
From: "J. Hannken-Illjes"
Looks like this thread is dead. No one beside David Holland is
interested and David objects. I take back my proposal.
I'm interested, but I haven't fit enough of the vnode life cycle or
the fstrans mechanism into my hea
> Looks like this thread is dead. No one beside David Holland is
> interested and David objects. I take back my proposal.
i'm very interested in this idea.
> David wants to track information about threads running a vnode
> operation from vnode_if.c. I have no idea how this could be done
> with
On Tue, Dec 04, 2012 at 05:31:59PM +0100, J. Hannken-Illjes wrote:
> >> A suspended fs has the guarantee that no other thread will be inside
> >> fstrans_suspend / fstrans_done of any vnode operation.
> >>
> >> Threads stuck permanently as in (c) are impossible to catch.
> >
> > ...doesn't
On Thu, Dec 06, 2012 at 10:32:01AM +, Julian Yon wrote:
> I think you could take some inspiration from Linux here: it has a very
> handy umount -l which detaches the filesystem from the tree, but defers
> the rest of the unmount/cleanup until the fs is no longer busy. This
> can help in sit
On Thu, 6 Dec 2012 08:23:07 +0100
"J. Hannken-Illjes" wrote:
> Looks like this thread is dead. No one beside David Holland is
> interested and David objects. I take back my proposal.
Have been reading the discussion. Don't assume that no contribution
means no interest!
> David wants forced un
On Dec 6, 2012, at 10:14 AM, Martin Husemann wrote:
> I am interested, but I lack significant vnode clue. So, sorry if answers
> are obvious - they are not to me.
>
> About the only situation I ever (and it is almost reproducable at will), in
> daily life, wanted to use forced unmounts instead o
I am interested, but I lack significant vnode clue. So, sorry if answers
are obvious - they are not to me.
About the only situation I ever (and it is almost reproducable at will), in
daily life, wanted to use forced unmounts instead of rebooting a machine (or
before the machine rebooted itself in
On Dec 6, 2012, at 8:32 AM, Michael van Elst wrote:
> hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") writes:
>
>> David wants forced unmounts to work even if a thread gets stuck
>> permanently in a vnode operation.
>
> How can it get stuck (short of bugs) ?
Here we are talking about bugs only.
On Wed, 5 Dec 2012 20:42:32 +
David Holland wrote:
> That may be, but it's still true of file descriptors. Traditionally
> they're capabilities, and I really don't like the idea of rearranging
> that arbitrarily and inconsistently.
>
> I think to do this correctly, exec and search on file ha
13 matches
Mail list logo
