On Jan 6, 2005, at 9:28 AM, John Szakmeister wrote:
> Peter N. Lundblad wrote:
>> On Thu, 6 Jan 2005, [UTF-8] Branko �^Libej wrote:
>>
>>
>>> Brian W. Fitzpatrick wrote:
>>>
>>> In short, you avoid quadratic I/O behaviour here in exactly the same
>>> way
>>> as we did in the WC -- by caching the entries files. I'm not sure if
>>> this is a valid thing to do in the face of possibly multi-process
>>> access
>>> to the FS, though.
>>>
>>
>> As long as we think that our current APIs, where each lock/unlock
>> requires
>> at least one network round-trip, I think we shouldn't care very much
>> about
>> this. Locking 10,000 files in one directory is really a corner case,
>> isn't
>> it?
>
> I'm not sure about that. I currently work with a customer who has a
> pretty large setup, and they're dying for locking to get into place.
> They've already asked me several times about being able to have locks
> on
> every file in the repository. I would not put it past them to hit this
> case... and to do it the first time they get locking up and running.
Well, even if we implement locking as an O(1) operation on the server,
it's going to take *forever* for your customer to lock and unlock every
file in the repository. That is to say that they're going to have
bigger problems that the implementation of the lock storage mechanism.
-Fitz
- application/pkcs7-signature attachment: smime.p7s
Received on Thu Jan 6 17:13:24 2005