On 09 Apr 2014, at 19:09, Chuck Silvers wrote:
> On Tue, Apr 08, 2014 at 11:23:11AM +0200, J. Hannken-Illjes wrote:
>>
>> On 07 Apr 2014, at 19:28, Chuck Silvers wrote:
>>
>>> On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
Currently all file systems have to implement
On Tue, Apr 08, 2014 at 11:23:11AM +0200, J. Hannken-Illjes wrote:
>
> On 07 Apr 2014, at 19:28, Chuck Silvers wrote:
>
> > On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
> >> Currently all file systems have to implement their own cache of
> >> vnode / fs node pairs. Most fi
Thor Lancelot Simon wrote:
> On Wed, Apr 09, 2014 at 02:43:23AM +0100, Mindaugas Rasiukevicius wrote:
> >
> > This is a very positive work for the cases when system is used as a
> > server or other workloads which may involve cryptographic activity.
> > However, you seem to assume that aggressive
On 09 Apr 2014, at 15:57, Taylor R Campbell
wrote:
> Date: Wed, 9 Apr 2014 11:10:37 +0200
> From: "J. Hannken-Illjes"
>
> There is no need to do this VI_CHANGING etc. here. Primary goal of
> the vnode cache is to always initialise vnode / fs node pairs before
> they become visible o
Date: Wed, 9 Apr 2014 11:10:37 +0200
From: "J. Hannken-Illjes"
There is no need to do this VI_CHANGING etc. here. Primary goal of
the vnode cache is to always initialise vnode / fs node pairs before
they become visible or appear on any lists.
But the vnode/fsnode pair effectively
On Wed, Apr 09, 2014 at 08:30:31AM +0200, Manuel Bouyer wrote:
> On Tue, Apr 08, 2014 at 10:33:32PM -0400, Thor Lancelot Simon wrote:
> > > > - rnd_add_uint32(&skewsrc, rnd_counter());
> > > > - callout_schedule(&skew_callout, hz);
> > > > + rnd_add_uint64(
On 07 Apr 2014, at 18:02, Taylor R Campbell
wrote:
> Date: Mon, 7 Apr 2014 15:51:00 +0200
> From: "J. Hannken-Illjes"
>
> On 07 Apr 2014, at 03:22, Taylor R Campbell
> wrote:
>
>> Is the plan to nix getnewvnode and ungetnewvnode? It would be good to
>> avoid long-term duplication of
