On Sat, Sep 14, 2019 at 09:51:12AM -0700, Jason Thorpe wrote:
> >> Given the list of smart people I've seen discussing this, I'm
> >> presumably just missing something, but what?
> >
> > Loonix.
>
> Linux isn't the only system that has such a capability.
No, but I'm pretty sure it was the
On 9/14/19, Mouse wrote:
>> [...], because fexecve is causing rumbles about doing significantly
>> more reverse lookups.
>
> Why is everyone so concerned about finding "the" name of an inode, or
> indeed any name for an inode? As far as I can tell there has never
> been any promise that any
> On Sep 14, 2019, at 1:20 AM, David Holland wrote:
>
>> Given the list of smart people I've seen discussing this, I'm
>> presumably just missing something, but what?
>
> Loonix.
Linux isn't the only system that has such a capability.
-- thorpej
On Fri, Sep 13, 2019 at 07:49:54PM -0400, Mouse wrote:
> > [...], because fexecve is causing rumbles about doing significantly
> > more reverse lookups.
>
> Why is everyone so concerned about finding "the" name of an inode, or
> indeed any name for an inode? As far as I can tell there has
> [...], because fexecve is causing rumbles about doing significantly
> more reverse lookups.
Why is everyone so concerned about finding "the" name of an inode, or
indeed any name for an inode? As far as I can tell there has never
been any promise that any given inode has any names pointing to
On Fri 13 Sep 2019 at 18:04:06 +, David Holland wrote:
> On Wed, Sep 11, 2019 at 09:43:18AM +0300, Jason Thorpe wrote:
> > Another advantage of de-duping the name strings is that you can
> > compare names by testing pointer equivalence.
>
> I'd expect that trying to dedup the strings would
In article <20190913180602.gb20...@netbsd.org>,
David Holland wrote:
>On Wed, Sep 11, 2019 at 03:53:18PM +0700, Robert Elz wrote:
> > What's more interesting to me is to know just how many long names people
> > are seeing which are currently excluded from the cache, and would benefit
> > from
On Wed, Sep 11, 2019 at 03:53:18PM +0700, Robert Elz wrote:
> What's more interesting to me is to know just how many long names people
> are seeing which are currently excluded from the cache, and would benefit
> from the change - that is, what percentage of all lookups fail in the
> cache for
On Wed, Sep 11, 2019 at 09:43:18AM +0300, Jason Thorpe wrote:
> > I'm confused; nothing in there should lead to duplicate entries...
>
> Duplicate names != duplicate entries.
> [...]
> Another advantage of de-duping the name strings is that you can
> compare names by testing pointer
> On Sep 11, 2019, at 11:53 AM, Robert Elz wrote:
>
>Date:Wed, 11 Sep 2019 09:43:18 +0300
>From:Jason Thorpe
>Message-ID:
>
> | Another advantage of de-duping the name strings is that you can
> | compare names by testing pointer equivalence.
>
> That works
Date:Wed, 11 Sep 2019 09:43:18 +0300
From:Jason Thorpe
Message-ID:
| Another advantage of de-duping the name strings is that you can
| compare names by testing pointer equivalence.
That works only if string you're comparing against the cache entry
is itself a
> On Sep 11, 2019, at 8:18 AM, David Holland wrote:
>
> I'm confused; nothing in there should lead to duplicate entries...
Duplicate names != duplicate entries.
Consider the case:
bin/CVS
bin/cat/CVS
.
.
.
bin/sh/CVS
.
.
.
Distinct vnodes, with distinct parents, all having the same name.
On Wed, Sep 11, 2019 at 06:49:05AM +0300, Jason Thorpe wrote:
> > On Sep 11, 2019, at 2:23 AM, Christos Zoulas wrote:
> >
> > Comments?
>
> This looks good, and I think it would be fine for it to go in now.
> However, I think we should probably instrument how many duplicate
> names may
> On Sep 11, 2019, at 2:23 AM, Christos Zoulas wrote:
>
> Comments?
This looks good, and I think it would be fine for it to go in now. However, I
think we should probably instrument how many duplicate names may end up in the
name cache over the course of "normal" operation (insert
14 matches
Mail list logo
