mbrennan@swift.cs.tcd.ie (11/29/90)
Can anyone explain to me how the mmap(2) system call actually works. I know that it maps an area from a file into virtual memory, but I am not sure of some of the finer details of the relationship between the size of the file as it appears in the file system and the size of the mmap'ed area? For example I have a file which is 300 bytes long (created using vi). When I do an mmap call I must specify 4096 bytes (on the DN10000) as the length of the segment to be mapped (len must be a multiple of the pagesize). Sure enough the return value in len indicates that 300 bytes have been mapped. However if I copy say a 1000 byte string (using strcpy) into that mapped region there is no objection. If I terminate the program and examine the data file then I can see the first 300 bytes of the string I copied into the mapped region - fair enough. If I rerun the program, map 4096 bytes from the same 300-byte data file I can now access the 1000 byte string I copied in there during the last run of the program. My question is where were bytes 301-1000 of that string stored between successive runs of the program - or maybe more correctly what was I clobbering. The following is my mmap call: len = 4096 ; ret = mmap(NULL, &len, PROT_READ | PROT_WRITE, MAP_FILE | MAP_NOEXTEND | MAP_SHARED, fd, 0) ; It is being run on an Apollo DN10000 under DomainOS 10.2 (bsd 4.3) and/or Apollo 3550 under DomainOS 10.1 (bsd 4.3) Any help at all appreciated. -- , , , , , , , , , , Micheal O Braonain Roinn Riomheolaiochta, Colaiste Na Trinoide, BAC 2. Email mbrennan@cs.tcd.ie
rees@pisa.ifs.umich.edu (Jim Rees) (11/30/90)
In article <1990Nov28.172733.7570@swift.cs.tcd.ie>, mbrennan@swift.cs.tcd.ie writes:
Can anyone explain to me how the mmap(2) system call actually works.
I know that it maps an area from a file into virtual memory, but I
am not sure of some of the finer details of the relationship between
the size of the file as it appears in the file system and the size of
the mmap'ed area?
It's really very simple. Files are allocated, stored, and mapped in pages,
which are either 1k or 4k bytes. But since most Unix programs expect to
read and write bytes, not pages, the length of the file is also stored
somewhere (in the inode, actually). If you map a file, you can read and
write all of the bytes in the pages you mapped, even past the "end" of the
file. But the "size" of the file (as returned by stat()) determines how
many bytes you can actually read (from read()).
It wouldn't be a good idea to depend on this "feature." Reading and writing
in portions of a mapped file past the "end" may work today, but it's
technically undefined behavior, and certainly depends at least on the page
size.