Although fork() theoretically copies the address space of the parent process to create the child's address space, Unix normally does not actually make a real copy. Instead it marks everything as copy on write and then waits for either the parent or the child to dirty a page, whereupon it does copies only as much as it has to. This makes forks much faster, which is very important since things in Unix fork a lot.

(Disclaimer: this is the traditional implementation for paged virtual memory. I don't know what V7 did, since it only had swapping.)

At least that is the theory and the ideal, but not in this case the practical.

The second and probably real reason that vfork() exists is that when UC Berkeley was adding paged virtual memory to Unix, they couldn't get copy on write working on their cheap Vax 11/750s (although it did work on the higher end 11/780s). To avoid a fairly bad performance hit on what were already low end machines, they added vfork() (which doesn't require copy on write to run fast) and modified sh and csh to use it.

The specific problem was apparently bugs in the 750 microcode that caused writes to read only pages in the stack to not fault correctly. One of the reasons that the 750 was cheaper than the 780 was that it did a number of things in microcode that the 780 did in hardware, which explains why 780s didn't have this problem.

(My source for the details is a message from John Levine here .)