git: 318ceda5fb - main - articles/vm-design: Fix typo

The branch main has been updated by dbaio:

URL: https://cgit.FreeBSD.org/doc/commit/?id=318ceda5fb29eee8ab7dd7622d7db280c1a123d3

commit 318ceda5fb29eee8ab7dd7622d7db280c1a123d3
Author:     Danilo G. Baio <dbaio@FreeBSD.org>
AuthorDate: 2022-04-23 12:37:25 +0000
Commit:     Danilo G. Baio <dbaio@FreeBSD.org>
CommitDate: 2022-04-23 12:37:25 +0000

    articles/vm-design: Fix typo
    
    Submitted by:   dymil
    Pull Request:   https://github.com/freebsd/freebsd-doc/pull/65
---
 documentation/content/en/articles/vm-design/_index.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/content/en/articles/vm-design/_index.adoc b/documentation/content/en/articles/vm-design/_index.adoc
index cac81535c5..7499c1e362 100644
--- a/documentation/content/en/articles/vm-design/_index.adoc
+++ b/documentation/content/en/articles/vm-design/_index.adoc
@@ -106,7 +106,7 @@ Data may be modified on a page-by-page basis whereas the file mapping encompasse
 The complexity further increases when a process forks.
 When a process forks, the result is two processes-each with their own private address spaces, including any modifications made by the original process prior to the call to `fork()`.
 It would be silly for the VM system to make a complete copy of the data at the time of the `fork()` because it is quite possible that at least one of the two processes will only need to read from that page from then on, allowing the original page to continue to be used.
-What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not effect the other.
+What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not affect the other.
 
 FreeBSD manages all of this with a layered VM Object model.
 The original binary program file winds up being the lowest VM Object layer.