a
separate patch as it may be less worth adding and it
probably needs work for portability. I won't loose sleep
if you want to reject it.
These are against trunk.
>From 489d53e4a6b0c4497f389b2e6dcc1b3e4bcef1d1 Mon Sep 17 00:00:00 2001
From: Wilson Snyder
Date: Thu, 6 May 2010 10:13:03 -0400
I'm hitting a NFS issue causing bad caching. (And yes, we have
no_subtree_check.)
This is a bug present in 2.4, but it is also present in
trunk b964c173cf493a1c0c0749a9c6a39bc07936507b which is used
for the below diagnosis.
The issue seems to occur only when there are three compiles
on differen
Two followups.
First, though not the problem I'm seeing, as I understand
it, mkstemp isn't guaranteed to work on NFS v2 mounted
drives. Thus I suggest including the hostname; there's
already tmp_string() which is perfect. Patch below.
Second, I'm still not sure of the cause, but if I count
byt
>I recently released a GPL tool which is, in part, an alternative to
>ccache and thought I'd drop a line to this list for anyone interested.
>The front page is at http://audited-objects.sourceforge.net/ and a
>comparison with ccache is at
>http://audited-objects.sourceforge.net/html/man/ao-ccache.
>First, congrats on finishing the latest release. It's so wonderful to
>have great progress.
>
>Anyhow, here's a trivial patch I'd like considered. I had
>to resolve a conflict around it in git when I updated so
>might as well feed it up, as it may help others debug too!
Sorry sent the old vers
First, congrats on finishing the latest release. It's so wonderful to
have great progress.
Anyhow, here's a trivial patch I'd like considered. I had
to resolve a conflict around it in git when I updated so
might as well feed it up, as it may help others debug too!
diff --git a/util.c b/util.c
"git describe --dirty" is a very recent addition. I would
suggest the following so that the version works properly on
older versions.
Thanks!
diff --git a/dev.mk.in b/dev.mk.in
index d4dc1f7..1a7c00b 100644
--- a/dev.mk.in
+++ b/dev.mk.in
@@ -8,7 +8,7 @@ XSLTPROC = xsltproc
MANPAGE_XSL = /etc/
I'm trying to reduce the load a bit on our NFS ccache server. I noted the
following pattern of accesses on a cache hit:
# stat("$CACHE_DIR", {...}) = 0
# stat("$CACHE_DIR/tmp", {...}) = 0
# stat("$CACHE_DIR/CACHEDIR.TAG", {...}) = 0
* stat("$CACHE_DIR/3", {...}) = 0
* stat("$CACHE_DIR/3/d", {...
Re my last patch, here's another that avoids these two stat calls on hits:
stat("$CACHE_DIR/tmp", {...}) = 0
stat("$CACHE_DIR/CACHEDIR.TAG", {...}) = 0
diff --git a/ccache.c b/ccache.c
index eed076f..d1b3878 100644
--- a/ccache.c
+++ b/ccache.c
@@ -73,7 +73,7 @@ static char *current_working_
>On 2010-10-05 22:29, Joel Rosdahl wrote:
>> On 2010-10-04 23:08, Wilson Snyder wrote:
>>> There are still extra calls (the #s); it would be best if
>>> the code assumed directories existed and just tried to read
>>> the manifest or .o. Then the directory cre
Several months ago I reported a problem with NFS corruption
from three simultaneous NFS users of ccache on the same
file; two writers to the cache and one reader.
I believe I have tracked this issue down to a race related
to the use of unlink. On NFS, unlink() is NOT atomic; so
what seemed to be
GZIP files contain CRC checksums, however ccache doesn't
notice CRC errors because it doesn't check gzerror at the
end of decompression. This patch fixes it. (It's arguably
a bad API decision on the gz library's part, but we're stuck
with it.)
Thanks
diff --git a/util.c b/util.c
index 58723f0.
>> GZIP files contain CRC checksums, however ccache doesn't
>> notice CRC errors because it doesn't check gzerror at the
>> end of decompression. This patch fixes it. (It's arguably
>> a bad API decision on the gz library's part, but we're stuck
>> with it.)
>...
>
>> +gzeof(gz_in);
>
>Why is
>On 25 November 2010 00:52, Henrik Goldman wrote:
>> Hello,
>>
>> I wonder if anyone ever considered using memcached as an optional backend
>> for ccached?
>>
>> Here is the issue we're considering. In our C++ project we have a number of
>> developers doing their own local compilations. When any u
>> If you already are, are you really doing enough writes to
>> swamp a NFS cache server? It probably requires hundreds of
>> compiling clients; since we have over a hundred here and
>> don't see a bottleneck - with a single well performing NFS
>> server.
>
>In our case we're talking about 25 sha
>> We have about 100 machines, with about 400 cores - a mix of
>> older 2 socket up to modern 12 core systems. Compiles are
>> ~~10% of the work load. The NFS server with CCACHE_DIR has
>> 6 RAID-5 disks; it does other things too, not just ccache.
>> We decided to bond 4 ethernet ports into the
>...
>When ccache invokes my compiler, it runs like this:
>
>cd /path/to/ONE/obj/subdir/foo
>my-special-gcc -c -E ../../../src/subdir/foo/foo.c
>
>This works, as you can see above. But, it's a serious drag from a
>debugging standpoint, because now the pathname for that file in my
>> Maybe the right thing to do would be to have ccache keep track of the
>> source files' attributes. =A0If some environment variable was set,
>> ccache would treat a file with unchanged attributes as unchanged.
>> (ccache could maintain a new index into its cache, indexed on absolute
>> path, or i
>For usage of ccache at our company, here is one of our biggest hassles today:
>even with the CCACHE_BASEDIR feature, users complain when gdb points to files
>that no longer exist.
>
>Independently, a couple of our engineers have proposed the following fix :
>
>1. On a cache miss, generate prepr
>A quick question: man page suggests that it is possible to share ccache across
>multiple developers by following a set of rules for permissions, umask and
>setting up of ccache dirs env vars etc. What it doesn't talk about is what
>happens if two developers are compiling at the same time and th
>I would like to improve ccache's configurability. As you
>know, configuration of ccache is today done by setting a
>bunch of environment variables, but that's becoming
>increasingly messy; there are currently 24 CCACHE_*
>variables in the development version of ccache. I think
>it's time to move
>This patch lets ccache examine an include file's mtime and size in
>lieu of hashing it, during direct mode. If the mtime and size don't
>match, we fall back to hashing.
>
>The net result is roughly a factor-of-two speedup in ccache hits (*),
>on my machine.
>
>I'm not sure if this is a desirable
>> I can't say I'm particularly interested in supporting two manifest
>> versions simultaneously
>
>I agree that supporting only the latest should be enough.
>
>Coming to think of it, perhaps it would be a good idea to include the
>manifest version in the manifest hash so that ccache versions usin
>> Allowing multiple versions to co-reside and not trash each
>> other's result would be useful. =A0Presently I need redefine
>> CCACHE_DIR for each version to avoid overlap, which is
>> annoying. [...]
>
> From the top of my head, the issues I'm aware of regarding different
>ccache versions acces
24 matches
Mail list logo
