Date: Sun, 17 May 2026 18:24:16 +0000 From: Vladlen Popolitov <vladlen@FreeBSD.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org Subject: git: 01a65121c5 - main - update translation of articles/ r-v to Russian Message-ID: <6a0a07d0.248df.59aac807@gitrepo.freebsd.org>
index | next in thread | raw e-mail
The branch main has been updated by vladlen: URL: https://cgit.FreeBSD.org/doc/commit/?id=01a65121c592c742790ec8f3e4d6d440173e3728 commit 01a65121c592c742790ec8f3e4d6d440173e3728 Author: Vladlen Popolitov <vladlen@FreeBSD.org> AuthorDate: 2026-05-17 18:24:06 +0000 Commit: Vladlen Popolitov <vladlen@FreeBSD.org> CommitDate: 2026-05-17 18:24:06 +0000 update translation of articles/ r-v to Russian Reviewed by: andy Differential Revision: https://reviews.freebsd.org/В56941 --- .../content/ru/articles/rc-scripting/_index.adoc | 4 +- .../content/ru/articles/rc-scripting/_index.po | 6 +- .../content/ru/articles/releng/_index.adoc | 4 +- documentation/content/ru/articles/releng/_index.po | 6 +- .../content/ru/articles/remote-install/_index.adoc | 2 +- .../content/ru/articles/remote-install/_index.po | 4 +- .../content/ru/articles/serial-uart/_index.adoc | 2 +- .../content/ru/articles/serial-uart/_index.po | 4 +- .../content/ru/articles/solid-state/_index.adoc | 6 +- .../content/ru/articles/solid-state/_index.po | 12 +- .../content/ru/articles/vinum/_index.adoc | 4 +- documentation/content/ru/articles/vinum/_index.po | 6 +- .../content/ru/articles/vm-design/_index.adoc | 44 ++-- .../content/ru/articles/vm-design/_index.po | 292 +++++++++++---------- 14 files changed, 199 insertions(+), 197 deletions(-) diff --git a/documentation/content/ru/articles/rc-scripting/_index.adoc b/documentation/content/ru/articles/rc-scripting/_index.adoc index d95808356b..e75b812ed0 100644 --- a/documentation/content/ru/articles/rc-scripting/_index.adoc +++ b/documentation/content/ru/articles/rc-scripting/_index.adoc @@ -63,7 +63,7 @@ toc::[] Основные идеи, лежащие в основе BSD [.filename]#rc.d#, — это _тонкая модульность_ и __повторное использование кода__. _Тонкая модульность_ означает, что каждая базовая «служба», такая как системный демон или примитивная задача запуска, получает собственный сценарий man:sh[1], способный запустить службу, остановить её, перезагрузить или проверить её состояние. Конкретное действие выбирается аргументом командной строки, переданным в сценарий. Сценарий [.filename]#/etc/rc# по-прежнему управляет запуском системы, но теперь он просто вызывает небольшие сценари один за другим с аргументом `start`. Также легко выполнять задачи завершения работы, запуская тот же набор сценариев с аргументом `stop`, что и делает [.filename]#/etc/rc.shutdown#. Обратите внимание, насколько это близко следует Unix-подходу, где используется набор небольших специализированных инструментов, каждый из которых выполняет свою задачу наилучшим образом. _Повторное использование кода_ означает, что общие операции реализованы как функции man:sh[1] и собраны в [.filename]#/etc/rc.subr#. Теперь типичный сценарий может состоять всего из нескольких строк кода man: sh[1]. Наконец, важной частью инфраструктуры [.filename]#rc.d# является man:rcorder[8], который помогает [.filename]#/etc/rc# упорядоченно запускать небольшие сценарии с учётом зависимостей между ними. Он также может помочь [.filename]#/etc/rc.shutdown#, поскольку правильный порядок завершения работы противоположен порядку запуска. -Дизайн BSD [.filename]#rc.d# описан в crossref:rc-scripting[lukem, оригинальной статье Люка Мьюберна], а компоненты [.filename]#rc.d# подробно документированы в crossref:rc-scripting[manpages, соответствующих страницах Справочника]. Однако новичку в [.filename]#rc.d# может быть неочевидно, как связать многочисленные элементы вместе, чтобы создать хорошо структурированный скрипт для конкретной задачи. Поэтому в этой статье будет предпринята попытка описать [.filename]#rc.d# с другого ракурса. В ней будет показано, какие функции следует использовать в ряде типичных случаев и почему. Обратите нимание, что это не руководство HowTo, поскольку наша цель — не предоставление готовых рецептов, а демонстрация нескольких простых способов входа в мир [.filename]#rc.d#. Также эта статья не заменяет соответствующие страниц Справочника. Не стесняйтесь обращаться к ним для получения более формальной и полной документации во время чтения этой статьи. +Дизайн BSD [.filename]#rc.d# описан в crossref:rc-scripting[lukem, оригинальной статье Люка Мьюберна], а компоненты [.filename]#rc.d# подробно документированы в crossref:rc-scripting[manpages, соответствующих страницах Справочника]. Однако новичку в [.filename]#rc.d# может быть неочевидно, как связать многочисленные элементы вместе, чтобы создать хорошо структурированный скрипт для конкретной задачи. Поэтому в этой статье будет предпринята попытка описать [.filename]#rc.d# с другого ракурса. В ней будет показано, какие функции следует использовать в ряде типичных случаев и почему. Обратите нимание, что это не руководство HowTo, поскольку наша цель — не предоставление готовых рецептов, а демонстрация нескольких простых способов входа в мир [.filename]#rc.d#. Также эта статья не заменяет соответствующие страницы Справочника. Не стесняйтесь обращаться к ним для получения более формальной и полной документации во время чтения этой статьи. Для понимания этой статьи есть предварительные требования. Прежде всего, вы должны быть знакомы с языком написания сценариев man:sh[1], чтобы освоить [.filename]#rc.d#. Кроме того, вы должны знать, как система выполняет задачи запуска и завершения работы пользовательского пространства, что описано в man:rc[8]. @@ -761,7 +761,7 @@ run_rc_command "$1" # service dummy_foo start .... -Вышеприведённое создает экземпляр службы dummy с именем dummy_foo. Он использует не файл конфигурации [.filename]#/usr/local/etc/dummy.cfg#, а файл конфигурации [.filename]#/usr/local/etc/dummy_foo.cfg# (➐), и использует PID-файл [.filename]#/var/run/dummy/dummy_foo.pid# вместо [.filename]#/var/run/dummy/dummy.pid#. +Вышеприведённое создаёт экземпляр службы dummy с именем dummy_foo. Он использует не файл конфигурации [.filename]#/usr/local/etc/dummy.cfg#, а файл конфигурации [.filename]#/usr/local/etc/dummy_foo.cfg# (➐), и использует PID-файл [.filename]#/var/run/dummy/dummy_foo.pid# вместо [.filename]#/var/run/dummy/dummy.pid#. Сервисы dummy и dummy_foo могут управляться независимо друг от друга, при этом скрипт запуска обновляется автоматически при обновлении пакета (благодаря символьной ссылке). Это не обновляет строку REQUIRE, поэтому нет простого способа зависеть от конкретного экземпляра. Чтобы зависеть от конкретного экземпляра в порядке запуска, необходимо создать копию вместо использования символьной ссылки. Это предотвращает автоматическое применение изменений в скрипте запуска при установке обновления. diff --git a/documentation/content/ru/articles/rc-scripting/_index.po b/documentation/content/ru/articles/rc-scripting/_index.po index 0eeb313a8b..4986e76dd3 100644 --- a/documentation/content/ru/articles/rc-scripting/_index.po +++ b/documentation/content/ru/articles/rc-scripting/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2026-03-08 09:11+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlesrc-scripting_index/ru/>\n" @@ -236,7 +236,7 @@ msgstr "" "почему. Обратите внимание, что это не руководство HowTo, поскольку наша цель " "— не предоставление готовых рецептов, а демонстрация нескольких простых " "способов входа в мир [.filename]#rc.d#. Также эта статья не заменяет " -"соответствующие страниц Справочника. Не стесняйтесь обращаться к ним для " +"соответствующие страницы Справочника. Не стесняйтесь обращаться к ним для " "получения более формальной и полной документации во время чтения этой статьи." #. type: Plain text @@ -2691,7 +2691,7 @@ msgid "" "uses the PID file [.filename]#/var/run/dummy/dummy_foo.pid# instead of [." "filename]#/var/run/dummy/dummy.pid#." msgstr "" -"Вышеприведённое создает экземпляр службы dummy с именем dummy_foo. Он " +"Вышеприведённое создаёт экземпляр службы dummy с именем dummy_foo. Он " "использует не файл конфигурации [.filename]#/usr/local/etc/dummy.cfg#, а " "файл конфигурации [.filename]#/usr/local/etc/dummy_foo.cfg# (➐), и " "использует PID-файл [.filename]#/var/run/dummy/dummy_foo.pid# вместо [." diff --git a/documentation/content/ru/articles/releng/_index.adoc b/documentation/content/ru/articles/releng/_index.adoc index 1ccbba5108..6ec8b123c5 100644 --- a/documentation/content/ru/articles/releng/_index.adoc +++ b/documentation/content/ru/articles/releng/_index.adoc @@ -58,7 +58,7 @@ toc::[] [[introduction]] == Введение -Разработка FreeBSD — это очень открытый процесс. FreeBSD создается благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion footnote:[Subversion, http://subversion.apache.org] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право за писи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти extref:{contributors}[коммиттеры FreeBSD, staff-committers]footnote:[extref:{contributors}[коммиттеры FreeBSD, staff-committers]] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Выбранная группа разработчиков — link:https://www.FreeBSD.org/administration/#t-core[Основна команда (Core Team)]footnote:[link:https://www.FreeBSD.org/administration/#t-core[Основна команда FreeBSD]] — обеспечивает некоторый уровень руководства проектом. +Разработка FreeBSD — это очень открытый процесс. FreeBSD создаётся благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion footnote:[Subversion, http://subversion.apache.org] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право за писи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти extref:{contributors}[коммиттеры FreeBSD, staff-committers]footnote:[extref:{contributors}[коммиттеры FreeBSD, staff-committers]] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Выбранная группа разработчиков — link:https://www.FreeBSD.org/administration/#t-core[Основна команда (Core Team)]footnote:[link:https://www.FreeBSD.org/administration/#t-core[Основна команда FreeBSD]] — обеспечивает некоторый уровень руководства проектом. Быстрый темп разработки `FreeBSD` делает основную ветку разработки непригодной для повседневного использования широкой публикой. В частности, требуются усилия по стабилизации для доведения системы разработки до релиза производственного качества. Для решения этого конфликта разработка продолжается по нескольким параллельным направлениям. Основная ветка разработки — это _HEAD_ или _trunk_ нашего дерева Subversion, известная как "FreeBSD-CURRENT" или сокращённо "-CURRENT". @@ -115,7 +115,7 @@ MFC означает "Merge From CURRENT" и описывает процесс Вскоре после начала заморозки кода создаётся образ _BETA1_ и выпускается для широкого тестирования. В период заморозки кода не реже чем раз в две недели выпускается как минимум один бета-образ или кандидат в релизы, пока не будет готов финальный выпуск. В дни, предшествующие финальному релизу, команда разработки выпусков постоянно взаимодействует с командой security-officer, сопровождающими документации и сопровождающими портов, чтобы убедиться, что все необходимые компоненты для успешного релиза доступны. -После того, как качество BETA-образов становится достаточно удовлетворительным и не планируется крупных и потенциально рискованных изменений, создается ветка релиза, и образы _Release Candidate_ (RC) собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в режим "жёсткой заморозки кода", когда становится значительно сложнее обосновать новые изменения в системе, за исключением исправления серьезных ошибок или проблем безопасности. +После того, как качество BETA-образов становится достаточно удовлетворительным и не планируется крупных и потенциально рискованных изменений, создаётся ветка релиза, и образы _Release Candidate_ (RC) собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в режим "жёсткой заморозки кода", когда становится значительно сложнее обосновать новые изменения в системе, за исключением исправления серьезных ошибок или проблем безопасности. === Контрольный список финального выпуска diff --git a/documentation/content/ru/articles/releng/_index.po b/documentation/content/ru/articles/releng/_index.po index 706a94cf6b..6b4ace4815 100644 --- a/documentation/content/ru/articles/releng/_index.po +++ b/documentation/content/ru/articles/releng/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2026-03-08 09:11+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlesreleng_index/ru/>\n" @@ -103,7 +103,7 @@ msgid "" "administration/#t-core[FreeBSD Core Team]] of developers provide some level " "of direction over the project." msgstr "" -"Разработка FreeBSD — это очень открытый процесс. FreeBSD создается благодаря " +"Разработка FreeBSD — это очень открытый процесс. FreeBSD создаётся благодаря " "вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к " "Subversion footnote:[Subversion, http://subversion.apache.org] для широкой " "публики, чтобы другие могли просматривать сообщения журнала, различия (патчи)" @@ -465,7 +465,7 @@ msgid "" msgstr "" "После того, как качество BETA-образов становится достаточно " "удовлетворительным и не планируется крупных и потенциально рискованных " -"изменений, создается ветка релиза, и образы _Release Candidate_ (RC) " +"изменений, создаётся ветка релиза, и образы _Release Candidate_ (RC) " "собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также " "снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в " "режим \"жёсткой заморозки кода\", когда становится значительно сложнее " diff --git a/documentation/content/ru/articles/remote-install/_index.adoc b/documentation/content/ru/articles/remote-install/_index.adoc index ee38155597..ba345cfc22 100644 --- a/documentation/content/ru/articles/remote-install/_index.adoc +++ b/documentation/content/ru/articles/remote-install/_index.adoc @@ -68,7 +68,7 @@ toc::[] ==== . Как мы упоминали в разделе crossref:remote-install[background, Предыстория], многие авторитетные компании, предоставляющие хостинг серверов, предлагают своего рода систему восстановления, которая загружается из их локальной сети и доступна через SSH. Обычно они предоставляют эту возможность, чтобы помочь клиентам восстановить повреждённые операционные системы. Как будет объяснено в этой статье, с помощью таких систем восстановления можно установить FreeBSD. + -. Следующий раздел этой статьи описывает, как настроить и собрать минималистичную FreeBSD на локальной машине. Эта версия в конечном итоге будет запущена на удаленной машине с ramdisk, что позволит нам установить полную операционную систему FreeBSD с FTP-зеркала с помощью утилиты sysinstall. +. Следующий раздел этой статьи описывает, как настроить и собрать минималистичную FreeBSD на локальной машине. Эта версия в конечном итоге будет запущена на удалённой машине с ramdisk, что позволит нам установить полную операционную систему FreeBSD с FTP-зеркала с помощью утилиты sysinstall. . Оставшаяся часть статьи описывает процедуру установки, а также настройку файловой системы ZFS. ==== diff --git a/documentation/content/ru/articles/remote-install/_index.po b/documentation/content/ru/articles/remote-install/_index.po index db1d88a41d..2021791a89 100644 --- a/documentation/content/ru/articles/remote-install/_index.po +++ b/documentation/content/ru/articles/remote-install/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2026-03-08 09:11+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlesremote-install_index/ru/>\n" @@ -143,7 +143,7 @@ msgid "" msgstr "" "Следующий раздел этой статьи описывает, как настроить и собрать " "минималистичную FreeBSD на локальной машине. Эта версия в конечном итоге " -"будет запущена на удаленной машине с ramdisk, что позволит нам установить " +"будет запущена на удалённой машине с ramdisk, что позволит нам установить " "полную операционную систему FreeBSD с FTP-зеркала с помощью утилиты " "sysinstall." diff --git a/documentation/content/ru/articles/serial-uart/_index.adoc b/documentation/content/ru/articles/serial-uart/_index.adoc index d172ca320e..56f3b56383 100644 --- a/documentation/content/ru/articles/serial-uart/_index.adoc +++ b/documentation/content/ru/articles/serial-uart/_index.adoc @@ -98,7 +98,7 @@ USART Universal Synchronous-Asynchronous Receiver/Transmitter — Универс === Другие функции UART -Помимо основной задачи преобразования данных из параллельного формата в последовательный для передачи и из последовательного в параллельный при приеме, UART обычно предоставляет дополнительные схемы для сигналов, которые могут использоваться для указания состояния среды передачи и регулирования потока данных в случае, если удаленное устройство не готово принимать больше данных. Например, когда устройство, подключенное к UART, является модемом, модем может сообщать о наличии несущей на телефонной линии, в то время как компьютер може дать команду модему сбросить себя или не принимать вызовы, поднимая или опуская один или несколько из этих дополнительных сигналов. Функция каждого из этих дополнительных сигналов определена в стандарте EIA RS232-C. +Помимо основной задачи преобразования данных из параллельного формата в последовательный для передачи и из последовательного в параллельный при приеме, UART обычно предоставляет дополнительные схемы для сигналов, которые могут использоваться для указания состояния среды передачи и регулирования потока данных в случае, если удалённое устройство не готово принимать больше данных. Например, когда устройство, подключенное к UART, является модемом, модем может сообщать о наличии несущей на телефонной линии, в то время как компьютер може дать команду модему сбросить себя или не принимать вызовы, поднимая или опуская один или несколько из этих дополнительных сигналов. Функция каждого из этих дополнительных сигналов определена в стандарте EIA RS232-C. === Стандарты RS232-C и V.24 diff --git a/documentation/content/ru/articles/serial-uart/_index.po b/documentation/content/ru/articles/serial-uart/_index.po index a0e7e0d534..54dd8dd935 100644 --- a/documentation/content/ru/articles/serial-uart/_index.po +++ b/documentation/content/ru/articles/serial-uart/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2026-03-09 04:45+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlesserial-uart_index/ru/>\n" @@ -343,7 +343,7 @@ msgstr "" "последовательный для передачи и из последовательного в параллельный при " "приеме, UART обычно предоставляет дополнительные схемы для сигналов, которые " "могут использоваться для указания состояния среды передачи и регулирования " -"потока данных в случае, если удаленное устройство не готово принимать больше " +"потока данных в случае, если удалённое устройство не готово принимать больше " "данных. Например, когда устройство, подключенное к UART, является модемом, " "модем может сообщать о наличии несущей на телефонной линии, в то время как " "компьютер может дать команду модему сбросить себя или не принимать вызовы, " diff --git a/documentation/content/ru/articles/solid-state/_index.adoc b/documentation/content/ru/articles/solid-state/_index.adoc index 663594956a..b41c96b313 100644 --- a/documentation/content/ru/articles/solid-state/_index.adoc +++ b/documentation/content/ru/articles/solid-state/_index.adoc @@ -66,7 +66,7 @@ toc::[] [[kernel]] == Параметры ядра -Для тех, кто создает встраиваемую систему FreeBSD, интерес представляют несколько параметров ядра. +Для тех, кто создаёт встраиваемую систему FreeBSD, интерес представляют несколько параметров ядра. Все встраиваемые системы FreeBSD, которые используют флеш-память в качестве системного диска, заинтересованы в использовании дисков в памяти и файловых систем в памяти. Из-за ограниченного количества циклов записи, которые можно выполнить с флеш-памятью, диск и файловые системы на нём будут, скорее всего, монтироваться в режиме доступа только для чтения. В таком случае файловые системы типа [.filename]#/tmp# и [.filename]#/var# монтируются как файловые системы в памяти для того, чтобы позволить системе создать журналы и обновить счетчики и временные фа йлы. Файловые системы в памяти являются критическим компонентом успешной работы FreeBSD на твердотельных устройствах. @@ -82,7 +82,7 @@ options MD_ROOT # md device usable as a potential root device Инициализация встраиваемой системы FreeBSD после загрузки управляется [.filename]#/etc/rc.initdiskless#. -[.filename]#/etc/rc.d/var# монтирует [.filename]#/var# как файловую систему в памяти, создает указываемый список каталогов в [.filename]#/var# при помощи команды man:mkdir[1], изменяет режимы доступа на некоторые из этих каталогов. В процессе выполнения [.filename]#/etc/rc.d/var# задействуется ещё одна переменная [.filename]#rc.conf# - `varsize`. Скрипт [.filename]#/etc/rc.d/var# создает раздел [.filename]#/var# на основе значения этой переменной из [.filename]#rc.conf#: +[.filename]#/etc/rc.d/var# монтирует [.filename]#/var# как файловую систему в памяти, создаёт указываемый список каталогов в [.filename]#/var# при помощи команды man:mkdir[1], изменяет режимы доступа на некоторые из этих каталогов. В процессе выполнения [.filename]#/etc/rc.d/var# задействуется ещё одна переменная [.filename]#rc.conf# - `varsize`. Скрипт [.filename]#/etc/rc.d/var# создаёт раздел [.filename]#/var# на основе значения этой переменной из [.filename]#rc.conf#: [.programlisting] .... @@ -202,7 +202,7 @@ ftp> get tarfile.tar "| zcat | tar xvf -" === Cron -Во время загрузки содержимое каталогa [.filename]#/var# формируется скриптом [.filename]#/etc/rc.d/var# используя данные из [.filename]#/etc/mtree/BSD.var.dist#, поэтому в нём создается несколько стандартных каталогов, в числе которых - [.filename]#cron#, [.filename]#cron/tabs#, [.filename]#at#. +Во время загрузки содержимое каталогa [.filename]#/var# формируется скриптом [.filename]#/etc/rc.d/var# используя данные из [.filename]#/etc/mtree/BSD.var.dist#, поэтому в нём создаётся несколько стандартных каталогов, в числе которых - [.filename]#cron#, [.filename]#cron/tabs#, [.filename]#at#. Однако это не решает проблему с сохранением cron-таблиц между перезагрузками. Когда система перезагружается, то файловая система [.filename]#/var#, которая располагается в памяти, будет уничтожена, вместе со всеми cron-таблицами, которые вы могли там иметь. Поэтому одним из решений может стать создание cron-таблиц для пользователей, которым они нужны, монтирование вашей файловой системы [.filename]#/# в режиме чтения и записи, и копирование этих cron-таблиц в безопасное место, например, в [.filename]#/etc/tabs#, и последующее добавление строки в конец скрипта [.filename]#/e tc/rc.initdiskless# для копирования этих cron-таблиц в каталог [.filename]#/var/cron/tabs# после его создания во время инициализации системы. Вам может также потребоваться добавить строку, которая изменяет режимы доступа и права на каталоги, которые вы создали, и на файлы, которые вы скопировали в скрипте [.filename]#/etc/rc.initdiskless#. diff --git a/documentation/content/ru/articles/solid-state/_index.po b/documentation/content/ru/articles/solid-state/_index.po index afa4125ead..256d9de345 100644 --- a/documentation/content/ru/articles/solid-state/_index.po +++ b/documentation/content/ru/articles/solid-state/_index.po @@ -1,12 +1,12 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025. +# Vladlen Popolitov <vladlenpopolitov@list.ru>, 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2024-12-29 08:30-0500\n" -"PO-Revision-Date: 2025-11-25 04:45+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlessolid-state_index/ru/>\n" @@ -172,7 +172,7 @@ msgid "" "A few kernel options are of specific interest to those creating an embedded " "FreeBSD system." msgstr "" -"Для тех, кто создает встраиваемую систему FreeBSD, интерес представляют " +"Для тех, кто создаёт встраиваемую систему FreeBSD, интерес представляют " "несколько параметров ядра." #. type: Plain text @@ -241,11 +241,11 @@ msgid "" "[.filename]#rc.conf#:" msgstr "" "[.filename]#/etc/rc.d/var# монтирует [.filename]#/var# как файловую систему " -"в памяти, создает указываемый список каталогов в [.filename]#/var# при " +"в памяти, создаёт указываемый список каталогов в [.filename]#/var# при " "помощи команды man:mkdir[1], изменяет режимы доступа на некоторые из этих " "каталогов. В процессе выполнения [.filename]#/etc/rc.d/var# задействуется " "ещё одна переменная [.filename]#rc.conf# - `varsize`. Скрипт [.filename]#/" -"etc/rc.d/var# создает раздел [.filename]#/var# на основе значения этой " +"etc/rc.d/var# создаёт раздел [.filename]#/var# на основе значения этой " "переменной из [.filename]#rc.conf#:" #. type: delimited block . 4 @@ -658,7 +658,7 @@ msgid "" msgstr "" "Во время загрузки содержимое каталогa [.filename]#/var# формируется скриптом " "[.filename]#/etc/rc.d/var# используя данные из [.filename]#/etc/mtree/BSD.var" -".dist#, поэтому в нём создается несколько стандартных каталогов, в числе " +".dist#, поэтому в нём создаётся несколько стандартных каталогов, в числе " "которых - [.filename]#cron#, [.filename]#cron/tabs#, [.filename]#at#." #. type: delimited block = 4 diff --git a/documentation/content/ru/articles/vinum/_index.adoc b/documentation/content/ru/articles/vinum/_index.adoc index ddebec7ce0..6a6e78de9e 100644 --- a/documentation/content/ru/articles/vinum/_index.adoc +++ b/documentation/content/ru/articles/vinum/_index.adoc @@ -177,7 +177,7 @@ crossref:vinum[vinum-comparison, Организации плексов в [.file [[vinum-examples]] == Некоторые примеры -[.filename]#vinum# поддерживает _базу данных конфигурации_, которая описывает объекты, известные конкретной системе. Первоначально пользователь создает базу данных конфигурации из одного или нескольких конфигурационных файлов с помощью man:gvinum[8]. [.filename]#vinum# хранит копию своей базы данных конфигурации на каждом _устройстве_ диска, находящемся под его управлением. Эта база данных обновляется при каждом изменении состояния, так что перезапуск точно восстанавливает состояние каждого объекта [.filename]#vinum#. +[.filename]#vinum# поддерживает _базу данных конфигурации_, которая описывает объекты, известные конкретной системе. Первоначально пользователь создаёт базу данных конфигурации из одного или нескольких конфигурационных файлов с помощью man:gvinum[8]. [.filename]#vinum# хранит копию своей базы данных конфигурации на каждом _устройстве_ диска, находящемся под его управлением. Эта база данных обновляется при каждом изменении состояния, так что перезапуск точно восстанавливает состояние каждого объекта [.filename]#vinum#. === Файл конфигурации @@ -389,7 +389,7 @@ image::vinum-raid10-vol.png[] sd length 100m drive drive4 .... -После обработки этого файла man:gvinum[8] создает следующую структуру в [.filename]#/dev/gvinum#: +После обработки этого файла man:gvinum[8] создаёт следующую структуру в [.filename]#/dev/gvinum#: [.programlisting] .... diff --git a/documentation/content/ru/articles/vinum/_index.po b/documentation/content/ru/articles/vinum/_index.po index affce6fe8a..651eebad56 100644 --- a/documentation/content/ru/articles/vinum/_index.po +++ b/documentation/content/ru/articles/vinum/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2026-03-08 09:11+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlesvinum_index/ru/>\n" @@ -740,7 +740,7 @@ msgid "" msgstr "" "[.filename]#vinum# поддерживает _базу данных конфигурации_, которая " "описывает объекты, известные конкретной системе. Первоначально пользователь " -"создает базу данных конфигурации из одного или нескольких конфигурационных " +"создаёт базу данных конфигурации из одного или нескольких конфигурационных " "файлов с помощью man:gvinum[8]. [.filename]#vinum# хранит копию своей базы " "данных конфигурации на каждом _устройстве_ диска, находящемся под его " "управлением. Эта база данных обновляется при каждом изменении состояния, так " @@ -1417,7 +1417,7 @@ msgid "" "After processing this file, man:gvinum[8] creates the following structure in " "[.filename]#/dev/gvinum#:" msgstr "" -"После обработки этого файла man:gvinum[8] создает следующую структуру в [." +"После обработки этого файла man:gvinum[8] создаёт следующую структуру в [." "filename]#/dev/gvinum#:" #. type: delimited block . 4 diff --git a/documentation/content/ru/articles/vm-design/_index.adoc b/documentation/content/ru/articles/vm-design/_index.adoc index 804913d6df..3311334419 100644 --- a/documentation/content/ru/articles/vm-design/_index.adoc +++ b/documentation/content/ru/articles/vm-design/_index.adoc @@ -59,7 +59,7 @@ toc::[] [[introduction]] == Введение -Перед тем, как перейти непосредственно к существующей архитектуре, потратим немного времени на рассмотрение вопроса о необходимости поддержки и модернизации любого длительно живущего кода. В мире программирования алгоритмы становятся более важными, чем код, и именно из-за академических корней BSD изначально большое внимание уделялось проработке алгоритмов. Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости кода, который может быть достаточно легко изменен, расширен или с течением времени заменен. Хотя некот рые считают BSD "старой" операционной системой, те их нас, кто работает над ней, видят её скорее системой со "зрелым" кодом с различными компонентами, которые были заменены, расширены или изменены современным кодом. Он развивается, и FreeBSD остаётся передовой системой, вне зависимости от того, насколько старой может быть часть кода. Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой ошибкой, которую может допустить программист, является игнорирование истории, и это именно та ошибка, которую сделали многие другие сов ременные операционные системы. Самым ярким примером здесь является Windows NT(R), и последствия ужасны. Linux также в некоторой степени совершил эту ошибку — достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории для сравнения идей, проблема, которая легко и быстро решается сообществом Linux точно так же, как она решается в сообществе BSD-постоянной работой над кодом. Разработчики Windows NT(R), с другой стороны, постоянно совершают те же самые ошибки, что были ре ены в UNIX(R) десятки лет назад, а затем тратят годы на их устранение. Снова и снова. Есть несколько случаев "проработка архитектуры отсутствует" и "мы всегда правы, потому что так говорит наш отдел продаж". Я плохо переношу тех, кого не учит история. +Перед тем, как перейти непосредственно к существующей архитектуре, потратим немного времени на рассмотрение вопроса о необходимости поддержки и модернизации любого длительно живущего кода. В мире программирования алгоритмы становятся более важными, чем код, и именно из-за академических корней BSD изначально большое внимание уделялось проработке алгоритмов. Более тщательное внимание к проектированию в целом приводит к созданию чистой и гибкой кодовой базы, которую со временем можно достаточно легко модифицировать, расширять или з аменять. Хотя некоторые считают BSD "старой" операционной системой, те их нас, кто работает над ней, видят её скорее системой со "зрелым" кодом с различными компонентами, которые были заменены, расширены или изменены современным кодом. Он развивается, и FreeBSD остаётся передовой системой, вне зависимости от того, насколько старой может быть часть кода. Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой ошибкой, которую может допустить программист, является игнорирование истории, и это именно та ошибка, которую сдела и многие другие современные операционные системы. Самым ярким примером здесь является Windows NT(R), и последствия ужасны. Linux также в некоторой степени совершил эту ошибку — достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории для сравнения идей, проблема, которая легко и быстро решается сообществом Linux точно так же, как она решается в сообществе BSD — постоянной работой над кодом. Разработчики Windows NT(R), с другой стороны, постоянно совершают те же сам ые ошибки, что были решены в UNIX(R) десятки лет назад, а затем тратят годы на их устранение. Снова и снова. У них тяжёлый случай синдрома „не нами разработано“ и „мы всегда правы, потому что так говорит наш отдел маркетинга“. Я плохо переношу тех, кого не учит история. Большинство очевидной сложности архитектуры FreeBSD, особенно в подсистеме VM/Swap, является прямым следствием того, что она решает серьезные проблемы с производительностью, которые проявляются при различных условиях. Эти проблемы вызваны не плохой проработкой алгоритмов, а возникают из окружающих факторов. В любом прямом сравнении между платформами эти проблемы проявляются, когда системные ресурсы начинают истощаться. Так как я описываю подсистему VM/Swap во FreeBSD, то читатель должен всегда иметь в виду два обстоятельства: @@ -71,44 +71,44 @@ toc::[] [[vm-objects]] == Объекты VM -Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на нее с точки зрения пользовательского процесса. Каждый пользовательский процесс имеет единое, принадлежащее только ему и неразрывное адресное пространство VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные характеристики. Код программы и её данные являются единым файлом, отображаемым в память (это выполняющийся двоичный файл), однако код программы доступен только для чтения, тогда как данные программы размещаются в режиме копирования-при-запи си. BSS программы представляет собой всего лишь выделенную область памяти, заполненную, если это требовалось, нулями, что называется обнулением страниц памяти по требованию. Отдельные файлы могут также отображаться в адресное пространство, именно так работают динамические библиотеки. Такие отображения требуют изменений, чтобы оставаться принадлежащими процессу, который их выполнил. Системный вызов fork переводит проблему управления VM полностью в новую плоскость, вдобавок к уже имеющимся сложностям. +Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на неё с точки зрения пользовательского процесса. Каждый пользовательский процесс имеет единое, принадлежащее только ему и неразрывное адресное пространство VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные характеристики. Код программы и её данные являются единым файлом, отображаемым в память (это выполняющийся двоичный файл), однако код программы доступен только для чтения, тогда как данные программы размещаются в режиме копирования-при-запи си. BSS программы представляет собой всего лишь выделенную область памяти, заполненную, если это требовалось, нулями, что называется обнулением страниц памяти по требованию. Отдельные файлы могут также отображаться в адресное пространство, именно так работают динамические библиотеки. Такие отображения требуют изменений, чтобы оставаться принадлежащими процессу, который их выполнил. Системный вызов fork переводит проблему управления VM полностью в новую плоскость, вдобавок к уже имеющимся сложностям. Иллюстрирует сложность страница данных двоичной программы (которая является страницей копируемой-при-записи). Двоичная программа содержит секцию предварительно инициализированных данных, которая первоначально отображается непосредственно из файла программы. Когда программа загружается в виртуальную память процесса, эта область сначала отображается в память и поддерживается бинарным файлом программы, позволяя VM-системе освобождать/повторно использовать страницу, а потом загружать её снова из бинарного файла. Однако в момент, когда процесс изменяет эти данные, VM-система должна сделать копию страницы, принадлежащую только этому процессу. Так как эта копия была изменена, то VM-система не может больше освобождать эту страницу, так как впоследствии её невозможно будет восстановить. -Вы тут же заметите, что то, что сначала было простым отображением файла в память, становится гораздо более сложным предметом. Данные могут модифицироваться постранично, когда как отображение файла выполняется для многих страниц за раз. Сложность ещё более увеличивается, когда процесс выполняет вызов fork. При этом порождаются два процесса-каждый с собственным адресным пространством, включающим все изменения, выполненные исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы делать полную копию данных во время вызова `f ork()`, так как весьма вероятно, что один из двух процессов будет нужен только для чтения из той страницы, что позволяет использование исходной страницы. То, что было страницей, принадлежащей только процессу, сделается снова страницей, копируемой при записи, так как каждый из процессов (и родитель, и потомок) полагают, что их собственные изменения после разветвления будут принадлежать только им, и не затронут родственный процесс. +Вы тут же заметите, что то, что сначала было простым отображением файла в память, становится гораздо более сложным предметом. Данные могут модифицироваться постранично, когда как отображение файла выполняется для многих страниц за раз. Сложность ещё более увеличивается, когда процесс выполняет вызов fork. При этом порождаются два процесса, и каждый с собственным адресным пространством, включающим все изменения, выполненные исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы делать полную копию данных во время вызов `fork()`, так как весьма вероятно, что один из двух процессов будет нужен только для чтения из той страницы, что позволяет использование исходной страницы. То, что было страницей, принадлежащей только процессу, снова становится страницей, копируемой при записи, поскольку каждый из процессов (родительский и дочерний) рассчитывает на то, что его собственные изменения после вызова fork() останутся приватными и не повлияют на другой процесс. -FreeBSD управляет всем этим при помощи многоуровневой модели VM-объектов. Исходный файл с двоичной программой переносится на самый нижний уровень объектов VM. Уровень страниц, копируемых при записи, находится выше него, и хранит те страницы, которые были скопированы из исходного файла. Если программа модифицирует страницы данных, относящиеся к исходному файлу, то система VM обнаруживает это и переносит копию этой страницы на более высокий уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. Это можно показать на прос том примере. Функция `fork()` является общей операцией для всех систем *BSD, так что в этом примере будет рассматриваться программа, которая запускается, а затем разветвляется. Когда процесс запускается, VM-система создает некоторый уровень объектов, обозначим его **A**: +FreeBSD управляет всем этим при помощи многоуровневой модели VM-объектов. Исходный файл с двоичной программой переносится на самый нижний уровень объектов VM. Уровень страниц, копируемых при записи, находится выше него, и хранит те страницы, которые были скопированы из исходного файла. Если программа изменяет страницу данных, принадлежащую исходному файлу, подсистема виртуальной памяти обрабатывает страничное нарушение (page fault) и создаёт копию этой страницы на вышележащем уровне. Когда процесс разветвляется, добавляются новые уровни VM-о бъектов. Понять это поможет достаточно простой пример. Функция `fork()` является общей операцией для всех систем *BSD, так что в этом примере будет рассматриваться программа, которая запускается, а затем разветвляется. Когда процесс запускается, VM-система создаёт некоторый уровень объектов, обозначим его **A**: image::fig1.png["Рисунок"] -На рисунке *A* соответствует файлу — по необходимости страницы памяти могут высвобождаться и подгружаться с носителя файла. Подгрузка с диска может потребоваться программе, однако на самом деле мы не хотим, чтобы она записывалась обратно в файл. Поэтому VM-система создает второй уровень, **B**, который физически поддерживается дисковым пространством подкачки: +На рисунке *A* соответствует файлу — по необходимости страницы памяти могут высвобождаться и подгружаться с носителя файла. Подгрузка с диска может потребоваться программе, однако на самом деле мы не хотим, чтобы она записывалась обратно в файл. Поэтому VM-система создаёт второй уровень, **B**, который физически поддерживается дисковым пространством подкачки: image::fig2.png[] -При первой записи в страницу после выполнения этой операции в **B** создается новая страница, содержимое которой берётся из **A**. Все страницы в **B** могут сбрасываться и считываться из устройства подкачки. Когда программа ветвится, VM-система создает два новых уровня объектов — **C1** для порождающего процесса и **C2** для порожденного — они располагаются поверх **B**: +При первой записи в страницу после выполнения этой операции в **B** создаётся новая страница, содержимое которой берётся из **A**. Все страницы в **B** могут сбрасываться и считываться из устройства подкачки. Когда программа ветвится, VM-система создаёт два новых уровня объектов — **C1** для порождающего процесса и **C2** для порождённого — они располагаются поверх **B**: image::fig3.png[] -В этом случае, допустим, что страница в **B** была изменена начальным родительским процессом. В процессе возникнет ситуация копирования при записи, и страница скопируется в **C1**, при этом исходная страница останется в **B** нетронутой. Теперь допустим, что та же самая страница в **B** изменяется порожденным процессом. В процессе возникнет ситуация копирования при записи и страница скопируется в **C2**. Исходная страница в **B** теперь полностью скрыта, так как и **C1**, и **C2** имеют копии, а уровень **B** теоретически может быть уничтожен, если он не предс тавляет собой "реального" файла). Однако такую оптимизацию не так уж просто осуществить, потому что это надо делать на уровне слишком мелких единиц. Во FreeBSD такая оптимизация не выполняется. Теперь положим (а это часто случается), что порожденный процесс выполняет вызов `exec()`. Его текущее адресное пространство обычно заменяется новым адресным пространством, представляющим новый файл. В этом случае уровень **C2** уничтожается: +В этом случае, допустим, что страница в **B** была изменена начальным родительским процессом. Процесс вызовет страничное нарушение копирования-при-записи и продублирует страницу в **C1**, при этом исходная страница останется в **B** нетронутой. Теперь допустим, что та же самая страница в **B** изменяется дочерним процессом. В процессе возникнет ситуация копирования при записи и страница скопируется в **C2**. Исходная страница в **B** теперь полностью скрыта, так как и **C1**, и **C2** имеют копии, а уровень **B** теоретически может быть уничтожен, если он не редставляет собой "реального" файла). Однако такую оптимизацию не так уж просто осуществить, потому что это надо делать на уровне слишком мелких единиц. Во FreeBSD такая оптимизация не выполняется. Теперь положим (а это часто случается), что дочерний процесс выполняет вызов `exec()`. Его текущее адресное пространство обычно заменяется новым адресным пространством, представляющим новый файл. В этом случае уровень **C2** уничтожается: image::fig4.png[] -В этом случае количество потомков **B** становится равным одному и все обращения к **B** теперь выполняются через **C1**. Это означает, что **B** и **C1** могут быть объединены. Все страницы в **B**, которые также существуют и в **C1**, во время объединения из** B** удаляются. Таким образом, хотя оптимизация на предыдущем шаге может не делаться, мы можем восстановить мертвые страницы при окончании работы процессов или при вызове `exec()`. +В этом случае количество потомков **B** становится равным одному и все обращения к **B** теперь выполняются через **C1**. Это означает, что **B** и **C1** могут быть объединены. Все страницы в **B**, которые также существуют и в **C1**, во время объединения из** B** удаляются. Таким образом, хотя оптимизация на предыдущем шаге может не делаться, мы можем восстановить мёртвые страницы при окончании работы процессов или при вызове `exec()`. -Такая модель создает некоторое количество потенциальных проблем. Первая, с которой вы можете столкнуться, заключается в сравнительно большой последовательности уровней объектов VM, на сканирование которых тратится время и память. Большое количество уровней может возникнуть, когда процессы разветвляются, а затем разветвляются ещё раз (как порожденные, так и порождающие). Вторая проблема заключается в том, что вы можете столкнуться с мертвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем последнем примере если как р одитель, так и потомок изменяют одну и ту же страницу, они оба получают собственные копии страницы, а исходная страница на уровне **B** становится никому не доступной. Такая страница в **B** может быть высвобождена. +Такая модель создаёт некоторое количество потенциальных проблем. Во-первых, можно получить относительно глубокий стек наслоённых объектов виртуальной памяти, что может увеличить время сканирования и расход памяти при обработке страничного исключения. Большое количество уровней может возникнуть, когда процессы разветвляются, а затем разветвляются ещё раз (как порождённые, так и порождающие). Вторая проблема заключается в том, что вы можете столкнуться с мёртвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем посл днем примере, если и родитель, и потомок изменяют одну и ту же страницу, они оба получают собственные копии, а исходная страница на уровне **B** становится недоступной ни для одного из них. Такая страница в **B** может быть высвобождена. -FreeBSD решает проблему с глубиной вложенности с помощью приёма оптимизации, который называется "All Shadowed Case". Этот случай возникает, если в **C1** либо *C2* происходит столько случаев копирования страниц при записи, что они полностью перекрывают все страницы в *B*. Допустим, что такое произошло в *C1*. Уровень *C1* может теперь полностью пропускать уровень *B*, так что вместо цепочек *C1* -> *B* -> *A* и *C2* -> *B* -> *A* мы теперь имеем цепочки *C1* -> *A* и *C2* -> *B* -> *A*. Но посмотрите, что получается — теперь *B* имеет только одну ссылку (*C2*), так что мы можем объединить *B* и *C2* . В конечном итоге *B* будет полностью удалён, и мы получим цепочки *C1*-> *A* и *C2*-> *A*. Часто *B* будет содержать большое количество страниц, и ни *C1*, ни *C2* не смогут полностью его заменить. Если мы снова породим процесс и создадим набор уровней *D*, при этом, однако, более вероятно, что один из уровней *D* постепенно сможет полностью заместить гораздо меньший набор данных, представленный *C1* и *C2*. Та же самая оптимизация работает в любой точке графа и её главным результатом является то, что даже на сильно загруженной машине с множеством порождаемых п роцессов стеки объектов VM не часто бывают глубже четырёх уровней. Это верно как для порождающего, так и для порождённого процессов, и остаётся справедливым как в случае, когда ветвление выполняет родитель, так и в случае, когда ветвление выполняет его потомок. +FreeBSD решает проблему с глубиной вложенности с помощью приёма оптимизации, который называется "All Shadowed Case". Этот случай возникает, если в **C1** либо *C2* происходит столько случаев копирования страниц при записи, что они полностью перекрывают все страницы в *B*. Допустим, что такое произошло в *C1*. Уровень *C1* может теперь полностью пропускать уровень *B*, так что вместо цепочек *C1* -> *B* -> *A* и *C2* -> *B* -> *A* мы теперь имеем цепочки *C1* -> *A* и *C2* -> *B* -> *A*. Но посмотрите, что получается — теперь *B* имеет только одну ссылку (*C2*), так что мы можем объединить *B* и *C2* . В конечном итоге *B* будет полностью удалён, и мы получим цепочки *C1* -> *A* и *C2* -> *A*. Часто *B* будет содержать большое количество страниц, и ни *C1*, ни *C2* не смогут полностью его заменить. Если мы снова породим процесс и создадим набор уровней *D*, при этом, однако, более вероятно, что один из уровней *D* постепенно сможет полностью заместить гораздо меньший набор данных, представленный *C1* и *C2*. Та же самая оптимизация работает в любой точке графа и её главным результатом является то, что даже на сильно загруженной машине с множеством порождаемых процессов стеки объектов VM не часто бывают глубже четырёх уровней. Это верно как для порождающего, так и для порождённого процессов, и остаётся справедливым как в случае, когда ветвление выполняет родитель, так и в случае, когда ветвление выполняет его потомок. -Проблема с мертвой страницей все ещё имеет место, когда *C1* или *C2* не полностью перекрывают *B*. Из-за других применяемых нами методов оптимизации этот случай не представляет большой проблемы и мы просто позволяем таким страницам существовать. Если система испытывает нехватку оперативной памяти, она выполняет их выгрузку в область подкачки, что занимает некоторое пространство в области подкачки, но это всё. +Проблема с мёртвой страницей все ещё имеет место, когда *C1* или *C2* не полностью перекрывают *B*. Из-за других применяемых нами методов оптимизации этот случай не представляет большой проблемы, и мы просто позволяем таким страницам существовать. Если система испытывает нехватку оперативной памяти, она выполняет их выгрузку в область подкачки, что занимает некоторое пространство в области подкачки, но это всё. -Преимущество модели VM-объектов заключается в очень быстром выполнении функции `fork()`, так как при этом не выполняется реального копирования данных. Минусом этого подхода является то, что вы можете построить сравнительно сложную иерархию объектов VM, которая несколько замедляет обработку ситуаций отсутствия страниц памяти, и к тому же тратится память на управление структурами объектов VM. Приёмы оптимизации, применяемые во FreeBSD, позволяют снизить значимость этих проблем до степени, когда их можно без особых потерь игнорировать. +Преимущество модели VM-объектов заключается в очень быстром выполнении функции `fork()`, так как при этом не выполняется реального копирования данных. Минусом этого подхода является то, что вы можете построить сравнительно сложную иерархию объектов VM, которая несколько замедляет обработку страничных нарушений, и к тому же тратится память на управление структурами объектов VM. Приёмы оптимизации, применяемые во FreeBSD, позволяют снизить значимость этих проблем до степени, когда их можно без особых потерь игнорировать. [[swap-layers]] == Уровни области подкачки -Страницы с собственными данными первоначально являются страницами, копируемыми-при-записи или заполняемыми нулями. Когда выполняется изменение, и, соответственно, копирование, начальное хранилище объекта (обычно файл) не может больше использоваться для хранения копии страницы, когда VM-системе нужно использовать её повторно для других целей. В этот момент на помощь приходит область подкачки. Область подкачки выделяется для организации хранилища памяти, которая иначе не может быть доступна. FreeBSD создает структуру управления подкач ой для объекта VM, только когда это действительно нужно. Однако структура управления подкачкой исторически имела некоторые проблемы: +Страницы с собственными данными первоначально являются страницами, копируемыми-при-записи или заполняемыми нулями. Когда выполняется изменение, и, соответственно, копирование, начальное хранилище объекта (обычно файл) не может больше использоваться для хранения копии страницы, когда VM-системе нужно использовать её повторно для других целей. В этот момент на помощь приходит область подкачки. Область подкачки выделяется для организации хранилища памяти, которая иначе не может быть доступна. FreeBSD создаёт структуру управления подкач ой для объекта VM, только когда это действительно нужно. Однако структура управления подкачкой исторически имела некоторые проблемы: -* Во FreeBSD 3.X в структуре управления областью подкачки предварительно выделяется массив, который представляет целый объект, требующий хранения в области подкачки — даже если только несколько страниц этого объекта хранятся в области подкачки. Это создает проблему фрагментации памяти ядра в случае, когда в память отображаются большие объекты или когда ветвятся процессы, занимающие большой объём памяти при работе (RSS). +* В FreeBSD 3.X в структуре управления областью подкачки предварительно выделяется массив, который представляет собой целый объект, требующий хранения в области подкачки — даже если только несколько страниц этого объекта хранятся в области подкачки. Это создаёт проблему фрагментации памяти ядра в случае, когда в память отображаются большие объекты или когда ветвятся процессы, занимающие большой объём памяти при работе (RSS). * Также для отслеживания памяти подкачки в памяти ядра поддерживается "список дыр", и он также несколько фрагментирован. Так как "список дыр" является последовательным списком, то производительность при распределении и высвобождении памяти в области подкачки неоптимальна, и её сложность зависит от количества страниц как O(n). * Также в процессе высвобождения памяти из области подкачки требуется выделение памяти в ядре, и это приводит к проблемам блокировки при недостатке памяти. * Проблема ещё более обостряется из-за дыр, создаваемых по чередующемуся алгоритму. @@ -129,26 +129,26 @@ FreeBSD решает проблему с глубиной вложенности Так как система VM использует всю доступную память для кэширования диска, то обычно действительно незанятых страниц очень мало. Система VM зависит от того, как она точно выбирает незанятые страницы для повторного использования для новых распределений. Оптимальный выбор страниц для высвобождения, возможно, является самой важной функцией любой VM-системы, из тех, что она может выполнять, потому что при неправильном выборе система VM вынуждена будет запрашивать страницы с диска, значительно снижая производительность всей системы. -Какую дополнительную нагрузку мы может выделить в критическом пути для избежания высвобождения не той страницы? Каждый неправильный выбор будет стоить нам сотни тысяч тактов работы центрального процессора и заметное замедление работы затронутых процессов, так что мы должны смириться со значительными издержками для того, чтобы была выбрана правильная страница. Вот почему FreeBSD превосходит другие системы в производительности при нехватке ресурсов памяти. +Какую дополнительную нагрузку мы может выделить в критическом пути для избежания высвобождения неверно выбранной страницы? Каждый неправильный выбор будет стоить нам сотен тысяч тактов работы центрального процессора и заметного замедления работы затронутых процессов, так что мы должны смириться со значительными издержками ради того, чтобы была выбрана правильная страница. Вот почему FreeBSD превосходит другие системы в производительности при нехватке ресурсов памяти. Алгоритм определения свободной страницы написан на основе истории использования страниц памяти. Для получения этой истории система использует возможности бита использования памяти, которые имеются в большинстве аппаратных таблицах страниц памяти. В любом случае, бит использования страницы очищается, и в некоторый более поздний момент VM-система обращается к странице снова и обнаруживает, что этот бит установлен. Это указывает на то, что страница активно используется. Периодически проверяя этот бит, накапливается история использования (в виде счетчика) физической страницы. Когда позже VM-системе требуется высвободить некоторые страницы, проверка истории выступает указателем при определении наиболее вероятной кандидатуры для повторного использования. -Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. Она снимает отображение или защищает страницу, что приводит к ошибке доступа к странице, если к странице выполняется повторное обращение. При возникновении этой ошибки система просто помечает страницу как используемую и снимает защиту со страницы, так что она может использоваться. Хотя использование такого приема только для определения использования страницы весьма накладно, это выгоднее, чем повторно использовать страницу для других целей и обнаружить, ч то она снова нужна процессу и подгружать её с диска. +Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. Она снимает отображение или защищает страницу, что приводит к страничному нарушению, если к странице выполняется повторное обращение. При возникновении этого страничного нарушения система просто помечает страницу как используемую и снимает защиту со страницы, так что она может использоваться. Хотя использование такого приема только для определения использования страницы весьма накладно, это выгоднее, чем повторно использовать страницу для других целей и обнаружить, что она снова нужна процессу и подгружать её с диска. -FreeBSD использует несколько очередей страниц для обновления выбора страниц для повторного использования, а также для определения того, когда же грязные страницы должны быть сброшены в хранилище. Так как таблицы страниц во FreeBSD являются динамическими объектами, практически ничего не стоит вырезать страницу из адресного пространства любого использующего её процесса. После того, как подходящая страница, на основе счетчика использования, выбрана, именно это и выполняется. Система должна различать чистые страницы, которые теоретически м огут быть высвобождены в любое время, и грязные страницы, которые сначала должны быть переписаны в хранилище перед тем, как их можно будет использовать повторно. После нахождения подходящей страницы она перемещается в неактивную очередь, если она является грязной, или в очередь кэша, если она чистая. Отдельный алгоритм, основывающийся на отношении количества грязных страниц к чистым, определяет, когда грязные страницы в неактивной очереди должны быть сброшены на диск. Когда это выполнится, сброшенные страницы перемещаются из неакти ной очереди в очередь кэша. В этот момент страницы в очереди кэша могут быть повторно активизированы VM со сравнительно малыми накладными расходами. Однако страницы в очереди кэша предполагается "высвобождать немедленно" и повторно использовать в LRU-порядке (меньше всего используемый), когда системе потребуется выделение дополнительной памяти. +FreeBSD использует несколько очередей страниц для обновления выбора страниц для повторного использования, а также для определения того, когда же грязные страницы должны быть сброшены в хранилище. Так как таблицы страниц во FreeBSD являются динамическими объектами, практически ничего не стоит вырезать страницу из адресного пространства любого использующего её процесса. После того как подходящая страница на основе счётчика использования выбрана, именно это и выполняется. Система должна различать чистые страницы, которые теоретически мо ут быть высвобождены в любое время, и грязные страницы, которые сначала должны быть переписаны в хранилище перед тем, как их можно будет использовать повторно. После нахождения подходящей страницы она перемещается в неактивную очередь, если она является грязной, или в очередь кэша, если она чистая. Отдельный алгоритм, основывающийся на отношении количества грязных страниц к чистым, определяет, когда грязные страницы в неактивной очереди должны быть сброшены на диск. Когда это выполнится, сброшенные страницы перемещаются из неактивн ой очереди в очередь кэша. В этот момент страницы в очереди кэша могут быть повторно активизированы страничными нарушениями VM со сравнительно малыми накладными расходами. Однако страницы в очереди кэша предполагается "высвобождать немедленно" и повторно использовать в LRU-порядке (наименее давно используемый), когда системе потребуется выделение дополнительной памяти. Стоит отметить, что во FreeBSD VM-система пытается разделить чистые и грязные страницы во избежание срочной необходимости в ненужных сбросах грязных страниц (что отражается на пропускной способности ввода/вывода) и не перемещает беспричинно страницы между разными очередями, когда подсистема управления памятью не испытывает нехватку ресурсов. Вот почему вы можете видеть, что при выполнении команды `systat -vm` в некоторых системах значение счетчика очереди кэша мало, а счетчик активной очереди большой. При повышении нагрузки на VM-систему он прилагает большие усилия на поддержку различных очередей страниц в соотношениях, которые являются наиболее эффективными. Годами ходили современные легенды, что Linux выполняет работу по предотвращению выгрузки на диск лучше, чем FreeBSD, но это не так. На самом деле FreeBSD старается сбросить на диск неиспользуемые страницы для освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я не знаю, остаётся ли это правдой на сегодняшний день. [[prefault-optimizations]] -== Оптимизация ошибок доступа к страницам и их обнуления +== Упреждающая оптимизация страничных нарушений и обнуления -Полагая, что ошибка доступа к странице памяти в VM не является операцией с большими накладными расходами, если страница уже находится в основной памяти и может быть просто отображена в адресное пространство процесса, может оказаться, что это станет весьма накладно, если их будет оказываться регулярно много. Хорошим примером этой ситуации является запуск таких программ, как man:ls[1] или man:ps[1], снова и снова. Если бинарный файл программы отображен в память, но не отображен в таблицу страниц, то все страницы, к которым обращалась программа, о ажутся недоступными при каждом запуске программы. Это не так уж необходимо, если эти страницы уже присутствуют в кэше VM, так что FreeBSD будет пытаться восстанавливать таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. Однако во FreeBSD пока не выполняется предварительное копирование при записи определённых страниц при выполнении вызова exec. Например, если вы запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то заметите, что она всегда выдает некоторое количество ошибок доступа к страницам, даже когда вы запу каете её снова и снова. Эти ошибки относятся к типу zero-fill и не связаны с доступом к коду программы (который уже был предварительно отображён). Предварительное копирование страниц при выполнении вызовов exec или fork находятся в области, требующей более тщательного изучения. +Полагая, что страничное нарушение в VM не является операцией с большими накладными расходами, если страница уже находится в основной памяти и может быть просто отображена в адресное пространство процесса, может оказаться, что это станет весьма накладно, если их будет оказываться регулярно много. Хорошим примером этой ситуации является запуск таких программ, как man:ls[1] или man:ps[1], снова и снова. Если бинарный файл программы отображён в память, но не отображён в таблицу страниц, то все страницы, к которым обращалась программа, окажутся нед ступными при каждом запуске программы. Это не так уж необходимо, если эти страницы уже присутствуют в кэше VM, так что FreeBSD будет пытаться восстанавливать таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. Однако во FreeBSD пока не выполняется предварительное копирование при записи определённых страниц при выполнении вызова exec. Например, если вы запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то заметите, что она всегда выдаёт некоторое количество ошибок доступа к страницам, даже когда вы запускаете её сн ова и снова. Эти ошибки относятся к типу zero-fill и не связаны с доступом к коду программы (который уже был предварительно отображён). Предварительное копирование страниц при выполнении вызовов exec или fork находятся в области, требующей более тщательного изучения. -Большой процент ошибок доступа к страницам, относится к ошибкам при заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды `vmstat -s`. Это происходит, когда процесс обращается к страницам в своей области BSS. Область BSS предполагается изначально заполненной нулями, но VM-система не заботится о выделении памяти до тех пор, пока процесс реально к ней не обратится. При возникновении ошибки VM-система должна не только выделить новую страницу, но и заполнить её нулями. Для оптимизации операции по заполнению нулями в системе VM и еется возможность предварительно обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при возникновении ошибок заполнения нулями. Предварительное заполнение нулями происходит, когда CPU простаивает, однако количество страниц, которые система заранее заполняет нулями, ограничено, для того, чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради оптимизации критического пути. +Большой процент страничных нарушений относится к страничным нарушениям при заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды `vmstat -s`. Это происходит, когда процесс обращается к страницам в своей области BSS. Область BSS предполагается изначально заполненной нулями, но VM-система не заботится о выделении памяти до тех пор, пока процесс реально к ней не обратится. При страничном нарушении VM-система должна не только выделить новую страницу, но и заполнить её нулями. Для оптимизации операции по заполнению нулями в си теме VM имеется возможность предварительно обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при возникновении страничных нарушений заполнения нулями. Предварительное заполнение нулями происходит, когда CPU простаивает, однако количество страниц, которые система заранее заполняет нулями, ограничено, для того, чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради оптимизации критического пути. [[page-table-optimizations]] == Оптимизация таблицы страниц @@ -187,9 +187,9 @@ FreeBSD 3.X использует "последовательный список Это означает, что FreeBSD не будет очень сильно стараться над отделением грязных страниц (неактивная очередь) от чистых страниц (очередь кэша), когда система не находится под нагрузкой, и не будет деактивировать страницы (активная очередь -> неактивная очередь), когда система не нагружена, даже если они не используются. -=== В примере с man:ls(1) и `vmstat 1` выше могут ли некоторые ошибки доступа к странице быть ошибками страниц данных (COW из выполнимого файла в приватные страницы)? То есть я полагаю, что ошибки доступа к страницам являются частично ошибками при заполнении нулями, а частично данных программы. Или вы гарантируете, что FreeBSD выполняет предварительно COW для данных программы? +=== В примере с man:ls(1) и `vmstat 1` выше могут ли некоторые страничные нарушения быть страничными нарушениями данных (COW из выполнимого файла в приватные страницы)? Иными словами, я ожидаю, что часть страничных нарушений будет связана с заполнением нулями, а часть — с программными данными. Или вы гарантируете, что FreeBSD выполняет предварительно COW для данных программы? -Ошибка COW может быть ошибкой при заполнении нулями или данных программы. Механизм в любом случае один и тот же, потому что хранилище данных программы уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет предварительное COW данных программы и заполнение нулями, но она _выполняет_ предварительно отображение страниц, которые имеются в её кэше. +Страничное нарушение COW может быть связано или с заполнением нулями, или с данными программы. Механизм в любом случае один и тот же, потому что хранилище данных программы уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет предварительное COW данных программы и заполнение нулями, но она _выполняет_ предварительно отображение страниц, которые имеются в её кэше. === В вашем разделе об оптимизации таблицы страниц, не могли бы вы более подробно рассказать о pv_entry и vm_page (или vm_page должна быть vm_pmap-как в 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? А именно какое действие/реакцию должно потребоваться для сканирования отображений? diff --git a/documentation/content/ru/articles/vm-design/_index.po b/documentation/content/ru/articles/vm-design/_index.po index adf0052a38..87686da716 100644 --- a/documentation/content/ru/articles/vm-design/_index.po +++ b/documentation/content/ru/articles/vm-design/_index.po @@ -6,7 +6,7 @@ msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-06-29 21:20+0100\n" -"PO-Revision-Date: 2026-03-23 04:45+0000\n" +"PO-Revision-Date: 2026-04-05 04:45+0000\n" "Last-Translator: Vladlen Popolitov <vladlenpopolitov@list.ru>\n" "Language-Team: Russian <https://translate-dev.freebsd.org/projects/" "documentation/articlesvm-design_index/ru/>\n" @@ -130,27 +130,28 @@ msgstr "" "модернизации любого длительно живущего кода. В мире программирования " "алгоритмы становятся более важными, чем код, и именно из-за академических " "корней BSD изначально большое внимание уделялось проработке алгоритмов. " -"Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости " -"кода, который может быть достаточно легко изменен, расширен или с течением " -"времени заменен. Хотя некоторые считают BSD \"старой\" операционной " -"системой, те их нас, кто работает над ней, видят её скорее системой со " -"\"зрелым\" кодом с различными компонентами, которые были заменены, расширены " -"или изменены современным кодом. Он развивается, и FreeBSD остаётся передовой " -"системой, вне зависимости от того, насколько старой может быть часть кода. " -"Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой " -"ошибкой, которую может допустить программист, является игнорирование " -"истории, и это именно та ошибка, которую сделали многие другие современные " -"операционные системы. Самым ярким примером здесь является Windows NT(R), и " -"последствия ужасны. Linux также в некоторой степени совершил эту ошибку — " -"достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому " -"поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории " -"для сравнения идей, проблема, которая легко и быстро решается сообществом " -"Linux точно так же, как она решается в сообществе BSD-постоянной работой над " -"кодом. Разработчики Windows NT(R), с другой стороны, постоянно совершают те " -"же самые ошибки, что были решены в UNIX(R) десятки лет назад, а затем тратят " -"годы на их устранение. Снова и снова. Есть несколько случаев \"проработка " -"архитектуры отсутствует\" и \"мы всегда правы, потому что так говорит наш " -"отдел продаж\". Я плохо переношу тех, кого не учит история." +"Более тщательное внимание к проектированию в целом приводит к созданию " +"чистой и гибкой кодовой базы, которую со временем можно достаточно легко " +"модифицировать, расширять или заменять. Хотя некоторые считают BSD \"старой\"" +" операционной системой, те их нас, кто работает над ней, видят её скорее " +"системой со \"зрелым\" кодом с различными компонентами, которые были " +"заменены, расширены или изменены современным кодом. Он развивается, и " +"FreeBSD остаётся передовой системой, вне зависимости от того, насколько " +"старой может быть часть кода. Это важное отличие, которое, к сожалению, не " +"всеми понимается. Самой большой ошибкой, которую может допустить " +"программист, является игнорирование истории, и это именно та ошибка, которую " +"сделали многие другие современные операционные системы. Самым ярким примером " +"здесь является Windows NT(R), и последствия ужасны. Linux также в некоторой " +"степени совершил эту ошибку — достаточно, чтобы мы, люди BSD, по крайней " +"мере по разу отпустили по этому поводу шутку. Проблема Linux заключается " +"просто в отсутствии опыта и истории для сравнения идей, проблема, которая " +"легко и быстро решается сообществом Linux точно так же, как она решается в " +"сообществе BSD — постоянной работой над кодом. Разработчики Windows NT(R), с " +"другой стороны, постоянно совершают те же самые ошибки, что были решены в " +"UNIX(R) десятки лет назад, а затем тратят годы на их устранение. Снова и " +"снова. У них тяжёлый случай синдрома „не нами разработано“ и „мы всегда " +"правы, потому что так говорит наш отдел маркетинга“. Я плохо переношу тех, " +"кого не учит история." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:86 @@ -240,7 +241,7 @@ msgid "" "process making them. The fork system call adds an entirely new dimension to " "the VM management problem on top of the complexity already given." msgstr "" -"Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на нее с " +"Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на неё с " "точки зрения пользовательского процесса. Каждый пользовательский процесс " "имеет единое, принадлежащее только ему и неразрывное адресное пространство " "VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные " @@ -303,16 +304,16 @@ msgstr "" "память, становится гораздо более сложным предметом. Данные могут " "модифицироваться постранично, когда как отображение файла выполняется для " "многих страниц за раз. Сложность ещё более увеличивается, когда процесс " -"выполняет вызов fork. При этом порождаются два процесса-каждый с собственным " -"адресным пространством, включающим все изменения, выполненные исходным " -"процессом до вызова функции `fork()`. Было бы глупо для VM-системы делать " -"полную копию данных во время вызова `fork()`, так как весьма вероятно, что " -"один из двух процессов будет нужен только для чтения из той страницы, что " -"позволяет использование исходной страницы. То, что было страницей, " -"принадлежащей только процессу, сделается снова страницей, копируемой при " -"записи, так как каждый из процессов (и родитель, и потомок) полагают, что их " -"собственные изменения после разветвления будут принадлежать только им, и не " -"затронут родственный процесс." +"выполняет вызов fork. При этом порождаются два процесса, и каждый с " +"собственным адресным пространством, включающим все изменения, выполненные " +"исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы " +"делать полную копию данных во время вызова `fork()`, так как весьма " +"вероятно, что один из двух процессов будет нужен только для чтения из той " +"страницы, что позволяет использование исходной страницы. То, что было " +"страницей, принадлежащей только процессу, снова становится страницей, " +"копируемой при записи, поскольку каждый из процессов (родительский и " +"дочерний) рассчитывает на то, что его собственные изменения после вызова " +"fork() останутся приватными и не повлияют на другой процесс." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:127 @@ -332,14 +333,14 @@ msgstr "" "Исходный файл с двоичной программой переносится на самый нижний уровень " "объектов VM. Уровень страниц, копируемых при записи, находится выше него, и " "хранит те страницы, которые были скопированы из исходного файла. Если " -"программа модифицирует страницы данных, относящиеся к исходному файлу, то " -"система VM обнаруживает это и переносит копию этой страницы на более высокий " -"уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. " -"Это можно показать на простом примере. Функция `fork()` является общей " -"операцией для всех систем *BSD, так что в этом примере будет рассматриваться " -"программа, которая запускается, а затем разветвляется. Когда процесс " -"запускается, VM-система создает некоторый уровень объектов, обозначим его " -"**A**:" +"программа изменяет страницу данных, принадлежащую исходному файлу, " +"подсистема виртуальной памяти обрабатывает страничное нарушение (page fault) " +"и создаёт копию этой страницы на вышележащем уровне. Когда процесс " +"разветвляется, добавляются новые уровни VM-объектов. Понять это поможет " +"достаточно простой пример. Функция `fork()` является общей операцией для " +"всех систем *BSD, так что в этом примере будет рассматриваться программа, " +"которая запускается, а затем разветвляется. Когда процесс запускается, VM-" +"система создаёт некоторый уровень объектов, обозначим его **A**:" #. type: Positional ($1) AttributeList argument for macro 'image' #: documentation/content/en/articles/vm-design/_index.adoc:128 @@ -365,7 +366,7 @@ msgstr "" "На рисунке *A* соответствует файлу — по необходимости страницы памяти могут " "высвобождаться и подгружаться с носителя файла. Подгрузка с диска может " "потребоваться программе, однако на самом деле мы не хотим, чтобы она " -"записывалась обратно в файл. Поэтому VM-система создает второй уровень, **B**" +"записывалась обратно в файл. Поэтому VM-система создаёт второй уровень, **B**" ", который физически поддерживается дисковым пространством подкачки:" #. type: Target for macro image @@ -383,10 +384,10 @@ msgid "" "layers-C1 for the parent, and C2 for the child-that rest on top of B:" msgstr "" "При первой записи в страницу после выполнения этой операции в **B** " -"создается новая страница, содержимое которой берётся из **A**. Все страницы " +"создаётся новая страница, содержимое которой берётся из **A**. Все страницы " "в **B** могут сбрасываться и считываться из устройства подкачки. Когда " -"программа ветвится, VM-система создает два новых уровня объектов — **C1** " -"для порождающего процесса и **C2** для порожденного — они располагаются " +"программа ветвится, VM-система создаёт два новых уровня объектов — **C1** " +"для порождающего процесса и **C2** для порождённого — они располагаются " "поверх **B**:" #. type: Target for macro image @@ -412,17 +413,17 @@ msgid "" "C2 layer is destroyed:" msgstr "" "В этом случае, допустим, что страница в **B** была изменена начальным " -"родительским процессом. В процессе возникнет ситуация копирования при " -"записи, и страница скопируется в **C1**, при этом исходная страница " +"родительским процессом. Процесс вызовет страничное нарушение копирования-при-" +"записи и продублирует страницу в **C1**, при этом исходная страница " "останется в **B** нетронутой. Теперь допустим, что та же самая страница в " -"**B** изменяется порожденным процессом. В процессе возникнет ситуация " +"**B** изменяется дочерним процессом. В процессе возникнет ситуация " "копирования при записи и страница скопируется в **C2**. Исходная страница в " "**B** теперь полностью скрыта, так как и **C1**, и **C2** имеют копии, а " "уровень **B** теоретически может быть уничтожен, если он не представляет " "собой \"реального\" файла). Однако такую оптимизацию не так уж просто " "осуществить, потому что это надо делать на уровне слишком мелких единиц. Во " "FreeBSD такая оптимизация не выполняется. Теперь положим (а это часто " -"случается), что порожденный процесс выполняет вызов `exec()`. Его текущее " +"случается), что дочерний процесс выполняет вызов `exec()`. Его текущее " "адресное пространство обычно заменяется новым адресным пространством, " "представляющим новый файл. В этом случае уровень **C2** уничтожается:" @@ -447,7 +448,7 @@ msgstr "" "**C1** могут быть объединены. Все страницы в **B**, которые также существуют " "и в **C1**, во время объединения из** B** удаляются. Таким образом, хотя " "оптимизация на предыдущем шаге может не делаться, мы можем восстановить " -"мертвые страницы при окончании работы процессов или при вызове `exec()`." +"мёртвые страницы при окончании работы процессов или при вызове `exec()`." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:165 @@ -462,17 +463,17 @@ msgid "" "the page and the original page in B is no longer accessible by anyone. That " "page in B can be freed." msgstr "" -"Такая модель создает некоторое количество потенциальных проблем. Первая, с " -"которой вы можете столкнуться, заключается в сравнительно большой " -"последовательности уровней объектов VM, на сканирование которых тратится " -"время и память. Большое количество уровней может возникнуть, когда процессы " -"разветвляются, а затем разветвляются ещё раз (как порожденные, так и " -"порождающие). Вторая проблема заключается в том, что вы можете столкнуться с " -"мертвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем " -"последнем примере если как родитель, так и потомок изменяют одну и ту же " -"страницу, они оба получают собственные копии страницы, а исходная страница " -"на уровне **B** становится никому не доступной. Такая страница в **B** может " -"быть высвобождена." +"Такая модель создаёт некоторое количество потенциальных проблем. Во-первых, " +"можно получить относительно глубокий стек наслоённых объектов виртуальной " +"памяти, что может увеличить время сканирования и расход памяти при обработке " +"страничного исключения. Большое количество уровней может возникнуть, когда " +"процессы разветвляются, а затем разветвляются ещё раз (как порождённые, так " +"и порождающие). Вторая проблема заключается в том, что вы можете столкнуться " +"с мёртвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем " +"последнем примере, если и родитель, и потомок изменяют одну и ту же " +"страницу, они оба получают собственные копии, а исходная страница на уровне " +"**B** становится недоступной ни для одного из них. Такая страница в **B** " +"может быть высвобождена." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:176 @@ -499,21 +500,21 @@ msgstr "" "**C1** либо *C2* происходит столько случаев копирования страниц при записи, " "что они полностью перекрывают все страницы в *B*. Допустим, что такое " "произошло в *C1*. Уровень *C1* может теперь полностью пропускать уровень *B*" -", так что вместо цепочек *C1* -> *B* -> *A* и *C2* -> *B* -> *A* мы теперь имеем " -"цепочки *C1* -> *A* и *C2* -> *B* -> *A*. Но посмотрите, что получается — теперь " -"*B* имеет только одну ссылку (*C2*), так что мы можем объединить *B* и *C2*. " -"В конечном итоге *B* будет полностью удалён, и мы получим цепочки *C1* -> *A* и " -"*C2* -> *A*. Часто *B* будет содержать большое количество страниц, и ни *C1*, ни " -"*C2* не смогут полностью его заменить. Если мы снова породим процесс и " -"создадим набор уровней *D*, при этом, однако, более вероятно, что один из " -"уровней *D* постепенно сможет полностью заместить гораздо меньший набор " -"данных, представленный *C1* и *C2*. Та же самая оптимизация работает в любой " -"точке графа и её главным результатом является то, что даже на сильно " -"загруженной машине с множеством порождаемых процессов стеки объектов VM не " -"часто бывают глубже четырёх уровней. Это верно как для порождающего, так и " -"для порождённого процессов, и остаётся справедливым как в случае, когда " -"ветвление выполняет родитель, так и в случае, когда ветвление выполняет его " -"потомок." +", так что вместо цепочек *C1* -> *B* -> *A* и *C2* -> *B* -> *A* мы теперь " +"имеем цепочки *C1* -> *A* и *C2* -> *B* -> *A*. Но посмотрите, что " +"получается — теперь *B* имеет только одну ссылку (*C2*), так что мы можем " +"объединить *B* и *C2*. В конечном итоге *B* будет полностью удалён, и мы " +"получим цепочки *C1* -> *A* и *C2* -> *A*. Часто *B* будет содержать большое " +"количество страниц, и ни *C1*, ни *C2* не смогут полностью его заменить. " +"Если мы снова породим процесс и создадим набор уровней *D*, при этом, " +"однако, более вероятно, что один из уровней *D* постепенно сможет полностью " +"заместить гораздо меньший набор данных, представленный *C1* и *C2*. Та же " +"самая оптимизация работает в любой точке графа и её главным результатом " +"является то, что даже на сильно загруженной машине с множеством порождаемых " +"процессов стеки объектов VM не часто бывают глубже четырёх уровней. Это " +"верно как для порождающего, так и для порождённого процессов, и остаётся " +"справедливым как в случае, когда ветвление выполняет родитель, так и в " +"случае, когда ветвление выполняет его потомок." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:180 @@ -524,9 +525,9 @@ msgid "" "the system runs low on memory it will swap them out, eating a little swap, " "but that is it." msgstr "" -"Проблема с мертвой страницей все ещё имеет место, когда *C1* или *C2* не " +"Проблема с мёртвой страницей все ещё имеет место, когда *C1* или *C2* не " "полностью перекрывают *B*. Из-за других применяемых нами методов оптимизации " -"этот случай не представляет большой проблемы и мы просто позволяем таким " +"этот случай не представляет большой проблемы, и мы просто позволяем таким " "страницам существовать. Если система испытывает нехватку оперативной памяти, " "она выполняет их выгрузку в область подкачки, что занимает некоторое " "пространство в области подкачки, но это всё." @@ -545,10 +546,10 @@ msgstr "" "функции `fork()`, так как при этом не выполняется реального копирования " "данных. Минусом этого подхода является то, что вы можете построить " "сравнительно сложную иерархию объектов VM, которая несколько замедляет " -"обработку ситуаций отсутствия страниц памяти, и к тому же тратится память на " -"управление структурами объектов VM. Приёмы оптимизации, применяемые во " -"FreeBSD, позволяют снизить значимость этих проблем до степени, когда их " -"можно без особых потерь игнорировать." +"обработку страничных нарушений, и к тому же тратится память на управление " +"структурами объектов VM. Приёмы оптимизации, применяемые во FreeBSD, " +"позволяют снизить значимость этих проблем до степени, когда их можно без " +"особых потерь игнорировать." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:186 @@ -574,7 +575,7 @@ msgstr "" "может больше использоваться для хранения копии страницы, когда VM-системе " "нужно использовать её повторно для других целей. В этот момент на помощь " "приходит область подкачки. Область подкачки выделяется для организации " -"хранилища памяти, которая иначе не может быть доступна. FreeBSD создает " +"хранилища памяти, которая иначе не может быть доступна. FreeBSD создаёт " "структуру управления подкачкой для объекта VM, только когда это " "действительно нужно. Однако структура управления подкачкой исторически имела " "некоторые проблемы:" @@ -588,12 +589,12 @@ msgid "" "fragmentation problem when large objects are mapped, or processes with large " "runsizes (RSS) fork." msgstr "" -"Во FreeBSD 3.X в структуре управления областью подкачки предварительно " -"выделяется массив, который представляет целый объект, требующий хранения в " -"области подкачки — даже если только несколько страниц этого объекта хранятся " -"в области подкачки. Это создает проблему фрагментации памяти ядра в случае, " -"когда в память отображаются большие объекты или когда ветвятся процессы, " -"занимающие большой объём памяти при работе (RSS)." +"В FreeBSD 3.X в структуре управления областью подкачки предварительно " +"выделяется массив, который представляет собой целый объект, требующий " +"хранения в области подкачки — даже если только несколько страниц этого " +"объекта хранятся в области подкачки. Это создаёт проблему фрагментации " +"памяти ядра в случае, когда в память отображаются большие объекты или когда " +"ветвятся процессы, занимающие большой объём памяти при работе (RSS)." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:197 @@ -754,12 +755,12 @@ msgid "" "systems when memory resources become stressed." msgstr "" "Какую дополнительную нагрузку мы может выделить в критическом пути для " -"избежания высвобождения не той страницы? Каждый неправильный выбор будет " -"стоить нам сотни тысяч тактов работы центрального процессора и заметное " -"замедление работы затронутых процессов, так что мы должны смириться со " -"значительными издержками для того, чтобы была выбрана правильная страница. " -"Вот почему FreeBSD превосходит другие системы в производительности при " -"нехватке ресурсов памяти." +"избежания высвобождения неверно выбранной страницы? Каждый неправильный " +"выбор будет стоить нам сотен тысяч тактов работы центрального процессора и " +"заметного замедления работы затронутых процессов, так что мы должны " +"смириться со значительными издержками ради того, чтобы была выбрана " +"правильная страница. Вот почему FreeBSD превосходит другие системы в " +"производительности при нехватке ресурсов памяти." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:224 @@ -806,13 +807,14 @@ msgid "" "process needs it back and then have to go to disk." msgstr "" "Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. " -"Она снимает отображение или защищает страницу, что приводит к ошибке доступа " -"к странице, если к странице выполняется повторное обращение. При " -"возникновении этой ошибки система просто помечает страницу как используемую " -"и снимает защиту со страницы, так что она может использоваться. Хотя " -"использование такого приема только для определения использования страницы " -"весьма накладно, это выгоднее, чем повторно использовать страницу для других " -"целей и обнаружить, что она снова нужна процессу и подгружать её с диска." +"Она снимает отображение или защищает страницу, что приводит к страничному " +"нарушению, если к странице выполняется повторное обращение. При " +"возникновении этого страничного нарушения система просто помечает страницу " +"как используемую и снимает защиту со страницы, так что она может " +"использоваться. Хотя использование такого приема только для определения " +"использования страницы весьма накладно, это выгоднее, чем повторно " +"использовать страницу для других целей и обнаружить, что она снова нужна " +"процессу и подгружать её с диска." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:245 @@ -841,8 +843,8 @@ msgstr "" "страницы должны быть сброшены в хранилище. Так как таблицы страниц во " "FreeBSD являются динамическими объектами, практически ничего не стоит " "вырезать страницу из адресного пространства любого использующего её " -"процесса. После того, как подходящая страница, на основе счетчика " -"использования, выбрана, именно это и выполняется. Система должна различать " +"процесса. После того как подходящая страница на основе счётчика " +"использования выбрана, именно это и выполняется. Система должна различать " "чистые страницы, которые теоретически могут быть высвобождены в любое время, " "и грязные страницы, которые сначала должны быть переписаны в хранилище перед " "тем, как их можно будет использовать повторно. После нахождения подходящей " @@ -852,10 +854,10 @@ msgstr "" "страницы в неактивной очереди должны быть сброшены на диск. Когда это " "выполнится, сброшенные страницы перемещаются из неактивной очереди в очередь " "кэша. В этот момент страницы в очереди кэша могут быть повторно " -"активизированы VM со сравнительно малыми накладными расходами. Однако " -"страницы в очереди кэша предполагается \"высвобождать немедленно\" и " -"повторно использовать в LRU-порядке (меньше всего используемый), когда " -"системе потребуется выделение дополнительной памяти." +"активизированы страничными нарушениями VM со сравнительно малыми накладными " +"расходами. Однако страницы в очереди кэша предполагается \"высвобождать " +"немедленно\" и повторно использовать в LRU-порядке (наименее давно " +"используемый), когда системе потребуется выделение дополнительной памяти." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:249 @@ -901,7 +903,7 @@ msgstr "" #: documentation/content/en/articles/vm-design/_index.adoc:255 #, no-wrap msgid "Pre-Faulting and Zeroing Optimizations" -msgstr "Оптимизация ошибок доступа к страницам и их обнуления" +msgstr "Упреждающая оптимизация страничных нарушений и обнуления" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:265 @@ -922,26 +924,25 @@ msgid "" "faults, not program code faults (which were pre-faulted in already). Pre-" "copying pages on exec or fork is an area that could use more study." msgstr "" -"Полагая, что ошибка доступа к странице памяти в VM не является операцией с " -"большими накладными расходами, если страница уже находится в основной памяти " -"и может быть просто отображена в адресное пространство процесса, может " -"оказаться, что это станет весьма накладно, если их будет оказываться " -"регулярно много. Хорошим примером этой ситуации является запуск таких " -"программ, как man:ls[1] или man:ps[1], снова и снова. Если бинарный файл " -"программы отображен в память, но не отображен в таблицу страниц, то все " -"страницы, к которым обращалась программа, окажутся недоступными при каждом " -"запуске программы. Это не так уж необходимо, если эти страницы уже " -"присутствуют в кэше VM, так что FreeBSD будет пытаться восстанавливать " -"таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. " -"Однако во FreeBSD пока не выполняется предварительное копирование при записи " -"определённых страниц при выполнении вызова exec. Например, если вы " -"запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то " -"заметите, что она всегда выдает некоторое количество ошибок доступа к " -"страницам, даже когда вы запускаете её снова и снова. Эти ошибки относятся к " -"типу zero-fill и не связаны с доступом к коду программы (который уже был " -"предварительно отображён). Предварительное копирование страниц при " -"выполнении вызовов exec или fork находятся в области, требующей более " -"тщательного изучения." +"Полагая, что страничное нарушение в VM не является операцией с большими " +"накладными расходами, если страница уже находится в основной памяти и может " +"быть просто отображена в адресное пространство процесса, может оказаться, " +"что это станет весьма накладно, если их будет оказываться регулярно много. " +"Хорошим примером этой ситуации является запуск таких программ, как man:ls[1] " +"или man:ps[1], снова и снова. Если бинарный файл программы отображён в " +"память, но не отображён в таблицу страниц, то все страницы, к которым " +"обращалась программа, окажутся недоступными при каждом запуске программы. " +"Это не так уж необходимо, если эти страницы уже присутствуют в кэше VM, так " +"что FreeBSD будет пытаться восстанавливать таблицы страниц процесса из тех " +"страниц, что уже располагаются в VM-кэше. Однако во FreeBSD пока не " +"выполняется предварительное копирование при записи определённых страниц при " +"выполнении вызова exec. Например, если вы запускаете программу man:ls[1] " +"одновременно с работающей `vmstat 1`, то заметите, что она всегда выдаёт " +"некоторое количество ошибок доступа к страницам, даже когда вы запускаете её " +"снова и снова. Эти ошибки относятся к типу zero-fill и не связаны с доступом " +"к коду программы (который уже был предварительно отображён). Предварительное " +"копирование страниц при выполнении вызовов exec или fork находятся в " +"области, требующей более тщательного изучения." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:274 @@ -959,20 +960,20 @@ msgid "" "memory caches. This is an excellent example of adding complexity to the VM " "system to optimize the critical path." msgstr "" -"Большой процент ошибок доступа к страницам, относится к ошибкам при " +"Большой процент страничных нарушений относится к страничным нарушениям при " "заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды `" "vmstat -s`. Это происходит, когда процесс обращается к страницам в своей " "области BSS. Область BSS предполагается изначально заполненной нулями, но VM-" "система не заботится о выделении памяти до тех пор, пока процесс реально к " -"ней не обратится. При возникновении ошибки VM-система должна не только " +"ней не обратится. При страничном нарушении VM-система должна не только " "выделить новую страницу, но и заполнить её нулями. Для оптимизации операции " "по заполнению нулями в системе VM имеется возможность предварительно " "обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при " -"возникновении ошибок заполнения нулями. Предварительное заполнение нулями " -"происходит, когда CPU простаивает, однако количество страниц, которые " -"система заранее заполняет нулями, ограничено, для того, чтобы не переполнить " -"кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради " -"оптимизации критического пути." +"возникновении страничных нарушений заполнения нулями. Предварительное " +"заполнение нулями происходит, когда CPU простаивает, однако количество " +"страниц, которые система заранее заполняет нулями, ограничено, для того, " +"чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности " +"в VM-систему ради оптимизации критического пути." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:276 @@ -1232,10 +1233,10 @@ msgstr "" #, no-wrap msgid "In man:ls[1] the / vmstat 1 example, would not some of the page faults be data page faults (COW from executable file to private page)? I.e., I would expect the page faults to be some zero-fill and some program data. Or are you implying that FreeBSD does do pre-COW for the program data?" msgstr "" -"В примере с man:ls(1) и `vmstat 1` выше могут ли некоторые ошибки доступа к " -"странице быть ошибками страниц данных (COW из выполнимого файла в приватные " -"страницы)? То есть я полагаю, что ошибки доступа к страницам являются " -"частично ошибками при заполнении нулями, а частично данных программы. Или вы " +"В примере с man:ls(1) и `vmstat 1` выше могут ли некоторые страничные " +"нарушения быть страничными нарушениями данных (COW из выполнимого файла в " +"приватные страницы)? Иными словами, я ожидаю, что часть страничных нарушений " +"будет связана с заполнением нулями, а часть — с программными данными. Или вы " "гарантируете, что FreeBSD выполняет предварительно COW для данных программы?" #. type: Plain text @@ -1247,11 +1248,12 @@ msgid "" "COW program data or zero-fill, but it _does_ pre-map pages that exist in its " "cache." msgstr "" -"Ошибка COW может быть ошибкой при заполнении нулями или данных программы. " -"Механизм в любом случае один и тот же, потому что хранилище данных программы " -"уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет " -"предварительное COW данных программы и заполнение нулями, но она _выполняет_ " -"предварительно отображение страниц, которые имеются в её кэше." +"Страничное нарушение COW может быть связано или с заполнением нулями, или с " +"данными программы. Механизм в любом случае один и тот же, потому что " +"хранилище данных программы уже в кэше. Я на самом деле не рад ни тому, ни " +"другому. FreeBSD не выполняет предварительное COW данных программы и " +"заполнение нулями, но она _выполняет_ предварительно отображение страниц, " +"которые имеются в её кэше." #. type: Title === #: documentation/content/en/articles/vm-design/_index.adoc:346home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6a0a07d0.248df.59aac807>