Re: [PATCH v4] gc: save log from daemonized gc --auto and print it next time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 16, 2015 at 11:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>
>> I'm not sure what behavior you want. At one point you say "puts the file
>> to a final place if it is non-empty" but later you say "leave it if
>> non-empty". Should the file be written directly, or should it be written
>> to a lockfile and renamed into place only when complete?
>
> I do not think we care that deeply either way, as we do not want to
> run multiple auto-gc's at the same time in the first place.  So either
> one of the following is perfectly fine:
>
>  * We open the final destination directly, but with O_CREAT|O_EXCL,
>    which as a side effect also detects the simultanous execution
>    [*1*].  We do not do any "finalizing rename" if we go this route.
>    When we are done, close it and remove it if we did not write
>    anything, or leave it there if we did write something.
>
>  * We open a lockfile the usual way.  When we are done, close it and
>    and remove it if we did not write anything, or finalize it by
>    renaming it if we did write something.
>
> I think Duy's code wants to do the latter.

We do keep another lock before coming to opening this log file. So
once we get here we already know nobody else will be opening the log
file. We can simply open it the normal way, then make sure we clean it
up at atexit().

>> This doesn't seem like a common thing to want (as in, this might be the
>> only caller), but it probably makes sense to build it into the
>> tempfile/lockfile API nevertheless, because implementing it externally
>> would require a lot of other code to be duplicated.
>>
>> Another possibility that might work (maybe without requiring changes to
>> tempfile/lockfile): don't worry about deleting the log file if it is
>> empty, but make observers treat an empty log file the same as an absent one.
>
> Probably your "don't remove and check for emptiness" approach would
> be the simpler of the two, but I think we can go either way.

People have complained to me about stray files in $GIT_DIR, so it's
probably best that we delete empty/useless files. Although we could
delete empty files at the beginning of the next gc instead of at
atexit(). Let me try it out and see which is simplest.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]