lkml.org 
[lkml]   [2005]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/12] FS-Cache: Generic filesystem caching facility
Date
Linus Torvalds <torvalds@osdl.org> wrote:

> > This series of patches does four things:
>
> Ok, interesting, and I like most of what I see.. But why do you have that
> horrible "FSCACHE_NEGATIVE_COOKIE" thing?
>
> We normally call that thing "NULL", and we test for it with code like "if
> (!cookie)" instead of making up really nasty (and apparently misleading)
> names.
>
> The reason I say "misleading" is that a real negative cache entry doesn't
> mean that the entry isn't cached, it means that it positively does not
> exist. Which is something different from what you seem to be saying if I
> read the patch right. From my quick reading, it looks like you use that
> "NEGATIVE" not as a negative cache, but as a "I don't have this cached"
> cache. Which is not negative at all.

Not exactly. Whilst it is a case of what you want is not in the cache (or was
discarded when examined), I'm also refusing to add it to the cache for some
reason or other (ENOMEM, no cache, I/O error on cache, insufficient available
space, etc).

If it was not in the cache, but I am going to let you cache it then I'll
return a cookie instead. All reads on that cookie will return ENODATA until at
such time data has been stored in the cache and can then be retrieved.

All attempts to perform accesses using the "negative" cookie will then fail
gracefully. A "negative" cookie will not be instantiated. You have to get a
new cookie.

> (The difference is like the difference between a "hole" in a file and a
> "don't know what this page is". One is real knowledge - and in UNIX
> means that it's filled with zero - and the other one means that you have
> to go look what the contents are).

But UNIX normally allows you to subsequently go and fill a hole (subject to
space constraints, etc)...

> And if it _is_ properly named (ie it really does mean "this entry
> positively does not exist") then it shouldn't have the same representation
> as NULL, because NULL really is traditionally used for "unknown" rather
> than "known to not exist".
>
> So depending on which it is, I really think you should either have
>
> - just use NULL for "don't know"

It isn't a "don't know" exactly. It's a "no".

> or
>
> - use #define FSCACHE_NEGATIVE_COOKIE ((struct fscache_cookie *)-1)
> for "this is known to not exist".

Hmmm... Which is possibly less efficient because CPUs generally are better at
determining 0 than -1.

> (and quite often, you might well want to have both).

I don't think I have a need for both. Either I give you a cookie (for which
there may be nothing in the cache); or I give you the "negative" cookie for
which there's definitely nothing in the cache, and gracefully refuse to
service it.


So, would you still rather I used NULL? If so, I can change it easily enough.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-15 14:54    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site