Re: Explanation for dropping write-back in mmap

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

 



Hi Ram,

> Shawn O. Pearce wrote:
>> I would strongly suggest finding another way to implement the SVN
>> exporter, without using MAP_SHARED.
> 
> David has already started working on using realloc + persist, but I'd
> like to know the reason for your recommendation- is it simply because
> mmap with MAP_SHARED is difficult to port, or is there some other
> reason as well?

I had a think about it, this would be a good chance to enforce append-only writes.
The general strategy would be to write batches of objects for each commit.
All of the data structures in use support this pattern.
However, I'll need to refactor string_pool slightly to make it work cleanly.

> Junio C Hamano wrote:
>> I don't think we _dropped_ a _working_ support that allowed shared
>> mapping.  IIRC the implementation emulated only private mapping well
>> enough to support the use of mmap() in our codebase (iow, instead of
>> allocating a buffer and reading into it and possibly mucking with it
>> without affecting outside world, map it to read and then possibly mucking
>> with it), but lacked input validation to make sure that no caller
>> mistakenly thinks the implementation could satisfy non private mapping.
> 
> Ah, so you did it for safety/ sanity reasons back then.

Having not read the backstory, this was my guess as to the rationale.

--
David Barr.

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