Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

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

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

>>> After the series completes, this lock is only used in reflog_expire.
>>> So I'd rather move it inside the function? Then we could run the reflog_expire
>>> function in parallel for different locks in theory?
>>
>> I am not sure about the "parallel" part, but I would imagine that it
>> is an essential prerequisite to move this outside the "client" code
>> if we want to later replace the backing storage of refs and reflogs
>> outside the filesystem, so from that point of view,  I think the
>> suggestion makes sense.
>>
>> Thanks.
>>
>
> Sorry for the confusion. With parallel I mean,...

There is no confusion.  I understand exactly what you meant.

What I said was not sure was if "parallel" is a practical enough
possiblity to include into the set of value propositions the
suggested change to move the lock out of the "client" may give us.

In other words, "With this change, doing a parallel will become a
lot easier"---"Really?  It probably is not one of the harder part of
the problem if you really want to go parallel" was the discourse I
had in my mind.

;-)
--
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]