From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pb-smtp1.pobox.com ([64.147.108.70]:62833 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756712AbeATW1D (ORCPT ); Sat, 20 Jan 2018 17:27:03 -0500 From: Junio C Hamano To: Theodore Ts'o Cc: Christoph Hellwig , Linus Torvalds , =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Git Mailing List , linux-fsdevel , Chris Mason , Jeff King Subject: Re: [PATCH] enable core.fsyncObjectFiles by default References: <20180117184828.31816-1-hch@lst.de> <87h8rki2iu.fsf@evledraar.gmail.com> <20180117235220.GD6948@thunk.org> <20180118162721.GA26078@lst.de> <20180120221445.GA4451@thunk.org> Date: Sat, 20 Jan 2018 14:27:00 -0800 In-Reply-To: <20180120221445.GA4451@thunk.org> (Theodore Ts'o's message of "Sat, 20 Jan 2018 17:14:45 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Theodore Ts'o writes: > .... I've never been fond of the "git repack -A" behavior > where it can generate huge numbers of loose files. I'd much prefer it > if the other objects ended up in a separate pack file, and then some > other provision made for nuking that pack file some time later.... Yes, a "cruft pack" that holds unreachable object has been discussed a few times recently on list, and I do agree that it is a desirable thing to have in the longer run. What's tricky is to devise a way to allow us to salvage objects that are placed in a cruft pack because they are accessed recently, proving themselves to be no longer crufts. It could be that a good way to resurrect them is to explode them to loose form when they are accessed out of a cruft pack. We need to worry about interactions with read-only users if we go that route, but with the current "explode unreachable to loose, touch their mtime when they are accessed" scheme ends up ignoring accesses from read-only users that cannot update mtime, so it might not be too bad.