From nobody Tue Apr 04 02:41:47 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PrBqW54vPz43jmD for ; Tue, 4 Apr 2023 02:41:59 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PrBqW3P4Bz44QM for ; Tue, 4 Apr 2023 02:41:59 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62b.google.com with SMTP id w4so29952453plg.9 for ; Mon, 03 Apr 2023 19:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; t=1680576118; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FO3FSzhOvcfExnz1kXLjfRmQUiRBGs+nubjQ/V8PjXM=; b=jOgEenDHDfxEVttO8eMkGpFIqR0zvUvg4t5H0552/VsYSnV5j3s3ljbcsnnubvUF6R JQU4jC5pjQlEjnXgN3pNXCxZThEfyniC2bj+W204wDMWbgkKf5dXvaLrM0ABpqTFy54a be6bJUrXkxzIUTQj5MLqU3Xjbrz7sDRaAWHUDZ0QtyzUTzSHV9Kmhq9fF8ItAIsKd7M4 lSaek6ZThee9rFCm9F5m+HDsHBOEfVaPrvAb3jZjDOgiaHS4LEUgh+QIZPA40C+Fzm5m zbtOiU0jXBapc2F7y/tkeiLfCoj9rLP3Bp/ZyYKn/8M7CW4goxNSnNmCteRrsnJjlQG7 4nww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680576118; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FO3FSzhOvcfExnz1kXLjfRmQUiRBGs+nubjQ/V8PjXM=; b=r8QwwZPUPTmnBOtrg5/wjoMeY9JGmmuwSIHSvDsGY8M63rVrnQ4qbxutfKyNRV7/ad ajzOG04s901wgUofGzdQqN3ioUfNo4vrYEmWPxMoLUNZRE+Nq1ob9frkceB2Y701J7SP EBz+tiKgQgjjyu3nErU3+qMekK8QpM/kBK3b8JD1hZ2pljC/ykOHFH+/yMG26cMjcupZ Wi/dksLnIK9bzcOJdoEha70Q90w6Ku2JwPKPpxdhm/Q5x9i7bb2nW5PWin0vA71wiMVf lAxVlg/C+Hn3KhgP+vzRlnmghXU+zhleG+FMK+cKcoRBAVjCfcH3jEkmh1GBi4CSbpGZ RzBg== X-Gm-Message-State: AAQBX9cstPleMv1V5qjTsYGrKVbGIbsaF/yuvtP8+TSVOFyITzh3Vn+e SyA/H9njohW7nk8djqKLlbAREQG9PY186Mx/VjpMhw== X-Google-Smtp-Source: AKy350aCPT08PbdC8vr14Wt8P7fwJlT2U9+MINwQL2nxiVtbZk0ebmUBC1rrsVsd4dToSGOH86NMaw== X-Received: by 2002:a05:6a20:6687:b0:db:6a5a:3ce7 with SMTP id o7-20020a056a20668700b000db6a5a3ce7mr824659pzh.12.1680576118255; Mon, 03 Apr 2023 19:41:58 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id m3-20020aa79003000000b006260645f2a7sm7904036pfo.17.2023.04.03.19.41.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2023 19:41:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: ccache From: Bakul Shah In-Reply-To: <92bc05d9-14fc-0928-4f36-4b55815303fe@freebsd.org> Date: Mon, 3 Apr 2023 19:41:47 -0700 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <671864AD-11F0-487B-9597-ACF28D24591B@iitbombay.org> <92bc05d9-14fc-0928-4f36-4b55815303fe@freebsd.org> To: Craig Leres X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4PrBqW3P4Bz44QM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On Apr 3, 2023, at 6:48 PM, Craig Leres wrote: >=20 > On 4/3/23 17:09, Bakul Shah wrote: >> Am I use ccache incorrectly or is there a bug? >> # CCACHE_DIR=3D/usr/obj/ccache ccache -s >> cache directory /usr/obj/ccache >> primary config /usr/obj/ccache/ccache.conf >> secondary config (readonly) /usr/local/etc/ccache.conf >> stats updated Mon Apr 3 16:54:31 2023 >> ... >> cleanups performed 507 >> files in cache 2795230 >> cache size 2.9 GB <=3D=3D=3D >> max cache size 15.0 GB >> # find /usr/obj/ccache -type f |wc >> 2795395 2795395 142222206 >> # du -sh /usr/obj/ccache >> 83G /usr/obj/ccache <=3D=3D=3D >> I have >> WITH_CCACHE_BUILD=3Dyes >> CCACHE_DIR=3D/usr/obj/ccache >> in /etc/make.conf >=20 > Thank you for bringing this up; I have the same issue and have never = figured it out. But I think I've found another piece or two of the = puzzle. >=20 > Using my favorite ktrace trick we can see that by default it tries to = open /usr/local/etc/ccache.conf: >=20 > zinc 32 % cd /tmp && ktrace -di ccache -s > /dev/null > zinc 33 % kdump | fgrep NAMI | fgrep ccache.conf > 17418 ccache NAMI "/usr/local/etc/ccache.conf" > 17418 ccache NAMI "/home/zinc/u0/leres/.ccache/ccache.conf" >=20 > I suspect the trick here is when ccache runs inside a poudriere jail, = ccache.conf is not present and/or not in the right location. I checked that it uses the correct ccache.conf and ccache dir. >=20 > On my build server I have /var/cache/ccache/ccache.conf which I = believe works for some things but I still have 46 GB in = /var/cache/ccache and /var/cache/ccache/ccache.conf is trying to limit = use to 8 GB. >=20 > If I start up a poudriere jail and look around I find = /root/.ccache/ccache.conf is a copy of /var/cache/ccache/ccache.conf. So = I don't get why it doesn't work. >=20 > (Now I'll sit back and wait for something who knows more chimes in...) >=20 > Craig I did the same thing this time as before -- I manually ran "ccache -c". Even now the number it reports is smaller by a few G than what du -sh reveals, and it says there are many more files in the cache than find reveals. I suspect it either doesn't do proper bookkeeping or gets confused if you ^Ced a build at the wrong time. It does seem to update $CCACHE_DIR/?/stats files. ccache -c took a very long time. ktrace shows it does the equivalent of=20 for each file f to be deleted rename $f $f.ccache.rm.tmp unlink $f.ccache.rm.tmp Not sure why the rename is needed.