diff --git a/documentation/content/ru/articles/serial-uart/_index.adoc b/documentation/content/ru/articles/serial-uart/_index.adoc index a1e802e10e..d172ca320e 100644 --- a/documentation/content/ru/articles/serial-uart/_index.adoc +++ b/documentation/content/ru/articles/serial-uart/_index.adoc @@ -1,1034 +1,1034 @@ --- authors: - author: 'Frank Durda' email: uhclem@FreeBSD.org description: 'Подробная информация об использовании последовательных портов и UART в FreeBSD' tags: ["Serial", "hardware", "UART", "Tutorial", "FreeBSD"] title: 'Учебное руководство по последовательному интерфейсу и UART' trademarks: ["freebsd", "microsoft", "general"] --- = Учебное руководство по последовательному интерфейсу и UART :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/serial-uart/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Аннотация Эта статья рассказывает об использовании последовательного оборудования с FreeBSD. ''' toc::[] [[uart]] == UART: Что это и как работает _Copyright (R) 1996 `{uhclem}`, All Rights Reserved. 13 января 1996 год_ Универсальный асинхронный приёмопередатчик (UART) — это ключевой компонент подсистемы последовательной передачи данных компьютера. UART принимает байты данных и передаёт отдельные биты последовательно. На стороне приёмника второй UART собирает биты обратно в полные байты. Последовательная передача данных обычно используется с модемами и для не сетевого взаимодействия между компьютерами, терминалами и другими устройствами. Существует две основные формы последовательной передачи данных: синхронная и асинхронная. В зависимости от режимов, поддерживаемых оборудованием, название подсистемы связи обычно включает букву `A`, если она поддерживает асинхронную передачу, и букву `S`, если поддерживается синхронная передача. Обе формы описаны ниже. Некоторые распространённые сокращения: [.blockquote] UART Universal Asynchronous Receiver/Transmitter — Универсальный асинхронный приёмопередатчик [.blockquote] USART Universal Synchronous-Asynchronous Receiver/Transmitter — Универсальный синхронно-асинхронный приёмопередатчик === Синхронная последовательная передача Синхронная последовательная передача данных требует, чтобы отправитель и получатель имели общий тактовый сигнал, либо чтобы отправитель предоставлял строб-сигнал или другой сигнал синхронизации, чтобы получатель знал, когда "считывать" следующий бит данных. В большинстве форм синхронной последовательной связи, если в данный момент нет доступных данных для передачи, вместо них должен быть отправлен заполняющий символ, чтобы передача данных не прерывалась. Синхронная связь обычно более эффективна, так как между отправителем и получателем передаются только биты данных, однако она может быть более затратной, если требуются дополнительные провода и схемы для обмена тактовым сигналом между отправителем и получателем. Форма синхронной передачи используется с принтерами и устройствами с жёсткими дисками, где данные передаются по одному набору проводов, а тактовый сигнал или строб — по другому проводу. Принтеры и устройства с жёсткими дисками обычно не являются последовательными устройствами, так как большинство стандартов интерфейсов жёстких дисков передают целое слово данных для каждого тактового сигнала или строба, используя отдельный провод для каждого бита слова. В индустрии ПК такие устройства известны как параллельные. Стандартное оборудование для последовательной связи в ПК не поддерживает синхронные операции. Этот режим описан здесь только для сравнения. === Асинхронная последовательная передача Асинхронная передача позволяет передавать данные без необходимости отправки тактового сигнала от отправителя к получателю. Вместо этого отправитель и получатель заранее согласовывают параметры синхронизации, а к каждому слову добавляются специальные биты, которые используются для синхронизации передающего и принимающего устройств. При передаче слова через UART в асинхронном режиме к началу каждого передаваемого слова добавляется бит, называемый "стартовым битом". Стартовый бит используется для оповещения приёмника о начале передачи слова данных, а также для синхронизации тактового сигнала приёмника с тактовым сигналом передатчика. Эти два тактовых сигнала должны быть достаточно точными, чтобы их расхождение по частоте не превышало 10% во время передачи оставшихся битов слова. (Данное требование было установлено во времена механических телетайпов и легко выполняется современным электронным оборудованием.) После стартового бита передаются отдельные биты слова данных, начиная с младшего значащего бита (LSB). Каждый бит передаётся в течение точно такого же времени, как и все остальные биты, и приемник "проверяет" состояние линии примерно на середине интервала, отведенного для каждого бита, чтобы определить, является ли бит `1` или `0`. Например, если передача каждого бита занимает две секунды, приемник проверит сигнал, чтобы определить, является ли он `1` или `0`, через одну секунду, затем подождет две секунды и проверит значение следующего бита, и так далее. Отправитель не знает, когда получатель «посмотрел» значение бита. Отправитель знает только, когда по тактовому сигналу нужно начать передачу следующего бита слова. Когда все слово данных отправлено, передатчик может добавить бит чётности, который он генерирует. Бит чётности может быть использован приемником для выполнения простой проверки на ошибки. Затем передатчик отправляет как минимум один стоповый бит. Когда приемник получил все биты в слове данных, он может проверить биты чётности (как отправитель, так и приемник должны договориться о том, будет ли использоваться бит чётности), а затем приемник ищет стоповый бит. Если стоповый бит не появляется, когда должен, UART считает все слово искаженным и сообщит об ошибке кадрирования главному процессору при чтении слова данных. Обычная причина ошибки кадрирования — несовпадение скорости тактовых сигналов отправителя и приемника или прерывание сигнала. Независимо от того, были ли данные получены правильно или нет, UART автоматически отбрасывает бит чётности, стартовый и стоповый биты. Если отправитель и получатель настроены одинаково, эти биты не передаются хосту. Если готово следующее слово для передачи, стартовый бит нового слова может быть отправлен сразу после того, как будет отправлен стоповый бит предыдущего слова. Поскольку асинхронные данные являются "самосинхронизирующимися", если нет данных для передачи, линия передачи может быть неактивна. === Другие функции UART Помимо основной задачи преобразования данных из параллельного формата в последовательный для передачи и из последовательного в параллельный при приеме, UART обычно предоставляет дополнительные схемы для сигналов, которые могут использоваться для указания состояния среды передачи и регулирования потока данных в случае, если удаленное устройство не готово принимать больше данных. Например, когда устройство, подключенное к UART, является модемом, модем может сообщать о наличии несущей на телефонной линии, в то время как компьютер может дать команду модему сбросить себя или не принимать вызовы, поднимая или опуская один или несколько из этих дополнительных сигналов. Функция каждого из этих дополнительных сигналов определена в стандарте EIA RS232-C. === Стандарты RS232-C и V.24 В большинстве компьютерных систем UART подключен к схеме, которая генерирует сигналы, соответствующие спецификации EIA RS232-C. Также существует стандарт CCITT под названием V.24, который отражает спецификации, включенные в RS232-C. ==== Назначения битов RS232-C (метки и пробелы) В стандарте RS232-C значение `1` называется `Маркер` (Mark), а значение `0` — `Пробел` (Space). Когда линия связи находится в состоянии покоя, говорят, что она "маркирует" (Marking), то есть передаёт непрерывные значения `1`. Стартовый бит всегда имеет значение `0` (пробел). Стоповый бит всегда имеет значение `1` (метка). Это означает, что на линии всегда будет переход от метки (1) к пробелу (0) в начале каждого слова, даже при передаче нескольких слов подряд. Это гарантирует, что отправитель и получатель могут синхронизировать свои тактовые сигналы независимо от содержимого передаваемых битов данных. Время простоя между стоповым и стартовым битами не обязательно должно быть точным кратным (включая ноль) скорости передачи данных коммуникационного канала, однако большинство UART спроектированы таким образом для простоты. В стандарте RS232-C сигнал «Marking» (логическая `1`) представлен напряжением от -2 В до -12 В, а сигнал «Spacing» (логический `0`) — напряжением от 0 В до +12 В. Передатчик должен выдавать +12 В или -12 В, а приёмник должен учитывать возможные потери напряжения в длинных кабелях. Некоторые маломощные передатчики (например, в портативных компьютерах) иногда используют только +5 В и -5 В, но эти значения всё ещё допустимы для приёмника RS232-C при условии использования коротких кабелей. ==== Сигнал Break в RS232-C RS232-C также определяет сигнал под названием `Break`, который вызывается передачей непрерывных значений Spacing (без стартовых или стоповых битов). Когда на линии данных отсутствует напряжение, считается, что линия передаёт `Break`. Сигнал `Break` должен иметь длительность больше, чем время, необходимое для передачи полного байта, включая стартовый, стоповый и биты чётности. Большинство UART способны различить ошибку кадрирования и сигнал Break, но если UART не поддерживает эту функцию, для определения Break можно использовать обнаружение ошибки кадрирования. Во времена телетайпов, когда множество принтеров по всей стране были соединены последовательно (например, в службах новостей), любое устройство могло вызвать `Break`, временно размыкая всю цепь, чтобы ток не протекал. Это использовалось для того, чтобы место с срочными новостями могло прервать устройство в другом месте, которое в данный момент передавало информацию. В современных системах существует два типа сигналов Break. Если Break длится дольше 1,6 секунд, он считается "Модемным Break", и некоторые модемы можно запрограммировать на завершение соединения и переход в режим ожидания или вход в командный режим модема при обнаружении этого сигнала. Если Break короче 1,6 секунд, это означает "Break данных", и удалённый компьютер должен решить, как реагировать на этот сигнал. Иногда такая форма Break используется как сигнал "Внимание" или "Прерывание", а иногда принимается как замена символу ASCII CONTROL-C. Метки и пробелы также эквивалентны "дыркам" и "отсутствию дырок" в системах с бумажной лентой. [NOTE] ==== Разрывы не могут быть сгенерированы с перфоленты или из любого другого байтового значения, поскольку байты всегда отправляются со стартовым и стоповым битами. UART обычно способен генерировать непрерывный сигнал Spacing в ответ на специальную команду от главного управляющего устройства (процессора передачи). ==== ==== RS232-C устройства DTE и DCE Спецификация RS232-C определяет два типа оборудования: оконечное оборудование данных (DTE — Data Terminal Equipment) и оборудование передачи данных (DCE — Data Carrier Equipment). Обычно устройство DTE — это терминал (или компьютер), а DCE — модем. На другом конце телефонной линии в разговоре принимающий модем также является устройством DCE, а компьютер, подключённый к этому модему, — устройством DTE. Устройство DCE принимает сигналы на тех контактах, на которых устройство DTE передаёт, и наоборот. Когда два устройства, оба являющиеся DTE или DCE, должны быть соединены вместе без модема или аналогичного преобразователя среды между ними, необходимо использовать NULL модем. NULL модем электрически перестраивает кабель так, что выход передатчика подключается ко входу приемника на другом устройстве, и наоборот. Аналогичные преобразования выполняются для всех управляющих сигналов, чтобы каждое устройство видело то, что оно считает сигналами DCE (или DTE) от другого устройства. Количество сигналов, генерируемых устройствами DTE и DCE, не симметрично. Устройство DTE генерирует меньше сигналов для устройства DCE, чем получает от него. ==== Назначение контактов RS232-C Спецификация EIA RS232-C (и её эквивалент ITU, V.24) предусматривает использование двадцатипятиконтактного разъёма (обычно DB25) и определяет назначение большинства контактов в этом разъёме. В IBM Personal Computer и подобных системах подмножество сигналов RS232-C предоставляется через девятиконтактные разъемы (DB9). Сигналы, которые не включены в разъем ПК, в основном связаны с синхронной работой, и этот режим передачи не поддерживается UART, выбранным IBM для использования в IBM PC. В зависимости от производителя компьютера, для связи по RS232-C могут использоваться разъемы DB25, DB9 или оба типа. (В IBM PC также используется разъем DB25 для параллельного интерфейса принтера, что иногда вызывает путаницу.) Ниже представлена таблица назначений сигналов RS232-C в разъемах DB25 и DB9. [.informaltable] [cols="1,1,1,1,1,1,1", frame="none", options="header"] |=== | Контакт в DB25 RS232-C | Контакт в DB9 IBM PC | Символ цепи по EIA | Символ цепи по CCITT | Общее имя | Источник сигнала | Описание |1 |- |AA |101 |PG/FG |- |Защитное заземление (Frame/Protective Ground) |2 |3 |BA |103 |TD |DTE |Передача Данных (Transmit Data) |3 |2 |BB |104 |RD |DCE |Прием данных (Receive Data) |4 |7 |CA |105 |RTS |DTE |Запрос на передачу (Request to Send) |5 |8 |CB |106 |CTS |DCE |Готовность к приёму (Clear to Send) |6 |6 |CC |107 |DSR |DCE |Готовность терминального оборудования (Data Set Ready) |7 |5 |AV |102 |SG/GND |- |Сигнальная земля (Signal Ground) |8 |1 |CF |109 |DCD/CD |DCE |Обнаружение несущей (Data Carrier Detect) |9 |- |- |- |- |- |Зарезервировано для Теста |10 |- |- |- |- |- |Зарезервировано для Теста |11 |- |- |- |- |- |Зарезервировано для Теста |12 |- |CI |122 |SRLSD |DCE |Детектор сигнала вторичной линии приёма |13 |- |SCB |121 |SCTS |DCE |Вторичный сигнал готовности к приёму |14 |- |SBA |118 |STD |DTE |Вторичная линия передачи данных |15 |- |DB |114 |TSET |DCE |Тактирование элементов сигнала передатчика (Trans. Sig. Element Timing) |16 |- |SBB |119 |SRD |DCE |Вторичная линия приема данных |17 |- |DD |115 |RSET |DCE |Тактирование элементов сигнала приёмника (Receiver Signal Element Timing) |18 |- |- |141 |LOOP |DTE |Локальная петля |19 |- |SCA |120 |SRS |DTE |Вторичный запрос на передачу |20 |4 |CD |108.2 |DTR |DTE |Готовность терминального оборудования (Data Terminal Ready) |21 |- |- |- |RDL |DTE |Режим удалённой цифровой петли (Remote Digital Loopback) |22 |9 |CE |125 |RI |DCE |Индикатор передачи данных (Ring Indicator) |23 |- |CH |111 |DSRS |DTE |Селектор скорости передачи данных |24 |- |DA |113 |TSET |DTE |Тактирование элементов сигнала передатчика (Trans. Sig. Element Timing) |25 |- |- |142 |- |DCE |Режим тестирования |=== -=== Биты, Боды и Символы +=== Биты, боды и символы Скорость передачи данных (Baud) — это единица измерения скорости передачи в асинхронной связи. Из-за развития технологий модемной связи этот термин часто ошибочно используют для описания скорости передачи данных в современных устройствах. -Традиционно, скорость передачи (Baud Rate) представляет количество битов, фактически передаваемых по среде, а не объем данных, которые действительно перемещаются от одного устройства DTE к другому. Подсчет Baud включает служебные биты — Start, Stop и Parity, которые генерируются передающим UART и удаляются принимающим UART. Это означает, что 7-битные слова данных на самом деле занимают 10 бит для полной передачи. Следовательно, модем, способный передавать 300 бит в секунду, обычно может передавать только 30 7-битных слов, если используется Parity и присутствуют один бит Start и один бит Stop. +Традиционно, скорость передачи (Baud Rate) представляет количество битов, фактически передаваемых по среде, а не объём данных, которые действительно перемещаются от одного устройства DTE к другому. Подсчет Baud включает служебные биты — Start, Stop и Parity, которые генерируются передающим UART и удаляются принимающим UART. Это означает, что 7-битные слова данных на самом деле занимают 10 бит для полной передачи. Следовательно, модем, способный передавать 300 бит в секунду, обычно может передавать только 30 7-битных слов, если используется Parity и присутствуют один бит Start и один бит Stop. Если используются 8-битные слова данных и биты чётности, скорость передачи данных снижается до 27,27 слов в секунду, так как теперь для передачи восьмибитных слов требуется 11 бит, а модем по-прежнему передаёт только 300 бит в секунду. Формула преобразования байтов в секунду в бодовую скорость и наоборот была простой до появления модемов с коррекцией ошибок. Эти модемы принимают последовательный поток битов от UART в компьютере (даже внутренние модемы часто работают с последовательными данными) и преобразуют биты обратно в байты. Затем эти байты объединяются в пакеты и передаются по телефонной линии с использованием синхронного метода передачи. Это означает, что стоповые, стартовые и биты чётности, добавленные UART в DTE (компьютере), удаляются модемом перед передачей отправляющим модемом. Когда эти байты принимаются удалённым модемом, он добавляет стартовые, стоповые и биты чётности к словам, преобразует их в последовательный формат и отправляет на принимающий UART в удалённом компьютере, который затем удаляет стартовые, стоповые и биты чётности. Причина, по которой выполняются все эти дополнительные преобразования, заключается в том, чтобы два модема могли осуществлять коррекцию ошибок. Это означает, что принимающий модем может запросить у передающего модема повторную отправку блока данных, который был получен с некорректной контрольной суммой. Эта проверка обрабатывается модемами, и устройства DTE обычно не осознают, что этот процесс происходит. Удаляя стартовые, стоповые и биты чётности, дополнительные биты данных, которые два модема должны обмениваться между собой для выполнения коррекции ошибок, в основном скрываются от эффективной скорости передачи, наблюдаемой отправляющим и принимающим оборудованием DTE. Например, если модем отправляет десять 7-битных слов другому модему без включения стартовых, стоповых и битов чётности, отправляющий модем сможет добавить 30 бит своей собственной информации, которую принимающий модем может использовать для коррекции ошибок, не влияя на скорость передачи реальных данных. Использование термина "Бод" дополнительно осложняется модемами, выполняющими сжатие. Одно 8-битное слово, переданное по телефонной линии, может представлять собой дюжину слов, переданных на отправляющий модем. Принимающий модем развернёт данные обратно в их исходное содержимое и передаст эти данные принимающему DTE. Современные модемы также включают буферы, которые позволяют скорости передачи битов по телефонной линии (DCE к DCE) отличаться от скорости передачи битов между DTE и DCE на обоих концах соединения. Обычно скорость между DTE и DCE выше, чем скорость между DCE и DCE, из-за использования сжатия модемами. Поскольку количество битов, необходимых для описания байта, менялось во время передачи между двумя машинами, а также из-за различающихся скоростей передачи в битах в секунду на линиях DTE-DCE и DCE-DCE, использование термина «Бод» для описания общей скорости связи вызывает проблемы и может искажать реальную скорость передачи. Таким образом, термин «Биты в секунду» (bps) является корректным для описания скорости передачи на интерфейсе DCE-DCE, а термины «Бод» или «Биты в секунду» допустимы, когда соединение устанавливается между двумя системами с проводным подключением или используется модем, не выполняющий коррекцию ошибок или сжатие. Современные высокоскоростные модемы (2400, 9600, 14,400 и 19,200 бит/с) на самом деле всё ещё работают на скорости 2400 бод или ниже, или, точнее, 2400 символов в секунду. Высокоскоростные модемы способны кодировать больше бит данных в каждый символ с использованием техники, называемой "Заполнение созвездия (Constellation Stuffing)", поэтому эффективная скорость передачи данных в битах в секунду у модема выше, но модем продолжает работать в ограниченной полосе пропускания звуковых частот, предоставляемой телефонной системой. Модемы, работающие на скоростях 28,800 и выше, имеют переменную скорость передачи символов, но техника остаётся той же. === UART в IBM PC Начиная с оригинального IBM Personal Computer, IBM выбрала UART INS8250 от National Semiconductor для использования в адаптере Parallel/Serial IBM PC. Последующие поколения совместимых компьютеров от IBM и других производителей продолжали использовать INS8250 или улучшенные версии UART из семейства National Semiconductor. ==== Генеалогическое дерево National Semiconductor UART Существует несколько версий и последующих поколений UART INS8250. Основные версии описаны ниже. [.programlisting] .... INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D .... INS8250:: Эта часть использовалась в оригинальном IBM PC и IBM PC/XT. Первоначальное название этой части — INS8250 ACE (Asynchronous Communications Element), и она изготовлена по NMOS-технологии. + 8250 использует восемь портов ввода-вывода и имеет однобайтовый буфер передачи и однобайтовый буфер приема. Этот оригинальный UART имеет несколько состояний гонки и другие недостатки. Оригинальный BIOS IBM включает код для обхода этих недостатков, но это сделало BIOS зависимым от их наличия, поэтому последующие модели, такие как 8250A, 16450 или 16550, не могли быть использованы в оригинальном IBM PC или IBM PC/XT. INS8250-B:: Это более медленная скорость INS8250, созданная по NMOS-технологии. Она имеет те же проблемы, что и оригинальный INS8250. INS8250A:: Улучшенная версия INS8250 с использованием технологии XMOS, в которой исправлены различные функциональные недостатки. INS8250A изначально использовалась в клонах ПК от производителей, применявших "чистые" проекты BIOS. Из-за исправлений в микросхеме этот чип не мог использоваться с BIOS, совместимой с INS8250 или INS8250B. INS82C50A:: Это CMOS-версия (с низким энергопотреблением) INS8250A и имеет схожие функциональные характеристики. NS16450:: Так же, как NS8250A, но с улучшениями для работы с более быстрыми шинами CPU. IBM использовала этот компонент в IBM AT и обновила IBM BIOS, чтобы она больше не зависела от ошибок в INS8250. NS16C450:: Это версия NS16450 с технологией CMOS (низкое энергопотребление). NS16550:: То же, что и NS16450, с 16-байтовым буфером передачи и приема, но конструкция буфера была неудачной и не могла быть надёжно использована. NS16550A:: То же, что и NS16550, но с исправленными недостатками буфера. 16550A и его преемники стали наиболее популярными UART-устройствами в индустрии ПК, в основном благодаря их способности надёжно работать на высоких скоростях передачи данных в операционных системах с медленным временем отклика прерываний. NS16C552:: Этот компонент состоит из двух CMOS UART NS16C550A в одном корпусе. PC16550D:: Так же, как NS16550A, с исправленными незначительными недостатками. Это ревизия D семейства 16550 и последняя доступная версия от National Semiconductor. ==== NS16550AF и PC16550D — это одно и то же -Компания National реорганизовала свою систему нумерации деталей несколько лет назад, и чип NS16550AFN больше не существует под этим названием. (Если у вас есть NS16550AFN, посмотрите на дату изготовления на корпусе — это четырехзначное число, обычно начинающееся с девятки. Первые две цифры обозначают год, а последние две — неделю года, когда чип был упакован. Если у вас есть NS16550AFN, скорее всего, он уже довольно старый.) +Компания National реорганизовала свою систему нумерации деталей несколько лет назад, и чип NS16550AFN больше не существует под этим названием. (Если у вас есть NS16550AFN, посмотрите на дату изготовления на корпусе — это четырёхзначное число, обычно начинающееся с девятки. Первые две цифры обозначают год, а последние две — неделю года, когда чип был упакован. Если у вас есть NS16550AFN, скорее всего, он уже довольно старый.) Новые номера выглядят как PC16550DV, с незначительными отличиями в суффиксных буквах в зависимости от материала корпуса и его формы. (Описание системы нумерации можно найти ниже.) Важно понимать, что в некоторых магазинах можно заплатить $15 (США) за микросхему NS16550AFN, выпущенную в 1990 году, а в соседнем ящике могут лежать новые PC16550DN с небольшими исправлениями, которые National внесла с момента выпуска AFN. PC16550DN, вероятно, произведены в последние полгода и стоят вдвое дешевле (от $5 (США) при оптовой покупке), чем NS16550AFN, поскольку они легко доступны. Поскольку поставки чипов NS16550AFN продолжают сокращаться, цена, вероятно, будет расти до тех пор, пока больше людей не узнают и не примут тот факт, что PC16550DN действительно выполняет ту же функцию, что и старый номер детали. ==== Система нумерации компонентов National Semiconductor Старые номера деталей NS``__nnnnnrqp__`` теперь имеют формат PC``__nnnnnrgp__``. `_r_` — это поле ревизии. Текущая ревизия 16550 от National Semiconductor — `D`. `_p_` — это поле типа пакета. Типы: [.informaltable] [cols="1,1,1", frame="none"] |=== |"F" |QFP |(quad flat pack - квадратный плоский корпус) с L-образными выводами |"N" |DIP |(dual inline package — корпус с двусторонним расположением выводов) для сквозного монтажа с прямыми выводами |"V" |LPCC |(lead plastic chip carrier — пластиковый корпус) с J-образными выводами |=== Поле _g_ обозначает класс изделия. Если перед буквой типа пакета стоит `I`, это указывает на «промышленный» класс детали, который имеет более высокие характеристики, чем стандартная деталь, но не такие высокие, как компонент военного назначения (Milspec). Это необязательное поле. То, что мы раньше называли NS16550AFN (DIP-корпус), теперь называется PC16550DN или PC16550DIN. === Другие производители и аналогичные UART На протяжении многих лет чипы 8250, 8250A, 16450 и 16550 лицензировались или копировались другими производителями. В случае с 8250, 8250A и 16450 точная схема ("мегаячейка") была лицензирована многими производителями, включая Western Digital и Intel. Другие производители проводили обратную разработку чипа или создавали эмуляции с аналогичным поведением. Во внутренних модемах разработчик модема часто эмулирует 8250A/16450 с помощью микропроцессора модема, и эмулированный UART часто имеет скрытый буфер размером в несколько сотен байт. Благодаря размеру буфера, эти эмуляции могут быть такими же надёжными, как 16550A, в способности обрабатывать высокоскоростные данные. Однако большинство операционных систем по-прежнему сообщают, что UART является только 8250A или 16450, и могут не эффективно использовать дополнительную буферизацию, присутствующую в эмулированном UART, если не используются специальные драйверы. Некоторые производители модемов под давлением рыночных сил отказываются от конструкции с буфером в сотни байт и вместо этого используют UART 16550A, чтобы их продукция выглядела выигрышно в рыночных сравнениях, даже если это может снизить фактическую производительность. Распространённое заблуждение заключается в том, что все микросхемы с маркировкой "16550A" одинаковы по производительности. Однако между ними существуют различия, а в некоторых клонах 16550A даже встречаются серьёзные недостатки. Когда компания National Semiconductor разработала NS16550, она получила несколько патентов на эту конструкцию и также ограничила лицензирование, что затруднило для других производителей выпуск чипов с аналогичными характеристиками. В результате патентов обратно спроектированные конструкции и эмуляции должны были избегать нарушения пунктов, охватываемых патентами. Впоследствии эти копии почти никогда не работают точно так же, как NS16550A или PC16550D, которые являются компонентами, наиболее востребованными производителями компьютеров и модемов, но иногда они не готовы платить цену, необходимую для получения оригинальных деталей. -Некоторые различия в клонах микросхем 16550A несущественны, в то время как другие могут полностью препятствовать использованию устройства с определенной операционной системой или драйвером. Эти различия могут проявиться при использовании других драйверов или при возникновении определенных комбинаций событий, которые не были хорошо протестированы или учтены в драйвере Windows(R). Это происходит потому, что большинство производителей модемов и клонов 16550 используют драйверы Microsoft из Windows(R) for Workgroups 3.11 и утилиту Microsoft(R) MS-DOS(R) в качестве основных тестов на совместимость с NS16550A. Этот чрезмерно упрощенный критерий означает, что при использовании другой операционной системы могут возникнуть проблемы из-за тонких различий между клонами и оригинальными компонентами. +Некоторые различия в клонах микросхем 16550A несущественны, в то время как другие могут полностью препятствовать использованию устройства с определённой операционной системой или драйвером. Эти различия могут проявиться при использовании других драйверов или при возникновении определённых комбинаций событий, которые не были хорошо протестированы или учтены в драйвере Windows(R). Это происходит потому, что большинство производителей модемов и клонов 16550 используют драйверы Microsoft из Windows(R) for Workgroups 3.11 и утилиту Microsoft(R) MS-DOS(R) в качестве основных тестов на совместимость с NS16550A. Этот чрезмерно упрощенный критерий означает, что при использовании другой операционной системы могут возникнуть проблемы из-за тонких различий между клонами и оригинальными компонентами. National Semiconductor предоставила программу под названием COMTEST, которая выполняет тесты совместимости независимо от каких-либо драйверов ОС. Следует помнить, что цель такого типа программ — демонстрация недостатков в продуктах конкурентов, поэтому программа будет сообщать как о значительных, так и о крайне незначительных различиях в поведении тестируемого компонента. В серии тестов, проведенных автором этого документа в 1994 году, компоненты производства National Semiconductor, TI, StarTech и CMD, а также мегаячейки и эмуляции, встроенные во внутренние модемы, были протестированы с помощью COMTEST. Ниже приведен счетчик различий для некоторых из этих компонентов. Поскольку эти тесты проводились в 1994 году, они могут не отражать текущую производительность данного продукта от поставщика. Следует отметить, что COMTEST обычно завершает работу при обнаружении чрезмерного количества или определённых типов проблем. В рамках этого тестирования COMTEST был изменён так, чтобы он не завершал работу независимо от количества обнаруженных различий. [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Поставщик | Номер детали | Ошибки (также известные как "различия" в отчётах) |National |(PC16550DV) |0 |National |(NS16550AFN) |0 |National |(NS16C552V) |0 |TI |(TL16550AFN) |3 |CMD |(16C550PE) |19 |StarTech |(ST16C550J) |23 |Rockwell |Стандартный модем с внутренним 16550 или его эмуляцией (RC144DPi/C3000-25) |117 |Sierra |Модем с внутренним 16550 (SC11951/SC11351) |91 |=== [NOTE] ==== На сегодняшний день автор данного документа не обнаружил ни одного не-National компонента, который бы показывал нулевые различия при использовании программы COMTEST. Также следует отметить, что у National было пять версий 16550 за эти годы, и новейшие компоненты ведут себя несколько иначе, чем классический NS16550AFN, который считается эталоном функциональности. COMTEST, по-видимому, закрывает глаза на различия внутри линейки продуктов National и не сообщает об ошибках в компонентах National (за исключением оригинальной 16550), даже когда существуют официальные errata, описывающие ошибки в ревизиях A, B и C этих компонентов, поэтому эту предвзятость COMTEST необходимо учитывать. ==== -Важно понимать, что простое подсчитывание различий с COMTEST не дает полного представления о том, какие различия существенны, а какие нет. Например, около половины различий, обнаруженных в двух вышеупомянутых модемах с внутренними UART, были вызваны тем, что клоновые UART не поддерживают режимы пяти- и шестибитных символов. Настоящие UART 16550, 16450 и 8250 поддерживают эти режимы, и COMTEST проверяет их функциональность, поэтому фиксируется более пятидесяти различий. Однако почти ни один современный модем не поддерживает пяти- или шестибитные символы, особенно те, что обладают функциями коррекции ошибок и сжатия. Это означает, что различия, связанные с режимами пяти- и шестибитных символов, можно не учитывать. +Важно понимать, что простое подсчитывание различий с COMTEST не даёт полного представления о том, какие различия существенны, а какие нет. Например, около половины различий, обнаруженных в двух вышеупомянутых модемах с внутренними UART, были вызваны тем, что клоновые UART не поддерживают режимы пяти- и шестибитных символов. Настоящие UART 16550, 16450 и 8250 поддерживают эти режимы, и COMTEST проверяет их функциональность, поэтому фиксируется более пятидесяти различий. Однако почти ни один современный модем не поддерживает пяти- или шестибитные символы, особенно те, что обладают функциями коррекции ошибок и сжатия. Это означает, что различия, связанные с режимами пяти- и шестибитных символов, можно не учитывать. Многие различия, о которых сообщает COMTEST, связаны с временными характеристиками. Во многих клонированных конструкциях, когда хост читает из одного порта, статусные биты в другом порте могут обновляться с иной скоростью (быстрее или медленнее), чем у _настоящего_ NS16550AFN, и COMTEST выявляет эти различия. Это означает, что количество различий может вводить в заблуждение: одно устройство может иметь всего одно или два различия, но они крайне критичны, тогда как другое устройство, обновляющее статусные регистры быстрее или медленнее эталонной части (что, вероятно, никогда не повлияет на работу правильно написанного драйвера), может иметь десятки зарегистрированных различий. COMTEST можно использовать в качестве инструмента проверки, чтобы предупредить администратора о наличии потенциально несовместимых компонентов, которые могут вызвать проблемы или потребуют особого подхода. Если вы запускаете COMTEST на 16550, который находится в модеме или к модему подключён последовательный порт, необходимо сначала отправить модему команду ATE0&W, чтобы модем не эхо-повторял ни один из тестовых символов. Если вы забудете это сделать, COMTEST сообщит как минимум об одном различии: [source, shell] .... Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 .... -=== 8250/16450/16550 Регистры +=== Регистры 8250/16450/16550 UART 8250/16450/16550 занимает восемь последовательных адресов портов ввода-вывода. В IBM PC определены два расположения для этих восьми портов, которые вместе известны как [.filename]#COM1# и [.filename]#COM2#. Производители PC-клонов и дополнительных карт создали два дополнительных области, известных как [.filename]#COM3# и [.filename]#COM4#, но эти дополнительные COM-порты конфликтуют с другим оборудованием на некоторых системах. Наиболее распространённый конфликт возникает с видеоадаптерами, обеспечивающими эмуляцию IBM 8514. [.filename]#COM1# находится в диапазоне от 0x3f8 до 0x3ff и обычно использует IRQ 4. [.filename]#COM2# находится в диапазоне от 0x2f8 до 0x2ff и обычно использует IRQ 3. [.filename]#COM3# находится в диапазоне от 0x3e8 до 0x3ef и не имеет стандартного IRQ. [.filename]#COM4# находится в диапазоне от 0x2e8 до 0x2ef и не имеет стандартного IRQ. Описание портов ввода-вывода UART 8250/16450/16550 представлено ниже. [.informaltable] [cols="10%,10%,80%", frame="none", options="header"] |=== | Порт ввода/вывода | Доступ Разрешен | Описание |+0x00 |запись (DLAB==0) | Регистр передачи данных (THR). Информация, записанная в этот порт, обрабатывается как слова данных и передаётся через UART. |+0x00 |чтение (DLAB==0) | Регистр буфера приема (RBR). Любые слова данных, полученные UART из последовательного соединения, доступны для чтения хостом через этот порт. |+0x00 |запись/чтение (DLAB==1) | Младший байт защелки делителя (DLL — Divisor Latch LSB) Это значение будет поделено от основного входного тактового сигнала (в IBM PC основной тактовый сигнал равен 1,8432 МГц), и полученный тактовый сигнал будет определять скорость передачи UART. Этот регистр содержит биты с 0 по 7 делителя. |+0x01 |запись/чтение (DLAB==1) | Старший байт защелки делителя (DLH — Divisor Latch MSB) Это значение будет разделено от основного входного тактового сигнала (в IBM PC основной тактовый сигнал равен 1,8432 МГц), и полученный тактовый сигнал будет определять скорость передачи данных UART. Этот регистр содержит биты с 8 по 15 делителя. |+0x01 |запись/чтение (DLAB==0) |Регистр разрешения прерываний (IER) + UART 8250/16450/1655 классифицирует события на четыре категории. Каждая категория может быть настроена на генерацию прерывания при возникновении любого из событий. UART 8250/16450/16550 генерирует единый внешний сигнал прерывания независимо от того, сколько событий в разрешённых категориях произошло. Задача главного процессора — обработать прерывание и затем опросить разрешённые категории прерываний (обычно прерывания разрешены для всех категорий), чтобы определить истинную причину(ы) прерывания. + Бит 7 -> Зарезервирован, всегда 0. + Бит 6 -> Зарезервирован, всегда 0. + Бит 5 -> Зарезервирован, всегда 0. + Бит 4 -> Зарезервирован, всегда 0. + Бит 3 -> Разрешение прерывания по состоянию модема (EDSSI). Установка этого бита в "1" позволяет UART генерировать прерывание при изменении состояния одной или нескольких линий статуса. + Бит 2 -> Разрешение прерывания по состоянию линии приёмника (ELSI). Установка этого бита в "1" приводит к генерации прерывания UART при обнаружении ошибки (или сигнала BREAK) во входящих данных. + Бит 1 -> Разрешение прерывания по опустошению регистра передатчика (ETBEI). Установка этого бита в "1" приводит к генерации прерывания UART, когда в UART появляется место для одного или более дополнительных символов, предназначенных для передачи. + Бит 0 -> Разрешение прерывания по наличию принятых данных (ERBFI). Установка этого бита в "1" приводит к генерации прерывания UART, когда UART принял достаточное количество символов для превышения порога FIFO, или истекло время ожидания FIFO (устаревшие данные), или принят одиночный символ при отключённом FIFO. |+0x02 |запись |Регистр управления FIFO (FCR — FIFO Control Register) (Этот порт отсутствует в UART 8250 и 16450.) + Бит 7 -> Бит триггера приемника #1 + Бит 6 -> Бит триггера приемника #0 + Эти два бита определяют, при каком количестве данных приемник должен генерировать прерывание, когда FIFO активен. + 7 6 Количество слов перед генерацией прерывания + 0 0 1 + 0 1 4 + 1 0 8 + 1 1 14 + Бит 5 -> Зарезервирован, всегда 0. + Бит 4 -> Зарезервирован, всегда 0. + Бит 3 -> Выбор режима DMA. Если бит 0 установлен в "1" (FIFO включены), установка этого бита изменяет работу сигналов -RXRDY и -TXRDY с режима 0 на режим 1. + Бит 2 -> Сброс передающего FIFO. При записи "1" в этот бит содержимое FIFO очищается. Любое слово, которое передаётся в данный момент, будет отправлено полностью. Эта функция полезна для прерывания передачи. + Бит 1 -> Сброс приемного FIFO. При записи "1" в этот бит содержимое FIFO очищается. Любое слово, которое в данный момент собирается в сдвиговом регистре, будет принято полностью. + Бит 0 -> Включение FIFO 16550. При установке этого бита активируются как передающий, так и приемный FIFO. Любое содержимое в регистре хранения, сдвиговых регистрах или FIFO теряется при включении или отключении FIFO. + |+0x02 |чтение |Регистр идентификации прерываний + Бит 7 -> FIFO включены. На UART 8250/16450 этот бит равен нулю. + Бит 6 -> FIFO включены. На UART 8250/16450 этот бит равен нулю. + Бит 5 -> Зарезервирован, всегда 0. + Бит 4 -> Зарезервирован, всегда 0. + Бит 3 -> Бит идентификатора прерывания №2. На UART 8250/16450 этот бит равен нулю. + Бит 2 -> Бит идентификатора прерывания №1 + Бит 1 -> Бит идентификатора прерывания №0.Эти три бита объединяются для указания категории события, вызвавшего текущее прерывание. Эти категории имеют приоритеты, поэтому, если несколько категорий событий происходят одновременно, UART сообщит о более важных событиях первыми, и хост должен обрабатывать события в порядке их поступления. Все события, вызвавшие текущее прерывание, должны быть обработаны до генерации новых прерываний. (Это ограничение архитектуры ПК.) + 2 1 0 Приоритет Описание + 0 1 1 Первый Принятая ошибка (OE, PE, BI или FE) + 0 1 0 Второй Доступны принятые данные + 1 1 0 Второй Идентификация уровня триггера (Устаревшие данные в буфере приема) + 0 0 1 Третий Передатчик готов принять больше данных (THRE) + 0 0 0 Четвертый Изменение состояния модема (-CTS, -DSR, -RI или -DCD) + Бит 0 -> Бит ожидания прерывания. Если этот бит установлен в "0", то как минимум одно прерывание ожидает обработки. |+0x03 |запись/чтение |Регистр управления линией (LCR — Line Control Register) + Бит 7 -> Бит доступа к защелке делителя (DLAB). При установке доступ к регистру передачи/приема данных (THR/RBR) и регистру разрешения прерываний (IER) отключается. Любой доступ к этим портам перенаправляется к регистрам защелки делителя. Установка этого бита, загрузка регистров делителя и сброс DLAB должны выполняться при отключенных прерываниях. + Бит 6 -> Установка прерывания. При установке в "1" передатчик начинает передавать непрерывный интервал (Spacing), пока этот бит не будет сброшен в "0". Это переопределяет любые передаваемые биты символов. + Бит 5 -> Фиксированный бит чётности. При включенной проверке чётности установка этого бита приводит к тому, что бит чётности всегда будет "1" или "0" в зависимости от значения бита 4. Бит 4 -> Выбор чётности (EPS). При включенной проверке чётности и если бит 5 равен "0", установка этого бита приводит к использованию и ожиданию четной чётности. В противном случае используется нечетная чётность. + Бит 3 -> Разрешение проверки чётности (PEN). При установке в "1" бит чётности вставляется между последним битом данных и стоповым битом. UART также ожидает наличие бита чётности в принимаемых данных. + Бит 2 -> Количество стоповых битов (STB). Если установлен в "1" и используются 5-битные слова данных, передаётся и ожидается 1.5 стоповых бита в каждом слове данных. Для 6, 7 и 8-битных слов данных передаётся и ожидается 2 стоповых бита. Если этот бит сброшен в "0", используется один стоповый бит в каждом слове данных. + Бит 1 -> Бит выбора длины слова #1 (WLSB1) + Бит 0 -> Бит выбора длины слова #0 (WLSB0) + Вместе эти биты определяют количество битов в каждом слове данных. + 1 0 Длина слова + 0 0 5 бит данных + 0 1 6 бит данных + 1 0 7 бит данных + 1 1 8 бит данных + |+0x04 |запись/чтение |Регистр управления модемом (MCR — Modem Control Register) + Бит 7 -> Зарезервирован, всегда 0. + Бит 6 -> Зарезервирован, всегда 0. + Бит 5 -> Зарезервирован, всегда 0. + Бит 4 -> Режим петли (Loop-Back). При установке в "1" передатчик и приёмник UART соединяются внутри для диагностики. Также выходы управления модемом UART подключаются к его входам: CTS к RTS, DTR к DSR, OUT1 к RI, а OUT2 к DCD. + Бит 3 -> OUT2. Вспомогательный выход, который процессор может установить в высокий или низкий уровень. В адаптере IBM PC (и большинстве клонов) OUT2 используется для отключения сигнала прерывания от UART 8250/16450/16550. + Бит 2 -> OUT1. Вспомогательный выход, который процессор может установить в высокий или низкий уровень. На адаптере IBM PC не используется. + Бит 1 -> Запрос на передачу (RTS). При установке в "1" выход линии -RTS UART переходит в низкий уровень (активное состояние). + Бит 0 -> Готовность терминала данных (DTR). При установке в "1" выход линии -DTR UART переходит в низкий уровень (активное состояние). + |+0x05 |запись/чтение |Регистр состояния линии (LSR — Line Status Register) + Бит 7 -> Ошибка в FIFO приемника. На UART 8250/16450 этот бит равен нулю. Этот бит устанавливается в «1», когда любой из байтов в FIFO имеет одно или несколько из следующих условий ошибки: PE, FE или BI. + Бит 6 -> Передатчик пуст (TEMT). Когда установлен в «1», в FIFO передатчика или сдвиговом регистре передатчика не осталось слов. Передатчик полностью бездействует. + -Бит 5 -> Регистр хранения передатчика пуст (THRE). Когда установлен в «1», в FIFO (или регистре хранения) теперь есть место для передачи как минимум одного дополнительного слова. Передатчик может все еще передавать данные, когда этот бит установлен в «1». + +Бит 5 -> Регистр хранения передатчика пуст (THRE). Когда установлен в «1», в FIFO (или регистре хранения) теперь есть место для передачи как минимум одного дополнительного слова. Передатчик может все ещё передавать данные, когда этот бит установлен в «1». + Бит 4 -> Прерывание по Break (BI). Приемник обнаружил сигнал Break. + Бит 3 -> Ошибка кадрирования (FE). Обнаружен стартовый бит, но стоповый бит не появился в ожидаемое время. Принятое слово, вероятно, искажено. + Бит 2 -> Ошибка чётности (PE). Бит чётности для принятого слова был некорректен. + Бит 1 -> Ошибка переполнения (OE). Было получено новое слово, но в буфере приема не было места. Вновь поступившее слово в сдвиговом регистре отбрасывается. На UART 8250/16450 слово в регистре хранения отбрасывается, а вновь поступившее слово помещается в регистр хранения. + Бит 0 -> Данные готовы (DR). Одно или несколько слов находятся в FIFO приемника, которые хост может прочитать. Слово должно быть полностью принято и перемещено из сдвигового регистра в FIFO (или регистр хранения для 8250/16450) до того, как этот бит будет установлен. |+0x06 |запись/чтение |Регистр состояния модема (MSR — Modem Status Register) + Бит 7 -> Обнаружение несущей данных (DCD). Отражает состояние линии DCD на UART. + Бит 6 -> Индикатор вызова (RI). Отражает состояние линии RI на UART. + Бит 5 -> Готовность передатчика данных (DSR). Отражает состояние линии DSR на UART. + Бит 4 -> Готовность к приёму (CTS). Отражает состояние линии CTS на UART. + Бит 3 -> Изменение состояния обнаружения несущей данных (DDCD). Устанавливается в "1", если линия -DCD изменила состояние ещё раз с момента последнего чтения MSR хостом. + Бит 2 -> Фронт сигнала вызова (TERI). Устанавливается в "1", если линия -RI перешла из низкого уровня в высокий с момента последнего чтения MSR хостом. + Бит 1 -> Изменение состояния готовности передатчика данных (DDSR). Устанавливается в "1", если линия -DSR изменила состояние ещё раз с момента последнего чтения MSR хостом. + Бит 0 -> Изменение состояния готовности к приёму (DCTS). Устанавливается в "1", если линия -CTS изменила состояние ещё раз с момента последнего чтения MSR хостом. + |+0x07 |запись/чтение |Регистр Scratch (SCR — Scratch Register). Этот регистр не выполняет никакой функции в UART. Хост может записать любое значение в это место и позднее считать его. |=== === За пределами UART 16550A Хотя National Semiconductor не предлагала никаких компонентов, совместимых с 16550 и предоставляющих дополнительные функции, другие производители сделали это. Некоторые из этих компонентов описаны ниже. Следует понимать, что для эффективного использования этих улучшений могут потребоваться драйверы от производителя чипа, поскольку большинство популярных операционных систем не поддерживают функции, выходящие за рамки возможностей 16550. ST16650:: По умолчанию эта часть аналогична NS16550A, но дополнительно можно включить расширенный 32-байтовый буфер отправки и приёма. Производитель — StarTech. TIL16660:: По умолчанию эта часть ведёт себя аналогично NS16550A, но дополнительно может быть включён расширенный 64-байтный буфер передачи и приёма. Производится Texas Instruments. Hayes ESP:: Эта проприетарная внешняя карта содержит буфер передачи и приема размером 2048 байт и поддерживает скорость передачи данных до 230,4 Кбит/с. Произведено компанией Hayes. -В дополнение к этим "простым" UART многие производители выпускают интеллектуальные платы для последовательной связи. Такой тип конструкции обычно включает микропроцессор, который взаимодействует с несколькими UART, обрабатывает и буферизует данные, а затем при необходимости уведомляет основной процессор ПК. Поскольку в такой системе связи UART не доступны напрямую процессору ПК, производителю не обязательно использовать UART, совместимые с 8250, 16450 или 16550. Это дает разработчику свободу выбора компонентов с лучшими характеристиками производительности. +В дополнение к этим "простым" UART многие производители выпускают интеллектуальные платы для последовательной связи. Такой тип конструкции обычно включает микропроцессор, который взаимодействует с несколькими UART, обрабатывает и буферизует данные, а затем при необходимости уведомляет основной процессор ПК. Поскольку в такой системе связи UART не доступны напрямую процессору ПК, производителю не обязательно использовать UART, совместимые с 8250, 16450 или 16550. Это даёт разработчику свободу выбора компонентов с лучшими характеристиками производительности. [[sio]] == Настройка драйвера [.filename]#sio# Драйвер [.filename]#sio# обеспечивает поддержку интерфейсов связи EIA RS-232C (CCITT V.24) на основе NS8250, NS16450, NS16550 и NS16550A. Также поддерживаются несколько многопортовых карт. Подробную техническую документацию смотрите на man:sio[4]. === Digi International (DigiBoard) PC/8 _Предоставлено `{awebster}`. 26 августа 1995._ Вот фрагмент конфигурации с машины, на которой установлена плата Digi International PC/8 с чипом 16550. К ней подключено 8 модемов, работающих на этих 8 линиях, и они отлично функционируют. Не забудьте добавить `options COM_MULTIPORT`, иначе работа будет нестабильной! [.programlisting] .... device sio4 at isa? port 0x100 flags 0xb05 device sio5 at isa? port 0x108 flags 0xb05 device sio6 at isa? port 0x110 flags 0xb05 device sio7 at isa? port 0x118 flags 0xb05 device sio8 at isa? port 0x120 flags 0xb05 device sio9 at isa? port 0x128 flags 0xb05 device sio10 at isa? port 0x130 flags 0xb05 device sio11 at isa? port 0x138 flags 0xb05 irq 9 .... Хитрость настройки заключается в том, что старший бит флагов представляет последний порт SIO, в данном случае 11, поэтому флаги равны 0xb05. === Boca 16 _Предоставлено `{whiteside}`. 26 августа 1995._ Процедуры по настройке платы Boca с 16 портами в FreeBSD довольно просты, но вам понадобится несколько вещей для успешной работы: . Вам необходимо либо установить исходные коды ядра, чтобы перекомпилировать нужные опции, либо найти кого-то, кто сделает это за вас. Стандартное ядро версии 2.0.5 _не_ включает поддержку нескольких портов, и в любом случае вам потребуется добавить запись устройства для каждого порта. . Два, вам нужно знать прерывание и настройку ввода-вывода для вашей платы Boca, чтобы правильно установить эти параметры в ядре. Важное замечание — реальные микросхемы UART для Boca 16 находятся в соединительной коробке, а не на внутренней плате. Поэтому, если она отключена, попытки проверить эти порты завершатся неудачей. Я никогда не проверял загрузку с отключённой коробкой и последующим её подключением, и не рекомендую вам этого делать. Если у вас ещё нет настроенного файла конфигурации пользовательского ядра, обратитесь к разделу extref:{handbook}kernelconfig[Конфигурация ядра, kernelconfig] в руководстве FreeBSD для получения общих инструкций. Ниже приведены конкретные настройки для платы Boca 16, предполагается, что вы используете ядро с именем MYKERNEL и редактируете его с помощью vi. [.procedure] ==== . Добавьте строку + [.programlisting] .... options COM_MULTIPORT .... в конфигурационный файл. . Где находятся текущие строки `device sio__n__`, вам нужно добавить ещё 16 устройств. В следующем примере показана плата Boca Board с прерыванием 3 и базовым адресом ввода-вывода 100h. Адрес ввода-вывода для каждого порта увеличивается на 8 в шестнадцатеричной системе относительно предыдущего порта, поэтому адреса будут 100h, 108h, 110h... + [.programlisting] .... device sio1 at isa? port 0x100 flags 0x1005 device sio2 at isa? port 0x108 flags 0x1005 device sio3 at isa? port 0x110 flags 0x1005 device sio4 at isa? port 0x118 flags 0x1005 ... device sio15 at isa? port 0x170 flags 0x1005 device sio16 at isa? port 0x178 flags 0x1005 irq 3 .... + Запись flags _обязательно_ должна быть изменена по сравнению с этим примером, если вы не используете точно такие же назначения sio. Флаги устанавливаются в соответствии с 0x``__MYY__``, где _M_ обозначает младший номер главного порта (последний порт на Boca 16), а _YY_ указывает, включен или выключен FIFO (включен), используется ли разделение IRQ (да) и есть ли регистр управления IRQ, совместимый с AST/4 (нет). В этом примере, + [.programlisting] .... flags 0x1005 .... указывает, что основной порт - sio16. Если добавить другую плату и назначить порты с sio17 по sio28, флаги для всех 16 портов на _этой_ плате будут 0x1C05, где 1C обозначает минорный номер основного порта. Не изменяйте значение 05. . Сохраните и завершите конфигурацию ядра, перекомпилируйте, установите и перезагрузитесь. Предполагая, что вы успешно установили перекомпилированное ядро и настроили правильный адрес и IRQ, сообщение при загрузке должно указывать на успешное обнаружение портов Boca следующим образом: (очевидно, номера sio, IO и IRQ могут отличаться) + [source, shell] .... sio1 at 0x100-0x107 flags 0x1005 on isa sio1: type 16550A (multiport) sio2 at 0x108-0x10f flags 0x1005 on isa sio2: type 16550A (multiport) sio3 at 0x110-0x117 flags 0x1005 on isa sio3: type 16550A (multiport) sio4 at 0x118-0x11f flags 0x1005 on isa sio4: type 16550A (multiport) sio5 at 0x120-0x127 flags 0x1005 on isa sio5: type 16550A (multiport) sio6 at 0x128-0x12f flags 0x1005 on isa sio6: type 16550A (multiport) sio7 at 0x130-0x137 flags 0x1005 on isa sio7: type 16550A (multiport) sio8 at 0x138-0x13f flags 0x1005 on isa sio8: type 16550A (multiport) sio9 at 0x140-0x147 flags 0x1005 on isa sio9: type 16550A (multiport) sio10 at 0x148-0x14f flags 0x1005 on isa sio10: type 16550A (multiport) sio11 at 0x150-0x157 flags 0x1005 on isa sio11: type 16550A (multiport) sio12 at 0x158-0x15f flags 0x1005 on isa sio12: type 16550A (multiport) sio13 at 0x160-0x167 flags 0x1005 on isa sio13: type 16550A (multiport) sio14 at 0x168-0x16f flags 0x1005 on isa sio14: type 16550A (multiport) sio15 at 0x170-0x177 flags 0x1005 on isa sio15: type 16550A (multiport) sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa sio16: type 16550A (multiport master) .... + Если сообщения проходят слишком быстро, чтобы их увидеть, + [source, shell] .... # dmesg | more .... покажет вам сообщения загрузки. . Далее необходимо создать соответствующие записи в [.filename]#/dev# для устройств с помощью скрипта [.filename]#/dev/MAKEDEV#. Этот шаг можно пропустить, если вы используете FreeBSD 5.X с ядром, в котором включена поддержка man:devfs[5]. + Если вам необходимо создать записи в [.filename]#/dev#, выполните следующую команду от имени `root`: + [source, shell] .... # cd /dev # ./MAKEDEV tty1 # ./MAKEDEV cua1 (everything in between) # ./MAKEDEV ttyg # ./MAKEDEV cuag .... + Если по какой-то причине вам не нужны или не требуются устройства исходящих соединений, вы можете обойтись без создания устройств [.filename]#cua*#. . Если вам нужен быстрый и небрежный способ убедиться, что устройства работают, вы можете просто подключить модем к каждому порту и (как root) + [source, shell] .... # echo at > ttyd* .... для каждого устройства, которое вы создали. Вы _должны_ увидеть, как мигают индикаторы RX для каждого рабочего порта. ==== === Поддержка дешёвых многоканальных UART-карт _Предоставлено Хельге Ольдахом_ mailto:hmo@sep.hamburg.com[hmo@sep.hamburg.com], сентябрь 1999 года Вы когда-нибудь задумывались о поддержке FreeBSD вашей 20-долларовой многофункциональной карты с двумя (или более) COM-портами, разделяющими IRQ? Вот как это сделать: Обычно единственный способ поддержки таких плат — использование отдельного IRQ для каждого порта. Например, если ваша материнская плата имеет встроенный порт [.filename]#COM1# (он же [.filename]#sio0# — адрес ввода-вывода 0x3F8 и IRQ 4), а у вас есть расширительная плата с двумя UART, то обычно их нужно настроить как [.filename]#COM2# (он же [.filename]#sio1# — адрес ввода-вывода 0x2F8 и IRQ 3), а третий порт (он же [.filename]#sio2#) — с адресом 0x3E8 и IRQ 5. Очевидно, это расточительное использование ресурсов IRQ, так как в принципе возможно запустить оба порта расширительной платы с одним IRQ, используя конфигурацию `COM_MULTIPORT`, описанную в предыдущих разделах. Такие недорогие платы ввода-вывода обычно имеют перемычечную матрицу 4x3 для COM-портов, подобную следующей: [.programlisting] .... o o o * Port A | o * o * Port B | o * o o IRQ 2 3 4 5 .... Показано, что порт A подключен для IRQ 5, а порт B — для IRQ 3. Столбцы IRQ на вашей конкретной плате могут отличаться — другие платы могут предоставлять перемычки для IRQ 3, 4, 5 и 7. -Можно было бы сделать вывод, что подключение обоих портов к IRQ 3 с помощью самодельной перемычки, замыкающей все три точки соединения в колонке IRQ 3, решит проблему, но это не так. Невозможно дублировать IRQ 3, потому что выходные драйверы каждого UART соединены по схеме "монтажное И", и если один из UART управляет IRQ 3, выходной сигнал будет не таким, как ожидается. В зависимости от реализации платы расширения или материнской платы, линия IRQ 3 будет постоянно находиться в высоком уровне или всегда оставаться низкой. +Можно было бы сделать вывод, что подключение обоих портов к IRQ 3 с помощью самодельной перемычки, замыкающей все три точки соединения в колонке IRQ 3, решит проблему, но это не так. Невозможно дублировать IRQ 3, потому что выходные драйверы каждого UART соединены по схеме "монтажное И", и если один из UART управляет IRQ 3, выходной сигнал будет не таким как ожидается. В зависимости от реализации платы расширения или материнской платы, линия IRQ 3 будет постоянно находиться в высоком уровне или всегда оставаться низкой. Вам необходимо разделить драйверы прерываний для двух UART, чтобы линия прерывания платы поднималась только тогда (и только тогда), когда один из UART вызывает прерывание, и оставалась низкой в противном случае. Решение было предложено Йоргом Вуншем mailto:j@ida.interface-business.de[j@ida.interface-business.de]: припаять монтажную схему "монтажное ИЛИ", состоящую из двух диодов (предпочтительно германиевых или типа Шоттки) и резистора на 1 кОм. Вот схема, начиная с контактного поля 4x3 выше: [.programlisting] .... Diode +---------->|-------+ / | o * o o | 1 kOhm Port A +----|######|-------+ o * o o | | Port B `-------------------+ ==+== o * o o | Ground \ | +--------->|-------+ IRQ 2 3 4 5 Diode .... Катоды диодов соединены в общей точке вместе с подтягивающим резистором 1 кОм. Важно подключить резистор к земле, чтобы избежать плавания линии IRQ на шине. Теперь мы готовы настроить ядро. Продолжая этот пример, мы настроим: [.programlisting] .... # standard on-board COM1 port device sio0 at isa? port "IO_COM1" flags 0x10 # patched-up multi-I/O extension board options COM_MULTIPORT device sio1 at isa? port "IO_COM2" flags 0x205 device sio2 at isa? port "IO_COM3" flags 0x205 irq 3 .... Обратите внимание, что настройка `flags` для [.filename]#sio1# и [.filename]#sio2# действительно важна; подробности смотрите в man:sio[4]. (Обычно `2` в атрибуте "flags" относится к [.filename]#sio#`2`, который содержит IRQ, и вам наверняка потребуется нижний ниббл `5`.) При включённом режиме подробного вывода ядра это должно дать что-то похожее на следующее: [source, shell] .... sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff flags 0x205 on isa sio1: type 16550A (multiport) sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa sio2: type 16550A (multiport master) .... Хотя [.filename]#/sys/i386/isa/sio.c# выглядит несколько загадочно из-за использования массива "irq maps" выше, основная идея заключается в том, что вы наблюдаете `0x1` на первой, третьей и четвертой позициях. Это означает, что соответствующий IRQ был установлен при выводе и сброшен после, что полностью соответствует ожиданиям. Если ваше ядро не демонстрирует такое поведение, скорее всего, проблема в вашей разводке. [[cy]] == Настройка драйвера [.filename]#cy# _Предоставлено Алексом Нэшем. 6 июня 1996._ Многопортовые карты Cyclades основаны на драйвере [.filename]#cy#, а не на обычном драйвере [.filename]#sio#, используемом другими многопортовыми картами. Настройка сводится к простым действиям: [.procedure] ==== . Добавьте устройство [.filename]#cy# в конфигурацию ядра (обратите внимание, что параметры irq и iomem могут отличаться). + [.programlisting] .... device cy0 at isa? irq 10 iomem 0xd4000 iosiz 0x2000 .... . Перестройте и установите новый образ ядра. . Создайте файлы устройств, введя (следующий пример предполагает 8-портовую плату): + [source, shell] .... # cd /dev # for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done .... . Если необходимо, добавьте записи для коммутируемого доступа в [.filename]#/etc/ttys#, дублируя записи для последовательных устройств (`ttyd`) и используя `ttyc` вместо `ttyd`. Например: + [.programlisting] .... ttyc0 "/usr/libexec/getty std.38400" unknown on insecure ttyc1 "/usr/libexec/getty std.38400" unknown on insecure ttyc2 "/usr/libexec/getty std.38400" unknown on insecure ... ttyc7 "/usr/libexec/getty std.38400" unknown on insecure .... . Перезагрузитесь с новым ядром. ==== == Настройка драйвера [.filename]#si# _Предоставлено `{nsayer}`. 25 марта 1998._ Специальные мультипортные карты Specialix SI/XIO и SX используют драйвер [.filename]#si#. На одной машине может быть установлено до 4 хост-карт. Поддерживаются следующие хост-карты: * ISA SI/XIO host card (2 versions) * EISA SI/XIO host card * PCI SI/XIO host card * ISA SX host card * PCI SX host card Хотя хост-карты SX и SI/XIO выглядят заметно по-разному, их функциональность практически одинакова. Хост-карты не используют порты ввода-вывода, а вместо этого требуют 32К сегмента памяти. Заводская конфигурация для карт ISA размещает этот сегмент по адресу `0xd0000-0xd7fff`. Также им требуется IRQ. Карты PCI, разумеется, настраиваются автоматически. Вы можете подключить до 4 внешних модулей к каждой карте хоста. Внешние модули содержат либо 4, либо 8 последовательных портов. Они бывают следующих видов: * Модули SI на 4 или 8 портов. Поддерживается скорость до 57600 бит/с на каждом порту. * XIO 8-портовые модули. Поддерживается скорость до 115200 бит/с на каждом порту. Один из типов модулей XIO имеет 7 последовательных и 1 параллельный порт. * Модули SXDC с 8 портами. Поддерживается скорость до 921600 бит/с на каждом порту. Как и в случае с XIO, доступен модуль с одним параллельным портом. Для настройки карты хоста ISA добавьте следующую строку в файл конфигурации ядра, изменив числа по мере необходимости: [.programlisting] .... device si0 at isa? iomem 0xd0000 irq 11 .... Допустимые номера IRQ: 9, 10, 11, 12 и 15 для SX ISA host cards и 11, 12 и 15 для SI/XIO ISA host cards. Для настройки карты EISA или PCI используйте следующую строку: [.programlisting] .... device si0 .... После добавления записи конфигурации пересоберите и установите свое новое ядро. [NOTE] ==== Следующий шаг не обязателен, если вы используете man:devfs[5] в FreeBSD 5._X_. ==== После перезагрузки с новым ядром необходимо создать файлы устройств в [.filename]#/dev#. Скрипт [.filename]#MAKEDEV# выполнит эту задачу за вас. Подсчитайте общее количество портов и введите: [source, shell] .... # cd /dev # ./MAKEDEV ttyAnn cuaAnn .... (где _nn_ — количество портов) Если вы хотите, чтобы приглашения к входу отображались на этих портах, вам нужно добавить такие строки в [.filename]#/etc/ttys#: [.programlisting] .... ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure .... Измените тип терминала по необходимости. Для модемов подойдут `dialup` или `unknown`. diff --git a/documentation/content/ru/articles/serial-uart/_index.po b/documentation/content/ru/articles/serial-uart/_index.po index ab608b6c26..a0e7e0d534 100644 --- a/documentation/content/ru/articles/serial-uart/_index.po +++ b/documentation/content/ru/articles/serial-uart/_index.po @@ -1,3904 +1,3904 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov , 2025. +# Vladlen Popolitov , 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2025-11-12 04:45+0000\n" +"PO-Revision-Date: 2026-03-09 04:45+0000\n" "Last-Translator: Vladlen Popolitov \n" "Language-Team: Russian \n" "Language: ru\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && " "n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" "X-Generator: Weblate 4.17\n" #. type: YAML Front Matter: description #: documentation/content/en/articles/serial-uart/_index.adoc:1 #, no-wrap msgid "Detailed information about the use of serial ports and UART with FreeBSD" msgstr "Подробная информация об использовании последовательных портов и UART в FreeBSD" #. type: Title = #: documentation/content/en/articles/serial-uart/_index.adoc:1 #: documentation/content/en/articles/serial-uart/_index.adoc:11 #, no-wrap msgid "Serial and UART Tutorial" msgstr "Учебное руководство по последовательному интерфейсу и UART" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:44 msgid "Abstract" msgstr "Аннотация" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:46 msgid "This article talks about using serial hardware with FreeBSD." msgstr "" "Эта статья рассказывает об использовании последовательного оборудования с " "FreeBSD." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:48 msgid "'''" msgstr "'''" #. type: Title == #: documentation/content/en/articles/serial-uart/_index.adoc:52 #, no-wrap msgid "The UART: What it is and how it works" msgstr "UART: Что это и как работает" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:55 msgid "_Copyright (R) 1996 `{uhclem}`, All Rights Reserved. 13 January 1996._" msgstr "" "_Copyright (R) 1996 `{uhclem}`, All Rights Reserved. 13 января 1996 год_" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:59 msgid "" "The Universal Asynchronous Receiver/Transmitter (UART) controller is the key " "component of the serial communications subsystem of a computer. The UART " "takes bytes of data and transmits the individual bits in a sequential " "fashion. At the destination, a second UART re-assembles the bits into " "complete bytes." msgstr "" "Универсальный асинхронный приёмопередатчик (UART) — это ключевой компонент " "подсистемы последовательной передачи данных компьютера. UART принимает байты " "данных и передаёт отдельные биты последовательно. На стороне приёмника " "второй UART собирает биты обратно в полные байты." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:61 msgid "" "Serial transmission is commonly used with modems and for non-networked " "communication between computers, terminals and other devices." msgstr "" "Последовательная передача данных обычно используется с модемами и для не " "сетевого взаимодействия между компьютерами, терминалами и другими " "устройствами." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:65 msgid "" "There are two primary forms of serial transmission: Synchronous and " "Asynchronous. Depending on the modes that are supported by the hardware, " "the name of the communication sub-system will usually include a `A` if it " "supports Asynchronous communications, and a `S` if it supports Synchronous " "communications. Both forms are described below." msgstr "" "Существует две основные формы последовательной передачи данных: синхронная и " "асинхронная. В зависимости от режимов, поддерживаемых оборудованием, " "название подсистемы связи обычно включает букву `A`, если она поддерживает " "асинхронную передачу, и букву `S`, если поддерживается синхронная передача. " "Обе формы описаны ниже." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:67 msgid "Some common acronyms are:" msgstr "Некоторые распространённые сокращения:" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:70 msgid "UART Universal Asynchronous Receiver/Transmitter" msgstr "" "UART Universal Asynchronous Receiver/Transmitter — Универсальный асинхронный " "приёмопередатчик" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:73 msgid "USART Universal Synchronous-Asynchronous Receiver/Transmitter" msgstr "" "USART Universal Synchronous-Asynchronous Receiver/Transmitter — " "Универсальный синхронно-асинхронный приёмопередатчик" #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:74 #, no-wrap msgid "Synchronous Serial Transmission" msgstr "Синхронная последовательная передача" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:79 msgid "" "Synchronous serial transmission requires that the sender and receiver share " "a clock with one another, or that the sender provide a strobe or other " "timing signal so that the receiver knows when to \"read\" the next bit of " "the data. In most forms of serial Synchronous communication, if there is no " "data available at a given instant to transmit, a fill character must be sent " "instead so that data is always being transmitted. Synchronous communication " "is usually more efficient because only data bits are transmitted between " "sender and receiver, and synchronous communication can be more costly if " "extra wiring and circuits are required to share a clock signal between the " "sender and receiver." msgstr "" "Синхронная последовательная передача данных требует, чтобы отправитель и " "получатель имели общий тактовый сигнал, либо чтобы отправитель предоставлял " "строб-сигнал или другой сигнал синхронизации, чтобы получатель знал, когда " "\"считывать\" следующий бит данных. В большинстве форм синхронной " "последовательной связи, если в данный момент нет доступных данных для " "передачи, вместо них должен быть отправлен заполняющий символ, чтобы " "передача данных не прерывалась. Синхронная связь обычно более эффективна, " "так как между отправителем и получателем передаются только биты данных, " "однако она может быть более затратной, если требуются дополнительные провода " "и схемы для обмена тактовым сигналом между отправителем и получателем." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:83 msgid "" "A form of Synchronous transmission is used with printers and fixed disk " "devices in that the data is sent on one set of wires while a clock or strobe " "is sent on a different wire. Printers and fixed disk devices are not " "normally serial devices because most fixed disk interface standards send an " "entire word of data for each clock or strobe signal by using a separate wire " "for each bit of the word. In the PC industry, these are known as Parallel " "devices." msgstr "" "Форма синхронной передачи используется с принтерами и устройствами с " "жёсткими дисками, где данные передаются по одному набору проводов, а " "тактовый сигнал или строб — по другому проводу. Принтеры и устройства с " "жёсткими дисками обычно не являются последовательными устройствами, так как " "большинство стандартов интерфейсов жёстких дисков передают целое слово " "данных для каждого тактового сигнала или строба, используя отдельный провод " "для каждого бита слова. В индустрии ПК такие устройства известны как " "параллельные." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:86 msgid "" "The standard serial communications hardware in the PC does not support " "Synchronous operations. This mode is described here for comparison purposes " "only." msgstr "" "Стандартное оборудование для последовательной связи в ПК не поддерживает " "синхронные операции. Этот режим описан здесь только для сравнения." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:87 #, no-wrap msgid "Asynchronous Serial Transmission" msgstr "Асинхронная последовательная передача" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:91 msgid "" "Asynchronous transmission allows data to be transmitted without the sender " "having to send a clock signal to the receiver. Instead, the sender and " "receiver must agree on timing parameters in advance and special bits are " "added to each word which are used to synchronize the sending and receiving " "units." msgstr "" "Асинхронная передача позволяет передавать данные без необходимости отправки " "тактового сигнала от отправителя к получателю. Вместо этого отправитель и " "получатель заранее согласовывают параметры синхронизации, а к каждому слову " "добавляются специальные биты, которые используются для синхронизации " "передающего и принимающего устройств." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:96 msgid "" "When a word is given to the UART for Asynchronous transmissions, a bit " "called the \"Start Bit\" is added to the beginning of each word that is to " "be transmitted. The Start Bit is used to alert the receiver that a word of " "data is about to be sent, and to force the clock in the receiver into " "synchronization with the clock in the transmitter. These two clocks must be " "accurate enough to not have the frequency drift by more than 10% during the " "transmission of the remaining bits in the word. (This requirement was set " "in the days of mechanical teleprinters and is easily met by modern " "electronic equipment.)" msgstr "" "При передаче слова через UART в асинхронном режиме к началу каждого " "передаваемого слова добавляется бит, называемый \"стартовым битом\". " "Стартовый бит используется для оповещения приёмника о начале передачи слова " "данных, а также для синхронизации тактового сигнала приёмника с тактовым " "сигналом передатчика. Эти два тактовых сигнала должны быть достаточно " "точными, чтобы их расхождение по частоте не превышало 10% во время передачи " "оставшихся битов слова. (Данное требование было установлено во времена " "механических телетайпов и легко выполняется современным электронным " "оборудованием.)" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:100 msgid "" "After the Start Bit, the individual bits of the word of data are sent, with " "the Least Significant Bit (LSB) being sent first. Each bit in the " "transmission is transmitted for exactly the same amount of time as all of " "the other bits, and the receiver \"looks\" at the wire at approximately " "halfway through the period assigned to each bit to determine if the bit is a " "`1` or a `0`. For example, if it takes two seconds to send each bit, the " "receiver will examine the signal to determine if it is a `1` or a `0` after " "one second has passed, then it will wait two seconds and then examine the " "value of the next bit, and so on." msgstr "" "После стартового бита передаются отдельные биты слова данных, начиная с " "младшего значащего бита (LSB). Каждый бит передаётся в течение точно такого " "же времени, как и все остальные биты, и приемник \"проверяет\" состояние " "линии примерно на середине интервала, отведенного для каждого бита, чтобы " "определить, является ли бит `1` или `0`. Например, если передача каждого " "бита занимает две секунды, приемник проверит сигнал, чтобы определить, " "является ли он `1` или `0`, через одну секунду, затем подождет две секунды и " "проверит значение следующего бита, и так далее." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:103 msgid "" "The sender does not know when the receiver has \"looked\" at the value of " "the bit. The sender only knows when the clock says to begin transmitting " "the next bit of the word." msgstr "" "Отправитель не знает, когда получатель «посмотрел» значение бита. " "Отправитель знает только, когда по тактовому сигналу нужно начать передачу " "следующего бита слова." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:107 msgid "" "When the entire data word has been sent, the transmitter may add a Parity " "Bit that the transmitter generates. The Parity Bit may be used by the " "receiver to perform simple error checking. Then at least one Stop Bit is " "sent by the transmitter." msgstr "" "Когда все слово данных отправлено, передатчик может добавить бит чётности, " "который он генерирует. Бит чётности может быть использован приемником для " "выполнения простой проверки на ошибки. Затем передатчик отправляет как " "минимум один стоповый бит." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:111 msgid "" "When the receiver has received all of the bits in the data word, it may " "check for the Parity Bits (both sender and receiver must agree on whether a " "Parity Bit is to be used), and then the receiver looks for a Stop Bit. If " "the Stop Bit does not appear when it is supposed to, the UART considers the " "entire word to be garbled and will report a Framing Error to the host " "processor when the data word is read. The usual cause of a Framing Error is " "that the sender and receiver clocks were not running at the same speed, or " "that the signal was interrupted." msgstr "" "Когда приемник получил все биты в слове данных, он может проверить биты " "чётности (как отправитель, так и приемник должны договориться о том, будет " "ли использоваться бит чётности), а затем приемник ищет стоповый бит. Если " "стоповый бит не появляется, когда должен, UART считает все слово искаженным " "и сообщит об ошибке кадрирования главному процессору при чтении слова " "данных. Обычная причина ошибки кадрирования — несовпадение скорости тактовых " "сигналов отправителя и приемника или прерывание сигнала." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:114 msgid "" "Regardless of whether the data was received correctly or not, the UART " "automatically discards the Start, Parity and Stop bits. If the sender and " "receiver are configured identically, these bits are not passed to the host." msgstr "" "Независимо от того, были ли данные получены правильно или нет, UART " "автоматически отбрасывает бит чётности, стартовый и стоповый биты. Если " "отправитель и получатель настроены одинаково, эти биты не передаются хосту." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:116 msgid "" "If another word is ready for transmission, the Start Bit for the new word " "can be sent as soon as the Stop Bit for the previous word has been sent." msgstr "" "Если готово следующее слово для передачи, стартовый бит нового слова может " "быть отправлен сразу после того, как будет отправлен стоповый бит " "предыдущего слова." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:118 msgid "" "As asynchronous data is \"self synchronizing\", if there is no data to " "transmit, the transmission line can be idle." msgstr "" "Поскольку асинхронные данные являются \"самосинхронизирующимися\", если нет " "данных для передачи, линия передачи может быть неактивна." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:119 #, no-wrap msgid "Other UART Functions" msgstr "Другие функции UART" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:124 msgid "" "In addition to the basic job of converting data from parallel to serial for " "transmission and from serial to parallel on reception, a UART will usually " "provide additional circuits for signals that can be used to indicate the " "state of the transmission media, and to regulate the flow of data in the " "event that the remote device is not prepared to accept more data. For " "example, when the device connected to the UART is a modem, the modem may " "report the presence of a carrier on the phone line while the computer may be " "able to instruct the modem to reset itself or to not take calls by raising " "or lowering one more of these extra signals. The function of each of these " "additional signals is defined in the EIA RS232-C standard." msgstr "" "Помимо основной задачи преобразования данных из параллельного формата в " "последовательный для передачи и из последовательного в параллельный при " "приеме, UART обычно предоставляет дополнительные схемы для сигналов, которые " "могут использоваться для указания состояния среды передачи и регулирования " "потока данных в случае, если удаленное устройство не готово принимать больше " "данных. Например, когда устройство, подключенное к UART, является модемом, " "модем может сообщать о наличии несущей на телефонной линии, в то время как " "компьютер может дать команду модему сбросить себя или не принимать вызовы, " "поднимая или опуская один или несколько из этих дополнительных сигналов. " "Функция каждого из этих дополнительных сигналов определена в стандарте EIA " "RS232-C." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:125 #, no-wrap msgid "The RS232-C and V.24 Standards" msgstr "Стандарты RS232-C и V.24" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:129 msgid "" "In most computer systems, the UART is connected to circuitry that generates " "signals that comply with the EIA RS232-C specification. There is also a " "CCITT standard named V.24 that mirrors the specifications included in RS232-" "C." msgstr "" "В большинстве компьютерных систем UART подключен к схеме, которая генерирует " "сигналы, соответствующие спецификации EIA RS232-C. Также существует стандарт " "CCITT под названием V.24, который отражает спецификации, включенные в RS232-" "C." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:130 #, no-wrap msgid "RS232-C Bit Assignments (Marks and Spaces)" msgstr "Назначения битов RS232-C (метки и пробелы)" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:134 msgid "" "In RS232-C, a value of `1` is called a `Mark` and a value of `0` is called a " "`Space`. When a communication line is idle, the line is said to be \"Marking" "\", or transmitting continuous `1` values." msgstr "" "В стандарте RS232-C значение `1` называется `Маркер` (Mark), а значение `0` " "— `Пробел` (Space). Когда линия связи находится в состоянии покоя, говорят, " "что она \"маркирует\" (Marking), то есть передаёт непрерывные значения `1`." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:139 msgid "" "The Start bit always has a value of `0` (a Space). The Stop Bit always has " "a value of `1` (a Mark). This means that there will always be a Mark (1) to " "Space (0) transition on the line at the start of every word, even when " "multiple word are transmitted back to back. This guarantees that sender and " "receiver can resynchronize their clocks regardless of the content of the " "data bits that are being transmitted." msgstr "" "Стартовый бит всегда имеет значение `0` (пробел). Стоповый бит всегда имеет " "значение `1` (метка). Это означает, что на линии всегда будет переход от " "метки (1) к пробелу (0) в начале каждого слова, даже при передаче нескольких " "слов подряд. Это гарантирует, что отправитель и получатель могут " "синхронизировать свои тактовые сигналы независимо от содержимого " "передаваемых битов данных." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:141 msgid "" "The idle time between Stop and Start bits does not have to be an exact " "multiple (including zero) of the bit rate of the communication link, but " "most UARTs are designed this way for simplicity." msgstr "" "Время простоя между стоповым и стартовым битами не обязательно должно быть " "точным кратным (включая ноль) скорости передачи данных коммуникационного " "канала, однако большинство UART спроектированы таким образом для простоты." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:145 msgid "" "In RS232-C, the \"Marking\" signal (a `1`) is represented by a voltage " "between -2 VDC and -12 VDC, and a \"Spacing\" signal (a `0`) is represented " "by a voltage between 0 and +12 VDC. The transmitter is supposed to send +12 " "VDC or -12 VDC, and the receiver is supposed to allow for some voltage loss " "in long cables. Some transmitters in low power devices (like portable " "computers) sometimes use only +5 VDC and -5 VDC, but these values are still " "acceptable to a RS232-C receiver, provided that the cable lengths are short." msgstr "" "В стандарте RS232-C сигнал «Marking» (логическая `1`) представлен " "напряжением от -2 В до -12 В, а сигнал «Spacing» (логический `0`) — " "напряжением от 0 В до +12 В. Передатчик должен выдавать +12 В или -12 В, а " "приёмник должен учитывать возможные потери напряжения в длинных кабелях. " "Некоторые маломощные передатчики (например, в портативных компьютерах) " "иногда используют только +5 В и -5 В, но эти значения всё ещё допустимы для " "приёмника RS232-C при условии использования коротких кабелей." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:146 #, no-wrap msgid "RS232-C Break Signal" msgstr "Сигнал Break в RS232-C" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:150 msgid "" "RS232-C also specifies a signal called a `Break`, which is caused by sending " "continuous Spacing values (no Start or Stop bits). When there is no " "electricity present on the data circuit, the line is considered to be " "sending `Break`." msgstr "" "RS232-C также определяет сигнал под названием `Break`, который вызывается " "передачей непрерывных значений Spacing (без стартовых или стоповых битов). " "Когда на линии данных отсутствует напряжение, считается, что линия передаёт " "`Break`." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:153 msgid "" "The `Break` signal must be of a duration longer than the time it takes to " "send a complete byte plus Start, Stop and Parity bits. Most UARTs can " "distinguish between a Framing Error and a Break, but if the UART cannot do " "this, the Framing Error detection can be used to identify Breaks." msgstr "" "Сигнал `Break` должен иметь длительность больше, чем время, необходимое для " "передачи полного байта, включая стартовый, стоповый и биты чётности. " "Большинство UART способны различить ошибку кадрирования и сигнал Break, но " "если UART не поддерживает эту функцию, для определения Break можно " "использовать обнаружение ошибки кадрирования." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:156 msgid "" "In the days of teleprinters, when numerous printers around the country were " "wired in series (such as news services), any unit could cause a `Break` by " "temporarily opening the entire circuit so that no current flowed. This was " "used to allow a location with urgent news to interrupt some other location " "that was currently sending information." msgstr "" "Во времена телетайпов, когда множество принтеров по всей стране были " "соединены последовательно (например, в службах новостей), любое устройство " "могло вызвать `Break`, временно размыкая всю цепь, чтобы ток не протекал. " "Это использовалось для того, чтобы место с срочными новостями могло прервать " "устройство в другом месте, которое в данный момент передавало информацию." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:161 msgid "" "In modern systems there are two types of Break signals. If the Break is " "longer than 1.6 seconds, it is considered a \"Modem Break\", and some modems " "can be programmed to terminate the conversation and go on-hook or enter the " "modems' command mode when the modem detects this signal. If the Break is " "smaller than 1.6 seconds, it signifies a Data Break and it is up to the " "remote computer to respond to this signal. Sometimes this form of Break is " "used as an Attention or Interrupt signal and sometimes is accepted as a " "substitute for the ASCII CONTROL-C character." msgstr "" "В современных системах существует два типа сигналов Break. Если Break длится " "дольше 1,6 секунд, он считается \"Модемным Break\", и некоторые модемы можно " "запрограммировать на завершение соединения и переход в режим ожидания или " "вход в командный режим модема при обнаружении этого сигнала. Если Break " "короче 1,6 секунд, это означает \"Break данных\", и удалённый компьютер " "должен решить, как реагировать на этот сигнал. Иногда такая форма Break " "используется как сигнал \"Внимание\" или \"Прерывание\", а иногда " "принимается как замена символу ASCII CONTROL-C." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:163 msgid "" "Marks and Spaces are also equivalent to \"Holes\" and \"No Holes\" in paper " "tape systems." msgstr "" "Метки и пробелы также эквивалентны \"дыркам\" и \"отсутствию дырок\" в " "системах с бумажной лентой." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:168 msgid "" "Breaks cannot be generated from paper tape or from any other byte value, " "since bytes are always sent with Start and Stop bit. The UART is usually " "capable of generating the continuous Spacing signal in response to a special " "command from the host processor." msgstr "" "Разрывы не могут быть сгенерированы с перфоленты или из любого другого " "байтового значения, поскольку байты всегда отправляются со стартовым и " "стоповым битами. UART обычно способен генерировать непрерывный сигнал " "Spacing в ответ на специальную команду от главного управляющего устройства " "(процессора передачи)." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:170 #, no-wrap msgid "RS232-C DTE and DCE Devices" msgstr "RS232-C устройства DTE и DCE" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:176 msgid "" "The RS232-C specification defines two types of equipment: the Data Terminal " "Equipment (DTE) and the Data Carrier Equipment (DCE). Usually, the DTE " "device is the terminal (or computer), and the DCE is a modem. Across the " "phone line at the other end of a conversation, the receiving modem is also a " "DCE device and the computer that is connected to that modem is a DTE " "device. The DCE device receives signals on the pins that the DTE device " "transmits on, and vice versa." msgstr "" "Спецификация RS232-C определяет два типа оборудования: оконечное " "оборудование данных (DTE — Data Terminal Equipment) и оборудование передачи " "данных (DCE — Data Carrier Equipment). Обычно устройство DTE — это терминал " "(или компьютер), а DCE — модем. На другом конце телефонной линии в разговоре " "принимающий модем также является устройством DCE, а компьютер, подключённый " "к этому модему, — устройством DTE. Устройство DCE принимает сигналы на тех " "контактах, на которых устройство DTE передаёт, и наоборот." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:180 msgid "" "When two devices that are both DTE or both DCE must be connected together " "without a modem or a similar media translator between them, a NULL modem " "must be used. The NULL modem electrically re-arranges the cabling so that " "the transmitter output is connected to the receiver input on the other " "device, and vice versa. Similar translations are performed on all of the " "control signals so that each device will see what it thinks are DCE (or DTE) " "signals from the other device." msgstr "" "Когда два устройства, оба являющиеся DTE или DCE, должны быть соединены " "вместе без модема или аналогичного преобразователя среды между ними, " "необходимо использовать NULL модем. NULL модем электрически перестраивает " "кабель так, что выход передатчика подключается ко входу приемника на другом " "устройстве, и наоборот. Аналогичные преобразования выполняются для всех " "управляющих сигналов, чтобы каждое устройство видело то, что оно считает " "сигналами DCE (или DTE) от другого устройства." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:183 msgid "" "The number of signals generated by the DTE and DCE devices are not " "symmetrical. The DTE device generates fewer signals for the DCE device than " "the DTE device receives from the DCE." msgstr "" "Количество сигналов, генерируемых устройствами DTE и DCE, не симметрично. " "Устройство DTE генерирует меньше сигналов для устройства DCE, чем получает " "от него." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:184 #, no-wrap msgid "RS232-C Pin Assignments" msgstr "Назначение контактов RS232-C" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:187 msgid "" "The EIA RS232-C specification (and the ITU equivalent, V.24) calls for a " "twenty-five pin connector (usually a DB25) and defines the purpose of most " "of the pins in that connector." msgstr "" "Спецификация EIA RS232-C (и её эквивалент ITU, V.24) предусматривает " "использование двадцатипятиконтактного разъёма (обычно DB25) и определяет " "назначение большинства контактов в этом разъёме." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:190 msgid "" "In the IBM Personal Computer and similar systems, a subset of RS232-C " "signals are provided via nine pin connectors (DB9). The signals that are " "not included on the PC connector deal mainly with synchronous operation, and " "this transmission mode is not supported by the UART that IBM selected for " "use in the IBM PC." msgstr "" "В IBM Personal Computer и подобных системах подмножество сигналов RS232-C " "предоставляется через девятиконтактные разъемы (DB9). Сигналы, которые не " "включены в разъем ПК, в основном связаны с синхронной работой, и этот режим " "передачи не поддерживается UART, выбранным IBM для использования в IBM PC." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:193 msgid "" "Depending on the computer manufacturer, a DB25, a DB9, or both types of " "connector may be used for RS232-C communications. (The IBM PC also uses a " "DB25 connector for the parallel printer interface which causes some " "confusion.)" msgstr "" "В зависимости от производителя компьютера, для связи по RS232-C могут " "использоваться разъемы DB25, DB9 или оба типа. (В IBM PC также используется " "разъем DB25 для параллельного интерфейса принтера, что иногда вызывает " "путаницу.)" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:195 msgid "" "Below is a table of the RS232-C signal assignments in the DB25 and DB9 " "connectors." msgstr "" "Ниже представлена таблица назначений сигналов RS232-C в разъемах DB25 и DB9." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:200 #, no-wrap msgid "DB25 RS232-C Pin" msgstr "Контакт в DB25 RS232-C" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:201 #, no-wrap msgid "DB9 IBM PC Pin" msgstr "Контакт в DB9 IBM PC" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:202 #, no-wrap msgid "EIA Circuit Symbol" msgstr "Символ цепи по EIA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:203 #, no-wrap msgid "CCITT Circuit Symbol" msgstr "Символ цепи по CCITT" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:204 #, no-wrap msgid "Common Name" msgstr "Общее имя" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:205 #, no-wrap msgid "Signal Source" msgstr "Источник сигнала" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:207 #: documentation/content/en/articles/serial-uart/_index.adoc:675 #, no-wrap msgid "Description" msgstr "Описание" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:208 #: documentation/content/en/articles/serial-uart/_index.adoc:265 #, no-wrap msgid "1" msgstr "1" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:209 #: documentation/content/en/articles/serial-uart/_index.adoc:213 #: documentation/content/en/articles/serial-uart/_index.adoc:261 #: documentation/content/en/articles/serial-uart/_index.adoc:273 #: documentation/content/en/articles/serial-uart/_index.adoc:274 #: documentation/content/en/articles/serial-uart/_index.adoc:275 #: documentation/content/en/articles/serial-uart/_index.adoc:276 #: documentation/content/en/articles/serial-uart/_index.adoc:277 #: documentation/content/en/articles/serial-uart/_index.adoc:281 #: documentation/content/en/articles/serial-uart/_index.adoc:282 #: documentation/content/en/articles/serial-uart/_index.adoc:283 #: documentation/content/en/articles/serial-uart/_index.adoc:284 #: documentation/content/en/articles/serial-uart/_index.adoc:285 #: documentation/content/en/articles/serial-uart/_index.adoc:289 #: documentation/content/en/articles/serial-uart/_index.adoc:290 #: documentation/content/en/articles/serial-uart/_index.adoc:291 #: documentation/content/en/articles/serial-uart/_index.adoc:292 #: documentation/content/en/articles/serial-uart/_index.adoc:293 #: documentation/content/en/articles/serial-uart/_index.adoc:297 #: documentation/content/en/articles/serial-uart/_index.adoc:305 #: documentation/content/en/articles/serial-uart/_index.adoc:313 #: documentation/content/en/articles/serial-uart/_index.adoc:321 #: documentation/content/en/articles/serial-uart/_index.adoc:329 #: documentation/content/en/articles/serial-uart/_index.adoc:337 #: documentation/content/en/articles/serial-uart/_index.adoc:345 #: documentation/content/en/articles/serial-uart/_index.adoc:346 #: documentation/content/en/articles/serial-uart/_index.adoc:353 #: documentation/content/en/articles/serial-uart/_index.adoc:369 #: documentation/content/en/articles/serial-uart/_index.adoc:370 #: documentation/content/en/articles/serial-uart/_index.adoc:371 #: documentation/content/en/articles/serial-uart/_index.adoc:385 #: documentation/content/en/articles/serial-uart/_index.adoc:393 #: documentation/content/en/articles/serial-uart/_index.adoc:401 #: documentation/content/en/articles/serial-uart/_index.adoc:402 #: documentation/content/en/articles/serial-uart/_index.adoc:404 #, no-wrap msgid "-" msgstr "-" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:210 #, no-wrap msgid "AA" msgstr "AA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:211 #, no-wrap msgid "101" msgstr "101" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:212 #, no-wrap msgid "PG/FG" msgstr "PG/FG" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:215 #, no-wrap msgid "Frame/Protective Ground" msgstr "Защитное заземление (Frame/Protective Ground)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:216 #: documentation/content/en/articles/serial-uart/_index.adoc:225 #, no-wrap msgid "2" msgstr "2" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:217 #: documentation/content/en/articles/serial-uart/_index.adoc:224 #: documentation/content/en/articles/serial-uart/_index.adoc:610 #, no-wrap msgid "3" msgstr "3" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:218 #, no-wrap msgid "BA" msgstr "BA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:219 #, no-wrap msgid "103" msgstr "103" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:220 #, no-wrap msgid "TD" msgstr "TD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:221 #: documentation/content/en/articles/serial-uart/_index.adoc:237 #: documentation/content/en/articles/serial-uart/_index.adoc:317 #: documentation/content/en/articles/serial-uart/_index.adoc:349 #: documentation/content/en/articles/serial-uart/_index.adoc:357 #: documentation/content/en/articles/serial-uart/_index.adoc:365 #: documentation/content/en/articles/serial-uart/_index.adoc:373 #: documentation/content/en/articles/serial-uart/_index.adoc:389 #: documentation/content/en/articles/serial-uart/_index.adoc:397 #, no-wrap msgid "DTE" msgstr "DTE" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:223 #, no-wrap msgid "Transmit Data" msgstr "Передача Данных (Transmit Data)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:226 #, no-wrap msgid "BB" msgstr "BB" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:227 #, no-wrap msgid "104" msgstr "104" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:228 #, no-wrap msgid "RD" msgstr "RD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:229 #: documentation/content/en/articles/serial-uart/_index.adoc:245 #: documentation/content/en/articles/serial-uart/_index.adoc:253 #: documentation/content/en/articles/serial-uart/_index.adoc:269 #: documentation/content/en/articles/serial-uart/_index.adoc:301 #: documentation/content/en/articles/serial-uart/_index.adoc:309 #: documentation/content/en/articles/serial-uart/_index.adoc:325 #: documentation/content/en/articles/serial-uart/_index.adoc:333 #: documentation/content/en/articles/serial-uart/_index.adoc:341 #: documentation/content/en/articles/serial-uart/_index.adoc:381 #: documentation/content/en/articles/serial-uart/_index.adoc:405 #, no-wrap msgid "DCE" msgstr "DCE" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:231 #, no-wrap msgid "Receive Data" msgstr "Прием данных (Receive Data)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:232 #: documentation/content/en/articles/serial-uart/_index.adoc:361 #, no-wrap msgid "4" msgstr "4" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:233 #: documentation/content/en/articles/serial-uart/_index.adoc:256 #, no-wrap msgid "7" msgstr "7" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:234 #, no-wrap msgid "CA" msgstr "CA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:235 #, no-wrap msgid "105" msgstr "105" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:236 #, no-wrap msgid "RTS" msgstr "RTS" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:239 #, no-wrap msgid "Request to Send" msgstr "Запрос на передачу (Request to Send)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:240 #: documentation/content/en/articles/serial-uart/_index.adoc:257 #, no-wrap msgid "5" msgstr "5" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:241 #: documentation/content/en/articles/serial-uart/_index.adoc:264 #, no-wrap msgid "8" msgstr "8" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:242 #, no-wrap msgid "CB" msgstr "CB" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:243 #, no-wrap msgid "106" msgstr "106" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:244 #, no-wrap msgid "CTS" msgstr "CTS" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:247 #, no-wrap msgid "Clear to Send" msgstr "Готовность к приёму (Clear to Send)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:248 #: documentation/content/en/articles/serial-uart/_index.adoc:249 #, no-wrap msgid "6" msgstr "6" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:250 #, no-wrap msgid "CC" msgstr "CC" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:251 #, no-wrap msgid "107" msgstr "107" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:252 #, no-wrap msgid "DSR" msgstr "DSR" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:255 #, no-wrap msgid "Data Set Ready" msgstr "Готовность терминального оборудования (Data Set Ready)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:258 #, no-wrap msgid "AV" msgstr "AV" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:259 #, no-wrap msgid "102" msgstr "102" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:260 #, no-wrap msgid "SG/GND" msgstr "SG/GND" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:263 #, no-wrap msgid "Signal Ground" msgstr "Сигнальная земля (Signal Ground)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:266 #, no-wrap msgid "CF" msgstr "CF" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:267 #, no-wrap msgid "109" msgstr "109" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:268 #, no-wrap msgid "DCD/CD" msgstr "DCD/CD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:271 #, no-wrap msgid "Data Carrier Detect" msgstr "Обнаружение несущей (Data Carrier Detect)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:272 #: documentation/content/en/articles/serial-uart/_index.adoc:377 #, no-wrap msgid "9" msgstr "9" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:279 #: documentation/content/en/articles/serial-uart/_index.adoc:287 #: documentation/content/en/articles/serial-uart/_index.adoc:295 #, no-wrap msgid "Reserved for Test" msgstr "Зарезервировано для Теста" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:280 #, no-wrap msgid "10" msgstr "10" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:288 #, no-wrap msgid "11" msgstr "11" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:296 #, no-wrap msgid "12" msgstr "12" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:298 #, no-wrap msgid "CI" msgstr "CI" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:299 #, no-wrap msgid "122" msgstr "122" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:300 #, no-wrap msgid "SRLSD" msgstr "SRLSD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:303 #, no-wrap msgid "Sec. Recv. Line Signal Detector" msgstr "Детектор сигнала вторичной линии приёма" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:304 #, no-wrap msgid "13" msgstr "13" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:306 #, no-wrap msgid "SCB" msgstr "SCB" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:307 #, no-wrap msgid "121" msgstr "121" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:308 #, no-wrap msgid "SCTS" msgstr "SCTS" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:311 #, no-wrap msgid "Secondary Clear to Send" msgstr "Вторичный сигнал готовности к приёму" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:312 #, no-wrap msgid "14" msgstr "14" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:314 #, no-wrap msgid "SBA" msgstr "SBA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:315 #, no-wrap msgid "118" msgstr "118" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:316 #, no-wrap msgid "STD" msgstr "STD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:319 #, no-wrap msgid "Secondary Transmit Data" msgstr "Вторичная линия передачи данных" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:320 #, no-wrap msgid "15" msgstr "15" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:322 #, no-wrap msgid "DB" msgstr "DB" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:323 #, no-wrap msgid "114" msgstr "114" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:324 #: documentation/content/en/articles/serial-uart/_index.adoc:396 #, no-wrap msgid "TSET" msgstr "TSET" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:327 #: documentation/content/en/articles/serial-uart/_index.adoc:399 #, no-wrap msgid "Trans. Sig. Element Timing" msgstr "Тактирование элементов сигнала передатчика (Trans. Sig. Element Timing)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:328 #, no-wrap msgid "16" msgstr "16" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:330 #, no-wrap msgid "SBB" msgstr "SBB" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:331 #, no-wrap msgid "119" msgstr "119" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:332 #, no-wrap msgid "SRD" msgstr "SRD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:335 #, no-wrap msgid "Secondary Received Data" msgstr "Вторичная линия приема данных" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:336 #, no-wrap msgid "17" msgstr "17" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:338 #, no-wrap msgid "DD" msgstr "DD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:339 #, no-wrap msgid "115" msgstr "115" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:340 #, no-wrap msgid "RSET" msgstr "RSET" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:343 #, no-wrap msgid "Receiver Signal Element Timing" msgstr "Тактирование элементов сигнала приёмника (Receiver Signal Element Timing)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:344 #, no-wrap msgid "18" msgstr "18" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:347 #, no-wrap msgid "141" msgstr "141" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:348 #, no-wrap msgid "LOOP" msgstr "LOOP" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:351 #, no-wrap msgid "Local Loopback" msgstr "Локальная петля" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:352 #: documentation/content/en/articles/serial-uart/_index.adoc:614 #, no-wrap msgid "19" msgstr "19" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:354 #, no-wrap msgid "SCA" msgstr "SCA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:355 #, no-wrap msgid "120" msgstr "120" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:356 #, no-wrap msgid "SRS" msgstr "SRS" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:359 #, no-wrap msgid "Secondary Request to Send" msgstr "Вторичный запрос на передачу" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:360 #, no-wrap msgid "20" msgstr "20" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:362 #, no-wrap msgid "CD" msgstr "CD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:363 #, no-wrap msgid "108.2" msgstr "108.2" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:364 #, no-wrap msgid "DTR" msgstr "DTR" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:367 #, no-wrap msgid "Data Terminal Ready" msgstr "Готовность терминального оборудования (Data Terminal Ready)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:368 #, no-wrap msgid "21" msgstr "21" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:372 #, no-wrap msgid "RDL" msgstr "RDL" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:375 #, no-wrap msgid "Remote Digital Loopback" msgstr "Режим удалённой цифровой петли (Remote Digital Loopback)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:376 #, no-wrap msgid "22" msgstr "22" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:378 #, no-wrap msgid "CE" msgstr "CE" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:379 #, no-wrap msgid "125" msgstr "125" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:380 #, no-wrap msgid "RI" msgstr "RI" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:383 #, no-wrap msgid "Ring Indicator" msgstr "Индикатор передачи данных (Ring Indicator)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:384 #: documentation/content/en/articles/serial-uart/_index.adoc:618 #, no-wrap msgid "23" msgstr "23" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:386 #, no-wrap msgid "CH" msgstr "CH" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:387 #, no-wrap msgid "111" msgstr "111" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:388 #, no-wrap msgid "DSRS" msgstr "DSRS" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:391 #, no-wrap msgid "Data Signal Rate Selector" msgstr "Селектор скорости передачи данных" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:392 #, no-wrap msgid "24" msgstr "24" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:394 #, no-wrap msgid "DA" msgstr "DA" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:395 #, no-wrap msgid "113" msgstr "113" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:400 #, no-wrap msgid "25" msgstr "25" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:403 #, no-wrap msgid "142" msgstr "142" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:406 #, no-wrap msgid "Test Mode" msgstr "Режим тестирования" #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:408 #, no-wrap msgid "Bits, Baud and Symbols" -msgstr "Биты, Боды и Символы" +msgstr "Биты, боды и символы" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:412 msgid "" "Baud is a measurement of transmission speed in asynchronous communication. " "Due to advances in modem communication technology, this term is frequently " "misused when describing the data rates in newer devices." msgstr "" "Скорость передачи данных (Baud) — это единица измерения скорости передачи в " "асинхронной связи. Из-за развития технологий модемной связи этот термин " "часто ошибочно используют для описания скорости передачи данных в " "современных устройствах." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:417 msgid "" "Traditionally, a Baud Rate represents the number of bits that are actually " "being sent over the media, not the amount of data that is actually moved " "from one DTE device to the other. The Baud count includes the overhead bits " "Start, Stop and Parity that are generated by the sending UART and removed by " "the receiving UART. This means that seven-bit words of data actually take " "10 bits to be completely transmitted. Therefore, a modem capable of moving " "300 bits per second from one place to another can normally only move 30 7-" "bit words if Parity is used and one Start and Stop bit are present." msgstr "" "Традиционно, скорость передачи (Baud Rate) представляет количество битов, " -"фактически передаваемых по среде, а не объем данных, которые действительно " +"фактически передаваемых по среде, а не объём данных, которые действительно " "перемещаются от одного устройства DTE к другому. Подсчет Baud включает " "служебные биты — Start, Stop и Parity, которые генерируются передающим UART " "и удаляются принимающим UART. Это означает, что 7-битные слова данных на " "самом деле занимают 10 бит для полной передачи. Следовательно, модем, " "способный передавать 300 бит в секунду, обычно может передавать только 30 7-" "битных слов, если используется Parity и присутствуют один бит Start и один " "бит Stop." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:419 msgid "" "If 8-bit data words are used and Parity bits are also used, the data rate " "falls to 27.27 words per second, because it now takes 11 bits to send the " "eight-bit words, and the modem still only sends 300 bits per second." msgstr "" "Если используются 8-битные слова данных и биты чётности, скорость передачи " "данных снижается до 27,27 слов в секунду, так как теперь для передачи " "восьмибитных слов требуется 11 бит, а модем по-прежнему передаёт только 300 " "бит в секунду." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:425 msgid "" "The formula for converting bytes per second into a baud rate and vice versa " "was simple until error-correcting modems came along. These modems receive " "the serial stream of bits from the UART in the host computer (even when " "internal modems are used the data is still frequently serialized) and " "converts the bits back into bytes. These bytes are then combined into " "packets and sent over the phone line using a Synchronous transmission " "method. This means that the Stop, Start, and Parity bits added by the UART " "in the DTE (the computer) were removed by the modem before transmission by " "the sending modem. When these bytes are received by the remote modem, the " "remote modem adds Start, Stop and Parity bits to the words, converts them to " "a serial format and then sends them to the receiving UART in the remote " "computer, who then strips the Start, Stop and Parity bits." msgstr "" "Формула преобразования байтов в секунду в бодовую скорость и наоборот была " "простой до появления модемов с коррекцией ошибок. Эти модемы принимают " "последовательный поток битов от UART в компьютере (даже внутренние модемы " "часто работают с последовательными данными) и преобразуют биты обратно в " "байты. Затем эти байты объединяются в пакеты и передаются по телефонной " "линии с использованием синхронного метода передачи. Это означает, что " "стоповые, стартовые и биты чётности, добавленные UART в DTE (компьютере), " "удаляются модемом перед передачей отправляющим модемом. Когда эти байты " "принимаются удалённым модемом, он добавляет стартовые, стоповые и биты " "чётности к словам, преобразует их в последовательный формат и отправляет на " "принимающий UART в удалённом компьютере, который затем удаляет стартовые, " "стоповые и биты чётности." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:428 msgid "" "The reason all these extra conversions are done is so that the two modems " "can perform error correction, which means that the receiving modem is able " "to ask the sending modem to resend a block of data that was not received " "with the correct checksum. This checking is handled by the modems, and the " "DTE devices are usually unaware that the process is occurring." msgstr "" "Причина, по которой выполняются все эти дополнительные преобразования, " "заключается в том, чтобы два модема могли осуществлять коррекцию ошибок. Это " "означает, что принимающий модем может запросить у передающего модема " "повторную отправку блока данных, который был получен с некорректной " "контрольной суммой. Эта проверка обрабатывается модемами, и устройства DTE " "обычно не осознают, что этот процесс происходит." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:431 msgid "" "By striping the Start, Stop and Parity bits, the additional bits of data " "that the two modems must share between themselves to perform error-" "correction are mostly concealed from the effective transmission rate seen by " "the sending and receiving DTE equipment. For example, if a modem sends ten " "7-bit words to another modem without including the Start, Stop and Parity " "bits, the sending modem will be able to add 30 bits of its own information " "that the receiving modem can use to do error-correction without impacting " "the transmission speed of the real data." msgstr "" "Удаляя стартовые, стоповые и биты чётности, дополнительные биты данных, " "которые два модема должны обмениваться между собой для выполнения коррекции " "ошибок, в основном скрываются от эффективной скорости передачи, наблюдаемой " "отправляющим и принимающим оборудованием DTE. Например, если модем " "отправляет десять 7-битных слов другому модему без включения стартовых, " "стоповых и битов чётности, отправляющий модем сможет добавить 30 бит своей " "собственной информации, которую принимающий модем может использовать для " "коррекции ошибок, не влияя на скорость передачи реальных данных." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:435 msgid "" "The use of the term Baud is further confused by modems that perform " "compression. A single 8-bit word passed over the telephone line might " "represent a dozen words that were transmitted to the sending modem. The " "receiving modem will expand the data back to its original content and pass " "that data to the receiving DTE." msgstr "" "Использование термина \"Бод\" дополнительно осложняется модемами, " "выполняющими сжатие. Одно 8-битное слово, переданное по телефонной линии, " "может представлять собой дюжину слов, переданных на отправляющий модем. " "Принимающий модем развернёт данные обратно в их исходное содержимое и " "передаст эти данные принимающему DTE." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:438 msgid "" "Modern modems also include buffers that allow the rate that bits move across " "the phone line (DCE to DCE) to be a different speed than the speed that the " "bits move between the DTE and DCE on both ends of the conversation. " "Normally the speed between the DTE and DCE is higher than the DCE to DCE " "speed because of the use of compression by the modems." msgstr "" "Современные модемы также включают буферы, которые позволяют скорости " "передачи битов по телефонной линии (DCE к DCE) отличаться от скорости " "передачи битов между DTE и DCE на обоих концах соединения. Обычно скорость " "между DTE и DCE выше, чем скорость между DCE и DCE, из-за использования " "сжатия модемами." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:441 msgid "" "As the number of bits needed to describe a byte varied during the trip " "between the two machines plus the differing bits-per-seconds speeds that are " "used present on the DTE-DCE and DCE-DCE links, the usage of the term Baud to " "describe the overall communication speed causes problems and can " "misrepresent the true transmission speed. So Bits Per Second (bps) is the " "correct term to use to describe the transmission rate seen at the DCE to DCE " "interface and Baud or Bits Per Second are acceptable terms to use when a " "connection is made between two systems with a wired connection, or if a " "modem is in use that is not performing error-correction or compression." msgstr "" "Поскольку количество битов, необходимых для описания байта, менялось во " "время передачи между двумя машинами, а также из-за различающихся скоростей " "передачи в битах в секунду на линиях DTE-DCE и DCE-DCE, использование " "термина «Бод» для описания общей скорости связи вызывает проблемы и может " "искажать реальную скорость передачи. Таким образом, термин «Биты в " "секунду» (bps) является корректным для описания скорости передачи на " "интерфейсе DCE-DCE, а термины «Бод» или «Биты в секунду» допустимы, когда " "соединение устанавливается между двумя системами с проводным подключением " "или используется модем, не выполняющий коррекцию ошибок или сжатие." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:445 msgid "" "Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in reality " "still operate at or below 2400 baud, or more accurately, 2400 Symbols per " "second. High speed modem are able to encode more bits of data into each " "Symbol using a technique called Constellation Stuffing, which is why the " "effective bits per second rate of the modem is higher, but the modem " "continues to operate within the limited audio bandwidth that the telephone " "system provides. Modems operating at 28,800 and higher speeds have variable " "Symbol rates, but the technique is the same." msgstr "" "Современные высокоскоростные модемы (2400, 9600, 14,400 и 19,200 бит/с) на " "самом деле всё ещё работают на скорости 2400 бод или ниже, или, точнее, 2400 " "символов в секунду. Высокоскоростные модемы способны кодировать больше бит " "данных в каждый символ с использованием техники, называемой \"Заполнение " "созвездия (Constellation Stuffing)\", поэтому эффективная скорость передачи " "данных в битах в секунду у модема выше, но модем продолжает работать в " "ограниченной полосе пропускания звуковых частот, предоставляемой телефонной " "системой. Модемы, работающие на скоростях 28,800 и выше, имеют переменную " "скорость передачи символов, но техника остаётся той же." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:446 #, no-wrap msgid "The IBM Personal Computer UART" msgstr "UART в IBM PC" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:450 msgid "" "Starting with the original IBM Personal Computer, IBM selected the National " "Semiconductor INS8250 UART for use in the IBM PC Parallel/Serial Adapter. " "Subsequent generations of compatible computers from IBM and other vendors " "continued to use the INS8250 or improved versions of the National " "Semiconductor UART family." msgstr "" "Начиная с оригинального IBM Personal Computer, IBM выбрала UART INS8250 от " "National Semiconductor для использования в адаптере Parallel/Serial IBM PC. " "Последующие поколения совместимых компьютеров от IBM и других производителей " "продолжали использовать INS8250 или улучшенные версии UART из семейства " "National Semiconductor." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:451 #, no-wrap msgid "National Semiconductor UART Family Tree" msgstr "Генеалогическое дерево National Semiconductor UART" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:454 msgid "" "There have been several versions and subsequent generations of the INS8250 " "UART. Each major version is described below." msgstr "" "Существует несколько версий и последующих поколений UART INS8250. Основные " "версии описаны ниже." #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:467 #, no-wrap msgid "" "INS8250 -> INS8250B\n" " \\\n" " \\\n" " \\-> INS8250A -> INS82C50A\n" " \\\n" " \\\n" " \\-> NS16450 -> NS16C450\n" " \\\n" " \\\n" " \\-> NS16550 -> NS16550A -> PC16550D\n" msgstr "" "INS8250 -> INS8250B\n" " \\\n" " \\\n" " \\-> INS8250A -> INS82C50A\n" " \\\n" " \\\n" " \\-> NS16450 -> NS16C450\n" " \\\n" " \\\n" " \\-> NS16550 -> NS16550A -> PC16550D\n" #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:469 #, no-wrap msgid "INS8250" msgstr "INS8250" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:472 msgid "" "This part was used in the original IBM PC and IBM PC/XT. The original name " "for this part was the INS8250 ACE (Asynchronous Communications Element) and " "it is made from NMOS technology." msgstr "" "Эта часть использовалась в оригинальном IBM PC и IBM PC/XT. Первоначальное " "название этой части — INS8250 ACE (Asynchronous Communications Element), и " "она изготовлена по NMOS-технологии." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:476 msgid "" "The 8250 uses eight I/O ports and has a one-byte send and a one-byte receive " "buffer. This original UART has several race conditions and other flaws. " "The original IBM BIOS includes code to work around these flaws, but this " "made the BIOS dependent on the flaws being present, so subsequent parts like " "the 8250A, 16450 or 16550 could not be used in the original IBM PC or IBM PC/" "XT." msgstr "" "8250 использует восемь портов ввода-вывода и имеет однобайтовый буфер " "передачи и однобайтовый буфер приема. Этот оригинальный UART имеет несколько " "состояний гонки и другие недостатки. Оригинальный BIOS IBM включает код для " "обхода этих недостатков, но это сделало BIOS зависимым от их наличия, " "поэтому последующие модели, такие как 8250A, 16450 или 16550, не могли быть " "использованы в оригинальном IBM PC или IBM PC/XT." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:476 #, no-wrap msgid "INS8250-B" msgstr "INS8250-B" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:479 msgid "" "This is the slower speed of the INS8250 made from NMOS technology. It " "contains the same problems as the original INS8250." msgstr "" "Это более медленная скорость INS8250, созданная по NMOS-технологии. Она " "имеет те же проблемы, что и оригинальный INS8250." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:480 #, no-wrap msgid "INS8250A" msgstr "INS8250A" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:484 msgid "" "An improved version of the INS8250 using XMOS technology with various " "functional flaws corrected. The INS8250A was used initially in PC clone " "computers by vendors who used \"clean\" BIOS designs. Due to the " "corrections in the chip, this part could not be used with a BIOS compatible " "with the INS8250 or INS8250B." msgstr "" "Улучшенная версия INS8250 с использованием технологии XMOS, в которой " "исправлены различные функциональные недостатки. INS8250A изначально " "использовалась в клонах ПК от производителей, применявших \"чистые\" проекты " "BIOS. Из-за исправлений в микросхеме этот чип не мог использоваться с BIOS, " "совместимой с INS8250 или INS8250B." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:485 #, no-wrap msgid "INS82C50A" msgstr "INS82C50A" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:487 msgid "" "This is a CMOS version (low power consumption) of the INS8250A and has " "similar functional characteristics." msgstr "" "Это CMOS-версия (с низким энергопотреблением) INS8250A и имеет схожие " "функциональные характеристики." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:488 #, no-wrap msgid "NS16450" msgstr "NS16450" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:491 msgid "" "Same as NS8250A with improvements so it can be used with faster CPU bus " "designs. IBM used this part in the IBM AT and updated the IBM BIOS to no " "longer rely on the bugs in the INS8250." msgstr "" "Так же, как NS8250A, но с улучшениями для работы с более быстрыми шинами " "CPU. IBM использовала этот компонент в IBM AT и обновила IBM BIOS, чтобы она " "больше не зависела от ошибок в INS8250." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:492 #, no-wrap msgid "NS16C450" msgstr "NS16C450" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:494 msgid "This is a CMOS version (low power consumption) of the NS16450." msgstr "Это версия NS16450 с технологией CMOS (низкое энергопотребление)." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:495 #, no-wrap msgid "NS16550" msgstr "NS16550" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:497 msgid "" "Same as NS16450 with a 16-byte send and receive buffer but the buffer design " "was flawed and could not be reliably be used." msgstr "" "То же, что и NS16450, с 16-байтовым буфером передачи и приема, но " "конструкция буфера была неудачной и не могла быть надёжно использована." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:498 #, no-wrap msgid "NS16550A" msgstr "NS16550A" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:501 msgid "" "Same as NS16550 with the buffer flaws corrected. The 16550A and its " "successors have become the most popular UART design in the PC industry, " "mainly due to its ability to reliably handle higher data rates on operating " "systems with sluggish interrupt response times." msgstr "" "То же, что и NS16550, но с исправленными недостатками буфера. 16550A и его " "преемники стали наиболее популярными UART-устройствами в индустрии ПК, в " "основном благодаря их способности надёжно работать на высоких скоростях " "передачи данных в операционных системах с медленным временем отклика " "прерываний." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:502 #, no-wrap msgid "NS16C552" msgstr "NS16C552" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:504 msgid "" "This component consists of two NS16C550A CMOS UARTs in a single package." msgstr "Этот компонент состоит из двух CMOS UART NS16C550A в одном корпусе." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:505 #, no-wrap msgid "PC16550D" msgstr "PC16550D" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:508 msgid "" "Same as NS16550A with subtle flaws corrected. This is revision D of the " "16550 family and is the latest design available from National Semiconductor." msgstr "" "Так же, как NS16550A, с исправленными незначительными недостатками. Это " "ревизия D семейства 16550 и последняя доступная версия от National " "Semiconductor." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:509 #, no-wrap msgid "The NS16550AF and the PC16550D are the same thing" msgstr "NS16550AF и PC16550D — это одно и то же" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:515 msgid "" "National reorganized their part numbering system a few years ago, and the " "NS16550AFN no longer exists by that name. (If you have a NS16550AFN, look " "at the date code on the part, which is a four digit number that usually " "starts with a nine. The first two digits of the number are the year, and " "the last two digits are the week in that year when the part was packaged. " "If you have a NS16550AFN, it is probably a few years old.)" msgstr "" "Компания National реорганизовала свою систему нумерации деталей несколько " "лет назад, и чип NS16550AFN больше не существует под этим названием. (Если у " "вас есть NS16550AFN, посмотрите на дату изготовления на корпусе — это " -"четырехзначное число, обычно начинающееся с девятки. Первые две цифры " +"четырёхзначное число, обычно начинающееся с девятки. Первые две цифры " "обозначают год, а последние две — неделю года, когда чип был упакован. Если " "у вас есть NS16550AFN, скорее всего, он уже довольно старый.)" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:518 msgid "" "The new numbers are like PC16550DV, with minor differences in the suffix " "letters depending on the package material and its shape. (A description of " "the numbering system can be found below.)" msgstr "" "Новые номера выглядят как PC16550DV, с незначительными отличиями в " "суффиксных буквах в зависимости от материала корпуса и его формы. (Описание " "системы нумерации можно найти ниже.)" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:520 msgid "" "It is important to understand that in some stores, you may pay $15(US) for a " "NS16550AFN made in 1990 and in the next bin are the new PC16550DN parts with " "minor fixes that National has made since the AFN part was in production, the " "PC16550DN was probably made in the past six months and it costs half (as low " "as $5(US) in volume) as much as the NS16550AFN because they are readily " "available." msgstr "" "Важно понимать, что в некоторых магазинах можно заплатить $15 (США) за " "микросхему NS16550AFN, выпущенную в 1990 году, а в соседнем ящике могут " "лежать новые PC16550DN с небольшими исправлениями, которые National внесла с " "момента выпуска AFN. PC16550DN, вероятно, произведены в последние полгода и " "стоят вдвое дешевле (от $5 (США) при оптовой покупке), чем NS16550AFN, " "поскольку они легко доступны." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:522 msgid "" "As the supply of NS16550AFN chips continues to shrink, the price will " "probably continue to increase until more people discover and accept that the " "PC16550DN really has the same function as the old part number." msgstr "" "Поскольку поставки чипов NS16550AFN продолжают сокращаться, цена, вероятно, " "будет расти до тех пор, пока больше людей не узнают и не примут тот факт, " "что PC16550DN действительно выполняет ту же функцию, что и старый номер " "детали." #. type: Title ==== #: documentation/content/en/articles/serial-uart/_index.adoc:523 #, no-wrap msgid "National Semiconductor Part Numbering System" msgstr "Система нумерации компонентов National Semiconductor" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:526 msgid "" "The older NS``__nnnnnrqp__`` part numbers are now of the format " "PC``__nnnnnrgp__``." msgstr "" "Старые номера деталей NS``__nnnnnrqp__`` теперь имеют формат " "PC``__nnnnnrgp__``." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:528 msgid "" "The `_r_` is the revision field. The current revision of the 16550 from " "National Semiconductor is `D`." msgstr "" "`_r_` — это поле ревизии. Текущая ревизия 16550 от National Semiconductor — " "`D`." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:530 msgid "The `_p_` is the package-type field. The types are:" msgstr "`_p_` — это поле типа пакета. Типы:" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:536 #, no-wrap msgid "\"F\"" msgstr "\"F\"" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:537 #, no-wrap msgid "QFP" msgstr "QFP" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:539 #, no-wrap msgid "(quad flat pack) L lead type" msgstr "(quad flat pack - квадратный плоский корпус) с L-образными выводами" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:540 #, no-wrap msgid "\"N\"" msgstr "\"N\"" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:541 #, no-wrap msgid "DIP" msgstr "DIP" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:543 #, no-wrap msgid "(dual inline package) through hole straight lead type" msgstr "(dual inline package — корпус с двусторонним расположением выводов) для сквозного монтажа с прямыми выводами" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:544 #, no-wrap msgid "\"V\"" msgstr "\"V\"" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:545 #, no-wrap msgid "LPCC" msgstr "LPCC" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:546 #, no-wrap msgid "(lead plastic chip carrier) J lead type" msgstr "(lead plastic chip carrier — пластиковый корпус) с J-образными выводами" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:551 msgid "" "The _g_ is the product grade field. If an `I` precedes the package-type " "letter, it indicates an \"industrial\" grade part, which has higher specs " "than a standard part but not as high as Military Specification (Milspec) " "component. This is an optional field." msgstr "" "Поле _g_ обозначает класс изделия. Если перед буквой типа пакета стоит `I`, " "это указывает на «промышленный» класс детали, который имеет более высокие " "характеристики, чем стандартная деталь, но не такие высокие, как компонент " "военного назначения (Milspec). Это необязательное поле." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:553 msgid "" "So what we used to call a NS16550AFN (DIP Package) is now called a PC16550DN " "or PC16550DIN." msgstr "" "То, что мы раньше называли NS16550AFN (DIP-корпус), теперь называется " "PC16550DN или PC16550DIN." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:554 #, no-wrap msgid "Other Vendors and Similar UARTs" msgstr "Другие производители и аналогичные UART" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:559 msgid "" "Over the years, the 8250, 8250A, 16450 and 16550 have been licensed or " "copied by other chip vendors. In the case of the 8250, 8250A and 16450, the " "exact circuit (the \"megacell\") was licensed to many vendors, including " "Western Digital and Intel. Other vendors reverse-engineered the part or " "produced emulations that had similar behavior." msgstr "" "На протяжении многих лет чипы 8250, 8250A, 16450 и 16550 лицензировались или " "копировались другими производителями. В случае с 8250, 8250A и 16450 точная " "схема (\"мегаячейка\") была лицензирована многими производителями, включая " "Western Digital и Intel. Другие производители проводили обратную разработку " "чипа или создавали эмуляции с аналогичным поведением." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:563 msgid "" "In internal modems, the modem designer will frequently emulate the " "8250A/16450 with the modem microprocessor, and the emulated UART will " "frequently have a hidden buffer consisting of several hundred bytes. Due to " "the size of the buffer, these emulations can be as reliable as a 16550A in " "their ability to handle high speed data. However, most operating systems " "will still report that the UART is only a 8250A or 16450, and may not make " "effective use of the extra buffering present in the emulated UART unless " "special drivers are used." msgstr "" "Во внутренних модемах разработчик модема часто эмулирует 8250A/16450 с " "помощью микропроцессора модема, и эмулированный UART часто имеет скрытый " "буфер размером в несколько сотен байт. Благодаря размеру буфера, эти " "эмуляции могут быть такими же надёжными, как 16550A, в способности " "обрабатывать высокоскоростные данные. Однако большинство операционных систем " "по-прежнему сообщают, что UART является только 8250A или 16450, и могут не " "эффективно использовать дополнительную буферизацию, присутствующую в " "эмулированном UART, если не используются специальные драйверы." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:565 msgid "" "Some modem makers are driven by market forces to abandon a design that has " "hundreds of bytes of buffer and instead use a 16550A UART so that the " "product will compare favorably in market comparisons even though the " "effective performance may be lowered by this action." msgstr "" "Некоторые производители модемов под давлением рыночных сил отказываются от " "конструкции с буфером в сотни байт и вместо этого используют UART 16550A, " "чтобы их продукция выглядела выигрышно в рыночных сравнениях, даже если это " "может снизить фактическую производительность." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:568 msgid "" "A common misconception is that all parts with \"16550A\" written on them are " "identical in performance. There are differences, and in some cases, " "outright flaws in most of these 16550A clones." msgstr "" "Распространённое заблуждение заключается в том, что все микросхемы с " "маркировкой \"16550A\" одинаковы по производительности. Однако между ними " "существуют различия, а в некоторых клонах 16550A даже встречаются серьёзные " "недостатки." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:572 msgid "" "When the NS16550 was developed, the National Semiconductor obtained several " "patents on the design and they also limited licensing, making it harder for " "other vendors to provide a chip with similar features. As a result of the " "patents, reverse-engineered designs and emulations had to avoid infringing " "the claims covered by the patents. Subsequently, these copies almost never " "perform exactly the same as the NS16550A or PC16550D, which are the parts " "most computer and modem makers want to buy but are sometimes unwilling to " "pay the price required to get the genuine part." msgstr "" "Когда компания National Semiconductor разработала NS16550, она получила " "несколько патентов на эту конструкцию и также ограничила лицензирование, что " "затруднило для других производителей выпуск чипов с аналогичными " "характеристиками. В результате патентов обратно спроектированные конструкции " "и эмуляции должны были избегать нарушения пунктов, охватываемых патентами. " "Впоследствии эти копии почти никогда не работают точно так же, как NS16550A " "или PC16550D, которые являются компонентами, наиболее востребованными " "производителями компьютеров и модемов, но иногда они не готовы платить цену, " "необходимую для получения оригинальных деталей." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:577 msgid "" "Some of the differences in the clone 16550A parts are unimportant, while " "others can prevent the device from being used at all with a given operating " "system or driver. These differences may show up when using other drivers, " "or when particular combinations of events occur that were not well tested or " "considered in the Windows(R) driver. This is because most modem vendors and " "16550-clone makers use the Microsoft drivers from Windows(R) for Workgroups " "3.11 and the Microsoft(R) MS-DOS(R) utility as the primary tests for " "compatibility with the NS16550A. This over-simplistic criteria means that " "if a different operating system is used, problems could appear due to subtle " "differences between the clones and genuine components." msgstr "" "Некоторые различия в клонах микросхем 16550A несущественны, в то время как " "другие могут полностью препятствовать использованию устройства с " -"определенной операционной системой или драйвером. Эти различия могут " +"определённой операционной системой или драйвером. Эти различия могут " "проявиться при использовании других драйверов или при возникновении " -"определенных комбинаций событий, которые не были хорошо протестированы или " +"определённых комбинаций событий, которые не были хорошо протестированы или " "учтены в драйвере Windows(R). Это происходит потому, что большинство " "производителей модемов и клонов 16550 используют драйверы Microsoft из " "Windows(R) for Workgroups 3.11 и утилиту Microsoft(R) MS-DOS(R) в качестве " "основных тестов на совместимость с NS16550A. Этот чрезмерно упрощенный " "критерий означает, что при использовании другой операционной системы могут " "возникнуть проблемы из-за тонких различий между клонами и оригинальными " "компонентами." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:580 msgid "" "National Semiconductor has made available a program named COMTEST that " "performs compatibility tests independent of any OS drivers. It should be " "remembered that the purpose of this type of program is to demonstrate the " "flaws in the products of the competition, so the program will report major " "as well as extremely subtle differences in behavior in the part being tested." msgstr "" "National Semiconductor предоставила программу под названием COMTEST, которая " "выполняет тесты совместимости независимо от каких-либо драйверов ОС. Следует " "помнить, что цель такого типа программ — демонстрация недостатков в " "продуктах конкурентов, поэтому программа будет сообщать как о значительных, " "так и о крайне незначительных различиях в поведении тестируемого компонента." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:583 msgid "" "In a series of tests performed by the author of this document in 1994, " "components made by National Semiconductor, TI, StarTech, and CMD as well as " "megacells and emulations embedded in internal modems were tested with " "COMTEST. A difference count for some of these components is listed below. " "Since these tests were performed in 1994, they may not reflect the current " "performance of the given product from a vendor." msgstr "" "В серии тестов, проведенных автором этого документа в 1994 году, компоненты " "производства National Semiconductor, TI, StarTech и CMD, а также мегаячейки " "и эмуляции, встроенные во внутренние модемы, были протестированы с помощью " "COMTEST. Ниже приведен счетчик различий для некоторых из этих компонентов. " "Поскольку эти тесты проводились в 1994 году, они могут не отражать текущую " "производительность данного продукта от поставщика." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:586 msgid "" "It should be noted that COMTEST normally aborts when an excessive number or " "certain types of problems have been detected. As part of this testing, " "COMTEST was modified so that it would not abort no matter how many " "differences were encountered." msgstr "" "Следует отметить, что COMTEST обычно завершает работу при обнаружении " "чрезмерного количества или определённых типов проблем. В рамках этого " "тестирования COMTEST был изменён так, чтобы он не завершал работу независимо " "от количества обнаруженных различий." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:591 #, no-wrap msgid "Vendor" msgstr "Поставщик" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:592 #, no-wrap msgid "Part Number" msgstr "Номер детали" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:594 #, no-wrap msgid "Errors (aka \"differences\" reported)" msgstr "Ошибки (также известные как \"различия\" в отчётах)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:595 #: documentation/content/en/articles/serial-uart/_index.adoc:599 #: documentation/content/en/articles/serial-uart/_index.adoc:603 #, no-wrap msgid "National" msgstr "National" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:596 #, no-wrap msgid "(PC16550DV)" msgstr "(PC16550DV)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:598 #: documentation/content/en/articles/serial-uart/_index.adoc:602 #: documentation/content/en/articles/serial-uart/_index.adoc:606 #, no-wrap msgid "0" msgstr "0" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:600 #, no-wrap msgid "(NS16550AFN)" msgstr "(NS16550AFN)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:604 #, no-wrap msgid "(NS16C552V)" msgstr "(NS16C552V)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:607 #, no-wrap msgid "TI" msgstr "TI" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:608 #, no-wrap msgid "(TL16550AFN)" msgstr "(TL16550AFN)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:611 #, no-wrap msgid "CMD" msgstr "CMD" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:612 #, no-wrap msgid "(16C550PE)" msgstr "(16C550PE)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:615 #, no-wrap msgid "StarTech" msgstr "StarTech" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:616 #, no-wrap msgid "(ST16C550J)" msgstr "(ST16C550J)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:619 #, no-wrap msgid "Rockwell" msgstr "Rockwell" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:620 #, no-wrap msgid "Reference modem with internal 16550 or an emulation (RC144DPi/C3000-25)" msgstr "Стандартный модем с внутренним 16550 или его эмуляцией (RC144DPi/C3000-25)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:622 #, no-wrap msgid "117" msgstr "117" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:623 #, no-wrap msgid "Sierra" msgstr "Sierra" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:624 #, no-wrap msgid "Modem with an internal 16550 (SC11951/SC11351)" msgstr "Модем с внутренним 16550 (SC11951/SC11351)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:625 #, no-wrap msgid "91" msgstr "91" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:632 msgid "" "To date, the author of this document has not found any non-National parts " "that report zero differences using the COMTEST program. It should also be " "noted that National has had five versions of the 16550 over the years and " "the newest parts behave a bit differently than the classic NS16550AFN that " "is considered the benchmark for functionality. COMTEST appears to turn a " "blind eye to the differences within the National product line and reports no " "errors on the National parts (except for the original 16550) even when there " "are official erratas that describe bugs in the A, B and C revisions of the " "parts, so this bias in COMTEST must be taken into account." msgstr "" "На сегодняшний день автор данного документа не обнаружил ни одного не-" "National компонента, который бы показывал нулевые различия при использовании " "программы COMTEST. Также следует отметить, что у National было пять версий " "16550 за эти годы, и новейшие компоненты ведут себя несколько иначе, чем " "классический NS16550AFN, который считается эталоном функциональности. " "COMTEST, по-видимому, закрывает глаза на различия внутри линейки продуктов " "National и не сообщает об ошибках в компонентах National (за исключением " "оригинальной 16550), даже когда существуют официальные errata, описывающие " "ошибки в ревизиях A, B и C этих компонентов, поэтому эту предвзятость " "COMTEST необходимо учитывать." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:639 msgid "" "It is important to understand that a simple count of differences from " "COMTEST does not reveal a lot about what differences are important and which " "are not. For example, about half of the differences reported in the two " "modems listed above that have internal UARTs were caused by the clone UARTs " "not supporting five- and six-bit character modes. The real 16550, 16450, " "and 8250 UARTs all support these modes and COMTEST checks the functionality " "of these modes so over fifty differences are reported. However, almost no " "modern modem supports five- or six-bit characters, particularly those with " "error-correction and compression capabilities. This means that the " "differences related to five- and six-bit character modes can be discounted." msgstr "" -"Важно понимать, что простое подсчитывание различий с COMTEST не дает полного " +"Важно понимать, что простое подсчитывание различий с COMTEST не даёт полного " "представления о том, какие различия существенны, а какие нет. Например, " "около половины различий, обнаруженных в двух вышеупомянутых модемах с " "внутренними UART, были вызваны тем, что клоновые UART не поддерживают режимы " "пяти- и шестибитных символов. Настоящие UART 16550, 16450 и 8250 " "поддерживают эти режимы, и COMTEST проверяет их функциональность, поэтому " "фиксируется более пятидесяти различий. Однако почти ни один современный " "модем не поддерживает пяти- или шестибитные символы, особенно те, что " "обладают функциями коррекции ошибок и сжатия. Это означает, что различия, " "связанные с режимами пяти- и шестибитных символов, можно не учитывать." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:643 msgid "" "Many of the differences COMTEST reports have to do with timing. In many of " "the clone designs, when the host reads from one port, the status bits in " "some other port may not update in the same amount of time (some faster, some " "slower) as a _real_ NS16550AFN and COMTEST looks for these differences. " "This means that the number of differences can be misleading in that one " "device may only have one or two differences but they are extremely serious, " "and some other device that updates the status registers faster or slower " "than the reference part (that would probably never affect the operation of a " "properly written driver) could have dozens of differences reported." msgstr "" "Многие различия, о которых сообщает COMTEST, связаны с временными " "характеристиками. Во многих клонированных конструкциях, когда хост читает из " "одного порта, статусные биты в другом порте могут обновляться с иной " "скоростью (быстрее или медленнее), чем у _настоящего_ NS16550AFN, и COMTEST " "выявляет эти различия. Это означает, что количество различий может вводить в " "заблуждение: одно устройство может иметь всего одно или два различия, но они " "крайне критичны, тогда как другое устройство, обновляющее статусные регистры " "быстрее или медленнее эталонной части (что, вероятно, никогда не повлияет на " "работу правильно написанного драйвера), может иметь десятки " "зарегистрированных различий." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:645 msgid "" "COMTEST can be used as a screening tool to alert the administrator to the " "presence of potentially incompatible components that might cause problems or " "have to be handled as a special case." msgstr "" "COMTEST можно использовать в качестве инструмента проверки, чтобы " "предупредить администратора о наличии потенциально несовместимых " "компонентов, которые могут вызвать проблемы или потребуют особого подхода." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:648 msgid "" "If you run COMTEST on a 16550 that is in a modem or a modem is attached to " "the serial port, you need to first issue a ATE0&W command to the modem so " "that the modem will not echo any of the test characters. If you forget to " "do this, COMTEST will report at least this one difference:" msgstr "" "Если вы запускаете COMTEST на 16550, который находится в модеме или к модему " "подключён последовательный порт, необходимо сначала отправить модему команду " "ATE0&W, чтобы модем не эхо-повторял ни один из тестовых символов. Если вы " "забудете это сделать, COMTEST сообщит как минимум об одном различии:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:652 #, no-wrap msgid "Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61\n" msgstr "Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61\n" #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:654 #, no-wrap msgid "8250/16450/16550 Registers" -msgstr "8250/16450/16550 Регистры" +msgstr "Регистры 8250/16450/16550" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:660 msgid "" "The 8250/16450/16550 UART occupies eight contiguous I/O port addresses. In " "the IBM PC, there are two defined locations for these eight ports and they " "are known collectively as [.filename]#COM1# and [.filename]#COM2#. The " "makers of PC-clones and add-on cards have created two additional areas known " "as [.filename]#COM3# and [.filename]#COM4#, but these extra COM ports " "conflict with other hardware on some systems. The most common conflict is " "with video adapters that provide IBM 8514 emulation." msgstr "" "UART 8250/16450/16550 занимает восемь последовательных адресов портов ввода-" "вывода. В IBM PC определены два расположения для этих восьми портов, которые " "вместе известны как [.filename]#COM1# и [.filename]#COM2#. Производители PC-" "клонов и дополнительных карт создали два дополнительных области, известных " "как [.filename]#COM3# и [.filename]#COM4#, но эти дополнительные COM-порты " "конфликтуют с другим оборудованием на некоторых системах. Наиболее " "распространённый конфликт возникает с видеоадаптерами, обеспечивающими " "эмуляцию IBM 8514." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:665 msgid "" "[.filename]#COM1# is located from 0x3f8 to 0x3ff and normally uses IRQ 4. [." "filename]#COM2# is located from 0x2f8 to 0x2ff and normally uses IRQ 3. [." "filename]#COM3# is located from 0x3e8 to 0x3ef and has no standardized IRQ. " "[.filename]#COM4# is located from 0x2e8 to 0x2ef and has no standardized IRQ." msgstr "" "[.filename]#COM1# находится в диапазоне от 0x3f8 до 0x3ff и обычно " "использует IRQ 4. [.filename]#COM2# находится в диапазоне от 0x2f8 до 0x2ff " "и обычно использует IRQ 3. [.filename]#COM3# находится в диапазоне от 0x3e8 " "до 0x3ef и не имеет стандартного IRQ. [.filename]#COM4# находится в " "диапазоне от 0x2e8 до 0x2ef и не имеет стандартного IRQ." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:667 msgid "" "A description of the I/O ports of the 8250/16450/16550 UART is provided " "below." msgstr "Описание портов ввода-вывода UART 8250/16450/16550 представлено ниже." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:672 #, no-wrap msgid "I/O Port" msgstr "Порт ввода/вывода" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:673 #, no-wrap msgid "Access Allowed" msgstr "Доступ Разрешен" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:676 #: documentation/content/en/articles/serial-uart/_index.adoc:684 #: documentation/content/en/articles/serial-uart/_index.adoc:692 #, no-wrap msgid "+0x00" msgstr "+0x00" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:677 #, no-wrap msgid "write (DLAB==0)" msgstr "запись (DLAB==0)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:683 #, no-wrap msgid "" "Transmit Holding Register (THR).\n" "\n" "Information written to this port are treated as data words and will be transmitted by the UART." msgstr "" "Регистр передачи данных (THR).\n" "\n" "Информация, записанная в этот порт, обрабатывается как слова данных и " "передаётся через UART." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:685 #, no-wrap msgid "read (DLAB==0)" msgstr "чтение (DLAB==0)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:691 #, no-wrap msgid "" "Receive Buffer Register (RBR).\n" "\n" "Any data words received by the UART form the serial link are accessed by the host by reading this port." msgstr "" "Регистр буфера приема (RBR).\n" "\n" "Любые слова данных, полученные UART из последовательного соединения, доступны для чтения хостом через этот порт." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:693 #: documentation/content/en/articles/serial-uart/_index.adoc:701 #, no-wrap msgid "write/read (DLAB==1)" msgstr "запись/чтение (DLAB==1)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:699 #, no-wrap msgid "" "Divisor Latch LSB (DLL)\n" "\n" "This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 0 thru 7 of the divisor." msgstr "" "Младший байт защелки делителя (DLL — Divisor Latch LSB)\n" "\n" "Это значение будет поделено от основного входного тактового сигнала (в IBM PC основной тактовый сигнал равен 1,8432 МГц), и полученный тактовый сигнал будет определять скорость передачи UART. Этот регистр содержит биты с 0 по 7 делителя." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:700 #: documentation/content/en/articles/serial-uart/_index.adoc:708 #, no-wrap msgid "+0x01" msgstr "+0x01" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:707 #, no-wrap msgid "" "Divisor Latch MSB (DLH)\n" "\n" "This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 8 thru 15 of the divisor." msgstr "" "Старший байт защелки делителя (DLH — Divisor Latch MSB)\n" "\n" "Это значение будет разделено от основного входного тактового сигнала (в IBM PC основной тактовый сигнал равен 1,8432 МГц), и полученный тактовый сигнал будет определять скорость передачи данных UART. Этот регистр содержит биты с 8 по 15 делителя." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:709 #, no-wrap msgid "write/read (DLAB==0)" msgstr "запись/чтение (DLAB==0)" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:721 #, no-wrap msgid "" "Interrupt Enable Register (IER) +\n" "\n" "The 8250/16450/16550 UART classifies events into one of four categories. Each category can be configured to generate an interrupt when any of the events occurs. The 8250/16450/16550 UART generates a single external interrupt signal regardless of how many events in the enabled categories have occurred. It is up to the host processor to respond to the interrupt and then poll the enabled interrupt categories (usually all categories have interrupts enabled) to determine the true cause(s) of the interrupt. +\n" "Bit 7 -> Reserved, always 0. +\n" "Bit 6 -> Reserved, always 0. +\n" "Bit 5 -> Reserved, always 0. +\n" "Bit 4 -> Reserved, always 0. +\n" "Bit 3 -> Enable Modem Status Interrupt (EDSSI). Setting this bit to \"1\" allows the UART to generate an interrupt when a change occurs on one or more of the status lines. +\n" "Bit 2 -> Enable Receiver Line Status Interrupt (ELSI) Setting this bit to \"1\" causes the UART to generate an interrupt when the an error (or a BREAK signal) has been detected in the incoming data. +\n" "Bit 1 -> Enable Transmitter Holding Register Empty Interrupt (ETBEI) Setting this bit to \"1\" causes the UART to generate an interrupt when the UART has room for one or more additional characters that are to be transmitted. +\n" "Bit 0 -> Enable Received Data Available Interrupt (ERBFI) Setting this bit to \"1\" causes the UART to generate an interrupt when the UART has received enough characters to exceed the trigger level of the FIFO, or the FIFO timer has expired (stale data), or a single character has been received when the FIFO is disabled." msgstr "" "Регистр разрешения прерываний (IER) +\n" "\n" "UART 8250/16450/1655 классифицирует события на четыре категории. Каждая категория может быть настроена на генерацию прерывания при возникновении любого из событий. UART 8250/16450/16550 генерирует единый внешний сигнал прерывания независимо от того, сколько событий в разрешённых категориях произошло. Задача главного процессора — обработать прерывание и затем опросить разрешённые категории прерываний (обычно прерывания разрешены для всех категорий), чтобы определить истинную причину(ы) прерывания. +\n" "Бит 7 -> Зарезервирован, всегда 0. +\n" "Бит 6 -> Зарезервирован, всегда 0. +\n" "Бит 5 -> Зарезервирован, всегда 0. +\n" "Бит 4 -> Зарезервирован, всегда 0. +\n" "Бит 3 -> Разрешение прерывания по состоянию модема (EDSSI). Установка этого бита в \"1\" позволяет UART генерировать прерывание при изменении состояния одной или нескольких линий статуса. +\n" "Бит 2 -> Разрешение прерывания по состоянию линии приёмника (ELSI). Установка этого бита в \"1\" приводит к генерации прерывания UART при обнаружении ошибки (или сигнала BREAK) во входящих данных. +\n" "Бит 1 -> Разрешение прерывания по опустошению регистра передатчика (ETBEI). Установка этого бита в \"1\" приводит к генерации прерывания UART, когда в UART появляется место для одного или более дополнительных символов, предназначенных для передачи. +\n" "Бит 0 -> Разрешение прерывания по наличию принятых данных (ERBFI). Установка этого бита в \"1\" приводит к генерации прерывания UART, когда UART принял достаточное количество символов для превышения порога FIFO, или истекло время ожидания FIFO (устаревшие данные), или принят одиночный символ при отключённом FIFO." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:722 #: documentation/content/en/articles/serial-uart/_index.adoc:741 #, no-wrap msgid "+0x02" msgstr "+0x02" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:723 #, no-wrap msgid "write" msgstr "запись" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:740 #, no-wrap msgid "" "FIFO Control Register (FCR) (This port does not exist on the 8250 and 16450 UART.) +\n" "Bit 7 -> Receiver Trigger Bit #1 +\n" "Bit 6 -> Receiver Trigger Bit #0 +\n" "\n" "These two bits control at what point the receiver is to generate an interrupt when the FIFO is active. +\n" "7 6 How many words are received before an interrupt is generated +\n" "0 0 1 +\n" "0 1 4 +\n" "1 0 8 +\n" "1 1 14 +\n" "Bit 5 -> Reserved, always 0. +\n" "Bit 4 -> Reserved, always 0. +\n" "Bit 3 -> DMA Mode Select. If Bit 0 is set to \"1\" (FIFOs enabled), setting this bit changes the operation of the -RXRDY and -TXRDY signals from Mode 0 to Mode 1. +\n" "Bit 2 -> Transmit FIFO Reset. When a \"1\" is written to this bit, the contents of the FIFO are discarded. Any word currently being transmitted will be sent intact. This function is useful in aborting transfers. +\n" "Bit 1 -> Receiver FIFO Reset. When a \"1\" is written to this bit, the contents of the FIFO are discarded. Any word currently being assembled in the shift register will be received intact. +\n" "Bit 0 -> 16550 FIFO Enable. When set, both the transmit and receive FIFOs are enabled. Any contents in the holding register, shift registers or FIFOs are lost when FIFOs are enabled or disabled. +" msgstr "" "Регистр управления FIFO (FCR — FIFO Control Register) (Этот порт отсутствует " "в UART 8250 и 16450.) +\n" "Бит 7 -> Бит триггера приемника #1 +\n" "Бит 6 -> Бит триггера приемника #0 +\n" "\n" "Эти два бита определяют, при каком количестве данных приемник должен " "генерировать прерывание, когда FIFO активен. +\n" "7 6 Количество слов перед генерацией прерывания +\n" "0 0 1 +\n" "0 1 4 +\n" "1 0 8 +\n" "1 1 14 +\n" "Бит 5 -> Зарезервирован, всегда 0. +\n" "Бит 4 -> Зарезервирован, всегда 0. +\n" "Бит 3 -> Выбор режима DMA. Если бит 0 установлен в \"1\" (FIFO включены), " "установка этого бита изменяет работу сигналов -RXRDY и -TXRDY с режима 0 на " "режим 1. +\n" "Бит 2 -> Сброс передающего FIFO. При записи \"1\" в этот бит содержимое FIFO " "очищается. Любое слово, которое передаётся в данный момент, будет отправлено " "полностью. Эта функция полезна для прерывания передачи. +\n" "Бит 1 -> Сброс приемного FIFO. При записи \"1\" в этот бит содержимое FIFO " "очищается. Любое слово, которое в данный момент собирается в сдвиговом " "регистре, будет принято полностью. +\n" "Бит 0 -> Включение FIFO 16550. При установке этого бита активируются как " "передающий, так и приемный FIFO. Любое содержимое в регистре хранения, " "сдвиговых регистрах или FIFO теряется при включении или отключении FIFO. +" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:742 #, no-wrap msgid "read" msgstr "чтение" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:758 #, no-wrap msgid "" "Interrupt Identification Register +\n" "Bit 7 -> FIFOs enabled. On the 8250/16450 UART, this bit is zero. +\n" "Bit 6 -> FIFOs enabled. On the 8250/16450 UART, this bit is zero. +\n" "Bit 5 -> Reserved, always 0. +\n" "Bit 4 -> Reserved, always 0. +\n" "Bit 3 -> Interrupt ID Bit #2. On the 8250/16450 UART, this bit is zero. +\n" "Bit 2 -> Interrupt ID Bit #1 +\n" "Bit 1 -> Interrupt ID Bit #0.These three bits combine to report the category of event that caused the interrupt that is in progress. These categories have priorities, so if multiple categories of events occur at the same time, the UART will report the more important events first and the host must resolve the events in the order they are reported. All events that caused the current interrupt must be resolved before any new interrupts will be generated. (This is a limitation of the PC architecture.) +\n" "2 1 0 Priority Description +\n" "0 1 1 First Received Error (OE, PE, BI, or FE) +\n" "0 1 0 Second Received Data Available +\n" "1 1 0 Second Trigger level identification (Stale data in receive buffer) +\n" "0 0 1 Third Transmitter has room for more words (THRE) +\n" "0 0 0 Fourth Modem Status Change (-CTS, -DSR, -RI, or -DCD) +\n" "Bit 0 -> Interrupt Pending Bit. If this bit is set to \"0\", then at least one interrupt is pending." msgstr "" "Регистр идентификации прерываний +\n" "Бит 7 -> FIFO включены. На UART 8250/16450 этот бит равен нулю. +\n" "Бит 6 -> FIFO включены. На UART 8250/16450 этот бит равен нулю. +\n" "Бит 5 -> Зарезервирован, всегда 0. +\n" "Бит 4 -> Зарезервирован, всегда 0. +\n" "Бит 3 -> Бит идентификатора прерывания №2. На UART 8250/16450 этот бит равен нулю. +\n" "Бит 2 -> Бит идентификатора прерывания №1 +\n" "Бит 1 -> Бит идентификатора прерывания №0.Эти три бита объединяются для указания категории события, вызвавшего текущее прерывание. Эти категории имеют приоритеты, поэтому, если несколько категорий событий происходят одновременно, UART сообщит о более важных событиях первыми, и хост должен обрабатывать события в порядке их поступления. Все события, вызвавшие текущее прерывание, должны быть обработаны до генерации новых прерываний. (Это ограничение архитектуры ПК.) +\n" "2 1 0 Приоритет Описание +\n" "0 1 1 Первый Принятая ошибка (OE, PE, BI или FE) +\n" "0 1 0 Второй Доступны принятые данные +\n" "1 1 0 Второй Идентификация уровня триггера (Устаревшие данные в буфере приема) +\n" "0 0 1 Третий Передатчик готов принять больше данных (THRE) +\n" "0 0 0 Четвертый Изменение состояния модема (-CTS, -DSR, -RI или -DCD) +\n" "Бит 0 -> Бит ожидания прерывания. Если этот бит установлен в \"0\", то как минимум одно прерывание ожидает обработки." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:759 #, no-wrap msgid "+0x03" msgstr "+0x03" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:760 #: documentation/content/en/articles/serial-uart/_index.adoc:778 #: documentation/content/en/articles/serial-uart/_index.adoc:790 #: documentation/content/en/articles/serial-uart/_index.adoc:802 #: documentation/content/en/articles/serial-uart/_index.adoc:813 #, no-wrap msgid "write/read" msgstr "запись/чтение" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:776 #, no-wrap msgid "" "Line Control Register (LCR) +\n" "Bit 7 -> Divisor Latch Access Bit (DLAB). When set, access to the data transmit/receive register (THR/RBR) and the Interrupt Enable Register (IER) is disabled. Any access to these ports is now redirected to the Divisor Latch Registers. Setting this bit, loading the Divisor Registers, and clearing DLAB should be done with interrupts disabled. +\n" "Bit 6 -> Set Break. When set to \"1\", the transmitter begins to transmit continuous Spacing until this bit is set to \"0\". This overrides any bits of characters that are being transmitted. +\n" "Bit 5 -> Stick Parity. When parity is enabled, setting this bit causes parity to always be \"1\" or \"0\", based on the value of Bit 4.\n" "Bit 4 -> Even Parity Select (EPS). When parity is enabled and Bit 5 is \"0\", setting this bit causes even parity to be transmitted and expected. Otherwise, odd parity is used. +\n" "Bit 3 -> Parity Enable (PEN). When set to \"1\", a parity bit is inserted between the last bit of the data and the Stop Bit. The UART will also expect parity to be present in the received data. +\n" "Bit 2 -> Number of Stop Bits (STB). If set to \"1\" and using 5-bit data words, 1.5 Stop Bits are transmitted and expected in each data word. For 6, 7 and 8-bit data words, 2 Stop Bits are transmitted and expected. When this bit is set to \"0\", one Stop Bit is used on each data word. +\n" "Bit 1 -> Word Length Select Bit #1 (WLSB1) +\n" "Bit 0 -> Word Length Select Bit #0 (WLSB0) +\n" "Together these bits specify the number of bits in each data word. +\n" "1 0 Word Length +\n" "0 0 5 Data Bits +\n" "0 1 6 Data Bits +\n" "1 0 7 Data Bits +\n" "1 1 8 Data Bits +" msgstr "" "Регистр управления линией (LCR — Line Control Register) +\n" "Бит 7 -> Бит доступа к защелке делителя (DLAB). При установке доступ к " "регистру передачи/приема данных (THR/RBR) и регистру разрешения прерываний " "(IER) отключается. Любой доступ к этим портам перенаправляется к регистрам " "защелки делителя. Установка этого бита, загрузка регистров делителя и сброс " "DLAB должны выполняться при отключенных прерываниях. +\n" "Бит 6 -> Установка прерывания. При установке в \"1\" передатчик начинает " "передавать непрерывный интервал (Spacing), пока этот бит не будет сброшен в " "\"0\". Это переопределяет любые передаваемые биты символов. +\n" "Бит 5 -> Фиксированный бит чётности. При включенной проверке чётности " "установка этого бита приводит к тому, что бит чётности всегда будет \"1\" " "или \"0\" в зависимости от значения бита 4.\n" "Бит 4 -> Выбор чётности (EPS). При включенной проверке чётности и если бит 5 " "равен \"0\", установка этого бита приводит к использованию и ожиданию четной " "чётности. В противном случае используется нечетная чётность. +\n" "Бит 3 -> Разрешение проверки чётности (PEN). При установке в \"1\" бит " "чётности вставляется между последним битом данных и стоповым битом. UART " "также ожидает наличие бита чётности в принимаемых данных. +\n" "Бит 2 -> Количество стоповых битов (STB). Если установлен в \"1\" и " "используются 5-битные слова данных, передаётся и ожидается 1.5 стоповых бита " "в каждом слове данных. Для 6, 7 и 8-битных слов данных передаётся и " "ожидается 2 стоповых бита. Если этот бит сброшен в \"0\", используется один " "стоповый бит в каждом слове данных. +\n" "Бит 1 -> Бит выбора длины слова #1 (WLSB1) +\n" "Бит 0 -> Бит выбора длины слова #0 (WLSB0) +\n" "Вместе эти биты определяют количество битов в каждом слове данных. +\n" "1 0 Длина слова +\n" "0 0 5 бит данных +\n" "0 1 6 бит данных +\n" "1 0 7 бит данных +\n" "1 1 8 бит данных +" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:777 #, no-wrap msgid "+0x04" msgstr "+0x04" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:788 #, no-wrap msgid "" "Modem Control Register (MCR) +\n" "Bit 7 -> Reserved, always 0. +\n" "Bit 6 -> Reserved, always 0. +\n" "Bit 5 -> Reserved, always 0. +\n" "Bit 4 -> Loop-Back Enable. When set to \"1\", the UART transmitter and receiver are internally connected together to allow diagnostic operations. In addition, the UART modem control outputs are connected to the UART modem control inputs. CTS is connected to RTS, DTR is connected to DSR, OUT1 is connected to RI, and OUT 2 is connected to DCD. +\n" "Bit 3 -> OUT 2. An auxiliary output that the host processor may set high or low. In the IBM PC serial adapter (and most clones), OUT 2 is used to tri-state (disable) the interrupt signal from the 8250/16450/16550 UART. +\n" "Bit 2 -> OUT 1. An auxiliary output that the host processor may set high or low. This output is not used on the IBM PC serial adapter. +\n" "Bit 1 -> Request to Send (RTS). When set to \"1\", the output of the UART -RTS line is Low (Active). +\n" "Bit 0 -> Data Terminal Ready (DTR). When set to \"1\", the output of the UART -DTR line is Low (Active). +" msgstr "" "Регистр управления модемом (MCR — Modem Control Register) +\n" "Бит 7 -> Зарезервирован, всегда 0. +\n" "Бит 6 -> Зарезервирован, всегда 0. +\n" "Бит 5 -> Зарезервирован, всегда 0. +\n" "Бит 4 -> Режим петли (Loop-Back). При установке в \"1\" передатчик и приёмник UART соединяются внутри для диагностики. Также выходы управления модемом UART подключаются к его входам: CTS к RTS, DTR к DSR, OUT1 к RI, а OUT2 к DCD. +\n" "Бит 3 -> OUT2. Вспомогательный выход, который процессор может установить в высокий или низкий уровень. В адаптере IBM PC (и большинстве клонов) OUT2 используется для отключения сигнала прерывания от UART 8250/16450/16550. +\n" "Бит 2 -> OUT1. Вспомогательный выход, который процессор может установить в высокий или низкий уровень. На адаптере IBM PC не используется. +\n" "Бит 1 -> Запрос на передачу (RTS). При установке в \"1\" выход линии -RTS UART переходит в низкий уровень (активное состояние). +\n" "Бит 0 -> Готовность терминала данных (DTR). При установке в \"1\" выход линии -DTR UART переходит в низкий уровень (активное состояние). +" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:789 #, no-wrap msgid "+0x05" msgstr "+0x05" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:800 #, no-wrap msgid "" "Line Status Register (LSR) +\n" "Bit 7 -> Error in Receiver FIFO. On the 8250/16450 UART, this bit is zero. This bit is set to \"1\" when any of the bytes in the FIFO have one or more of the following error conditions: PE, FE, or BI. +\n" "Bit 6 -> Transmitter Empty (TEMT). When set to \"1\", there are no words remaining in the transmit FIFO or the transmit shift register. The transmitter is completely idle. +\n" "Bit 5 -> Transmitter Holding Register Empty (THRE). When set to \"1\", the FIFO (or holding register) now has room for at least one additional word to transmit. The transmitter may still be transmitting when this bit is set to \"1\". +\n" "Bit 4 -> Break Interrupt (BI). The receiver has detected a Break signal. +\n" "Bit 3 -> Framing Error (FE). A Start Bit was detected but the Stop Bit did not appear at the expected time. The received word is probably garbled. +\n" "Bit 2 -> Parity Error (PE). The parity bit was incorrect for the word received. +\n" "Bit 1 -> Overrun Error (OE). A new word was received and there was no room in the receive buffer. The newly-arrived word in the shift register is discarded. On 8250/16450 UARTs, the word in the holding register is discarded and the newly- arrived word is put in the holding register. +\n" "Bit 0 -> Data Ready (DR) One or more words are in the receive FIFO that the host may read. A word must be completely received and moved from the shift register into the FIFO (or holding register for 8250/16450 designs) before this bit is set." msgstr "" "Регистр состояния линии (LSR — Line Status Register) +\n" "Бит 7 -> Ошибка в FIFO приемника. На UART 8250/16450 этот бит равен нулю. " "Этот бит устанавливается в «1», когда любой из байтов в FIFO имеет одно или " "несколько из следующих условий ошибки: PE, FE или BI. +\n" "Бит 6 -> Передатчик пуст (TEMT). Когда установлен в «1», в FIFO передатчика " "или сдвиговом регистре передатчика не осталось слов. Передатчик полностью " "бездействует. +\n" "Бит 5 -> Регистр хранения передатчика пуст (THRE). Когда установлен в «1», в " "FIFO (или регистре хранения) теперь есть место для передачи как минимум " -"одного дополнительного слова. Передатчик может все еще передавать данные, " +"одного дополнительного слова. Передатчик может все ещё передавать данные, " "когда этот бит установлен в «1». +\n" "Бит 4 -> Прерывание по Break (BI). Приемник обнаружил сигнал Break. +\n" "Бит 3 -> Ошибка кадрирования (FE). Обнаружен стартовый бит, но стоповый бит " "не появился в ожидаемое время. Принятое слово, вероятно, искажено. +\n" "Бит 2 -> Ошибка чётности (PE). Бит чётности для принятого слова был " "некорректен. +\n" "Бит 1 -> Ошибка переполнения (OE). Было получено новое слово, но в буфере " "приема не было места. Вновь поступившее слово в сдвиговом регистре " "отбрасывается. На UART 8250/16450 слово в регистре хранения отбрасывается, а " "вновь поступившее слово помещается в регистр хранения. +\n" "Бит 0 -> Данные готовы (DR). Одно или несколько слов находятся в FIFO " "приемника, которые хост может прочитать. Слово должно быть полностью принято " "и перемещено из сдвигового регистра в FIFO (или регистр хранения для 8250/" "16450) до того, как этот бит будет установлен." #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:801 #, no-wrap msgid "+0x06" msgstr "+0x06" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:811 #, no-wrap msgid "" "Modem Status Register (MSR) +\n" "Bit 7 -> Data Carrier Detect (DCD). Reflects the state of the DCD line on the UART. +\n" "Bit 6 -> Ring Indicator (RI). Reflects the state of the RI line on the UART. +\n" "Bit 5 -> Data Set Ready (DSR). Reflects the state of the DSR line on the UART. +\n" "Bit 4 -> Clear To Send (CTS). Reflects the state of the CTS line on the UART. +\n" "Bit 3 -> Delta Data Carrier Detect (DDCD). Set to \"1\" if the -DCD line has changed state one more time since the last time the MSR was read by the host. +\n" "Bit 2 -> Trailing Edge Ring Indicator (TERI). Set to \"1\" if the -RI line has had a low to high transition since the last time the MSR was read by the host. +\n" "Bit 1 -> Delta Data Set Ready (DDSR). Set to \"1\" if the -DSR line has changed state one more time since the last time the MSR was read by the host. +\n" "Bit 0 -> Delta Clear To Send (DCTS). Set to \"1\" if the -CTS line has changed state one more time since the last time the MSR was read by the host. +" msgstr "" "Регистр состояния модема (MSR — Modem Status Register) +\n" "Бит 7 -> Обнаружение несущей данных (DCD). Отражает состояние линии DCD на UART. +\n" "Бит 6 -> Индикатор вызова (RI). Отражает состояние линии RI на UART. +\n" "Бит 5 -> Готовность передатчика данных (DSR). Отражает состояние линии DSR на UART. +\n" "Бит 4 -> Готовность к приёму (CTS). Отражает состояние линии CTS на UART. +\n" "Бит 3 -> Изменение состояния обнаружения несущей данных (DDCD). Устанавливается в \"1\", если линия -DCD изменила состояние ещё раз с момента последнего чтения MSR хостом. +\n" "Бит 2 -> Фронт сигнала вызова (TERI). Устанавливается в \"1\", если линия -RI перешла из низкого уровня в высокий с момента последнего чтения MSR хостом. +\n" "Бит 1 -> Изменение состояния готовности передатчика данных (DDSR). Устанавливается в \"1\", если линия -DSR изменила состояние ещё раз с момента последнего чтения MSR хостом. +\n" "Бит 0 -> Изменение состояния готовности к приёму (DCTS). Устанавливается в \"1\", если линия -CTS изменила состояние ещё раз с момента последнего чтения MSR хостом. +" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:812 #, no-wrap msgid "+0x07" msgstr "+0x07" #. type: Table #: documentation/content/en/articles/serial-uart/_index.adoc:814 #, no-wrap msgid "Scratch Register (SCR). This register performs no function in the UART. Any value can be written by the host to this location and read by the host later on." msgstr "Регистр Scratch (SCR — Scratch Register). Этот регистр не выполняет никакой функции в UART. Хост может записать любое значение в это место и позднее считать его." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:816 #, no-wrap msgid "Beyond the 16550A UART" msgstr "За пределами UART 16550A" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:821 msgid "" "Although National Semiconductor has not offered any components compatible " "with the 16550 that provide additional features, various other vendors " "have. Some of these components are described below. It should be " "understood that to effectively utilize these improvements, drivers may have " "to be provided by the chip vendor since most of the popular operating " "systems do not support features beyond those provided by the 16550." msgstr "" "Хотя National Semiconductor не предлагала никаких компонентов, совместимых с " "16550 и предоставляющих дополнительные функции, другие производители сделали " "это. Некоторые из этих компонентов описаны ниже. Следует понимать, что для " "эффективного использования этих улучшений могут потребоваться драйверы от " "производителя чипа, поскольку большинство популярных операционных систем не " "поддерживают функции, выходящие за рамки возможностей 16550." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:822 #, no-wrap msgid "ST16650" msgstr "ST16650" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:825 msgid "" "By default this part is similar to the NS16550A, but an extended 32-byte " "send and receive buffer can be optionally enabled. Made by StarTech." msgstr "" "По умолчанию эта часть аналогична NS16550A, но дополнительно можно включить " "расширенный 32-байтовый буфер отправки и приёма. Производитель — StarTech." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:826 #, no-wrap msgid "TIL16660" msgstr "TIL16660" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:829 msgid "" "By default this part behaves similar to the NS16550A, but an extended 64-" "byte send and receive buffer can be optionally enabled. Made by Texas " "Instruments." msgstr "" "По умолчанию эта часть ведёт себя аналогично NS16550A, но дополнительно " "может быть включён расширенный 64-байтный буфер передачи и приёма. " "Производится Texas Instruments." #. type: Labeled list #: documentation/content/en/articles/serial-uart/_index.adoc:830 #, no-wrap msgid "Hayes ESP" msgstr "Hayes ESP" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:833 msgid "" "This proprietary plug-in card contains a 2048-byte send and receive buffer, " "and supports data rates to 230.4Kbit/sec. Made by Hayes." msgstr "" "Эта проприетарная внешняя карта содержит буфер передачи и приема размером " "2048 байт и поддерживает скорость передачи данных до 230,4 Кбит/с. " "Произведено компанией Hayes." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:838 msgid "" "In addition to these \"dumb\" UARTs, many vendors produce intelligent serial " "communication boards. This type of design usually provides a microprocessor " "that interfaces with several UARTs, processes and buffers the data, and then " "alerts the main PC processor when necessary. As the UARTs are not directly " "accessed by the PC processor in this type of communication system, it is not " "necessary for the vendor to use UARTs that are compatible with the 8250, " "16450, or the 16550 UART. This leaves the designer free to components that " "may have better performance characteristics." msgstr "" "В дополнение к этим \"простым\" UART многие производители выпускают " "интеллектуальные платы для последовательной связи. Такой тип конструкции " "обычно включает микропроцессор, который взаимодействует с несколькими UART, " "обрабатывает и буферизует данные, а затем при необходимости уведомляет " "основной процессор ПК. Поскольку в такой системе связи UART не доступны " "напрямую процессору ПК, производителю не обязательно использовать UART, " -"совместимые с 8250, 16450 или 16550. Это дает разработчику свободу выбора " +"совместимые с 8250, 16450 или 16550. Это даёт разработчику свободу выбора " "компонентов с лучшими характеристиками производительности." #. type: Title == #: documentation/content/en/articles/serial-uart/_index.adoc:840 #, no-wrap msgid "Configuring the [.filename]#sio# driver" msgstr "Настройка драйвера [.filename]#sio#" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:845 msgid "" "The [.filename]#sio# driver provides support for NS8250-, NS16450-, NS16550 " "and NS16550A-based EIA RS-232C (CCITT V.24) communications interfaces. " "Several multiport cards are supported as well. See the man:sio[4] manual " "page for detailed technical documentation." msgstr "" "Драйвер [.filename]#sio# обеспечивает поддержку интерфейсов связи EIA " "RS-232C (CCITT V.24) на основе NS8250, NS16450, NS16550 и NS16550A. Также " "поддерживаются несколько многопортовых карт. Подробную техническую " "документацию смотрите на man:sio[4]." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:846 #, no-wrap msgid "Digi International (DigiBoard) PC/8" msgstr "Digi International (DigiBoard) PC/8" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:849 msgid "_Contributed by `{awebster}`. 26 August 1995._" msgstr "_Предоставлено `{awebster}`. 26 августа 1995._" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:853 msgid "" "Here is a config snippet from a machine with a Digi International PC/8 with " "16550. It has 8 modems connected to these 8 lines, and they work just " "great. Do not forget to add `options COM_MULTIPORT` or it will not work " "very well!" msgstr "" "Вот фрагмент конфигурации с машины, на которой установлена плата Digi " "International PC/8 с чипом 16550. К ней подключено 8 модемов, работающих на " "этих 8 линиях, и они отлично функционируют. Не забудьте добавить `options " "COM_MULTIPORT`, иначе работа будет нестабильной!" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:864 #, no-wrap msgid "" "device sio4 at isa? port 0x100 flags 0xb05\n" "device sio5 at isa? port 0x108 flags 0xb05\n" "device sio6 at isa? port 0x110 flags 0xb05\n" "device sio7 at isa? port 0x118 flags 0xb05\n" "device sio8 at isa? port 0x120 flags 0xb05\n" "device sio9 at isa? port 0x128 flags 0xb05\n" "device sio10 at isa? port 0x130 flags 0xb05\n" "device sio11 at isa? port 0x138 flags 0xb05 irq 9\n" msgstr "" "device sio4 at isa? port 0x100 flags 0xb05\n" "device sio5 at isa? port 0x108 flags 0xb05\n" "device sio6 at isa? port 0x110 flags 0xb05\n" "device sio7 at isa? port 0x118 flags 0xb05\n" "device sio8 at isa? port 0x120 flags 0xb05\n" "device sio9 at isa? port 0x128 flags 0xb05\n" "device sio10 at isa? port 0x130 flags 0xb05\n" "device sio11 at isa? port 0x138 flags 0xb05 irq 9\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:867 msgid "" "The trick in setting this up is that the MSB of the flags represent the last " "SIO port, in this case 11 so flags are 0xb05." msgstr "" "Хитрость настройки заключается в том, что старший бит флагов представляет " "последний порт SIO, в данном случае 11, поэтому флаги равны 0xb05." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:868 #, no-wrap msgid "Boca 16" msgstr "Boca 16" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:871 msgid "_Contributed by `{whiteside}`. 26 August 1995._" msgstr "_Предоставлено `{whiteside}`. 26 августа 1995._" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:873 msgid "" "The procedures to make a Boca 16 port board with FreeBSD are pretty " "straightforward, but you will need a couple things to make it work:" msgstr "" "Процедуры по настройке платы Boca с 16 портами в FreeBSD довольно просты, но " "вам понадобится несколько вещей для успешной работы:" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:875 msgid "" "You either need the kernel sources installed so you can recompile the " "necessary options or you will need someone else to compile it for you. The " "2.0.5 default kernel does _not_ come with multiport support enabled and you " "will need to add a device entry for each port anyways." msgstr "" "Вам необходимо либо установить исходные коды ядра, чтобы перекомпилировать " "нужные опции, либо найти кого-то, кто сделает это за вас. Стандартное ядро " "версии 2.0.5 _не_ включает поддержку нескольких портов, и в любом случае вам " "потребуется добавить запись устройства для каждого порта." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:876 msgid "" "Two, you will need to know the interrupt and IO setting for your Boca Board " "so you can set these options properly in the kernel." msgstr "" "Два, вам нужно знать прерывание и настройку ввода-вывода для вашей платы " "Boca, чтобы правильно установить эти параметры в ядре." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:880 msgid "" "One important note - the actual UART chips for the Boca 16 are in the " "connector box, not on the internal board itself. So if you have it " "unplugged, probes of those ports will fail. I have never tested booting " "with the box unplugged and plugging it back in, and I suggest you do not " "either." msgstr "" "Важное замечание — реальные микросхемы UART для Boca 16 находятся в " "соединительной коробке, а не на внутренней плате. Поэтому, если она " "отключена, попытки проверить эти порты завершатся неудачей. Я никогда не " "проверял загрузку с отключённой коробкой и последующим её подключением, и не " "рекомендую вам этого делать." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:883 msgid "" "If you do not already have a custom kernel configuration file set up, refer " "to extref:{handbook}kernelconfig[Kernel Configuration, kernelconfig] chapter " "of the FreeBSD Handbook for general procedures. The following are the " "specifics for the Boca 16 board and assume you are using the kernel name " "MYKERNEL and editing with vi." msgstr "" "Если у вас ещё нет настроенного файла конфигурации пользовательского ядра, " "обратитесь к разделу extref:{handbook}kernelconfig[Конфигурация ядра, " "kernelconfig] в руководстве FreeBSD для получения общих инструкций. Ниже " "приведены конкретные настройки для платы Boca 16, предполагается, что вы " "используете ядро с именем MYKERNEL и редактируете его с помощью vi." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:887 msgid "Add the line" msgstr "Добавьте строку" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:891 #, no-wrap msgid "options COM_MULTIPORT\n" msgstr "options COM_MULTIPORT\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:893 msgid "to the config file." msgstr "в конфигурационный файл." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:894 msgid "" "Where the current `device sio__n__` lines are, you will need to add 16 more " "devices. The following example is for a Boca Board with an interrupt of 3, " "and a base IO address 100h. The IO address for Each port is +8 hexadecimal " "from the previous port, thus the 100h, 108h, 110h... addresses." msgstr "" "Где находятся текущие строки `device sio__n__`, вам нужно добавить ещё 16 " "устройств. В следующем примере показана плата Boca Board с прерыванием 3 и " "базовым адресом ввода-вывода 100h. Адрес ввода-вывода для каждого порта " "увеличивается на 8 в шестнадцатеричной системе относительно предыдущего " "порта, поэтому адреса будут 100h, 108h, 110h..." #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:904 #, no-wrap msgid "" "device sio1 at isa? port 0x100 flags 0x1005\n" "device sio2 at isa? port 0x108 flags 0x1005\n" "device sio3 at isa? port 0x110 flags 0x1005\n" "device sio4 at isa? port 0x118 flags 0x1005\n" "...\n" "device sio15 at isa? port 0x170 flags 0x1005\n" "device sio16 at isa? port 0x178 flags 0x1005 irq 3\n" msgstr "" "device sio1 at isa? port 0x100 flags 0x1005\n" "device sio2 at isa? port 0x108 flags 0x1005\n" "device sio3 at isa? port 0x110 flags 0x1005\n" "device sio4 at isa? port 0x118 flags 0x1005\n" "...\n" "device sio15 at isa? port 0x170 flags 0x1005\n" "device sio16 at isa? port 0x178 flags 0x1005 irq 3\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:909 msgid "" "The flags entry _must_ be changed from this example unless you are using the " "exact same sio assignments. Flags are set according to 0x``__MYY__`` where " "_M_ indicates the minor number of the master port (the last port on a Boca " "16) and _YY_ indicates if FIFO is enabled or disabled(enabled), IRQ sharing " "is used(yes) and if there is an AST/4 compatible IRQ control register(no). " "In this example," msgstr "" "Запись flags _обязательно_ должна быть изменена по сравнению с этим " "примером, если вы не используете точно такие же назначения sio. Флаги " "устанавливаются в соответствии с 0x``__MYY__``, где _M_ обозначает младший " "номер главного порта (последний порт на Boca 16), а _YY_ указывает, включен " "или выключен FIFO (включен), используется ли разделение IRQ (да) и есть ли " "регистр управления IRQ, совместимый с AST/4 (нет). В этом примере," #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:914 #, no-wrap msgid "" " flags\n" "\t 0x1005\n" msgstr "" " flags\n" "\t 0x1005\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:918 msgid "" "indicates that the master port is sio16. If I added another board and " "assigned sio17 through sio28, the flags for all 16 ports on _that_ board " "would be 0x1C05, where 1C indicates the minor number of the master port. Do " "not change the 05 setting." msgstr "" "указывает, что основной порт - sio16. Если добавить другую плату и назначить " "порты с sio17 по sio28, флаги для всех 16 портов на _этой_ плате будут " "0x1C05, где 1C обозначает минорный номер основного порта. Не изменяйте " "значение 05." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:919 msgid "" "Save and complete the kernel configuration, recompile, install and reboot. " "Presuming you have successfully installed the recompiled kernel and have it " "set to the correct address and IRQ, your boot message should indicate the " "successful probe of the Boca ports as follows: (obviously the sio numbers, " "IO and IRQ could be different)" msgstr "" "Сохраните и завершите конфигурацию ядра, перекомпилируйте, установите и " "перезагрузитесь. Предполагая, что вы успешно установили перекомпилированное " "ядро и настроили правильный адрес и IRQ, сообщение при загрузке должно " "указывать на успешное обнаружение портов Boca следующим образом: (очевидно, " "номера sio, IO и IRQ могут отличаться)" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:954 #, no-wrap msgid "" "sio1 at 0x100-0x107 flags 0x1005 on isa\n" "sio1: type 16550A (multiport)\n" "sio2 at 0x108-0x10f flags 0x1005 on isa\n" "sio2: type 16550A (multiport)\n" "sio3 at 0x110-0x117 flags 0x1005 on isa\n" "sio3: type 16550A (multiport)\n" "sio4 at 0x118-0x11f flags 0x1005 on isa\n" "sio4: type 16550A (multiport)\n" "sio5 at 0x120-0x127 flags 0x1005 on isa\n" "sio5: type 16550A (multiport)\n" "sio6 at 0x128-0x12f flags 0x1005 on isa\n" "sio6: type 16550A (multiport)\n" "sio7 at 0x130-0x137 flags 0x1005 on isa\n" "sio7: type 16550A (multiport)\n" "sio8 at 0x138-0x13f flags 0x1005 on isa\n" "sio8: type 16550A (multiport)\n" "sio9 at 0x140-0x147 flags 0x1005 on isa\n" "sio9: type 16550A (multiport)\n" "sio10 at 0x148-0x14f flags 0x1005 on isa\n" "sio10: type 16550A (multiport)\n" "sio11 at 0x150-0x157 flags 0x1005 on isa\n" "sio11: type 16550A (multiport)\n" "sio12 at 0x158-0x15f flags 0x1005 on isa\n" "sio12: type 16550A (multiport)\n" "sio13 at 0x160-0x167 flags 0x1005 on isa\n" "sio13: type 16550A (multiport)\n" "sio14 at 0x168-0x16f flags 0x1005 on isa\n" "sio14: type 16550A (multiport)\n" "sio15 at 0x170-0x177 flags 0x1005 on isa\n" "sio15: type 16550A (multiport)\n" "sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa\n" "sio16: type 16550A (multiport master)\n" msgstr "" "sio1 at 0x100-0x107 flags 0x1005 on isa\n" "sio1: type 16550A (multiport)\n" "sio2 at 0x108-0x10f flags 0x1005 on isa\n" "sio2: type 16550A (multiport)\n" "sio3 at 0x110-0x117 flags 0x1005 on isa\n" "sio3: type 16550A (multiport)\n" "sio4 at 0x118-0x11f flags 0x1005 on isa\n" "sio4: type 16550A (multiport)\n" "sio5 at 0x120-0x127 flags 0x1005 on isa\n" "sio5: type 16550A (multiport)\n" "sio6 at 0x128-0x12f flags 0x1005 on isa\n" "sio6: type 16550A (multiport)\n" "sio7 at 0x130-0x137 flags 0x1005 on isa\n" "sio7: type 16550A (multiport)\n" "sio8 at 0x138-0x13f flags 0x1005 on isa\n" "sio8: type 16550A (multiport)\n" "sio9 at 0x140-0x147 flags 0x1005 on isa\n" "sio9: type 16550A (multiport)\n" "sio10 at 0x148-0x14f flags 0x1005 on isa\n" "sio10: type 16550A (multiport)\n" "sio11 at 0x150-0x157 flags 0x1005 on isa\n" "sio11: type 16550A (multiport)\n" "sio12 at 0x158-0x15f flags 0x1005 on isa\n" "sio12: type 16550A (multiport)\n" "sio13 at 0x160-0x167 flags 0x1005 on isa\n" "sio13: type 16550A (multiport)\n" "sio14 at 0x168-0x16f flags 0x1005 on isa\n" "sio14: type 16550A (multiport)\n" "sio15 at 0x170-0x177 flags 0x1005 on isa\n" "sio15: type 16550A (multiport)\n" "sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa\n" "sio16: type 16550A (multiport master)\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:957 msgid "If the messages go by too fast to see," msgstr "Если сообщения проходят слишком быстро, чтобы их увидеть," #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:961 #, no-wrap msgid "# dmesg | more\n" msgstr "# dmesg | more\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:963 msgid "will show you the boot messages." msgstr "покажет вам сообщения загрузки." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:964 msgid "" "Next, appropriate entries in [.filename]#/dev# for the devices must be made " "using the [.filename]#/dev/MAKEDEV# script. This step can be omitted if you " "are running FreeBSD 5.X with a kernel that has man:devfs[5] support compiled " "in." msgstr "" "Далее необходимо создать соответствующие записи в [.filename]#/dev# для " "устройств с помощью скрипта [.filename]#/dev/MAKEDEV#. Этот шаг можно " "пропустить, если вы используете FreeBSD 5.X с ядром, в котором включена " "поддержка man:devfs[5]." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:966 msgid "" "If you do need to create the [.filename]#/dev# entries, run the following as " "`root`:" msgstr "" "Если вам необходимо создать записи в [.filename]#/dev#, выполните следующую " "команду от имени `root`:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:972 #, no-wrap msgid "" "# cd /dev\n" "# ./MAKEDEV tty1\n" "# ./MAKEDEV cua1\n" msgstr "" "# cd /dev\n" "# ./MAKEDEV tty1\n" "# ./MAKEDEV cua1\n" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:976 #, no-wrap msgid "" "(everything in between)\n" "# ./MAKEDEV ttyg\n" "# ./MAKEDEV cuag\n" msgstr "" "(everything in between)\n" "# ./MAKEDEV ttyg\n" "# ./MAKEDEV cuag\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:979 msgid "" "If you do not want or need call-out devices for some reason, you can " "dispense with making the [.filename]#cua*# devices." msgstr "" "Если по какой-то причине вам не нужны или не требуются устройства исходящих " "соединений, вы можете обойтись без создания устройств [.filename]#cua*#." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:980 msgid "" "If you want a quick and sloppy way to make sure the devices are working, you " "can simply plug a modem into each port and (as root)" msgstr "" "Если вам нужен быстрый и небрежный способ убедиться, что устройства " "работают, вы можете просто подключить модем к каждому порту и (как root)" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:984 #, no-wrap msgid "# echo at > ttyd*\n" msgstr "# echo at > ttyd*\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:986 msgid "" "for each device you have made. You _should_ see the RX lights flash for each " "working port." msgstr "" "для каждого устройства, которое вы создали. Вы _должны_ увидеть, как мигают " "индикаторы RX для каждого рабочего порта." #. type: Title === #: documentation/content/en/articles/serial-uart/_index.adoc:988 #, no-wrap msgid "Support for Cheap Multi-UART Cards" msgstr "Поддержка дешёвых многоканальных UART-карт" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:991 msgid "" "_Contributed by Helge Oldach_ mailto:hmo@sep.hamburg.com[hmo@sep.hamburg." "com], September 1999" msgstr "" "_Предоставлено Хельге Ольдахом_ mailto:hmo@sep.hamburg.com[hmo@sep.hamburg." "com], сентябрь 1999 года" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:993 msgid "" "Ever wondered about FreeBSD support for your 20$ multi-I/O card with two (or " "more) COM ports, sharing IRQs? Here is how:" msgstr "" "Вы когда-нибудь задумывались о поддержке FreeBSD вашей 20-долларовой " "многофункциональной карты с двумя (или более) COM-портами, разделяющими IRQ? " "Вот как это сделать:" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:997 msgid "" "Usually the only option to support these kind of boards is to use a distinct " "IRQ for each port. For example, if your CPU board has an on-board [." "filename]#COM1# port (aka [.filename]#sio0#-I/O address 0x3F8 and IRQ 4) and " "you have an extension board with two UARTs, you will commonly need to " "configure them as [.filename]#COM2# (aka [.filename]#sio1#-I/O address 0x2F8 " "and IRQ 3), and the third port (aka [.filename]#sio2#) as I/O 0x3E8 and IRQ " "5. Obviously this is a waste of IRQ resources, as it should be basically " "possible to run both extension board ports using a single IRQ with the " "`COM_MULTIPORT` configuration described in the previous sections." msgstr "" "Обычно единственный способ поддержки таких плат — использование отдельного " "IRQ для каждого порта. Например, если ваша материнская плата имеет " "встроенный порт [.filename]#COM1# (он же [.filename]#sio0# — адрес ввода-" "вывода 0x3F8 и IRQ 4), а у вас есть расширительная плата с двумя UART, то " "обычно их нужно настроить как [.filename]#COM2# (он же [.filename]#sio1# — " "адрес ввода-вывода 0x2F8 и IRQ 3), а третий порт (он же [.filename]#sio2#) — " "с адресом 0x3E8 и IRQ 5. Очевидно, это расточительное использование ресурсов " "IRQ, так как в принципе возможно запустить оба порта расширительной платы с " "одним IRQ, используя конфигурацию `COM_MULTIPORT`, описанную в предыдущих " "разделах." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:999 msgid "" "Such cheap I/O boards commonly have a 4 by 3 jumper matrix for the COM " "ports, similar to the following:" msgstr "" "Такие недорогие платы ввода-вывода обычно имеют перемычечную матрицу 4x3 для " "COM-портов, подобную следующей:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1008 #, no-wrap msgid "" " o o o *\n" "Port A |\n" " o * o *\n" "Port B |\n" " o * o o\n" "IRQ 2 3 4 5\n" msgstr "" " o o o *\n" "Port A |\n" " o * o *\n" "Port B |\n" " o * o o\n" "IRQ 2 3 4 5\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1012 msgid "" "Shown here is port A wired for IRQ 5 and port B wired for IRQ 3. The IRQ " "columns on your specific board may vary-other boards may supply jumpers for " "IRQs 3, 4, 5, and 7 instead." msgstr "" "Показано, что порт A подключен для IRQ 5, а порт B — для IRQ 3. Столбцы IRQ " "на вашей конкретной плате могут отличаться — другие платы могут " "предоставлять перемычки для IRQ 3, 4, 5 и 7." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1016 msgid "" "One could conclude that wiring both ports for IRQ 3 using a handcrafted wire-" "made jumper covering all three connection points in the IRQ 3 column would " "solve the issue, but no. You cannot duplicate IRQ 3 because the output " "drivers of each UART are wired in a \"totem pole\" fashion, so if one of the " "UARTs drives IRQ 3, the output signal will not be what you would expect. " "Depending on the implementation of the extension board or your motherboard, " "the IRQ 3 line will continuously stay up, or always stay low." msgstr "" "Можно было бы сделать вывод, что подключение обоих портов к IRQ 3 с помощью " "самодельной перемычки, замыкающей все три точки соединения в колонке IRQ 3, " "решит проблему, но это не так. Невозможно дублировать IRQ 3, потому что " "выходные драйверы каждого UART соединены по схеме \"монтажное И\", и если " -"один из UART управляет IRQ 3, выходной сигнал будет не таким, как ожидается. " +"один из UART управляет IRQ 3, выходной сигнал будет не таким как ожидается. " "В зависимости от реализации платы расширения или материнской платы, линия " "IRQ 3 будет постоянно находиться в высоком уровне или всегда оставаться " "низкой." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1020 msgid "" "You need to decouple the IRQ drivers for the two UARTs, so that the IRQ line " "of the board only goes up if (and only if) one of the UARTs asserts a IRQ, " "and stays low otherwise. The solution was proposed by Joerg Wunsch mailto:" "j@ida.interface-business.de[j@ida.interface-business.de]: To solder up a " "wired-or consisting of two diodes (Germanium or Schottky-types strongly " "preferred) and a 1 kOhm resistor. Here is the schematic, starting from the " "4 by 3 jumper field above:" msgstr "" "Вам необходимо разделить драйверы прерываний для двух UART, чтобы линия " "прерывания платы поднималась только тогда (и только тогда), когда один из " "UART вызывает прерывание, и оставалась низкой в противном случае. Решение " "было предложено Йоргом Вуншем mailto:j@ida.interface-business.de[j@ida." "interface-business.de]: припаять монтажную схему \"монтажное ИЛИ\", " "состоящую из двух диодов (предпочтительно германиевых или типа Шоттки) и " "резистора на 1 кОм. Вот схема, начиная с контактного поля 4x3 выше:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1034 #, no-wrap msgid "" " Diode\n" " +---------->|-------+\n" " / |\n" " o * o o | 1 kOhm\n" "Port A +----|######|-------+\n" " o * o o | |\n" "Port B `-------------------+ ==+==\n" " o * o o | Ground\n" " \\ |\n" " +--------->|-------+\n" "IRQ 2 3 4 5 Diode\n" msgstr "" " Diode\n" " +---------->|-------+\n" " / |\n" " o * o o | 1 kOhm\n" "Port A +----|######|-------+\n" " o * o o | |\n" "Port B `-------------------+ ==+==\n" " o * o o | Ground\n" " \\ |\n" " +--------->|-------+\n" "IRQ 2 3 4 5 Diode\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1038 msgid "" "The cathodes of the diodes are connected to a common point, together with a " "1 kOhm pull-down resistor. It is essential to connect the resistor to " "ground to avoid floating of the IRQ line on the bus." msgstr "" "Катоды диодов соединены в общей точке вместе с подтягивающим резистором 1 " "кОм. Важно подключить резистор к земле, чтобы избежать плавания линии IRQ на " "шине." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1041 msgid "" "Now we are ready to configure a kernel. Staying with this example, we would " "configure:" msgstr "Теперь мы готовы настроить ядро. Продолжая этот пример, мы настроим:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1050 #, no-wrap msgid "" "# standard on-board COM1 port\n" "device sio0 at isa? port \"IO_COM1\" flags 0x10\n" "# patched-up multi-I/O extension board\n" "options COM_MULTIPORT\n" "device sio1 at isa? port \"IO_COM2\" flags 0x205\n" "device sio2 at isa? port \"IO_COM3\" flags 0x205 irq 3\n" msgstr "" "# standard on-board COM1 port\n" "device sio0 at isa? port \"IO_COM1\" flags 0x10\n" "# patched-up multi-I/O extension board\n" "options COM_MULTIPORT\n" "device sio1 at isa? port \"IO_COM2\" flags 0x205\n" "device sio2 at isa? port \"IO_COM3\" flags 0x205 irq 3\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1055 msgid "" "Note that the `flags` setting for [.filename]#sio1# and [.filename]#sio2# is " "truly essential; refer to man:sio[4] for details. (Generally, the `2` in " "the \"flags\" attribute refers to [.filename]#sio#`2` which holds the IRQ, " "and you surely want a `5` low nibble.) With kernel verbose mode turned on " "this should yield something similar to this:" msgstr "" "Обратите внимание, что настройка `flags` для [.filename]#sio1# и [." "filename]#sio2# действительно важна; подробности смотрите в man:sio[4]. " "(Обычно `2` в атрибуте \"flags\" относится к [.filename]#sio#`2`, который " "содержит IRQ, и вам наверняка потребуется нижний ниббл `5`.) При включённом " "режиме подробного вывода ядра это должно дать что-то похожее на следующее:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1067 #, no-wrap msgid "" "sio0: irq maps: 0x1 0x11 0x1 0x1\n" "sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa\n" "sio0: type 16550A\n" "sio1: irq maps: 0x1 0x9 0x1 0x1\n" "sio1 at 0x2f8-0x2ff flags 0x205 on isa\n" "sio1: type 16550A (multiport)\n" "sio2: irq maps: 0x1 0x9 0x1 0x1\n" "sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa\n" "sio2: type 16550A (multiport master)\n" msgstr "" "sio0: irq maps: 0x1 0x11 0x1 0x1\n" "sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa\n" "sio0: type 16550A\n" "sio1: irq maps: 0x1 0x9 0x1 0x1\n" "sio1 at 0x2f8-0x2ff flags 0x205 on isa\n" "sio1: type 16550A (multiport)\n" "sio2: irq maps: 0x1 0x9 0x1 0x1\n" "sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa\n" "sio2: type 16550A (multiport master)\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1072 msgid "" "Though [.filename]#/sys/i386/isa/sio.c# is somewhat cryptic with its use of " "the \"irq maps\" array above, the basic idea is that you observe `0x1` in " "the first, third, and fourth place. This means that the corresponding IRQ " "was set upon output and cleared after, which is just what we would expect. " "If your kernel does not display this behavior, most likely there is " "something wrong with your wiring." msgstr "" "Хотя [.filename]#/sys/i386/isa/sio.c# выглядит несколько загадочно из-за " "использования массива \"irq maps\" выше, основная идея заключается в том, " "что вы наблюдаете `0x1` на первой, третьей и четвертой позициях. Это " "означает, что соответствующий IRQ был установлен при выводе и сброшен после, " "что полностью соответствует ожиданиям. Если ваше ядро не демонстрирует такое " "поведение, скорее всего, проблема в вашей разводке." #. type: Title == #: documentation/content/en/articles/serial-uart/_index.adoc:1074 #, no-wrap msgid "Configuring the [.filename]#cy# driver" msgstr "Настройка драйвера [.filename]#cy#" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1077 msgid "_Contributed by Alex Nash. 6 June 1996._" msgstr "_Предоставлено Алексом Нэшем. 6 июня 1996._" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1080 msgid "" "The Cyclades multiport cards are based on the [.filename]#cy# driver instead " "of the usual [.filename]#sio# driver used by other multiport cards. " "Configuration is a simple matter of:" msgstr "" "Многопортовые карты Cyclades основаны на драйвере [.filename]#cy#, а не на " "обычном драйвере [.filename]#sio#, используемом другими многопортовыми " "картами. Настройка сводится к простым действиям:" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1084 msgid "" "Add the [.filename]#cy# device to your kernel configuration (note that your " "irq and iomem settings may differ)." msgstr "" "Добавьте устройство [.filename]#cy# в конфигурацию ядра (обратите внимание, " "что параметры irq и iomem могут отличаться)." #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1088 #, no-wrap msgid "device cy0 at isa? irq 10 iomem 0xd4000 iosiz 0x2000\n" msgstr "device cy0 at isa? irq 10 iomem 0xd4000 iosiz 0x2000\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1090 msgid "Rebuild and install the new kernel." msgstr "Перестройте и установите новый образ ядра." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1091 msgid "" "Make the device nodes by typing (the following example assumes an 8-port " "board):" msgstr "" "Создайте файлы устройств, введя (следующий пример предполагает 8-портовую " "плату):" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1096 #, no-wrap msgid "" "# cd /dev\n" "# for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done\n" msgstr "" "# cd /dev\n" "# for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1099 msgid "" "If appropriate, add dialup entries to [.filename]#/etc/ttys# by duplicating " "serial device (`ttyd`) entries and using `ttyc` in place of `ttyd`. For " "example:" msgstr "" "Если необходимо, добавьте записи для коммутируемого доступа в [.filename]#/" "etc/ttys#, дублируя записи для последовательных устройств (`ttyd`) и " "используя `ttyc` вместо `ttyd`. Например:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1107 #, no-wrap msgid "" "ttyc0 \"/usr/libexec/getty std.38400\" unknown on insecure\n" "ttyc1 \"/usr/libexec/getty std.38400\" unknown on insecure\n" "ttyc2 \"/usr/libexec/getty std.38400\" unknown on insecure\n" "...\n" "ttyc7 \"/usr/libexec/getty std.38400\" unknown on insecure\n" msgstr "" "ttyc0 \"/usr/libexec/getty std.38400\" unknown on insecure\n" "ttyc1 \"/usr/libexec/getty std.38400\" unknown on insecure\n" "ttyc2 \"/usr/libexec/getty std.38400\" unknown on insecure\n" "...\n" "ttyc7 \"/usr/libexec/getty std.38400\" unknown on insecure\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1109 msgid "Reboot with the new kernel." msgstr "Перезагрузитесь с новым ядром." #. type: Title == #: documentation/content/en/articles/serial-uart/_index.adoc:1111 #, no-wrap msgid "Configuring the [.filename]#si# driver" msgstr "Настройка драйвера [.filename]#si#" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1114 msgid "_Contributed by `{nsayer}`. 25 March 1998._" msgstr "_Предоставлено `{nsayer}`. 25 марта 1998._" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1118 msgid "" "The Specialix SI/XIO and SX multiport cards use the [.filename]#si# driver. " "A single machine can have up to 4 host cards. The following host cards are " "supported:" msgstr "" "Специальные мультипортные карты Specialix SI/XIO и SX используют драйвер [." "filename]#si#. На одной машине может быть установлено до 4 хост-карт. " "Поддерживаются следующие хост-карты:" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1120 msgid "ISA SI/XIO host card (2 versions)" msgstr "ISA SI/XIO host card (2 versions)" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1121 msgid "EISA SI/XIO host card" msgstr "EISA SI/XIO host card" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1122 msgid "PCI SI/XIO host card" msgstr "PCI SI/XIO host card" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1123 msgid "ISA SX host card" msgstr "ISA SX host card" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1124 msgid "PCI SX host card" msgstr "PCI SX host card" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1130 msgid "" "Although the SX and SI/XIO host cards look markedly different, their " "functionality are basically the same. The host cards do not use I/O " "locations, but instead require a 32K chunk of memory. The factory " "configuration for ISA cards places this at `0xd0000-0xd7fff`. They also " "require an IRQ. PCI cards will, of course, auto-configure themselves." msgstr "" "Хотя хост-карты SX и SI/XIO выглядят заметно по-разному, их функциональность " "практически одинакова. Хост-карты не используют порты ввода-вывода, а вместо " "этого требуют 32К сегмента памяти. Заводская конфигурация для карт ISA " "размещает этот сегмент по адресу `0xd0000-0xd7fff`. Также им требуется IRQ. " "Карты PCI, разумеется, настраиваются автоматически." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1134 msgid "" "You can attach up to 4 external modules to each host card. The external " "modules contain either 4 or 8 serial ports. They come in the following " "varieties:" msgstr "" "Вы можете подключить до 4 внешних модулей к каждой карте хоста. Внешние " "модули содержат либо 4, либо 8 последовательных портов. Они бывают следующих " "видов:" #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1136 msgid "SI 4 or 8 port modules. Up to 57600 bps on each port supported." msgstr "" "Модули SI на 4 или 8 портов. Поддерживается скорость до 57600 бит/с на " "каждом порту." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1137 msgid "" "XIO 8 port modules. Up to 115200 bps on each port supported. One type of XIO " "module has 7 serial and 1 parallel port." msgstr "" "XIO 8-портовые модули. Поддерживается скорость до 115200 бит/с на каждом " "порту. Один из типов модулей XIO имеет 7 последовательных и 1 параллельный " "порт." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1138 msgid "" "SXDC 8 port modules. Up to 921600 bps on each port supported. Like XIO, a " "module is available with one parallel port as well." msgstr "" "Модули SXDC с 8 портами. Поддерживается скорость до 921600 бит/с на каждом " "порту. Как и в случае с XIO, доступен модуль с одним параллельным портом." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1140 msgid "" "To configure an ISA host card, add the following line to your kernel " "configuration file, changing the numbers as appropriate:" msgstr "" "Для настройки карты хоста ISA добавьте следующую строку в файл конфигурации " "ядра, изменив числа по мере необходимости:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1144 #, no-wrap msgid "device si0 at isa? iomem 0xd0000 irq 11\n" msgstr "device si0 at isa? iomem 0xd0000 irq 11\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1147 msgid "" "Valid IRQ numbers are 9, 10, 11, 12 and 15 for SX ISA host cards and 11, 12 " "and 15 for SI/XIO ISA host cards." msgstr "" "Допустимые номера IRQ: 9, 10, 11, 12 и 15 для SX ISA host cards и 11, 12 и " "15 для SI/XIO ISA host cards." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1149 msgid "To configure an EISA or PCI host card, use this line:" msgstr "Для настройки карты EISA или PCI используйте следующую строку:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1153 #, no-wrap msgid "device si0\n" msgstr "device si0\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1156 msgid "" "After adding the configuration entry, rebuild and install your new kernel." msgstr "" "После добавления записи конфигурации пересоберите и установите свое новое " "ядро." #. type: delimited block = 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1160 msgid "" "The following step, is not necessary if you are using man:devfs[5] in " "FreeBSD 5._X_." msgstr "" "Следующий шаг не обязателен, если вы используете man:devfs[5] в FreeBSD 5." "_X_." #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1165 msgid "" "After rebooting with the new kernel, you need to make the device nodes in [." "filename]#/dev#. The [.filename]#MAKEDEV# script will take care of this for " "you. Count how many total ports you have and type:" msgstr "" "После перезагрузки с новым ядром необходимо создать файлы устройств в [." "filename]#/dev#. Скрипт [.filename]#MAKEDEV# выполнит эту задачу за вас. " "Подсчитайте общее количество портов и введите:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1170 #, no-wrap msgid "" "# cd /dev\n" "# ./MAKEDEV ttyAnn cuaAnn\n" msgstr "" "# cd /dev\n" "# ./MAKEDEV ttyAnn cuaAnn\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1173 msgid "(where _nn_ is the number of ports)" msgstr "(где _nn_ — количество портов)" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1175 msgid "" "If you want login prompts to appear on these ports, you will need to add " "lines like this to [.filename]#/etc/ttys#:" msgstr "" "Если вы хотите, чтобы приглашения к входу отображались на этих портах, вам " "нужно добавить такие строки в [.filename]#/etc/ttys#:" #. type: delimited block . 4 #: documentation/content/en/articles/serial-uart/_index.adoc:1179 #, no-wrap msgid "ttyA01 \"/usr/libexec/getty std.9600\" vt100 on insecure\n" msgstr "ttyA01 \"/usr/libexec/getty std.9600\" vt100 on insecure\n" #. type: Plain text #: documentation/content/en/articles/serial-uart/_index.adoc:1182 msgid "" "Change the terminal type as appropriate. For modems, `dialup` or `unknown` " "is fine." msgstr "" "Измените тип терминала по необходимости. Для модемов подойдут `dialup` или " "`unknown`." diff --git a/documentation/content/ru/articles/solid-state/_index.adoc b/documentation/content/ru/articles/solid-state/_index.adoc index ee80d558a0..663594956a 100644 --- a/documentation/content/ru/articles/solid-state/_index.adoc +++ b/documentation/content/ru/articles/solid-state/_index.adoc @@ -1,266 +1,266 @@ --- authors: - author: 'John Kozubik' email: john@kozubik.com copyright: '2001 - 2021 The FreeBSD Documentation Project' description: 'Использование твердотельных накопителей (SSD) в FreeBSD' tags: ["Solid State", "embedded", "FreeBSD"] title: 'FreeBSD и твердотельные устройства (SSD)' trademarks: ["freebsd", "general"] --- = FreeBSD и твердотельные устройства (SSD) :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/solid-state/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Аннотация В этой статье описывается использование твердотельных дисковых устройств для создания встраиваемых систем на основе FreeBSD. -Встраиваемые системы имеют преимущество в повышенной надёжности по причине отсутствия в них движущихся частей (жестких дисков). Однако, следует принять во внимание, что системе, как правило, доступно очень малое дисковое пространство и ограниченный объем запоминающего устройства. +Встраиваемые системы имеют преимущество в повышенной надёжности по причине отсутствия в них движущихся частей (жёстких дисков). Однако, следует принять во внимание, что системе, как правило, доступно очень малое дисковое пространство и ограниченный объём запоминающего устройства. К отдельно рассматриваемым вопросам относятся типы и характеристики твердотельных носителей, подходящих для использования в качестве дисков во FreeBSD, параметры ядра, которые представляют интерес в таких условиях, механизмы [.filename]#rc.initdiskless#, автоматизирующие инициализацию таких систем и удовлетворяющие требованиям файловых систем, доступных только для чтения, а также построение файловых систем с нуля. Статья заканчивается описанием некоторых общих стратегий для случаев малых систем FreeBSD и работ в режиме только для чтения. ''' toc::[] [[intro]] == Твердотельные дисковые устройства -Эта статья будет ограничиваться рассмотрением твердотельных дисковых устройств, которые делаются на основе флеш-памяти. Флеш-память является твердотельным (здесь нет движущихся частей) запоминающим устройством, которое является энергонезависимым (данные остаются в памяти даже после отключения всех источников питания). Флеш-память может быть нечувствительной к сильным физическим воздействиям и достаточно быстра (решения на основе флеш-памяти, описываемые в этой статье, гораздо медленнее, чем диски EIDE для операций записи, и гораздо быстрее их в случае выполнения операций чтения). Одним из очень важных свойств флеш-памяти, различные варианты которого будут рассмотрены далее в этой статье, является то, что каждый сектор имеет ограниченные возможности по перезаписыванию. Вы можете только записывать, стирать и снова записывать на сектор флеш-памяти определенное количество раз до того, как сектор станет полностью неработоспособным. Хотя многие продукты на основе флеш-памяти автоматически перенаправляют испорченные блоки, а некоторые даже распределяют операции записи по всему модулю, фактом является наличие ограничения на количество операций записи, которые могут выполняться с устройством. Современные модули имеют характеристики от 1,000,000 до 10,000,000 циклов записи на сектор. Эти характеристики могут зависеть от температуры рабочей среды. +Эта статья будет ограничиваться рассмотрением твердотельных дисковых устройств, которые делаются на основе флеш-памяти. Флеш-память является твердотельным (здесь нет движущихся частей) запоминающим устройством, которое является энергонезависимым (данные остаются в памяти даже после отключения всех источников питания). Флеш-память может быть нечувствительной к сильным физическим воздействиям и достаточно быстра (решения на основе флеш-памяти, описываемые в этой статье, гораздо медленнее, чем диски EIDE для операций записи, и гораздо быстрее их в случае выполнения операций чтения). Одним из очень важных свойств флеш-памяти, различные варианты которого будут рассмотрены далее в этой статье, является то, что каждый сектор имеет ограниченные возможности по перезаписыванию. Вы можете только записывать, стирать и снова записывать на сектор флеш-памяти определённое количество раз до того, как сектор станет полностью неработоспособным. Хотя многие продукты на основе флеш-памяти автоматически перенаправляют испорченные блоки, а некоторые даже распределяют операции записи по всему модулю, фактом является наличие ограничения на количество операций записи, которые могут выполняться с устройством. Современные модули имеют характеристики от 1,000,000 до 10,000,000 циклов записи на сектор. Эти характеристики могут зависеть от температуры рабочей среды. В частности, мы обсудим компактные модули флеш-памяти, совместимые со стандартом ATA, которые стали весьма популярными в качестве носителя данных для цифровых камер. Особый интерес представляет тот факт, что они соответствуют шине IDE по контактам и совместимы с набором команд ATA. Таким образом, при помощи очень простого и дешевого адаптера такие устройства могут подключаться непосредственно к шине IDE компьютера. Если поступить таким образом, то такие операционные системы, как FreeBSD, распознают диск как обычный винчестер (весьма маленький). Существуют и другие решения для твердотельных дисков, но их стоимость, безвестность и сравнительная сложность использования выводят их за рамки этой статьи. [[kernel]] == Параметры ядра Для тех, кто создает встраиваемую систему FreeBSD, интерес представляют несколько параметров ядра. -Все встраиваемые системы FreeBSD, которые используют флеш-память в качестве системного диска, заинтересованы в использовании дисков в памяти и файловых систем в памяти. Из-за ограниченного количества циклов записи, которые можно выполнить с флеш-памятью, диск и файловые системы на нем будут, скорее всего, монтироваться в режиме доступа только для чтения. В таком случае файловые системы типа [.filename]#/tmp# и [.filename]#/var# монтируются как файловые системы в памяти для того, чтобы позволить системе создать журналы и обновить счетчики и временные файлы. Файловые системы в памяти являются критическим компонентом успешной работы FreeBSD на твердотельных устройствах. +Все встраиваемые системы FreeBSD, которые используют флеш-память в качестве системного диска, заинтересованы в использовании дисков в памяти и файловых систем в памяти. Из-за ограниченного количества циклов записи, которые можно выполнить с флеш-памятью, диск и файловые системы на нём будут, скорее всего, монтироваться в режиме доступа только для чтения. В таком случае файловые системы типа [.filename]#/tmp# и [.filename]#/var# монтируются как файловые системы в памяти для того, чтобы позволить системе создать журналы и обновить счетчики и временные файлы. Файловые системы в памяти являются критическим компонентом успешной работы FreeBSD на твердотельных устройствах. Вы должны удостовериться, что в конфигурационном файле вашего ядра присутствуют следующие строки: [.programlisting] .... options MD_ROOT # md device usable as a potential root device .... [[ro-fs]] == Подсистема `rc` и файловые системы в режиме только чтения Инициализация встраиваемой системы 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] .... varsize=8192 .... Запомните, что по умолчанию это значение указано в секторах. Факт использования файловой системы [.filename]#/var# в режиме чтения и записи является важным признаком, так как раздел [.filename]#/# (и любые другие разделы, которые могут находиться на флеш-носителе) должен монтироваться в режиме только для чтения. Вспомните, что в разделе crossref:solid-state[intro, Твердотельные дисковые устройства] мы касались ограничений флеш-памяти - особенно ограничений, касающихся возможностей записи. Важно не монтировать файловые системы на флеш-носителях в режимах чтения и записи, и важность отказа от файла подкачки не может быть переоценена. Файл подкачки на загруженной системе может пережечь кусок флеш-носителя менее чем за год. Частое журналирование и создание временных файлов приводят к тому же результату. Поэтому, кроме удаления записи `swap` из вашего файла [.filename]#/etc/fstab#, вы должны также изменить поле параметров каждой файловой системы на `ro` таким образом: [.programlisting] .... # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs ro 1 1 .... В результате этих изменений в среднестатистической системе несколько приложений немедленно перестанут работать. Например, cron не будет нормально запускаться в результате отсутствия таблиц для него в каталоге [.filename]#/var#, созданном [.filename]#/etc/rc.d/var#, а syslog и dhcp будут испытывать проблемы из-за доступа файловой системы только для чтения, а также отсутствия записей в [.filename]#/var#, который был создан скриптом [.filename]#/etc/rc.d/var#. Хотя эти проблемы являются временными и обсуждаются вместе с решением проблем с запуском распространённых программных пакетов в разделе crossref:solid-state[strategies, Стратегии работы с системой для случаев небольших и доступных только для чтения файловых систем]. Важно помнить, что файловая система, которая была смонтирована только для чтения при помощи файла [.filename]#/etc/fstab#, в любой момент может быть сделана доступной по чтению и записи выдачей команды: [source, shell] .... # /sbin/mount -uw partition .... и может быть возвращена к режиму доступа только для чтения по такой команде: [source, shell] .... # /sbin/mount -ur partition .... == Создание файловой системы с нуля -Так как совместимые с ATA компактные флеш-карты распознаются во FreeBSD как обычные жесткие диски IDE, то теоретически вы можете установить FreeBSD по сети при помощи дискет kern и mfsroot или с компакт-диска. +Так как совместимые с ATA компактные флеш-карты распознаются во FreeBSD как обычные жёсткие диски IDE, то теоретически вы можете установить FreeBSD по сети при помощи дискет kern и mfsroot или с компакт-диска. Однако даже маленькая установка FreeBSD при помощи обычных процедур установки может привести к созданию системы размером, превышающим 200 мегабайт. Так как большинство людей используют устройства флеш-памяти меньшего размера (128 мегабайт считается весьма большим - 32 или даже 16 мегабайт используются гораздо чаще), то установка обычным образом не подходит-просто на диске нет места даже для самой минимальной установки. -Самым простым способом обойти это ограничение на объем является установка FreeBSD обычным образом на обычный жесткий диск. После окончания установки, обрежьте операционную систему до размера, который помещается на ваш флеш-носитель, а затем полностью заархивируйте файловую систему. Следующие шаги поведут вас через процесс подготовки части флеш-памяти для вашей заархивированной файловой системы. Запомните, что из-за того, что обычная установка не выполнялась, такие операции, как разбиение на разделы, разметка, создание файловой системы и так далее должны быть выполнены вручную. Кроме дискет kern и mfsroot вам также нужно воспользоваться дискетой fixit. +Самым простым способом обойти это ограничение на объём является установка FreeBSD обычным образом на обычный жёсткий диск. После окончания установки, обрежьте операционную систему до размера, который помещается на ваш флеш-носитель, а затем полностью заархивируйте файловую систему. Следующие шаги поведут вас через процесс подготовки части флеш-памяти для вашей заархивированной файловой системы. Запомните, что из-за того, что обычная установка не выполнялась, такие операции, как разбиение на разделы, разметка, создание файловой системы и так далее должны быть выполнены вручную. Кроме дискет kern и mfsroot вам также нужно воспользоваться дискетой fixit. [.procedure] ==== . Разбиение вашего флеш-носителя на разделы + -После загрузки при помощи дискет kern и mfsroot, выберите пункт `custom` из меню установки. Из следующего пункта меню выберите `partition`. В меню работы с разделами вы должны удалить все существующие разделы при помощи клавиши kbd:[d]. После удаления всех имеющихся разделов создайте раздел при помощи клавиши kbd:[c] и согласитесь с предлагаемым по умолчанию размером раздела. Когда вы будете опрошены на предмет типа раздела, удостоверьтесь, что значение типа равно `165`. Теперь запишите эту таблицу разделов на диск, нажав клавишу kbd:[w] (на этом экране эта опция скрыта). Если вы используете компактную флеш-карту, совместимую с ATA, вы должны выбрать FreeBSD Boot Manager. Теперь нажмите клавишу kbd:[q] для выхода из меню работы с разделами. Должно быть выдано еще раз меню для выбора менеджера загрузки - повторите то, что вы выбирали ранее. +После загрузки при помощи дискет kern и mfsroot, выберите пункт `custom` из меню установки. Из следующего пункта меню выберите `partition`. В меню работы с разделами вы должны удалить все существующие разделы при помощи клавиши kbd:[d]. После удаления всех имеющихся разделов создайте раздел при помощи клавиши kbd:[c] и согласитесь с предлагаемым по умолчанию размером раздела. Когда вы будете опрошены на предмет типа раздела, удостоверьтесь, что значение типа равно `165`. Теперь запишите эту таблицу разделов на диск, нажав клавишу kbd:[w] (на этом экране эта опция скрыта). Если вы используете компактную флеш-карту, совместимую с ATA, вы должны выбрать FreeBSD Boot Manager. Теперь нажмите клавишу kbd:[q] для выхода из меню работы с разделами. Должно быть выдано ещё раз меню для выбора менеджера загрузки - повторите то, что вы выбирали ранее. . Создание файловых систем на вашем устройстве флеш-памяти + Выйдите из меню установки custom, и из главного меню установки выберите пункт `fixit`. После входа в режим работы fixit, введите следующую команду: + [source, shell] .... # disklabel -e /dev/ad0c .... + В этот момент вы войдете в редактор vi из-под команды disklabel. Затем, вам нужно добавить строку `a:` в конце файла. Эта строка `a:` должна выглядеть примерно так: + [.programlisting] .... a: 123456 0 4.2BSD 0 0 .... + Здесь _123456_ является числом, в точности совпадающим с тем, что характеризует размер имеющейся записи для `c:`. В общем, вы копируете существующую строку для `c:` для строки `a:`, не забывая определить fstype как `4.2BSD`. Сохраните файл и завершите редактирование. + [source, shell] .... # disklabel -B -r /dev/ad0c # newfs /dev/ad0a .... . Размещение вашей файловой системы на флеш-носителе + Смонтируйте только что подготовленный флеш-носитель: + [source, shell] .... # mount /dev/ad0a /flash .... + Подключите эту машину к сети, чтобы можно было перенести наш tar-файл и распаковать его в файловую систему на флеш-носителе. Вот пример того, как это можно сделать: + [source, shell] .... # ifconfig xl0 192.168.0.10 netmask 255.255.255.0 # route add default 192.168.0.1 .... + -Теперь, когда машина находится в сети, перепишите ваш tar-файл. Здесь вы можете столкнуться с некоторой проблемой - если объем вашей флеш-памяти равен, к примеру, 128 мегабайтам, а ваш tar-файл превышает 64 мегабайта, то вы не можете одновременно разместить tar-файл на флеш-носителе и распаковать его - вам не хватит места. Одним из решений этой проблемы, если вы используете FTP, является распаковка файла во время его передачи по FTP. Если вы передаёте файл именно так, то вы никогда не получите на диске одновременно архивный файл и его содержимое: +Теперь, когда машина находится в сети, перепишите ваш tar-файл. Здесь вы можете столкнуться с некоторой проблемой - если объём вашей флеш-памяти равен, к примеру, 128 мегабайтам, а ваш tar-файл превышает 64 мегабайта, то вы не можете одновременно разместить tar-файл на флеш-носителе и распаковать его - вам не хватит места. Одним из решений этой проблемы, если вы используете FTP, является распаковка файла во время его передачи по FTP. Если вы передаёте файл именно так, то вы никогда не получите на диске одновременно архивный файл и его содержимое: + [source, shell] .... ftp> get tarfile.tar "| tar xvf -" .... + Если ваш файл обработан утилитой gzip, вы также можете этого добиться: + [source, shell] .... ftp> get tarfile.tar "| zcat | tar xvf -" .... + После того, как вы получили содержимое вашей заархивированной файловой системы на файловой системе флеш-памяти, вы можете размонтировать флеш-память и выполнить перезагрузку: + [source, shell] .... # cd / # umount /flash # exit .... + При условии, что вы правильно настроили файловую систему при её создании на обычном жёстком диске (с монтированием файловых систем в режиме только для чтения и с необходимыми опциями, встроенными в ядро), ваша встраиваемая система FreeBSD теперь должна успешно загружаться. ==== [[strategies]] == Стратегии работы с системой для случаев небольших и доступных только для чтения файловых систем В разделе crossref:solid-state[ro-fs, Подсистема `rc` и файловые системы в режиме только чтения] было указано, что файловая система [.filename]#/var#, создаваемая скриптом [.filename]#/etc/rc.d/var#, и наличие корневой файловой системы, доступной только для чтения, приводят к проблемам при работе многих распространённых программных пакетов, используемых во FreeBSD. В этой статье будут даны рекомендации по настройке нормальной работы cron и syslog, установке портов и веб-сервера Apache. === 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]#/etc/rc.initdiskless# для копирования этих cron-таблиц в каталог [.filename]#/var/cron/tabs# после его создания во время инициализации системы. Вам может также потребоваться добавить строку, которая изменяет режимы доступа и права на каталоги, которые вы создали, и на файлы, которые вы скопировали в скрипте [.filename]#/etc/rc.initdiskless#. === Syslog В файле [.filename]#syslog.conf# задано местоположение некоторых файлов протоколов, которые имеются в каталоге [.filename]#/var/log#. Эти файлы не создаются скриптом [.filename]#/etc/rc.d/var# во время инициализации системы. Поэтому где-нибудь в скрипте [.filename]#/etc/rc.d/var#, после секции, создающей каталоги в [.filename]#/var#, вам нужно добавить нечто вроде следующего: [source, shell] .... # touch /var/log/security /var/log/maillog /var/log/cron /var/log/messages # chmod 0644 /var/log/* .... === Установка портов Перед тем, как обсудить изменения, которые нужно сделать для успешного использования дерева портов, необходимо напомнить о том, что ваши файловые системы на флеш-носителях доступны только для чтения. Поэтому вам нужно временно монтировать их в режиме чтения и записи, используя параметры командной строки, как это показано в crossref:solid-state[ro-fs, Подсистема `rc` и файловые системы в режиме только чтения]. Вы всегда должны перемонтировать эти файловые системы в режим только для чтения после окончания работ - излишние записи на флеш носитель могут значительно сократить его срок эксплуатации. Чтобы можно было войти в каталог с портами и успешно выполнить команду make `install`, необходимо создать каталог для пакетов в файловой системе, не располагающейся в памяти, где будут храниться пакеты между перезагрузками. Так как для установки пакета в любом случае требуется монтирование ваших файловых систем для чтения и записи, имеет смысл выделить область флеш-носителя также и для записи информации о пакете. Прежде всего создайте каталог с базой данных о пакетах. Обычно это каталог [.filename]#/var/db/pkg#, но мы не можем разместить базу именно здесь, так как она исчезнет после перезагрузки системы. [source, shell] .... # mkdir /etc/pkg .... Теперь в скрипт [.filename]#/etc/rc.d/var# добавьте строку, которая связывает каталог [.filename]#/etc/pkg# с [.filename]#/var/db/pkg#. Например: [source, shell] .... # ln -s /etc/pkg /var/db/pkg .... Теперь каждый раз при монтировании ваших файловых систем для чтения и записи и установки пакета, команда make `install` будет работать, а информация о пакете будет успешно записана в каталог [.filename]#/etc/pkg# (так как файловая система будет в это время смонтирована для чтения и записи), который всегда будет доступным операционной системе как [.filename]#/var/db/pkg#. === Веб-сервер Apache [NOTE] ==== Шаги, описанные в этой части статьи, необходимо выполнить лишь в том случае, если Apache настроен сохранять свой pid или журнал вне каталога [.filename]#/var#. С настройками по умолчанию Apache формирует свой pid файл в [.filename]#/var/run/httpd.pid#, а файлы журналов - в [.filename]#/var/log#. ==== Далее в статье подразумевается, что Apache сохраняет свои файлы журналов в каталог [.filename]#apache_log_dir# вне каталога [.filename]#/var#. Когда этот каталог расположен на файловой системе, смонтированной в режиме только для чтения, Apache не сможет сохранять файлы журналов, что в свою очередь может вызывать проблемы в работе веб-сервера. В таком случае необходимо добавить новый каталог к списку каталогов из [.filename]#/etc/rc.d/var# для их создания в каталоге [.filename]#/var# и связать [.filename]#apache_log_dir# с [.filename]#/var/log/apache#. Нужно также задать права доступа и владельца нового каталога. Сначала добавьте каталог `log/apache` к списку каталогов, создаваемых скриптом [.filename]#/etc/rc.d/var#. Затем добавьте в скрипт [.filename]#/etc/rc.d/var# после секции создания каталогов такие команды: [source, shell] .... # chmod 0774 /var/log/apache # chown nobody:nobody /var/log/apache .... И наконец, удалите существующий каталог [.filename]#apache_install/logs# и замените его ссылкой: [source, shell] .... # rm -rf apache_log_dir # ln -s /var/log/apache apache_log_dir .... diff --git a/documentation/content/ru/articles/solid-state/_index.po b/documentation/content/ru/articles/solid-state/_index.po index 3387b5de09..afa4125ead 100644 --- a/documentation/content/ru/articles/solid-state/_index.po +++ b/documentation/content/ru/articles/solid-state/_index.po @@ -1,904 +1,904 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. # Vladlen Popolitov , 2025. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2024-12-29 08:30-0500\n" -"PO-Revision-Date: 2025-11-20 04:45+0000\n" +"PO-Revision-Date: 2025-11-25 04:45+0000\n" "Last-Translator: Vladlen Popolitov \n" "Language-Team: Russian \n" "Language: ru\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && " "n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" "X-Generator: Weblate 4.17\n" #. type: YAML Front Matter: description #: documentation/content/en/articles/solid-state/_index.adoc:1 #, no-wrap msgid "The use of solid state disk devices in FreeBSD" msgstr "Использование твердотельных накопителей (SSD) в FreeBSD" #. type: Title = #: documentation/content/en/articles/solid-state/_index.adoc:1 #: documentation/content/en/articles/solid-state/_index.adoc:12 #, no-wrap msgid "FreeBSD and Solid State Devices" msgstr "FreeBSD и твердотельные устройства (SSD)" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:45 msgid "Abstract" msgstr "Аннотация" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:47 msgid "" "This article covers the use of solid state disk devices in FreeBSD to create " "embedded systems." msgstr "" "В этой статье описывается использование твердотельных дисковых устройств для " "создания встраиваемых систем на основе FreeBSD." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:50 msgid "" "Embedded systems have the advantage of increased stability due to the lack " "of integral moving parts (hard drives). Account must be taken, however, for " "the generally low disk space available in the system and the durability of " "the storage medium." msgstr "" "Встраиваемые системы имеют преимущество в повышенной надёжности по причине " -"отсутствия в них движущихся частей (жестких дисков). Однако, следует принять " +"отсутствия в них движущихся частей (жёстких дисков). Однако, следует принять " "во внимание, что системе, как правило, доступно очень малое дисковое " -"пространство и ограниченный объем запоминающего устройства." +"пространство и ограниченный объём запоминающего устройства." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:53 msgid "" "Specific topics to be covered include the types and attributes of solid " "state media suitable for disk use in FreeBSD, kernel options that are of " "interest in such an environment, the [.filename]#rc.initdiskless# mechanisms " "that automate the initialization of such systems and the need for read-only " "filesystems, and building filesystems from scratch. The article will " "conclude with some general strategies for small and read-only FreeBSD " "environments." msgstr "" "К отдельно рассматриваемым вопросам относятся типы и характеристики " "твердотельных носителей, подходящих для использования в качестве дисков во " "FreeBSD, параметры ядра, которые представляют интерес в таких условиях, " "механизмы [.filename]#rc.initdiskless#, автоматизирующие инициализацию таких " "систем и удовлетворяющие требованиям файловых систем, доступных только для " "чтения, а также построение файловых систем с нуля. Статья заканчивается " "описанием некоторых общих стратегий для случаев малых систем FreeBSD и работ " "в режиме только для чтения." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:55 msgid "'''" msgstr "'''" #. type: Title == #: documentation/content/en/articles/solid-state/_index.adoc:59 #, no-wrap msgid "Solid State Disk Devices" msgstr "Твердотельные дисковые устройства" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:69 msgid "" "The scope of this article will be limited to solid state disk devices made " "from flash memory. Flash memory is a solid state memory (no moving parts) " "that is non-volatile (the memory maintains data even after all power sources " "have been disconnected). Flash memory can withstand tremendous physical " "shock and is reasonably fast (the flash memory solutions covered in this " "article are slightly slower than a EIDE hard disk for write operations, and " "much faster for read operations). One very important aspect of flash " "memory, the ramifications of which will be discussed later in this article, " "is that each sector has a limited rewrite capacity. You can only write, " "erase, and write again to a sector of flash memory a certain number of times " "before the sector becomes permanently unusable. Although many flash memory " "products automatically map bad blocks, and although some even distribute " "write operations evenly throughout the unit, the fact remains that there " "exists a limit to the amount of writing that can be done to the device. " "Competitive units have between 1,000,000 and 10,000,000 writes per sector in " "their specification. This figure varies due to the temperature of the " "environment." msgstr "" "Эта статья будет ограничиваться рассмотрением твердотельных дисковых " "устройств, которые делаются на основе флеш-памяти. Флеш-память является " "твердотельным (здесь нет движущихся частей) запоминающим устройством, " "которое является энергонезависимым (данные остаются в памяти даже после " "отключения всех источников питания). Флеш-память может быть нечувствительной " "к сильным физическим воздействиям и достаточно быстра (решения на основе " "флеш-памяти, описываемые в этой статье, гораздо медленнее, чем диски EIDE " "для операций записи, и гораздо быстрее их в случае выполнения операций " "чтения). Одним из очень важных свойств флеш-памяти, различные варианты " "которого будут рассмотрены далее в этой статье, является то, что каждый " "сектор имеет ограниченные возможности по перезаписыванию. Вы можете только " -"записывать, стирать и снова записывать на сектор флеш-памяти определенное " +"записывать, стирать и снова записывать на сектор флеш-памяти определённое " "количество раз до того, как сектор станет полностью неработоспособным. Хотя " "многие продукты на основе флеш-памяти автоматически перенаправляют " "испорченные блоки, а некоторые даже распределяют операции записи по всему " "модулю, фактом является наличие ограничения на количество операций записи, " "которые могут выполняться с устройством. Современные модули имеют " "характеристики от 1,000,000 до 10,000,000 циклов записи на сектор. Эти " "характеристики могут зависеть от температуры рабочей среды." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:74 msgid "" "Specifically, we will be discussing ATA compatible compact-flash units, " "which are quite popular as storage media for digital cameras. Of particular " "interest is the fact that they pin out directly to the IDE bus and are " "compatible with the ATA command set. Therefore, with a very simple and low-" "cost adaptor, these devices can be attached directly to an IDE bus in a " "computer. Once implemented in this manner, operating systems such as " "FreeBSD see the device as a normal hard disk (albeit small)." msgstr "" "В частности, мы обсудим компактные модули флеш-памяти, совместимые со " "стандартом ATA, которые стали весьма популярными в качестве носителя данных " "для цифровых камер. Особый интерес представляет тот факт, что они " "соответствуют шине IDE по контактам и совместимы с набором команд ATA. Таким " "образом, при помощи очень простого и дешевого адаптера такие устройства " "могут подключаться непосредственно к шине IDE компьютера. Если поступить " "таким образом, то такие операционные системы, как FreeBSD, распознают диск " "как обычный винчестер (весьма маленький)." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:76 msgid "" "Other solid state disk solutions do exist, but their expense, obscurity, and " "relative unease of use places them beyond the scope of this article." msgstr "" "Существуют и другие решения для твердотельных дисков, но их стоимость, " "безвестность и сравнительная сложность использования выводят их за рамки " "этой статьи." #. type: Title == #: documentation/content/en/articles/solid-state/_index.adoc:78 #, no-wrap msgid "Kernel Options" msgstr "Параметры ядра" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:81 msgid "" "A few kernel options are of specific interest to those creating an embedded " "FreeBSD system." msgstr "" "Для тех, кто создает встраиваемую систему FreeBSD, интерес представляют " "несколько параметров ядра." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:86 msgid "" "All embedded FreeBSD systems that use flash memory as system disk will be " "interested in memory disks and memory filesystems. As a result of the " "limited number of writes that can be done to flash memory, the disk and the " "filesystems on the disk will most likely be mounted read-only. In this " "environment, filesystems such as [.filename]#/tmp# and [.filename]#/var# are " "mounted as memory filesystems to allow the system to create logs and update " "counters and temporary files. Memory filesystems are a critical component " "to a successful solid state FreeBSD implementation." msgstr "" "Все встраиваемые системы FreeBSD, которые используют флеш-память в качестве " "системного диска, заинтересованы в использовании дисков в памяти и файловых " "систем в памяти. Из-за ограниченного количества циклов записи, которые можно " -"выполнить с флеш-памятью, диск и файловые системы на нем будут, скорее " +"выполнить с флеш-памятью, диск и файловые системы на нём будут, скорее " "всего, монтироваться в режиме доступа только для чтения. В таком случае " "файловые системы типа [.filename]#/tmp# и [.filename]#/var# монтируются как " "файловые системы в памяти для того, чтобы позволить системе создать журналы " "и обновить счетчики и временные файлы. Файловые системы в памяти являются " "критическим компонентом успешной работы FreeBSD на твердотельных устройствах." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:88 msgid "" "You should make sure the following lines exist in your kernel configuration " "file:" msgstr "" "Вы должны удостовериться, что в конфигурационном файле вашего ядра " "присутствуют следующие строки:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:92 #, no-wrap msgid "options MD_ROOT # md device usable as a potential root device\n" msgstr "" "options MD_ROOT # md device usable as a potential root " "device\n" #. type: Title == #: documentation/content/en/articles/solid-state/_index.adoc:95 #, no-wrap msgid "The `rc` Subsystem and Read-Only Filesystems" msgstr "Подсистема `rc` и файловые системы в режиме только чтения" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:98 msgid "" "The post-boot initialization of an embedded FreeBSD system is controlled by " "[.filename]#/etc/rc.initdiskless#." msgstr "" "Инициализация встраиваемой системы FreeBSD после загрузки управляется [." "filename]#/etc/rc.initdiskless#." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:102 msgid "" "[.filename]#/etc/rc.d/var# mounts [.filename]#/var# as a memory filesystem, " "makes a configurable list of directories in [.filename]#/var# with the man:" "mkdir[1] command, and changes modes on some of those directories. In the " "execution of [.filename]#/etc/rc.d/var#, one other [.filename]#rc.conf# " "variable comes into play - `varsize`. A [.filename]#/var# partition is " "created by [.filename]#/etc/rc.d/var# based on the value of this variable in " "[.filename]#rc.conf#:" msgstr "" "[.filename]#/etc/rc.d/var# монтирует [.filename]#/var# как файловую систему " "в памяти, создает указываемый список каталогов в [.filename]#/var# при " "помощи команды man:mkdir[1], изменяет режимы доступа на некоторые из этих " "каталогов. В процессе выполнения [.filename]#/etc/rc.d/var# задействуется " -"еще одна переменная [.filename]#rc.conf# - `varsize`. Скрипт [.filename]#/" +"ещё одна переменная [.filename]#rc.conf# - `varsize`. Скрипт [.filename]#/" "etc/rc.d/var# создает раздел [.filename]#/var# на основе значения этой " "переменной из [.filename]#rc.conf#:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:106 #, no-wrap msgid "varsize=8192\n" msgstr "varsize=8192\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:109 msgid "Remember that this value is in sectors by default." msgstr "Запомните, что по умолчанию это значение указано в секторах." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:116 msgid "" "The fact that [.filename]#/var# is a read-write filesystem is an important " "distinction, as the [.filename]#/# partition (and any other partitions you " "may have on your flash media) should be mounted read-only. Remember that in " "crossref:solid-state[intro, Solid State Disk Devices] we detailed the " "limitations of flash memory - specifically the limited write capability. " "The importance of not mounting filesystems on flash media read-write, and " "the importance of not using a swap file, cannot be overstated. A swap file " "on a busy system can burn through a piece of flash media in less than one " "year. Heavy logging or temporary file creation and destruction can do the " "same. Therefore, in addition to removing the `swap` entry from your [." "filename]#/etc/fstab#, you should also change the Options field for each " "filesystem to `ro` as follows:" msgstr "" "Факт использования файловой системы [.filename]#/var# в режиме чтения и " "записи является важным признаком, так как раздел [.filename]#/# (и любые " "другие разделы, которые могут находиться на флеш-носителе) должен " "монтироваться в режиме только для чтения. Вспомните, что в разделе crossref" ":solid-state[intro, Твердотельные дисковые устройства] мы касались " "ограничений флеш-памяти - особенно ограничений, касающихся возможностей " "записи. Важно не монтировать файловые системы на флеш-носителях в режимах " "чтения и записи, и важность отказа от файла подкачки не может быть " "переоценена. Файл подкачки на загруженной системе может пережечь кусок флеш-" "носителя менее чем за год. Частое журналирование и создание временных файлов " "приводят к тому же результату. Поэтому, кроме удаления записи `swap` из " "вашего файла [.filename]#/etc/fstab#, вы должны также изменить поле " "параметров каждой файловой системы на `ro` таким образом:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:121 #, no-wrap msgid "" "# Device Mountpoint FStype Options Dump Pass#\n" "/dev/ad0s1a / ufs ro 1 1\n" msgstr "" "# Device Mountpoint FStype Options Dump Pass#" "\n" "/dev/ad0s1a / ufs ro 1 1\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:128 msgid "" "A few applications in the average system will immediately begin to fail as a " "result of this change. For instance, cron will not run properly as a result " "of missing cron tabs in the [.filename]#/var# created by [.filename]#/etc/rc." "d/var#, and syslog and dhcp will encounter problems as well as a result of " "the read-only filesystem and missing items in the [.filename]#/var# that [." "filename]#/etc/rc.d/var# has created. These are only temporary problems " "though, and are addressed, along with solutions to the execution of other " "common software packages in crossref:solid-state[strategies, System " "Strategies for Small and Read Only Environments]." msgstr "" "В результате этих изменений в среднестатистической системе несколько " "приложений немедленно перестанут работать. Например, cron не будет нормально " "запускаться в результате отсутствия таблиц для него в каталоге [." "filename]#/var#, созданном [.filename]#/etc/rc.d/var#, а syslog и dhcp будут " "испытывать проблемы из-за доступа файловой системы только для чтения, а " "также отсутствия записей в [.filename]#/var#, который был создан скриптом [." "filename]#/etc/rc.d/var#. Хотя эти проблемы являются временными и " "обсуждаются вместе с решением проблем с запуском распространённых " "программных пакетов в разделе crossref:solid-state[strategies, Стратегии " "работы с системой для случаев небольших и доступных только для чтения " "файловых систем]." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:130 msgid "" "An important thing to remember is that a filesystem that was mounted read-" "only with [.filename]#/etc/fstab# can be made read-write at any time by " "issuing the command:" msgstr "" "Важно помнить, что файловая система, которая была смонтирована только для " "чтения при помощи файла [.filename]#/etc/fstab#, в любой момент может быть " "сделана доступной по чтению и записи выдачей команды:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:134 #, no-wrap msgid "# /sbin/mount -uw partition\n" msgstr "# /sbin/mount -uw partition\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:137 msgid "and can be toggled back to read-only with the command:" msgstr "" "и может быть возвращена к режиму доступа только для чтения по такой команде:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:141 #, no-wrap msgid "# /sbin/mount -ur partition\n" msgstr "# /sbin/mount -ur partition\n" #. type: Title == #: documentation/content/en/articles/solid-state/_index.adoc:143 #, no-wrap msgid "Building a File System from Scratch" msgstr "Создание файловой системы с нуля" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:146 msgid "" "Since ATA compatible compact-flash cards are seen by FreeBSD as normal IDE " "hard drives, you could theoretically install FreeBSD from the network using " "the kern and mfsroot floppies or from a CD." msgstr "" "Так как совместимые с ATA компактные флеш-карты распознаются во FreeBSD как " -"обычные жесткие диски IDE, то теоретически вы можете установить FreeBSD по " +"обычные жёсткие диски IDE, то теоретически вы можете установить FreeBSD по " "сети при помощи дискет kern и mfsroot или с компакт-диска." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:149 msgid "" "However, even a small installation of FreeBSD using normal installation " "procedures can produce a system in size of greater than 200 megabytes. Most " "people will be using smaller flash memory devices (128 megabytes is " "considered fairly large - 32 or even 16 megabytes is common), so an " "installation using normal mechanisms is not possible-there is simply not " "enough disk space for even the smallest of conventional installations." msgstr "" "Однако даже маленькая установка FreeBSD при помощи обычных процедур " "установки может привести к созданию системы размером, превышающим 200 " "мегабайт. Так как большинство людей используют устройства флеш-памяти " "меньшего размера (128 мегабайт считается весьма большим - 32 или даже 16 " "мегабайт используются гораздо чаще), то установка обычным образом не " "подходит-просто на диске нет места даже для самой минимальной установки." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:155 msgid "" "The easiest way to overcome this space limitation is to install FreeBSD " "using conventional means to a normal hard disk. After the installation is " "complete, pare down the operating system to a size that will fit onto your " "flash media, then tar the entire filesystem. The following steps will guide " "you through the process of preparing a piece of flash memory for your tarred " "filesystem. Remember, because a normal installation is not being performed, " "operations such as partitioning, labeling, file-system creation, etc. need " "to be performed by hand. In addition to the kern and mfsroot floppy disks, " "you will also need to use the fixit floppy." msgstr "" -"Самым простым способом обойти это ограничение на объем является установка " -"FreeBSD обычным образом на обычный жесткий диск. После окончания установки, " +"Самым простым способом обойти это ограничение на объём является установка " +"FreeBSD обычным образом на обычный жёсткий диск. После окончания установки, " "обрежьте операционную систему до размера, который помещается на ваш флеш-" "носитель, а затем полностью заархивируйте файловую систему. Следующие шаги " "поведут вас через процесс подготовки части флеш-памяти для вашей " "заархивированной файловой системы. Запомните, что из-за того, что обычная " "установка не выполнялась, такие операции, как разбиение на разделы, " "разметка, создание файловой системы и так далее должны быть выполнены " "вручную. Кроме дискет kern и mfsroot вам также нужно воспользоваться " "дискетой fixit." #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:159 msgid "Partitioning Your Flash Media Device" msgstr "Разбиение вашего флеш-носителя на разделы" #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:169 msgid "" "After booting with the kern and mfsroot floppies, choose `custom` from the " "installation menu. In the custom installation menu, choose `partition`. In " "the partition menu, you should delete all existing partitions using kbd:" "[d]. After deleting all existing partitions, create a partition using kbd:" "[c] and accept the default value for the size of the partition. When asked " "for the type of the partition, make sure the value is set to `165`. Now " "write this partition table to the disk by pressing kbd:[w] (this is a hidden " "option on this screen). If you are using an ATA compatible compact flash " "card, you should choose the FreeBSD Boot Manager. Now press kbd:[q] to quit " "the partition menu. You will be shown the boot manager menu once more - " "repeat the choice you made earlier." msgstr "" "После загрузки при помощи дискет kern и mfsroot, выберите пункт `custom` из " "меню установки. Из следующего пункта меню выберите `partition`. В меню " "работы с разделами вы должны удалить все существующие разделы при помощи " "клавиши kbd:[d]. После удаления всех имеющихся разделов создайте раздел при " "помощи клавиши kbd:[c] и согласитесь с предлагаемым по умолчанию размером " "раздела. Когда вы будете опрошены на предмет типа раздела, удостоверьтесь, " "что значение типа равно `165`. Теперь запишите эту таблицу разделов на диск, " "нажав клавишу kbd:[w] (на этом экране эта опция скрыта). Если вы используете " "компактную флеш-карту, совместимую с ATA, вы должны выбрать FreeBSD Boot " "Manager. Теперь нажмите клавишу kbd:[q] для выхода из меню работы с " -"разделами. Должно быть выдано еще раз меню для выбора менеджера загрузки - " +"разделами. Должно быть выдано ещё раз меню для выбора менеджера загрузки - " "повторите то, что вы выбирали ранее." #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:170 msgid "Creating Filesystems on Your Flash Memory Device" msgstr "Создание файловых систем на вашем устройстве флеш-памяти" #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:173 msgid "" "Exit the custom installation menu, and from the main installation menu " "choose the `fixit` option. After entering the fixit environment, enter the " "following command:" msgstr "" "Выйдите из меню установки custom, и из главного меню установки выберите " "пункт `fixit`. После входа в режим работы fixit, введите следующую команду:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:177 #, no-wrap msgid "# disklabel -e /dev/ad0c\n" msgstr "# disklabel -e /dev/ad0c\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:181 msgid "" "At this point you will have entered the vi editor under the auspices of the " "disklabel command. Next, you need to add an `a:` line at the end of the " "file. This `a:` line should look like:" msgstr "" "В этот момент вы войдете в редактор vi из-под команды disklabel. Затем, вам " "нужно добавить строку `a:` в конце файла. Эта строка `a:` должна выглядеть " "примерно так:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:185 #, no-wrap msgid "a: 123456 0 4.2BSD 0 0\n" msgstr "a: 123456 0 4.2BSD 0 0\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:190 msgid "" "Where _123456_ is a number that is exactly the same as the number in the " "existing `c:` entry for size. Basically you are duplicating the existing `c:" "` line as an `a:` line, making sure that fstype is `4.2BSD`. Save the file " "and exit." msgstr "" "Здесь _123456_ является числом, в точности совпадающим с тем, что " "характеризует размер имеющейся записи для `c:`. В общем, вы копируете " "существующую строку для `c:` для строки `a:`, не забывая определить fstype " "как `4.2BSD`. Сохраните файл и завершите редактирование." #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:195 #, no-wrap msgid "" "# disklabel -B -r /dev/ad0c\n" "# newfs /dev/ad0a\n" msgstr "" "# disklabel -B -r /dev/ad0c\n" "# newfs /dev/ad0a\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:198 msgid "Placing Your Filesystem on the Flash Media" msgstr "Размещение вашей файловой системы на флеш-носителе" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:200 msgid "Mount the newly prepared flash media:" msgstr "Смонтируйте только что подготовленный флеш-носитель:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:204 #, no-wrap msgid "# mount /dev/ad0a /flash\n" msgstr "# mount /dev/ad0a /flash\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:208 msgid "" "Bring this machine up on the network so we may transfer our tar file and " "explode it onto our flash media filesystem. One example of how to do this " "is:" msgstr "" "Подключите эту машину к сети, чтобы можно было перенести наш tar-файл и " "распаковать его в файловую систему на флеш-носителе. Вот пример того, как " "это можно сделать:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:213 #, no-wrap msgid "" "# ifconfig xl0 192.168.0.10 netmask 255.255.255.0\n" "# route add default 192.168.0.1\n" msgstr "" "# ifconfig xl0 192.168.0.10 netmask 255.255.255.0\n" "# route add default 192.168.0.1\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:219 msgid "" "Now that the machine is on the network, transfer your tar file. You may be " "faced with a bit of a dilemma at this point - if your flash memory part is " "128 megabytes, for instance, and your tar file is larger than 64 megabytes, " "you cannot have your tar file on the flash media at the same time as you " "explode it - you will run out of space. One solution to this problem, if " "you are using FTP, is to untar the file while it is transferred over FTP. " "If you perform your transfer in this manner, you will never have the tar " "file and the tar contents on your disk at the same time:" msgstr "" "Теперь, когда машина находится в сети, перепишите ваш tar-файл. Здесь вы " -"можете столкнуться с некоторой проблемой - если объем вашей флеш-памяти " +"можете столкнуться с некоторой проблемой - если объём вашей флеш-памяти " "равен, к примеру, 128 мегабайтам, а ваш tar-файл превышает 64 мегабайта, то " "вы не можете одновременно разместить tar-файл на флеш-носителе и распаковать " "его - вам не хватит места. Одним из решений этой проблемы, если вы " "используете FTP, является распаковка файла во время его передачи по FTP. " "Если вы передаёте файл именно так, то вы никогда не получите на диске " "одновременно архивный файл и его содержимое:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:223 #, no-wrap msgid "ftp> get tarfile.tar \"| tar xvf -\"\n" msgstr "ftp> get tarfile.tar \"| tar xvf -\"\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:226 msgid "If your tarfile is gzipped, you can accomplish this as well:" msgstr "Если ваш файл обработан утилитой gzip, вы также можете этого добиться:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:230 #, no-wrap msgid "ftp> get tarfile.tar \"| zcat | tar xvf -\"\n" msgstr "ftp> get tarfile.tar \"| zcat | tar xvf -\"\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:233 msgid "" "After the contents of your tarred filesystem are on your flash memory " "filesystem, you can unmount the flash memory and reboot:" msgstr "" "После того, как вы получили содержимое вашей заархивированной файловой " "системы на файловой системе флеш-памяти, вы можете размонтировать флеш-" "память и выполнить перезагрузку:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:239 #, no-wrap msgid "" "# cd /\n" "# umount /flash\n" "# exit\n" msgstr "" "# cd /\n" "# umount /flash\n" "# exit\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:242 msgid "" "Assuming that you configured your filesystem correctly when it was built on " "the normal hard disk (with your filesystems mounted read-only, and with the " "necessary options compiled into the kernel) you should now be successfully " "booting your FreeBSD embedded system." msgstr "" "При условии, что вы правильно настроили файловую систему при её создании на " "обычном жёстком диске (с монтированием файловых систем в режиме только для " "чтения и с необходимыми опциями, встроенными в ядро), ваша встраиваемая " "система FreeBSD теперь должна успешно загружаться." #. type: Title == #: documentation/content/en/articles/solid-state/_index.adoc:245 #, no-wrap msgid "System Strategies for Small and Read Only Environments" msgstr "" "Стратегии работы с системой для случаев небольших и доступных только для " "чтения файловых систем" #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:249 msgid "" "In crossref:solid-state[ro-fs, The `rc` Subsystem and Read-Only " "Filesystems], it was pointed out that the [.filename]#/var# filesystem " "constructed by [.filename]#/etc/rc.d/var# and the presence of a read-only " "root filesystem causes problems with many common software packages used with " "FreeBSD. In this article, suggestions for successfully running cron, " "syslog, ports installations, and the Apache web server will be provided." msgstr "" "В разделе crossref:solid-state[ro-fs, Подсистема `rc` и файловые системы в " "режиме только чтения] было указано, что файловая система [.filename]#/var#, " "создаваемая скриптом [.filename]#/etc/rc.d/var#, и наличие корневой файловой " "системы, доступной только для чтения, приводят к проблемам при работе многих " "распространённых программных пакетов, используемых во FreeBSD. В этой статье " "будут даны рекомендации по настройке нормальной работы cron и syslog, " "установке портов и веб-сервера Apache." #. type: Title === #: documentation/content/en/articles/solid-state/_index.adoc:250 #, no-wrap msgid "Cron" msgstr "Cron" #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:253 msgid "" "Upon boot, [.filename]#/var# gets populated by [.filename]#/etc/rc.d/var# " "using the list from [.filename]#/etc/mtree/BSD.var.dist#, so the [." "filename]#cron#, [.filename]#cron/tabs#, [.filename]#at#, and a few other " "standard directories get created." 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 #: documentation/content/en/articles/solid-state/_index.adoc:258 msgid "" "However, this does not solve the problem of maintaining cron tabs across " "reboots. When the system reboots, the [.filename]#/var# filesystem that is " "in memory will disappear and any cron tabs you may have had in it will also " "disappear. Therefore, one solution would be to create cron tabs for the " "users that need them, mount your [.filename]#/# filesystem as read-write and " "copy those cron tabs to somewhere safe, like [.filename]#/etc/tabs#, then " "add a line to the end of [.filename]#/etc/rc.initdiskless# that copies those " "crontabs into [.filename]#/var/cron/tabs# after that directory has been " "created during system initialization. You may also need to add a line that " "changes modes and permissions on the directories you create and the files " "you copy with [.filename]#/etc/rc.initdiskless#." msgstr "" "Однако это не решает проблему с сохранением cron-таблиц между " "перезагрузками. Когда система перезагружается, то файловая система [." "filename]#/var#, которая располагается в памяти, будет уничтожена, вместе со " "всеми cron-таблицами, которые вы могли там иметь. Поэтому одним из решений " "может стать создание cron-таблиц для пользователей, которым они нужны, " "монтирование вашей файловой системы [.filename]#/# в режиме чтения и записи, " "и копирование этих cron-таблиц в безопасное место, например, в [.filename]#/" "etc/tabs#, и последующее добавление строки в конец скрипта [.filename]#/etc/" "rc.initdiskless# для копирования этих cron-таблиц в каталог [.filename]#/var/" "cron/tabs# после его создания во время инициализации системы. Вам может " "также потребоваться добавить строку, которая изменяет режимы доступа и права " "на каталоги, которые вы создали, и на файлы, которые вы скопировали в " "скрипте [.filename]#/etc/rc.initdiskless#." #. type: Title === #: documentation/content/en/articles/solid-state/_index.adoc:259 #, no-wrap msgid "Syslog" msgstr "Syslog" #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:264 msgid "" "[.filename]#syslog.conf# specifies the locations of certain log files that " "exist in [.filename]#/var/log#. These files are not created by [.filename]#/" "etc/rc.d/var# upon system initialization. Therefore, somewhere in [." "filename]#/etc/rc.d/var#, after the section that creates the directories in " "[.filename]#/var#, you will need to add something like this:" msgstr "" "В файле [.filename]#syslog.conf# задано местоположение некоторых файлов " "протоколов, которые имеются в каталоге [.filename]#/var/log#. Эти файлы не " "создаются скриптом [.filename]#/etc/rc.d/var# во время инициализации " "системы. Поэтому где-нибудь в скрипте [.filename]#/etc/rc.d/var#, после " "секции, создающей каталоги в [.filename]#/var#, вам нужно добавить нечто " "вроде следующего:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:269 #, no-wrap msgid "" "# touch /var/log/security /var/log/maillog /var/log/cron /var/log/messages\n" "# chmod 0644 /var/log/*\n" msgstr "" "# touch /var/log/security /var/log/maillog /var/log/cron /var/log/messages\n" "# chmod 0644 /var/log/*\n" #. type: Title === #: documentation/content/en/articles/solid-state/_index.adoc:271 #, no-wrap msgid "Ports Installation" msgstr "Установка портов" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:277 msgid "" "Before discussing the changes necessary to successfully use the ports tree, " "a reminder is necessary regarding the read-only nature of your filesystems " "on the flash media. Since they are read-only, you will need to temporarily " "mount them read-write using the mount syntax shown in crossref:solid-" "state[ro-fs, The `rc` Subsystem and Read-Only Filesystems]. You should " "always remount those filesystems read-only when you are done with any " "maintenance - unnecessary writes to the flash media could considerably " "shorten its lifespan." msgstr "" "Перед тем, как обсудить изменения, которые нужно сделать для успешного " "использования дерева портов, необходимо напомнить о том, что ваши файловые " "системы на флеш-носителях доступны только для чтения. Поэтому вам нужно " "временно монтировать их в режиме чтения и записи, используя параметры " "командной строки, как это показано в crossref:solid-state[ro-fs, Подсистема " "`rc` и файловые системы в режиме только чтения]. Вы всегда должны " "перемонтировать эти файловые системы в режим только для чтения после " "окончания работ - излишние записи на флеш носитель могут значительно " "сократить его срок эксплуатации." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:280 msgid "" "To make it possible to enter a ports directory and successfully run `make " "install`, we must create a packages directory on a non-memory filesystem " "that will keep track of our packages across reboots. As it is necessary to " "mount your filesystems as read-write for the installation of a package " "anyway, it is sensible to assume that an area on the flash media can also be " "used for package information to be written to." msgstr "" "Чтобы можно было войти в каталог с портами и успешно выполнить команду make " "`install`, необходимо создать каталог для пакетов в файловой системе, не " "располагающейся в памяти, где будут храниться пакеты между перезагрузками. " "Так как для установки пакета в любом случае требуется монтирование ваших " "файловых систем для чтения и записи, имеет смысл выделить область флеш-" "носителя также и для записи информации о пакете." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:283 msgid "" "First, create a package database directory. This is normally in [." "filename]#/var/db/pkg#, but we cannot place it there as it will disappear " "every time the system is booted." msgstr "" "Прежде всего создайте каталог с базой данных о пакетах. Обычно это каталог [." "filename]#/var/db/pkg#, но мы не можем разместить базу именно здесь, так как " "она исчезнет после перезагрузки системы." #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:287 #, no-wrap msgid "# mkdir /etc/pkg\n" msgstr "# mkdir /etc/pkg\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:290 msgid "" "Now, add a line to [.filename]#/etc/rc.d/var# that links the [.filename]#/" "etc/pkg# directory to [.filename]#/var/db/pkg#. An example:" msgstr "" "Теперь в скрипт [.filename]#/etc/rc.d/var# добавьте строку, которая " "связывает каталог [.filename]#/etc/pkg# с [.filename]#/var/db/pkg#. Например:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:294 #, no-wrap msgid "# ln -s /etc/pkg /var/db/pkg\n" msgstr "# ln -s /etc/pkg /var/db/pkg\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:297 msgid "" "Now, any time that you mount your filesystems as read-write and install a " "package, the `make install` will work, and package information will be " "written successfully to [.filename]#/etc/pkg# (because the filesystem will, " "at that time, be mounted read-write) which will always be available to the " "operating system as [.filename]#/var/db/pkg#." msgstr "" "Теперь каждый раз при монтировании ваших файловых систем для чтения и записи " "и установки пакета, команда make `install` будет работать, а информация о " "пакете будет успешно записана в каталог [.filename]#/etc/pkg# (так как " "файловая система будет в это время смонтирована для чтения и записи), " "который всегда будет доступным операционной системе как [.filename]#/var/db/" "pkg#." #. type: Title === #: documentation/content/en/articles/solid-state/_index.adoc:298 #, no-wrap msgid "Apache Web Server" msgstr "Веб-сервер Apache" #. type: delimited block = 4 #: documentation/content/en/articles/solid-state/_index.adoc:304 msgid "" "The steps in this section are only necessary if Apache is set up to write " "its pid or log information outside of [.filename]#/var#. By default, Apache " "keeps its pid file in [.filename]#/var/run/httpd.pid# and its log files in [." "filename]#/var/log#." msgstr "" "Шаги, описанные в этой части статьи, необходимо выполнить лишь в том случае, " "если Apache настроен сохранять свой pid или журнал вне каталога [." "filename]#/var#. С настройками по умолчанию Apache формирует свой pid файл в " "[.filename]#/var/run/httpd.pid#, а файлы журналов - в [.filename]#/var/log#." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:310 msgid "" "It is now assumed that Apache keeps its log files in a directory [." "filename]#apache_log_dir# outside of [.filename]#/var#. When this directory " "lives on a read-only filesystem, Apache will not be able to save any log " "files, and may have problems working. If so, it is necessary to add a new " "directory to the list of directories in [.filename]#/etc/rc.d/var# to create " "in [.filename]#/var#, and to link [.filename]#apache_log_dir# to [." "filename]#/var/log/apache#. It is also necessary to set permissions and " "ownership on this new directory." msgstr "" "Далее в статье подразумевается, что Apache сохраняет свои файлы журналов в " "каталог [.filename]#apache_log_dir# вне каталога [.filename]#/var#. Когда " "этот каталог расположен на файловой системе, смонтированной в режиме только " "для чтения, Apache не сможет сохранять файлы журналов, что в свою очередь " "может вызывать проблемы в работе веб-сервера. В таком случае необходимо " "добавить новый каталог к списку каталогов из [.filename]#/etc/rc.d/var# для " "их создания в каталоге [.filename]#/var# и связать [." "filename]#apache_log_dir# с [.filename]#/var/log/apache#. Нужно также задать " "права доступа и владельца нового каталога." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:312 msgid "" "First, add the directory `log/apache` to the list of directories to be " "created in [.filename]#/etc/rc.d/var#." msgstr "" "Сначала добавьте каталог `log/apache` к списку каталогов, создаваемых " "скриптом [.filename]#/etc/rc.d/var#." #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:314 msgid "" "Second, add these commands to [.filename]#/etc/rc.d/var# after the directory " "creation section:" msgstr "" "Затем добавьте в скрипт [.filename]#/etc/rc.d/var# после секции создания " "каталогов такие команды:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:319 #, no-wrap msgid "" "# chmod 0774 /var/log/apache\n" "# chown nobody:nobody /var/log/apache\n" msgstr "" "# chmod 0774 /var/log/apache\n" "# chown nobody:nobody /var/log/apache\n" #. type: Plain text #: documentation/content/en/articles/solid-state/_index.adoc:322 msgid "" "Finally, remove the existing [.filename]#apache_log_dir# directory, and " "replace it with a link:" msgstr "" "И наконец, удалите существующий каталог [.filename]#apache_install/logs# и " "замените его ссылкой:" #. type: delimited block . 4 #: documentation/content/en/articles/solid-state/_index.adoc:327 #, no-wrap msgid "" "# rm -rf apache_log_dir\n" "# ln -s /var/log/apache apache_log_dir\n" msgstr "" "# rm -rf apache_log_dir\n" "# ln -s /var/log/apache apache_log_dir\n" diff --git a/documentation/content/ru/articles/vinum/_index.adoc b/documentation/content/ru/articles/vinum/_index.adoc index b958205042..ddebec7ce0 100644 --- a/documentation/content/ru/articles/vinum/_index.adoc +++ b/documentation/content/ru/articles/vinum/_index.adoc @@ -1,601 +1,601 @@ --- authors: - author: 'Greg Lehey' description: 'Менеджер томов vinum в FreeBSD' tags: ["vinum", "Volume Manager", "FreeBSD"] title: 'Менеджер томов vinum' --- //// The Vinum Volume Manager By Greg Lehey (grog at lemis dot com) Added to the Handbook by Hiten Pandya and Tom Rhodes For the FreeBSD Documentation Project //// = Менеджер томов vinum :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/vinum/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] ''' toc::[] [[vinum-synopsis]] == Обзор Независимо от типа дисков, всегда существуют потенциальные проблемы. Диски могут быть слишком малы, слишком медленны или недостаточно надёжны для соответствия требованиям системы. Хотя диски становятся больше, требования к хранению данных также растут. Часто требуется файловая система, размер которой превышает емкость одного диска. Были предложены и реализованы различные решения этих проблем. Один из методов заключается в использовании нескольких, а иногда и избыточных дисков. Помимо поддержки различных карт и контроллеров для аппаратных систем RAID (Redundant Array of Independent Disks), базовая система FreeBSD включает менеджер томов [.filename]#vinum#, драйвер блочных устройств, который реализует виртуальные диски и решает эти три проблемы. [.filename]#vinum# обеспечивает большую гибкость, производительность и надёжность по сравнению с традиционными системами хранения данных, а также реализует модели `RAID`-0, `RAID`-1 и `RAID`-5 как по отдельности, так и в комбинации. Эта глава предоставляет обзор потенциальных проблем с традиционным дисковым хранилищем и введение в менеджер томов [.filename]#vinum#. [WARNING] ==== vinum устарел и отсутствует в FreeBSD 15.0 и более поздних версиях. Пользователям рекомендуется перейти на man:gconcat[8], man:gmirror[8], man:gstripe[8], man:graid[8] или man:zfs[8]. ==== [NOTE] ==== Начиная с FreeBSD 5, [.filename]#vinum# был переписан для интеграции в extref:{handbook}geom[архитектуру GEOM, geom-synopsis], сохраняя при этом оригинальные идеи, терминологию и метаданные на диске. Эта переработанная версия называется _gvinum_ (от _GEOM vinum_). Хотя в этой главе используется термин [.filename]#vinum#, все команды должны выполняться с помощью `gvinum`. Имя модуля ядра изменилось с оригинального [.filename]#vinum.ko# на [.filename]#geom_vinum.ko#, а все узлы устройств находятся в [.filename]#/dev/gvinum# вместо [.filename]#/dev/vinum#. Начиная с FreeBSD 6, оригинальная реализация [.filename]#vinum# больше не доступна в кодовой базе. ==== [[vinum-access-bottlenecks]] == Узкие места доступа Современные системы часто нуждаются в доступе к данным в условиях высокой параллельности. Например, крупные FTP- или HTTP-серверы могут поддерживать тысячи одновременных сеансов и иметь несколько 100 Мбит/с соединений с внешним миром, что значительно превышает устойчивую скорость передачи большинства дисков. Современные дисковые накопители могут передавать данные последовательно со скоростью до 70 МБ/с, но это значение имеет мало значения в среде, где множество независимых процессов обращаются к накопителю и могут достичь лишь доли этих значений. В таких случаях более интересно рассмотреть проблему с точки зрения дисковой подсистемы. Важным параметром является нагрузка, которую передача данных создаёт на подсистему, или время, в течение которого передача занимает задействованные накопители. При любом переносе данных на диск сначала необходимо позиционировать головки, дождаться, пока первый сектор окажется под считывающей головкой, а затем выполнить перенос. Эти действия можно считать атомарными, так как их прерывание не имеет смысла. [[vinum-latency]] Рассмотрим типичную передачу около 10 КБ: современные высокопроизводительные диски могут позиционировать головки в среднем за 3,5 мс. Самые быстрые диски вращаются со скоростью 15 000 об/мин, поэтому средняя задержка вращения (половина оборота) составляет 2 мс. При скорости 70 МБ/с сама передача занимает около 150 мкс, что почти ничто по сравнению с временем позиционирования. В таком случае эффективная скорость передачи падает до чуть более 1 МБ/с и явно сильно зависит от размера передачи. Традиционное и очевидное решение этой проблемы — «больше дисков»: вместо одного большого диска использовать несколько дисков меньшего размера с тем же общим объёмом хранилища. Каждый диск способен позиционироваться и передавать данные независимо, поэтому эффективная пропускная способность увеличивается почти пропорционально количеству используемых дисков. Фактическое увеличение пропускной способности меньше, чем количество задействованных дисков. Хотя каждый диск способен передавать данные параллельно, нет возможности гарантировать равномерное распределение запросов между дисками. Неизбежно нагрузка на один диск будет выше, чем на другой. Равномерность нагрузки на диски сильно зависит от способа распределения данных по накопителям. В дальнейшем обсуждении удобно представлять дисковое хранилище как большое количество секторов данных, адресуемых по номерам, подобно страницам в книге. Наиболее очевидный метод — разделить виртуальный диск на группы последовательных секторов размером с отдельные физические диски и хранить их таким образом, как если бы большую книгу разорвали на меньшие разделы. Этот метод называется _объединением_ (конкатенацией) и имеет преимущество в том, что диски не требуют каких-либо определённых соотношений размеров. Он хорошо работает, когда доступ к виртуальному диску равномерно распределён по его адресному пространству. Если доступ сосредоточен на меньшей области, улучшение менее заметно. crossref:vinum[vinum-concat, Организация методом объединения] иллюстрирует последовательность выделения блоков хранения в организации методом объединения. [[vinum-concat]] .Организация методом объединения image::vinum-concat.png[] Альтернативный метод распределения заключается в разделении адресного пространства на меньшие равные по размеру компоненты и их последовательном хранении на разных устройствах. Например, первые 256 секторов могут храниться на первом диске, следующие 256 секторов — на следующем диске и так далее. После заполнения последнего диска процесс повторяется, пока все диски не будут заполнены. Такой метод называется _чередованием (striping)_ или RAID-0. `RAID` предлагает различные формы отказоустойчивости, хотя RAID-0 несколько вводит в заблуждение, так как не обеспечивает избыточности. Разделение данных требует несколько больше усилий для их поиска и может создавать дополнительную нагрузку ввода-вывода, когда передача распределяется по нескольким дискам, но также может обеспечить более равномерную нагрузку на диски. crossref:vinum[vinum-striped,Организация методом чередования] иллюстрирует последовательность, в которой организуется распределение блоков хранения с чередованием. [[vinum-striped]] .Организация методом чередования image::vinum-striped.png[] [[vinum-data-integrity]] == Целостность данных Последняя проблема с дисками заключается в их ненадёжности. Хотя надёжность значительно повысилась за последние годы, дисковые накопители остаются наиболее вероятным компонентом сервера, который может выйти из строя. Когда это происходит, последствия могут быть катастрофическими, а замена вышедшего из строя диска и восстановление данных могут привести к простою сервера. Один из подходов к этой проблеме — _зеркалирование_, или `RAID-1`, при котором данные хранятся в двух экземплярах на разных физических носителях. Любая запись на том записывается на оба диска; чтение может выполняться с любого из них, поэтому при отказе одного диска данные остаются доступны на другом. Зеркалирование имеет две проблемы: * Требуется в два раза больше дискового пространства, чем для решения без избыточности. * Запись должна выполняться на оба диска, поэтому она занимает в два раза больше пропускной способности, чем в незеркалированном томе. Чтение не страдает от потери производительности и может быть даже быстрее. Альтернативным решением является _чётность_, реализованная в уровнях `RAID` 2, 3, 4 и 5. Из них `RAID-5` представляет наибольший интерес. В реализации [.filename]#vinum# это вариант организации с чередованием, где один блок каждой полосы выделяется под чётность одного из других блоков. В реализации [.filename]#vinum# плекс `RAID-5` аналогичен плексу с чередованием, за исключением того, что он реализует `RAID-5`, включая блок чётности в каждую полосу. Как требуется в `RAID-5`, расположение этого блока чётности меняется от одной полосы к другой. Числа в блоках данных обозначают относительные номера блоков. [[vinum-raid5-org]] .Организация `RAID`-5 image::vinum-raid5-org.png[] -По сравнению с зеркалированием, `RAID-5` имеет преимущество в виде значительно меньшего требуемого объема хранилища. Скорость чтения аналогична таковой при чередующейся организации, но скорость записи значительно ниже — примерно 25% от скорости чтения. Если один диск выходит из строя, массив может продолжать работу в деградировавшем режиме, при котором чтение с оставшихся доступных дисков продолжается в обычном режиме, а чтение с отказавшего диска пересчитывается из соответствующих блоков всех оставшихся дисков. +По сравнению с зеркалированием, `RAID-5` имеет преимущество в виде значительно меньшего требуемого объёма хранилища. Скорость чтения аналогична таковой при чередующейся организации, но скорость записи значительно ниже — примерно 25% от скорости чтения. Если один диск выходит из строя, массив может продолжать работу в деградировавшем режиме, при котором чтение с оставшихся доступных дисков продолжается в обычном режиме, а чтение с отказавшего диска пересчитывается из соответствующих блоков всех оставшихся дисков. [[vinum-objects]] == Объекты [.filename]#vinum# Для решения этих проблем [.filename]#vinum# реализует четырёхуровневую иерархию объектов: * Наиболее заметным объектом является виртуальный диск, называемый _томом_. Том обладает практически теми же свойствами, что и UNIX(R) дисковый накопитель, хотя есть некоторые незначительные отличия. Например, у тома нет ограничений по размеру. * Тома состоят из _плексов_, каждый из которых представляет полное адресное пространство тома. Этот уровень в иерархии обеспечивает избыточность. Можно представить плексы как отдельные диски в зеркальном массиве, каждый из которых содержит одинаковые данные. * Поскольку [.filename]#vinum# существует в рамках системы хранения данных UNIX(R), можно было бы использовать разделы UNIX(R) в качестве строительных блоков для многодисковых plexes. Однако на практике это оказывается слишком негибким, так как диски UNIX(R) могут иметь только ограниченное количество разделов. Вместо этого [.filename]#vinum# разбивает единственный раздел UNIX(R), называемый _дисковый раздел (drive)_, на непрерывные области, называемые _поддисками (subdisk)_, которые используются как строительные блоки для плексов. * Поддиски располагаются на _дисковых разделах_ [.filename]#vinum#, в настоящее время это разделы UNIX(R). Разделы [.filename]#vinum# могут содержать любое количество поддисков. За исключением небольшой области в начале раздела, которая используется для хранения конфигурации и состояния, весь раздел доступен для хранения данных. Следующие разделы статьи описывают, каким образом эти объекты обеспечивают функциональность, требуемую для [.filename]#vinum#. -=== Учет размера томов +=== Учёт размера томов Плексы могут включать несколько поддисков, распределенных по всем дискам в конфигурации [.filename]#vinum#. В результате, размер отдельного диска не ограничивает размер плекса или тома. === Избыточное хранение данных [.filename]#vinum# реализует зеркалирование путем присоединения нескольких плекс к тому. Каждый плекс представляет данные в томе. Том может содержать от одного до восьми плексов. Хотя плекс представляет полные данные тома, возможно, что некоторые части представления физически отсутствуют — либо по замыслу (если поддиск для частей плекса не определён), либо случайно (в результате выхода диска из строя). До тех пор, пока хотя бы один плекс может предоставить данные для полного адресного пространства тома, том остаётся полностью работоспособным. === Какую организацию плексов выбрать? [.filename]#vinum# реализует как объединение, так и чередование на уровне плекс: * _Плекс с объединением_ использует адресное пространство каждого поддиска по очереди. Объединённые плексы являются наиболее гибкими, так как могут содержать любое количество поддисков, а поддиски могут быть разной длины. Плекс может быть расширен путём добавления дополнительных поддисков. Они требуют меньше процессорного времени, чем чередующиеся плексы, хотя разница в нагрузке на процессор незначительна. С другой стороны, они наиболее подвержены "горячим точкам", когда один диск очень активен, а другие простаивают. * _Плекс с чередованием_ распределяет данные по каждому поддиску. Поддиски должны быть одного размера, и их должно быть как минимум два, чтобы отличить такой плекс от объединенного. Главное преимущество чередующихся плексов в том, что они уменьшают вероятность появления "горячих точек". Выбрав оптимальный размер полосы (около 256 КБ), можно равномерно распределить нагрузку на диски – компоненты системы. Расширение плекса путем добавления новых поддисков настолько сложно, что [.filename]#vinum# не реализует эту возможность. crossref:vinum[vinum-comparison, Организации плексов в [.filename]#vinum#] обобщает преимущества и недостатки каждой организации плексов. [[vinum-comparison]] .Организации плексов в [.filename]#vinum# [cols="1,1,1,1,1", frame="none", options="header"] |=== | Тип плекса | Минимальное количество поддисков | Может добавлять поддиски | Должен быть равного размера | Приложение |объединённый |1 |да |no |Крупное хранилище данных с максимальной гибкостью размещения и умеренной производительностью |чередуемый |2 |no |да |Высокая производительность в сочетании с высокопараллельным доступом |=== [[vinum-examples]] == Некоторые примеры [.filename]#vinum# поддерживает _базу данных конфигурации_, которая описывает объекты, известные конкретной системе. Первоначально пользователь создает базу данных конфигурации из одного или нескольких конфигурационных файлов с помощью man:gvinum[8]. [.filename]#vinum# хранит копию своей базы данных конфигурации на каждом _устройстве_ диска, находящемся под его управлением. Эта база данных обновляется при каждом изменении состояния, так что перезапуск точно восстанавливает состояние каждого объекта [.filename]#vinum#. === Файл конфигурации Файл конфигурации описывает отдельные объекты [.filename]#vinum#. Определение простого тома может выглядеть следующим образом: [.programlisting] .... drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a .... Этот файл описывает четыре объекта [.filename]#vinum#: * Строка _drive_ описывает раздел диска (_drive_) и его расположение относительно оборудования, на котором он расположен. Ему присваивается символическое имя _a_. Такое разделение символических имён от имён устройств позволяет перемещать диски из одного места в другое без путаницы. * Строка _volume_ описывает том. Единственный обязательный атрибут — это имя, в данном случае _myvol_. * Строка _plex_ определяет плекс. Единственный обязательный параметр — это организация, в данном случае _concat_. Имя не требуется, так как система автоматически генерирует его из имени тома, добавляя суффикс _.px_, где _x_ — номер плекса в томе. Таким образом, этот плекс будет называться _myvol.p0_. * Строка _sd_ описывает поддиск. Минимальные требования — это имя диска для его хранения и длина поддиска. Имя не обязательно, так как система автоматически назначает имена, производные от имени плекса, добавляя суффикс _.sx_, где _x_ — номер поддиска в плексе. Таким образом, [.filename]#vinum# присваивает этому поддиску имя _myvol.p0.s0_. После обработки этого файла команда man:gvinum[8] выводит следующий результат: [.programlisting] .... # gvinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB .... Этот вывод показывает краткий формат списка man:gvinum[8]. Он представлен графически в crossref:vinum[vinum-simple-vol, Простой том [.filename]#vinum#]. [[vinum-simple-vol]] .Простой том [.filename]#vinum# image::vinum-simple-vol.png[] Этот рисунок и следующие представляют том, который содержит плексы, которые, в свою очередь, содержат поддиски. В этом примере том содержит один плекс, а плекс содержит один поддиск. Этот конкретный том не имеет особых преимуществ по сравнению с обычным разделом диска. Он содержит один плекс, поэтому не является избыточным. Плекс содержит один поддиск, поэтому нет различий в распределении хранилища по сравнению с обычным разделом диска. В следующих разделах показаны различные более интересные методы конфигурации. === Увеличенная отказоустойчивость: зеркалирование Устойчивость тома может быть повышена за счёт зеркалирования. При создании зеркального тома важно убедиться, что поддиски каждого плекса находятся на разных дисках, чтобы выход из строя одного диска не затронул оба плекса. Следующая конфигурация создаёт зеркальный том: [.programlisting] .... drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b .... В этом примере не потребовалось снова указывать определение диска _a_, поскольку [.filename]#vinum# отслеживает все объекты в своей базе данных конфигурации. После обработки этого определения конфигурация выглядит следующим образом: [.programlisting] .... Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB .... crossref:vinum[vinum-mirrored-vol, Зеркальный том [.filename]#vinum#] графически отображает структуру. [[vinum-mirrored-vol]] .Зеркальный том [.filename]#vinum# image::vinum-mirrored-vol.png[] В этом примере каждый плекс содержит полные 512 МБ адресного пространства. Как и в предыдущем примере, каждый плекс содержит только один поддиск. === Оптимизация производительности Зеркальный том в предыдущем примере более устойчив к сбоям, чем незеркальный том, но его производительность ниже, так как каждая запись в том требует записи на оба диска, используя большую часть общей пропускной способности дисков. Соображения производительности требуют другого подхода: вместо зеркалирования данные распределяются по полосам на максимально возможное количество дисков. Следующая конфигурация показывает том с плексом, распределённым по полосам на четырёх дисках: [.programlisting] .... drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d .... Как и ранее, не нужно определять диски, которые уже известны [.filename]#vinum#. После обработки этого определения конфигурация выглядит следующим образом: [.programlisting] .... Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB .... [[vinum-striped-vol]] .Том [.filename]#vinum# с чередованием image::vinum-striped-vol.png[] Этот том представлен на схеме crossref:vinum[vinum-striped-vol, Том [.filename]#vinum# с чередованием]. Темнота полос указывает на позицию в адресном пространстве плекса, где самые светлые полосы идут первыми, а самые темные — последними. === Устойчивость и производительность [[vinum-resilience]]При достаточном аппаратном обеспечении можно создать тома, которые демонстрируют как повышенную отказоустойчивость, так и увеличенную производительность по сравнению со стандартными разделами UNIX(R). Типичный конфигурационный файл может выглядеть так: [.programlisting] .... volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b .... Поддиски второго плекса смещены на два диска относительно поддисков первого плекса. Это помогает гарантировать, что записи не будут направляться на одни и те же поддиски, даже если передача затронет два диска. crossref:vinum[vinum-raid10-vol, Том [.filename]#vinum# c зеркалированием и чередованием] представляет структуру этого тома. [[vinum-raid10-vol]] .Том [.filename]#vinum# c зеркалированием и чередованием image::vinum-raid10-vol.png[] [[vinum-object-naming]] == Именование объектов -[.filename]#vinum# назначает стандартные имена для плексов и поддисков, хотя их можно изменить. Не рекомендуется изменять стандартные имена, так как это не дает значительных преимуществ и может вызвать путаницу. +[.filename]#vinum# назначает стандартные имена для плексов и поддисков, хотя их можно изменить. Не рекомендуется изменять стандартные имена, так как это не даёт значительных преимуществ и может вызвать путаницу. Имена могут содержать любые непустые символы, но рекомендуется ограничиваться буквами, цифрами и символами подчёркивания. Имена томов, плексов и поддисков могут быть длиной до 64 символов, а имена дисков — до 32 символов. Объектам [.filename]#vinum# назначаются узлы устройств в иерархии [.filename]#/dev/gvinum#. Приведённая выше конфигурация приведёт к тому, что [.filename]#vinum# создаст следующие узлы устройств: * Записи устройств для каждого тома. Это основные устройства, используемые [.filename]#vinum#. Приведённая конфигурация включает устройства [.filename]#/dev/gvinum/myvol#, [.filename]#/dev/gvinum/mirror#, [.filename]#/dev/gvinum/striped#, [.filename]#/dev/gvinum/raid5# и [.filename]#/dev/gvinum/raid10#. * Все тома получают собственные записи в [.filename]#/dev/gvinum/#. * Каталоги [.filename]#/dev/gvinum/plex# и [.filename]#/dev/gvinum/sd#, которые содержат узлы устройств для каждого плекса и каждого субдиска соответственно. Например, рассмотрим следующий конфигурационный файл: [.programlisting] .... drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4 .... После обработки этого файла man:gvinum[8] создает следующую структуру в [.filename]#/dev/gvinum#: [.programlisting] .... drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd /dev/vinum/plex: total 0 crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/sd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 .... Хотя рекомендуется не назначать конкретные имена плексам и поддискам, диски [.filename]#vinum# должны быть именованными. Это позволяет переместить диск в другое место и по-прежнему автоматически его распознавать. Имена дисков могут быть длиной до 32 символов. === Создание файловых систем Тома для системы выглядят идентично дискам, за одним исключением. В отличие от дисков UNIX(R), [.filename]#vinum# не разбивает тома на разделы, поэтому они не содержат таблицы разделов. Это потребовало внесения изменений в некоторые утилиты для работы с дисками, в частности, в man:newfs[8], чтобы они не пытались интерпретировать последнюю букву имени тома [.filename]#vinum# как идентификатор раздела. Например, имя диска может выглядеть как [.filename]#/dev/ad0a# или [.filename]#/dev/da2h#. Эти имена обозначают первый раздел ([.filename]#a#) на первом (0) IDE-диске ([.filename]#ad#) и восьмой раздел ([.filename]#h#) на третьем (2) SCSI-диске ([.filename]#da#), соответственно. В отличие от этого, том [.filename]#vinum# может называться [.filename]#/dev/gvinum/concat#, что не имеет отношения к имени раздела. Чтобы создать файловую систему на этом томе, используйте man:newfs[8]: [source, shell] .... # newfs /dev/gvinum/concat .... [[vinum-config]] == Настройка [.filename]#vinum# Ядро [.filename]#GENERIC# не содержит [.filename]#vinum#. Можно собрать пользовательское ядро с включённым [.filename]#vinum#, но это не рекомендуется. Стандартный способ запуска [.filename]#vinum# — в качестве модуля ядра. Команда man:kldload[8] не требуется, так как при запуске man:gvinum[8] проверяет, загружен ли модуль, и если нет, загружает его автоматически. === Запуск [.filename]#vinum# хранит конфигурационную информацию на дисковых слайсах практически в той же форме, что и в конфигурационных файлах. При чтении из базы данных конфигурации [.filename]#vinum# распознаёт ряд ключевых слов, которые не допускаются в конфигурационных файлах. Например, конфигурация диска может содержать следующий текст: [.programlisting] .... volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b .... Очевидные различия здесь — наличие явной информации о местоположении и именования, что разрешено, но не рекомендуется, а также информация о состояниях. [.filename]#vinum# не хранит сведения о дисках в конфигурационной информации. Он находит диски, сканируя настроенные дисковые накопители на наличие разделов с меткой [.filename]#vinum#. Это позволяет [.filename]#vinum# корректно идентифицировать диски, даже если им были присвоены разные идентификаторы дисков UNIX(R). [[vinum-rc-startup]] ==== Автоматический запуск _Gvinum_ всегда запускается автоматически после загрузки модуля ядра через man:loader.conf[5]. Чтобы загрузить модуль _Gvinum_ при загрузке системы, добавьте `geom_vinum_load="YES"` в [.filename]#/boot/loader.conf#. Когда [.filename]#vinum# запускается командой `gvinum start`, [.filename]#vinum# читает конфигурационную базу данных с одного из дисков [.filename]#vinum#. В нормальных условиях каждый диск содержит идентичную копию конфигурационной базы данных, поэтому не имеет значения, с какого диска читать. Однако после сбоя [.filename]#vinum# должен определить, какой диск был обновлён последним, и прочитать конфигурацию с этого диска. Затем, если необходимо, он обновляет конфигурацию последовательно с более старых дисков. [[vinum-root]] == Использование [.filename]#vinum# для корневой файловой системы Для машины с полностью зеркалированными файловыми системами с использованием [.filename]#vinum#, желательно также зеркалировать корневую файловую систему. Настройка такой конфигурации менее тривиальна, чем зеркалирование произвольной файловой системы, потому что: * Корневая файловая система должна быть доступна очень рано в процессе загрузки, поэтому инфраструктура [.filename]#vinum# должна быть уже доступна на этом этапе. * Том, содержащий корневую файловую систему, также включает системный загрузчик и ядро. Они должны быть прочитаны с использованием родных утилит хостовой системы, таких как BIOS, который зачастую нельзя обучить работе с деталями [.filename]#vinum#. В следующих разделах термин "корневой том" обычно используется для описания тома [.filename]#vinum#, который содержит корневую файловую систему. === Запуск [.filename]#vinum# на раннем этапе для обеспечения доступа к корневой файловой системе Файл `[.filename]#vinum#` должен быть доступен на раннем этапе загрузки системы, так как `man:loader[8]` должен загрузить модуль ядра `vinum` перед запуском ядра. Это можно сделать, добавив следующую строку в `[.filename]#/boot/loader.conf#`: [.programlisting] .... geom_vinum_load="YES" .... === Создание корневого тома на основе [.filename]#vinum#, доступного для загрузчика Текущая загрузочная запись FreeBSD занимает всего 7,5 КБ кода и не понимает внутренние структуры [.filename]#vinum#. Это означает, что она не может разобрать конфигурационные данные [.filename]#vinum# или определить элементы загрузочного тома. Таким образом, необходимы некоторые обходные решения, чтобы предоставить загрузочному коду иллюзию стандартного раздела `a`, содержащего корневую файловую систему. Для этого должны быть выполнены следующие требования к корневому тому: * Корневой том не должен быть чередующимся или `RAID`-5. * Корневой том не должен содержать более одного объединённого поддиска на плекс. Обратите внимание, что желательно и возможно использовать несколько плексов, каждый из которых содержит одну реплику корневой файловой системы. Процесс начальной загрузки будет использовать только одну реплику для поиска загрузчика и всех загрузочных файлов, пока ядро не смонтирует корневую файловую систему. Каждый отдельный поддиск в этих плексах должен иметь свою собственную иллюзию раздела `a`, чтобы соответствующее устройство было загрузочным. Не строго необходимо, чтобы каждый из этих фальшивых разделов `a` находился на том же смещении внутри своего устройства по сравнению с другими устройствами, содержащими плекс корневого тома. Однако, вероятно, хорошей идеей будет создавать тома [.filename]#vinum# таким образом, чтобы результирующие зеркальные устройства были симметричными, чтобы избежать путаницы. Для настройки этих разделов `a` на каждом устройстве, содержащем часть корневого тома, требуется следующее: [.procedure] ==== . Местоположение, смещение от начала устройства и размер подобласти этого устройства, которая является частью корневого тома, необходимо проверить с помощью команды: + [source, shell] .... # gvinum l -rv root .... + Смещения и размеры в [.filename]#vinum# измеряются в байтах. Их необходимо разделить на 512, чтобы получить номера блоков, которые будут использоваться в `bsdlabel`. . Выполните эту команду для каждого устройства, участвующего в корневом томе: + [source, shell] .... # bsdlabel -e devname .... + `_devname_` должен быть либо именем диска, например, [.filename]#da0# для дисков без таблицы разделов, либо именем раздела, например, [.filename]#ad0s1#. + Если на устройстве уже существует раздел `a` из корневой файловой системы до [.filename]#vinum#, его следует переименовать во что-то другое, чтобы он оставался доступным (на всякий случай), но больше не использовался по умолчанию для загрузки системы. Текущий смонтированный корневой файловой системы нельзя переименовать, поэтому это должно выполняться либо при загрузке с "Fixit" носителя, либо в два этапа, когда в зеркале сначала обрабатывается диск, с которого в данный момент не загружаются. + Смещение раздела [.filename]#vinum# на этом устройстве (если есть) должно быть добавлено к смещению соответствующего поддиска корневого тома на этом устройстве. Полученное значение станет значением `offset` для нового раздела `a`. Значение `size` для этого раздела можно взять дословно из приведённых выше расчётов. Для `fstype` следует указать `4.2BSD`. Значения `fsize`, `bsize` и `cpg` должны быть выбраны в соответствии с реальной файловой системой, хотя в данном контексте они не слишком важны. + Таким образом, будет создан новый раздел `a`, который перекрывает раздел [.filename]#vinum# на этом устройстве. `bsdlabel` разрешит это перекрытие только в том случае, если раздел [.filename]#vinum# был правильно помечен с использованием типа файловой системы `vinum`. . Поддельный раздел `a` теперь существует на каждом устройстве, имеющем одну реплику корневого тома. Настоятельно рекомендуется проверить результат с помощью команды, например: + [source, shell] .... # fsck -n /dev/devnamea .... ==== Следует помнить, что все файлы, содержащие управляющую информацию, должны быть относительны к корневой файловой системе в томе [.filename]#vinum#, которая при настройке нового корневого тома [.filename]#vinum# может не совпадать с текущей активной корневой файловой системой. Поэтому, в частности, необходимо позаботиться о [.filename]#/etc/fstab# и [.filename]#/boot/loader.conf#. При следующей перезагрузке загрузчик должен определить соответствующую управляющую информацию из новой корневой файловой системы на основе [.filename]#vinum# и действовать соответствующим образом. В конце процесса инициализации ядра, после объявления всех устройств, явным признаком успешного завершения настройки будет сообщение вида: [source, shell] .... Mounting root from ufs:/dev/gvinum/root .... === Пример настройки корневой системы на основе [.filename]#vinum# После настройки корневого тома [.filename]#vinum#, вывод команды `gvinum l -rv root` может выглядеть следующим образом: [source, shell] .... ... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB) .... Значения, на которые следует обратить внимание: `135680` для смещения, относительного к разделу [.filename]#/dev/da0h#. Это соответствует 265 блокам диска по 512 байт в терминах `bsdlabel`. Аналогично, размер этого корневого тома составляет 245760 блоков по 512 байт. [.filename]#/dev/da1h#, содержащий вторую реплику этого корневого тома, имеет симметричную конфигурацию. Метка bsdlabel для этих устройств может выглядеть следующим образом: [source, shell] .... ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*) .... Можно заметить, что параметр `size` для поддельного раздела `a` совпадает с указанным выше значением, в то время как параметр `offset` представляет собой сумму смещения внутри раздела [.filename]#vinum# `h` и смещения этого раздела в устройстве или слайсе. Это стандартная настройка, необходимая для избежания проблемы, описанной в crossref:vinum[vinum-root-panic, Nothing Boots, the Bootstrap Panics]. Весь раздел `a` полностью находится внутри раздела `h`, содержащего все данные [.filename]#vinum# для этого устройства. -В приведенном выше примере все устройство выделено под [.filename]#vinum#, и не осталось корневого раздела, существовавшего до [.filename]#vinum#. +В приведённом выше примере все устройство выделено под [.filename]#vinum#, и не осталось корневого раздела, существовавшего до [.filename]#vinum#. === Устранение неполадок Следующий список содержит несколько известных подводных камней и их решения. ==== Загрузчик системы загружается, но система не запускается Если по какой-либо причине система не продолжает загрузку, процесс можно прервать, нажав kbd:[space] при появлении 10-секундного предупреждения. Переменную загрузчика `vinum.autostart` можно проверить, введя команду `show`, и изменить с помощью `set` или `unset`. -Если модуль ядра [.filename]#vinum# еще не был в списке модулей для автоматической загрузки, введите `load geom_vinum`. +Если модуль ядра [.filename]#vinum# ещё не был в списке модулей для автоматической загрузки, введите `load geom_vinum`. Когда всё готово, процесс загрузки можно продолжить, введя `boot -as`, где `-as` указывает ядру запросить корневую файловую систему для монтирования (`-a`) и остановить процесс загрузки в однопользовательском режиме (`-s`), при этом корневая файловая система монтируется в режиме только для чтения. Таким образом, даже если смонтирован только один слой многокомпонентного тома, не возникает риска несогласованности данных между слоями. На запрос о корневой файловой системе для монтирования можно ввести любое устройство, содержащее действительную корневую файловую систему. Если [.filename]#/etc/fstab# настроен правильно, по умолчанию должно быть что-то вроде `ufs:/dev/gvinum/root`. Типичным альтернативным выбором может быть что-то вроде `ufs:da0d`, что может быть гипотетическим разделом, содержащим корневую файловую систему до [.filename]#vinum#. Следует быть осторожным, если здесь вводится один из псевдонимов `a` разделов, чтобы он действительно ссылался на поддиски устройства [.filename]#vinum# root, потому что в зеркальной настройке это приведёт к монтированию только одной части зеркального корневого устройства. Если эта файловая система будет позже смонтирована в режиме чтения-записи, необходимо удалить другие плексы тома [.filename]#vinum# root, так как в противном случае эти плексы будут содержать несогласованные данные. ==== Только первичная загрузка Bootstrap Если [.filename]#/boot/loader# не загружается, но первичная загрузка всё ещё работает (это видно по одному дефису в левой части экрана сразу после начала процесса загрузки), можно попытаться прервать первичную загрузку, нажав kbd:[space]. Это остановит загрузку на extref:{handbook}boot[втором этапе, boot-boot1]. Здесь можно попытаться загрузиться с альтернативного раздела, например, с раздела, содержащего предыдущую корневую файловую систему, которая была перемещена из `a`. [[vinum-root-panic]] ==== Ничего не загружается, паника при загрузке Такая ситуация произойдет, если загрузчик был уничтожен при установке [.filename]#vinum#. К сожалению, [.filename]#vinum# случайно оставляет свободными только первые 4 КБ в начале своего раздела перед записью заголовочной информации [.filename]#vinum#. Однако, первая и вторая стадии загрузчика вместе с bsdlabel требуют 8 КБ. Поэтому, если раздел [.filename]#vinum# начинается со смещения 0 внутри слайса или диска, который должен быть загрузочным, установка [.filename]#vinum# повредит загрузчик. Аналогично, если описанная выше ситуация была исправлена загрузкой с "Fixit"-носителя, и загрузчик был переустановлен с помощью `bsdlabel -B`, как описано в extref:{handbook}boot[этапе два, boot-boot1], загрузчик повредит заголовок [.filename]#vinum#, и [.filename]#vinum# больше не сможет найти свои диски. Хотя фактические данные конфигурации [.filename]#vinum# или данные в томах [.filename]#vinum# не будут повреждены, и можно восстановить все данные, введя точно такую же конфигурацию [.filename]#vinum# снова, исправить ситуацию сложно. Необходимо переместить весь раздел [.filename]#vinum# как минимум на 4 КБ, чтобы заголовок [.filename]#vinum# и системный загрузчик больше не конфликтовали. diff --git a/documentation/content/ru/articles/vinum/_index.po b/documentation/content/ru/articles/vinum/_index.po index ed0dc23ab6..affce6fe8a 100644 --- a/documentation/content/ru/articles/vinum/_index.po +++ b/documentation/content/ru/articles/vinum/_index.po @@ -1,2260 +1,2260 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov , 2025. +# Vladlen Popolitov , 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-11-08 16:17+0000\n" -"PO-Revision-Date: 2025-11-12 04:45+0000\n" +"PO-Revision-Date: 2026-03-08 09:11+0000\n" "Last-Translator: Vladlen Popolitov \n" "Language-Team: Russian \n" "Language: ru\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && " "n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" "X-Generator: Weblate 4.17\n" #. type: YAML Front Matter: description #: documentation/content/en/articles/vinum/_index.adoc:1 #, no-wrap msgid "The vinum Volume Manager in FreeBSD" msgstr "Менеджер томов vinum в FreeBSD" #. The Vinum Volume Manager #. By Greg Lehey (grog at lemis dot com) #. Added to the Handbook by Hiten Pandya #. and Tom Rhodes #. For the FreeBSD Documentation Project #. type: Title = #: documentation/content/en/articles/vinum/_index.adoc:1 #: documentation/content/en/articles/vinum/_index.adoc:19 #, no-wrap msgid "The vinum Volume Manager" msgstr "Менеджер томов vinum" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:51 msgid "'''" msgstr "'''" #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:55 #, no-wrap msgid "Synopsis" msgstr "Обзор" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:62 msgid "" "No matter the type of disks, there are always potential problems. The disks " "can be too small, too slow, or too unreliable to meet the system's " "requirements. While disks are getting bigger, so are data storage " "requirements. Often a file system is needed that is bigger than a disk's " "capacity. Various solutions to these problems have been proposed and " "implemented." msgstr "" "Независимо от типа дисков, всегда существуют потенциальные проблемы. Диски " "могут быть слишком малы, слишком медленны или недостаточно надёжны для " "соответствия требованиям системы. Хотя диски становятся больше, требования " "к хранению данных также растут. Часто требуется файловая система, размер " "которой превышает емкость одного диска. Были предложены и реализованы " "различные решения этих проблем." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:66 msgid "" "One method is through the use of multiple, and sometimes redundant, disks. " "In addition to supporting various cards and controllers for hardware " "Redundant Array of Independent Disks RAID systems, the base FreeBSD system " "includes the [.filename]#vinum# volume manager, a block device driver that " "implements virtual disk drives and addresses these three problems. [." "filename]#vinum# provides more flexibility, performance, and reliability " "than traditional disk storage and implements `RAID`-0, `RAID`-1, and " "`RAID`-5 models, both individually and in combination." msgstr "" "Один из методов заключается в использовании нескольких, а иногда и " "избыточных дисков. Помимо поддержки различных карт и контроллеров для " "аппаратных систем RAID (Redundant Array of Independent Disks), базовая " "система FreeBSD включает менеджер томов [.filename]#vinum#, драйвер блочных " "устройств, который реализует виртуальные диски и решает эти три проблемы. [." "filename]#vinum# обеспечивает большую гибкость, производительность и " "надёжность по сравнению с традиционными системами хранения данных, а также " "реализует модели `RAID`-0, `RAID`-1 и `RAID`-5 как по отдельности, так и в " "комбинации." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:68 msgid "" "This chapter provides an overview of potential problems with traditional " "disk storage, and an introduction to the [.filename]#vinum# volume manager." msgstr "" "Эта глава предоставляет обзор потенциальных проблем с традиционным дисковым " "хранилищем и введение в менеджер томов [.filename]#vinum#." #. type: delimited block = 4 #: documentation/content/en/articles/vinum/_index.adoc:73 msgid "" "vinum is deprecated and is not present in FreeBSD 15.0 and later. Users are " "advised to migrate to man:gconcat[8], man:gmirror[8], man:gstripe[8], man:" "graid[8], or man:zfs[8]." msgstr "" "vinum устарел и отсутствует в FreeBSD 15.0 и более поздних версиях. " "Пользователям рекомендуется перейти на man:gconcat[8], man:gmirror[8], man:" "gstripe[8], man:graid[8] или man:zfs[8]." #. type: delimited block = 4 #: documentation/content/en/articles/vinum/_index.adoc:82 msgid "" "Starting with FreeBSD 5, [.filename]#vinum# has been rewritten to fit into " "the extref:{handbook}geom[GEOM architecture, geom], while retaining the " "original ideas, terminology, and on-disk metadata. This rewrite is called " "_gvinum_ (for _GEOM vinum_). While this chapter uses the term [." "filename]#vinum#, any command invocations should be performed with " "`gvinum`. The name of the kernel module has changed from the original [." "filename]#vinum.ko# to [.filename]#geom_vinum.ko#, and all device nodes " "reside under [.filename]#/dev/gvinum# instead of [.filename]#/dev/vinum#. " "As of FreeBSD 6, the original [.filename]#vinum# implementation is no longer " "available in the code base." msgstr "" "Начиная с FreeBSD 5, [.filename]#vinum# был переписан для интеграции в " "extref:{handbook}geom[архитектуру GEOM, geom-synopsis], сохраняя при этом " "оригинальные идеи, терминологию и метаданные на диске. Эта переработанная " "версия называется _gvinum_ (от _GEOM vinum_). Хотя в этой главе используется " "термин [.filename]#vinum#, все команды должны выполняться с помощью `gvinum`" ". Имя модуля ядра изменилось с оригинального [.filename]#vinum.ko# на [." "filename]#geom_vinum.ko#, а все узлы устройств находятся в [.filename]#/dev/" "gvinum# вместо [.filename]#/dev/vinum#. Начиная с FreeBSD 6, оригинальная " "реализация [.filename]#vinum# больше не доступна в кодовой базе." #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:85 #, no-wrap msgid "Access Bottlenecks" msgstr "Узкие места доступа" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:89 msgid "" "Modern systems frequently need to access data in a highly concurrent " "manner. For example, large FTP or HTTP servers can maintain thousands of " "concurrent sessions and have multiple 100 Mbit/s connections to the outside " "world, well beyond the sustained transfer rate of most disks." msgstr "" "Современные системы часто нуждаются в доступе к данным в условиях высокой " "параллельности. Например, крупные FTP- или HTTP-серверы могут поддерживать " "тысячи одновременных сеансов и иметь несколько 100 Мбит/с соединений с " "внешним миром, что значительно превышает устойчивую скорость передачи " "большинства дисков." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:93 msgid "" "Current disk drives can transfer data sequentially at up to 70 MB/s, but " "this value is of little importance in an environment where many independent " "processes access a drive, and where they may achieve only a fraction of " "these values. In such cases, it is more interesting to view the problem " "from the viewpoint of the disk subsystem. The important parameter is the " "load that a transfer places on the subsystem, or the time for which a " "transfer occupies the drives involved in the transfer." msgstr "" "Современные дисковые накопители могут передавать данные последовательно со " "скоростью до 70 МБ/с, но это значение имеет мало значения в среде, где " "множество независимых процессов обращаются к накопителю и могут достичь лишь " "доли этих значений. В таких случаях более интересно рассмотреть проблему с " "точки зрения дисковой подсистемы. Важным параметром является нагрузка, " "которую передача данных создаёт на подсистему, или время, в течение которого " "передача занимает задействованные накопители." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:96 msgid "" "In any disk transfer, the drive must first position the heads, wait for the " "first sector to pass under the read head, and then perform the transfer. " "These actions can be considered to be atomic as it does not make any sense " "to interrupt them." msgstr "" "При любом переносе данных на диск сначала необходимо позиционировать " "головки, дождаться, пока первый сектор окажется под считывающей головкой, а " "затем выполнить перенос. Эти действия можно считать атомарными, так как их " "прерывание не имеет смысла." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:101 msgid "" "[[vinum-latency]] Consider a typical transfer of about 10 kB: the current " "generation of high-performance disks can position the heads in an average of " "3.5 ms. The fastest drives spin at 15,000 rpm, so the average rotational " "latency (half a revolution) is 2 ms. At 70 MB/s, the transfer itself takes " "about 150 μs, almost nothing compared to the positioning time. In such a " "case, the effective transfer rate drops to a little over 1 MB/s and is " "clearly highly dependent on the transfer size." msgstr "" "[[vinum-latency]] Рассмотрим типичную передачу около 10 КБ: современные " "высокопроизводительные диски могут позиционировать головки в среднем за 3,5 " "мс. Самые быстрые диски вращаются со скоростью 15 000 об/мин, поэтому " "средняя задержка вращения (половина оборота) составляет 2 мс. При скорости " "70 МБ/с сама передача занимает около 150 мкс, что почти ничто по сравнению с " "временем позиционирования. В таком случае эффективная скорость передачи " "падает до чуть более 1 МБ/с и явно сильно зависит от размера передачи." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:104 msgid "" "The traditional and obvious solution to this bottleneck is \"more spindles" "\": rather than using one large disk, use several smaller disks with the " "same aggregate storage space. Each disk is capable of positioning and " "transferring independently, so the effective throughput increases by a " "factor close to the number of disks used." msgstr "" "Традиционное и очевидное решение этой проблемы — «больше дисков»: вместо " "одного большого диска использовать несколько дисков меньшего размера с тем " "же общим объёмом хранилища. Каждый диск способен позиционироваться и " "передавать данные независимо, поэтому эффективная пропускная способность " "увеличивается почти пропорционально количеству используемых дисков." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:108 msgid "" "The actual throughput improvement is smaller than the number of disks " "involved. Although each drive is capable of transferring in parallel, there " "is no way to ensure that the requests are evenly distributed across the " "drives. Inevitably the load on one drive will be higher than on another." msgstr "" "Фактическое увеличение пропускной способности меньше, чем количество " "задействованных дисков. Хотя каждый диск способен передавать данные " "параллельно, нет возможности гарантировать равномерное распределение " "запросов между дисками. Неизбежно нагрузка на один диск будет выше, чем на " "другой." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:116 msgid "" "The evenness of the load on the disks is strongly dependent on the way the " "data is shared across the drives. In the following discussion, it is " "convenient to think of the disk storage as a large number of data sectors " "which are addressable by number, rather like the pages in a book. The most " "obvious method is to divide the virtual disk into groups of consecutive " "sectors the size of the individual physical disks and store them in this " "manner, rather like taking a large book and tearing it into smaller " "sections. This method is called _concatenation_ and has the advantage that " "the disks are not required to have any specific size relationships. It " "works well when the access to the virtual disk is spread evenly about its " "address space. When access is concentrated on a smaller area, the " "improvement is less marked. crossref:vinum[vinum-concat, Concatenated " "Organization] illustrates the sequence in which storage units are allocated " "in a concatenated organization." msgstr "" "Равномерность нагрузки на диски сильно зависит от способа распределения " "данных по накопителям. В дальнейшем обсуждении удобно представлять дисковое " "хранилище как большое количество секторов данных, адресуемых по номерам, " "подобно страницам в книге. Наиболее очевидный метод — разделить виртуальный " "диск на группы последовательных секторов размером с отдельные физические " "диски и хранить их таким образом, как если бы большую книгу разорвали на " "меньшие разделы. Этот метод называется _объединением_ (конкатенацией) и " "имеет преимущество в том, что диски не требуют каких-либо определённых " "соотношений размеров. Он хорошо работает, когда доступ к виртуальному диску " "равномерно распределён по его адресному пространству. Если доступ " "сосредоточен на меньшей области, улучшение менее заметно. crossref:" "vinum[vinum-concat, Организация методом объединения] иллюстрирует " "последовательность выделения блоков хранения в организации методом " "объединения." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:118 #, no-wrap msgid "Concatenated Organization" msgstr "Организация методом объединения" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:119 #, no-wrap msgid "vinum-concat.png" msgstr "vinum-concat.png" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:125 msgid "" "An alternative mapping is to divide the address space into smaller, equal-" "sized components and store them sequentially on different devices. For " "example, the first 256 sectors may be stored on the first disk, the next 256 " "sectors on the next disk and so on. After filling the last disk, the " "process repeats until the disks are full. This mapping is called _striping_ " "or RAID-0." msgstr "" "Альтернативный метод распределения заключается в разделении адресного " "пространства на меньшие равные по размеру компоненты и их последовательном " "хранении на разных устройствах. Например, первые 256 секторов могут " "храниться на первом диске, следующие 256 секторов — на следующем диске и так " "далее. После заполнения последнего диска процесс повторяется, пока все диски " "не будут заполнены. Такой метод называется _чередованием (striping)_ или " "RAID-0." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:129 msgid "" "`RAID` offers various forms of fault tolerance, though RAID-0 is somewhat " "misleading as it provides no redundancy. Striping requires somewhat more " "effort to locate the data, and it can cause additional I/O load where a " "transfer is spread over multiple disks, but it can also provide a more " "constant load across the disks. crossref:vinum[vinum-striped, Striped " "Organization] illustrates the sequence in which storage units are allocated " "in a striped organization." msgstr "" "`RAID` предлагает различные формы отказоустойчивости, хотя RAID-0 несколько " "вводит в заблуждение, так как не обеспечивает избыточности. Разделение " "данных требует несколько больше усилий для их поиска и может создавать " "дополнительную нагрузку ввода-вывода, когда передача распределяется по " "нескольким дискам, но также может обеспечить более равномерную нагрузку на " "диски. crossref:vinum[vinum-striped,Организация методом чередования] " "иллюстрирует последовательность, в которой организуется распределение блоков " "хранения с чередованием." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:131 #, no-wrap msgid "Striped Organization" msgstr "Организация методом чередования" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:132 #, no-wrap msgid "vinum-striped.png" msgstr "vinum-striped.png" #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:135 #, no-wrap msgid "Data Integrity" msgstr "Целостность данных" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:140 msgid "" "The final problem with disks is that they are unreliable. Although " "reliability has increased tremendously over the last few years, disk drives " "are still the most likely core component of a server to fail. When they do, " "the results can be catastrophic and replacing a failed disk drive and " "restoring data can result in server downtime." msgstr "" "Последняя проблема с дисками заключается в их ненадёжности. Хотя надёжность " "значительно повысилась за последние годы, дисковые накопители остаются " "наиболее вероятным компонентом сервера, который может выйти из строя. Когда " "это происходит, последствия могут быть катастрофическими, а замена вышедшего " "из строя диска и восстановление данных могут привести к простою сервера." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:143 msgid "" "One approach to this problem is _mirroring_, or `RAID-1`, which keeps two " "copies of the data on different physical hardware. Any write to the volume " "writes to both disks; a read can be satisfied from either, so if one drive " "fails, the data is still available on the other drive." msgstr "" "Один из подходов к этой проблеме — _зеркалирование_, или `RAID-1`, при " "котором данные хранятся в двух экземплярах на разных физических носителях. " "Любая запись на том записывается на оба диска; чтение может выполняться с " "любого из них, поэтому при отказе одного диска данные остаются доступны на " "другом." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:145 msgid "Mirroring has two problems:" msgstr "Зеркалирование имеет две проблемы:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:147 msgid "It requires twice as much disk storage as a non-redundant solution." msgstr "" "Требуется в два раза больше дискового пространства, чем для решения без " "избыточности." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:148 msgid "" "Writes must be performed to both drives, so they take up twice the bandwidth " "of a non-mirrored volume. Reads do not suffer from a performance penalty and " "can even be faster." msgstr "" "Запись должна выполняться на оба диска, поэтому она занимает в два раза " "больше пропускной способности, чем в незеркалированном томе. Чтение не " "страдает от потери производительности и может быть даже быстрее." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:155 msgid "" "An alternative solution is _parity_, implemented in `RAID` levels 2, 3, 4 " "and 5. Of these, `RAID-5` is the most interesting. As implemented in [." "filename]#vinum#, it is a variant on a striped organization which dedicates " "one block of each stripe to parity one of the other blocks. As implemented " "by [.filename]#vinum#, a `RAID-5` plex is similar to a striped plex, except " "that it implements `RAID-5` by including a parity block in each stripe. As " "required by `RAID-5`, the location of this parity block changes from one " "stripe to the next. The numbers in the data blocks indicate the relative " "block numbers." msgstr "" "Альтернативным решением является _чётность_, реализованная в уровнях `RAID` " "2, 3, 4 и 5. Из них `RAID-5` представляет наибольший интерес. В реализации [." "filename]#vinum# это вариант организации с чередованием, где один блок " "каждой полосы выделяется под чётность одного из других блоков. В реализации [" ".filename]#vinum# плекс `RAID-5` аналогичен плексу с чередованием, за " "исключением того, что он реализует `RAID-5`, включая блок чётности в каждую " "полосу. Как требуется в `RAID-5`, расположение этого блока чётности меняется " "от одной полосы к другой. Числа в блоках данных обозначают относительные " "номера блоков." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:157 #, no-wrap msgid "`RAID`-5 Organization" msgstr "Организация `RAID`-5" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:158 #, no-wrap msgid "vinum-raid5-org.png" msgstr "vinum-raid5-org.png" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:163 msgid "" "Compared to mirroring, `RAID-5` has the advantage of requiring significantly " "less storage space. Read access is similar to that of striped " "organizations, but write access is significantly slower, approximately 25% " "of the read performance. If one drive fails, the array can continue to " "operate in degraded mode where a read from one of the remaining accessible " "drives continues normally, but a read from the failed drive is recalculated " "from the corresponding block from all the remaining drives." msgstr "" "По сравнению с зеркалированием, `RAID-5` имеет преимущество в виде " -"значительно меньшего требуемого объема хранилища. Скорость чтения аналогична " +"значительно меньшего требуемого объёма хранилища. Скорость чтения аналогична " "таковой при чередующейся организации, но скорость записи значительно ниже — " "примерно 25% от скорости чтения. Если один диск выходит из строя, массив " "может продолжать работу в деградировавшем режиме, при котором чтение с " "оставшихся доступных дисков продолжается в обычном режиме, а чтение с " "отказавшего диска пересчитывается из соответствующих блоков всех оставшихся " "дисков." #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:165 #, no-wrap msgid "[.filename]#vinum# Objects" msgstr "Объекты [.filename]#vinum#" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:168 msgid "" "To address these problems, [.filename]#vinum# implements a four-level " "hierarchy of objects:" msgstr "" "Для решения этих проблем [.filename]#vinum# реализует четырёхуровневую " "иерархию объектов:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:170 msgid "" "The most visible object is the virtual disk, called a _volume_. Volumes have " "essentially the same properties as a UNIX(R) disk drive, though there are " "some minor differences. For one, they have no size limitations." msgstr "" "Наиболее заметным объектом является виртуальный диск, называемый _томом_. " "Том обладает практически теми же свойствами, что и UNIX(R) дисковый " "накопитель, хотя есть некоторые незначительные отличия. Например, у тома нет " "ограничений по размеру." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:171 msgid "" "Volumes are composed of _plexes_, each of which represent the total address " "space of a volume. This level in the hierarchy provides redundancy. Think of " "plexes as individual disks in a mirrored array, each containing the same " "data." msgstr "" "Тома состоят из _плексов_, каждый из которых представляет полное адресное " "пространство тома. Этот уровень в иерархии обеспечивает избыточность. Можно " "представить плексы как отдельные диски в зеркальном массиве, каждый из " "которых содержит одинаковые данные." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:172 msgid "" "Since [.filename]#vinum# exists within the UNIX(R) disk storage framework, " "it would be possible to use UNIX(R) partitions as the building block for " "multi-disk plexes. In fact, this turns out to be too inflexible as UNIX(R) " "disks can have only a limited number of partitions. Instead, [." "filename]#vinum# subdivides a single UNIX(R) partition, the _drive_, into " "contiguous areas called _subdisks_, which are used as building blocks for " "plexes." msgstr "" "Поскольку [.filename]#vinum# существует в рамках системы хранения данных " "UNIX(R), можно было бы использовать разделы UNIX(R) в качестве строительных " "блоков для многодисковых plexes. Однако на практике это оказывается слишком " "негибким, так как диски UNIX(R) могут иметь только ограниченное количество " "разделов. Вместо этого [.filename]#vinum# разбивает единственный раздел " "UNIX(R), называемый _дисковый раздел (drive)_, на непрерывные области, " "называемые _поддисками (subdisk)_, которые используются как строительные " "блоки для плексов." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:173 msgid "" "Subdisks reside on [.filename]#vinum#_drives_, currently UNIX(R) partitions. " "[.filename]#vinum# drives can contain any number of subdisks. With the " "exception of a small area at the beginning of the drive, which is used for " "storing configuration and state information, the entire drive is available " "for data storage." msgstr "" "Поддиски располагаются на _дисковых разделах_ [.filename]#vinum#, в " "настоящее время это разделы UNIX(R). Разделы [.filename]#vinum# могут " "содержать любое количество поддисков. За исключением небольшой области в " "начале раздела, которая используется для хранения конфигурации и состояния, " "весь раздел доступен для хранения данных." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:175 msgid "" "The following sections describe the way these objects provide the " "functionality required of [.filename]#vinum#." msgstr "" "Следующие разделы статьи описывают, каким образом эти объекты обеспечивают " "функциональность, требуемую для [.filename]#vinum#." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:176 #, no-wrap msgid "Volume Size Considerations" -msgstr "Учет размера томов" +msgstr "Учёт размера томов" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:180 msgid "" "Plexes can include multiple subdisks spread over all drives in the [." "filename]#vinum# configuration. As a result, the size of an individual " "drive does not limit the size of a plex or a volume." msgstr "" "Плексы могут включать несколько поддисков, распределенных по всем дискам в " "конфигурации [.filename]#vinum#. В результате, размер отдельного диска не " "ограничивает размер плекса или тома." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:181 #, no-wrap msgid "Redundant Data Storage" msgstr "Избыточное хранение данных" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:186 msgid "" "[.filename]#vinum# implements mirroring by attaching multiple plexes to a " "volume. Each plex is a representation of the data in a volume. A volume " "may contain between one and eight plexes." msgstr "" "[.filename]#vinum# реализует зеркалирование путем присоединения нескольких " "плекс к тому. Каждый плекс представляет данные в томе. Том может содержать " "от одного до восьми плексов." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:189 msgid "" "Although a plex represents the complete data of a volume, it is possible for " "parts of the representation to be physically missing, either by design (by " "not defining a subdisk for parts of the plex) or by accident (as a result of " "the failure of a drive). As long as at least one plex can provide the data " "for the complete address range of the volume, the volume is fully functional." msgstr "" "Хотя плекс представляет полные данные тома, возможно, что некоторые части " "представления физически отсутствуют — либо по замыслу (если поддиск для " "частей плекса не определён), либо случайно (в результате выхода диска из " "строя). До тех пор, пока хотя бы один плекс может предоставить данные для " "полного адресного пространства тома, том остаётся полностью работоспособным." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:190 #, no-wrap msgid "Which Plex Organization?" msgstr "Какую организацию плексов выбрать?" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:193 msgid "" "[.filename]#vinum# implements both concatenation and striping at the plex " "level:" msgstr "" "[.filename]#vinum# реализует как объединение, так и чередование на уровне " "плекс:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:195 msgid "" "A _concatenated plex_ uses the address space of each subdisk in turn. " "Concatenated plexes are the most flexible as they can contain any number of " "subdisks, and the subdisks may be of different length. The plex may be " "extended by adding additional subdisks. They require less CPU time than " "striped plexes, though the difference in CPU overhead is not measurable. On " "the other hand, they are most susceptible to hot spots, where one disk is " "very active and others are idle." msgstr "" "_Плекс с объединением_ использует адресное пространство каждого поддиска по " "очереди. Объединённые плексы являются наиболее гибкими, так как могут " "содержать любое количество поддисков, а поддиски могут быть разной длины. " "Плекс может быть расширен путём добавления дополнительных поддисков. Они " "требуют меньше процессорного времени, чем чередующиеся плексы, хотя разница " "в нагрузке на процессор незначительна. С другой стороны, они наиболее " "подвержены \"горячим точкам\", когда один диск очень активен, а другие " "простаивают." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:196 msgid "" "A _striped plex_ stripes the data across each subdisk. The subdisks must all " "be the same size and there must be at least two subdisks to distinguish it " "from a concatenated plex. The greatest advantage of striped plexes is that " "they reduce hot spots. By choosing an optimum sized stripe, about 256 kB, " "the load can be evened out on the component drives. Extending a plex by " "adding new subdisks is so complicated that [.filename]#vinum# does not " "implement it." msgstr "" "_Плекс с чередованием_ распределяет данные по каждому поддиску. Поддиски " "должны быть одного размера, и их должно быть как минимум два, чтобы отличить " "такой плекс от объединенного. Главное преимущество чередующихся плексов в " "том, что они уменьшают вероятность появления \"горячих точек\". Выбрав " "оптимальный размер полосы (около 256 КБ), можно равномерно распределить " "нагрузку на диски – компоненты системы. Расширение плекса путем добавления " "новых поддисков настолько сложно, что [.filename]#vinum# не реализует эту " "возможность." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:198 msgid "" "crossref:vinum[vinum-comparison, [.filename]#vinum# Plex Organizations] " "summarizes the advantages and disadvantages of each plex organization." msgstr "" "crossref:vinum[vinum-comparison, Организации плексов в [.filename]#vinum#] " "обобщает преимущества и недостатки каждой организации плексов." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:200 #, no-wrap msgid "[.filename]#vinum# Plex Organizations" msgstr "Организации плексов в [.filename]#vinum#" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:204 #, no-wrap msgid "Plex type" msgstr "Тип плекса" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:205 #, no-wrap msgid "Minimum subdisks" msgstr "Минимальное количество поддисков" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:206 #, no-wrap msgid "Can add subdisks" msgstr "Может добавлять поддиски" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:207 #, no-wrap msgid "Must be equal size" msgstr "Должен быть равного размера" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:209 #, no-wrap msgid "Application" msgstr "Приложение" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:210 #, no-wrap msgid "concatenated" msgstr "объединённый" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:211 #, no-wrap msgid "1" msgstr "1" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:212 #: documentation/content/en/articles/vinum/_index.adoc:219 #, no-wrap msgid "yes" msgstr "да" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:213 #: documentation/content/en/articles/vinum/_index.adoc:218 #, no-wrap msgid "no" msgstr "no" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:215 #, no-wrap msgid "Large data storage with maximum placement flexibility and moderate performance" msgstr "Крупное хранилище данных с максимальной гибкостью размещения и умеренной производительностью" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:216 #, no-wrap msgid "striped" msgstr "чередуемый" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:217 #, no-wrap msgid "2" msgstr "2" #. type: Table #: documentation/content/en/articles/vinum/_index.adoc:220 #, no-wrap msgid "High performance in combination with highly concurrent access" msgstr "Высокая производительность в сочетании с высокопараллельным доступом" #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:223 #, no-wrap msgid "Some Examples" msgstr "Некоторые примеры" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:229 msgid "" "[.filename]#vinum# maintains a _configuration database_ which describes the " "objects known to an individual system. Initially, the user creates the " "configuration database from one or more configuration files using man:" "gvinum[8]. [.filename]#vinum# stores a copy of its configuration database " "on each disk _device_ under its control. This database is updated on each " "state change, so that a restart accurately restores the state of each [." "filename]#vinum# object." msgstr "" "[.filename]#vinum# поддерживает _базу данных конфигурации_, которая " "описывает объекты, известные конкретной системе. Первоначально пользователь " "создает базу данных конфигурации из одного или нескольких конфигурационных " "файлов с помощью man:gvinum[8]. [.filename]#vinum# хранит копию своей базы " "данных конфигурации на каждом _устройстве_ диска, находящемся под его " "управлением. Эта база данных обновляется при каждом изменении состояния, так " "что перезапуск точно восстанавливает состояние каждого объекта [." "filename]#vinum#." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:230 #, no-wrap msgid "The Configuration File" msgstr "Файл конфигурации" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:234 msgid "" "The configuration file describes individual [.filename]#vinum# objects. The " "definition of a simple volume might be:" msgstr "" "Файл конфигурации описывает отдельные объекты [.filename]#vinum#. " "Определение простого тома может выглядеть следующим образом:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:241 #, no-wrap msgid "" " drive a device /dev/da3h\n" " volume myvol\n" " plex org concat\n" " sd length 512m drive a\n" msgstr "" " drive a device /dev/da3h\n" " volume myvol\n" " plex org concat\n" " sd length 512m drive a\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:244 msgid "This file describes four [.filename]#vinum# objects:" msgstr "Этот файл описывает четыре объекта [.filename]#vinum#:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:246 msgid "" "The _drive_ line describes a disk partition (_drive_) and its location " "relative to the underlying hardware. It is given the symbolic name _a_. This " "separation of symbolic names from device names allows disks to be moved from " "one location to another without confusion." msgstr "" "Строка _drive_ описывает раздел диска (_drive_) и его расположение " "относительно оборудования, на котором он расположен. Ему присваивается " "символическое имя _a_. Такое разделение символических имён от имён устройств " "позволяет перемещать диски из одного места в другое без путаницы." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:247 msgid "" "The _volume_ line describes a volume. The only required attribute is the " "name, in this case _myvol_." msgstr "" "Строка _volume_ описывает том. Единственный обязательный атрибут — это имя, " "в данном случае _myvol_." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:248 msgid "" "The _plex_ line defines a plex. The only required parameter is the " "organization, in this case _concat_. No name is necessary as the system " "automatically generates a name from the volume name by adding the suffix _." "px_, where _x_ is the number of the plex in the volume. Thus this plex will " "be called _myvol.p0_." msgstr "" "Строка _plex_ определяет плекс. Единственный обязательный параметр — это " "организация, в данном случае _concat_. Имя не требуется, так как система " "автоматически генерирует его из имени тома, добавляя суффикс _.px_, где _x_ " "— номер плекса в томе. Таким образом, этот плекс будет называться _myvol.p0_." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:249 msgid "" "The _sd_ line describes a subdisk. The minimum specifications are the name " "of a drive on which to store it, and the length of the subdisk. No name is " "necessary as the system automatically assigns names derived from the plex " "name by adding the suffix _.sx_, where _x_ is the number of the subdisk in " "the plex. Thus [.filename]#vinum# gives this subdisk the name _myvol.p0.s0_." msgstr "" "Строка _sd_ описывает поддиск. Минимальные требования — это имя диска для " "его хранения и длина поддиска. Имя не обязательно, так как система " "автоматически назначает имена, производные от имени плекса, добавляя суффикс " "_.sx_, где _x_ — номер поддиска в плексе. Таким образом, [.filename]#vinum# " "присваивает этому поддиску имя _myvol.p0.s0_." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:251 msgid "" "After processing this file, man:gvinum[8] produces the following output:" msgstr "" "После обработки этого файла команда man:gvinum[8] выводит следующий " "результат:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:261 #, no-wrap msgid "" "# gvinum -> create config1\n" "Configuration summary\n" "Drives: 1 (4 configured)\n" "Volumes: 1 (4 configured)\n" "Plexes: 1 (8 configured)\n" "Subdisks: 1 (16 configured)\n" msgstr "" "# gvinum -> create config1\n" "Configuration summary\n" "Drives: 1 (4 configured)\n" "Volumes: 1 (4 configured)\n" "Plexes: 1 (8 configured)\n" "Subdisks: 1 (16 configured)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:263 #, no-wrap msgid " D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%)\n" msgstr " D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:265 #, no-wrap msgid " V myvol State: up Plexes: 1 Size: 512 MB\n" msgstr " V myvol State: up Plexes: 1 Size: 512 MB\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:267 #, no-wrap msgid " P myvol.p0 C State: up Subdisks: 1 Size: 512 MB\n" msgstr " P myvol.p0 C State: up Subdisks: 1 Size: 512 MB\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:269 #, no-wrap msgid " S myvol.p0.s0 State: up PO: 0 B Size: 512 MB\n" msgstr " S myvol.p0.s0 State: up PO: 0 B Size: 512 MB\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:273 msgid "" "This output shows the brief listing format of man:gvinum[8]. It is " "represented graphically in crossref:vinum[vinum-simple-vol, A Simple [." "filename]#vinum# Volume]." msgstr "" "Этот вывод показывает краткий формат списка man:gvinum[8]. Он представлен " "графически в crossref:vinum[vinum-simple-vol, Простой том [." "filename]#vinum#]." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:275 #, no-wrap msgid "A Simple [.filename]#vinum# Volume" msgstr "Простой том [.filename]#vinum#" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:276 #, no-wrap msgid "vinum-simple-vol.png" msgstr "vinum-simple-vol.png" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:280 msgid "" "This figure, and the ones which follow, represent a volume, which contains " "the plexes, which in turn contains the subdisks. In this example, the " "volume contains one plex, and the plex contains one subdisk." msgstr "" "Этот рисунок и следующие представляют том, который содержит плексы, которые, " "в свою очередь, содержат поддиски. В этом примере том содержит один плекс, а " "плекс содержит один поддиск." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:285 msgid "" "This particular volume has no specific advantage over a conventional disk " "partition. It contains a single plex, so it is not redundant. The plex " "contains a single subdisk, so there is no difference in storage allocation " "from a conventional disk partition. The following sections illustrate " "various more interesting configuration methods." msgstr "" "Этот конкретный том не имеет особых преимуществ по сравнению с обычным " "разделом диска. Он содержит один плекс, поэтому не является избыточным. " "Плекс содержит один поддиск, поэтому нет различий в распределении хранилища " "по сравнению с обычным разделом диска. В следующих разделах показаны " "различные более интересные методы конфигурации." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:286 #, no-wrap msgid "Increased Resilience: Mirroring" msgstr "Увеличенная отказоустойчивость: зеркалирование" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:291 msgid "" "The resilience of a volume can be increased by mirroring. When laying out a " "mirrored volume, it is important to ensure that the subdisks of each plex " "are on different drives, so that a drive failure will not take down both " "plexes. The following configuration mirrors a volume:" msgstr "" "Устойчивость тома может быть повышена за счёт зеркалирования. При создании " "зеркального тома важно убедиться, что поддиски каждого плекса находятся на " "разных дисках, чтобы выход из строя одного диска не затронул оба плекса. " "Следующая конфигурация создаёт зеркальный том:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:300 #, no-wrap msgid "" "\tdrive b device /dev/da4h\n" "\tvolume mirror\n" " plex org concat\n" " sd length 512m drive a\n" "\t plex org concat\n" "\t sd length 512m drive b\n" msgstr "" "\tdrive b device /dev/da4h\n" "\tvolume mirror\n" " plex org concat\n" " sd length 512m drive a\n" "\t plex org concat\n" "\t sd length 512m drive b\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:304 msgid "" "In this example, it was not necessary to specify a definition of drive _a_ " "again, since [.filename]#vinum# keeps track of all objects in its " "configuration database. After processing this definition, the configuration " "looks like:" msgstr "" "В этом примере не потребовалось снова указывать определение диска _a_, " "поскольку [.filename]#vinum# отслеживает все объекты в своей базе данных " "конфигурации. После обработки этого определения конфигурация выглядит " "следующим образом:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:312 #, no-wrap msgid "" "\tDrives: 2 (4 configured)\n" "\tVolumes: 2 (4 configured)\n" "\tPlexes: 3 (8 configured)\n" "\tSubdisks: 3 (16 configured)\n" msgstr "" "\tDrives: 2 (4 configured)\n" "\tVolumes: 2 (4 configured)\n" "\tPlexes: 3 (8 configured)\n" "\tSubdisks: 3 (16 configured)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:315 #, no-wrap msgid "" "\tD a State: up Device /dev/da3h Avail: 1549/2573 MB (60%)\n" "\tD b State: up Device /dev/da4h Avail: 2061/2573 MB (80%)\n" msgstr "" "\tD a State: up Device /dev/da3h Avail: 1549/2573 MB (60%)\n" "\tD b State: up Device /dev/da4h Avail: 2061/2573 MB (80%)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:318 #, no-wrap msgid "" " V myvol State: up Plexes: 1 Size: 512 MB\n" " V mirror State: up Plexes: 2 Size: 512 MB\n" msgstr "" " V myvol State: up Plexes: 1 Size: 512 MB\n" " V mirror State: up Plexes: 2 Size: 512 MB\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:322 #, no-wrap msgid "" " P myvol.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB\n" msgstr "" " P myvol.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:326 #, no-wrap msgid "" " S myvol.p0.s0 State: up PO: 0 B Size: 512 MB\n" "\tS mirror.p0.s0 State: up PO: 0 B Size: 512 MB\n" "\tS mirror.p1.s0 State: empty PO: 0 B Size: 512 MB\n" msgstr "" " S myvol.p0.s0 State: up PO: 0 B Size: 512 MB\n" "\tS mirror.p0.s0 State: up PO: 0 B Size: 512 MB\n" "\tS mirror.p1.s0 State: empty PO: 0 B Size: 512 MB\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:329 msgid "" "crossref:vinum[vinum-mirrored-vol, A Mirrored [.filename]#vinum# Volume] " "shows the structure graphically." msgstr "" "crossref:vinum[vinum-mirrored-vol, Зеркальный том [.filename]#vinum#] " "графически отображает структуру." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:331 #, no-wrap msgid "A Mirrored [.filename]#vinum# Volume" msgstr "Зеркальный том [.filename]#vinum#" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:332 #, no-wrap msgid "vinum-mirrored-vol.png" msgstr "vinum-mirrored-vol.png" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:336 msgid "" "In this example, each plex contains the full 512 MB of address space. As in " "the previous example, each plex contains only a single subdisk." msgstr "" "В этом примере каждый плекс содержит полные 512 МБ адресного пространства. " "Как и в предыдущем примере, каждый плекс содержит только один поддиск." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:337 #, no-wrap msgid "Optimizing Performance" msgstr "Оптимизация производительности" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:342 msgid "" "The mirrored volume in the previous example is more resistant to failure " "than an unmirrored volume, but its performance is less as each write to the " "volume requires a write to both drives, using up a greater proportion of the " "total disk bandwidth. Performance considerations demand a different " "approach: instead of mirroring, the data is striped across as many disk " "drives as possible. The following configuration shows a volume with a plex " "striped across four disk drives:" msgstr "" "Зеркальный том в предыдущем примере более устойчив к сбоям, чем незеркальный " "том, но его производительность ниже, так как каждая запись в том требует " "записи на оба диска, используя большую часть общей пропускной способности " "дисков. Соображения производительности требуют другого подхода: вместо " "зеркалирования данные распределяются по полосам на максимально возможное " "количество дисков. Следующая конфигурация показывает том с плексом, " "распределённым по полосам на четырёх дисках:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:353 #, no-wrap msgid "" " drive c device /dev/da5h\n" "\tdrive d device /dev/da6h\n" "\tvolume stripe\n" "\tplex org striped 512k\n" "\t sd length 128m drive a\n" "\t sd length 128m drive b\n" "\t sd length 128m drive c\n" "\t sd length 128m drive d\n" msgstr "" " drive c device /dev/da5h\n" "\tdrive d device /dev/da6h\n" "\tvolume stripe\n" "\tplex org striped 512k\n" "\t sd length 128m drive a\n" "\t sd length 128m drive b\n" "\t sd length 128m drive c\n" "\t sd length 128m drive d\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:357 msgid "" "As before, it is not necessary to define the drives which are already known " "to [.filename]#vinum#. After processing this definition, the configuration " "looks like:" msgstr "" "Как и ранее, не нужно определять диски, которые уже известны [." "filename]#vinum#. После обработки этого определения конфигурация выглядит " "следующим образом:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:365 #, no-wrap msgid "" "\tDrives: 4 (4 configured)\n" "\tVolumes: 3 (4 configured)\n" "\tPlexes: 4 (8 configured)\n" "\tSubdisks: 7 (16 configured)\n" msgstr "" "\tDrives: 4 (4 configured)\n" "\tVolumes: 3 (4 configured)\n" "\tPlexes: 4 (8 configured)\n" "\tSubdisks: 7 (16 configured)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:370 #, no-wrap msgid "" " D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%)\n" " D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%)\n" " D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%)\n" " D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%)\n" msgstr "" " D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%)\n" " D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%)\n" " D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%)\n" " D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:374 #, no-wrap msgid "" " V myvol State: up Plexes: 1 Size: 512 MB\n" " V mirror State: up Plexes: 2 Size: 512 MB\n" " V striped State: up Plexes: 1 Size: 512 MB\n" msgstr "" " V myvol State: up Plexes: 1 Size: 512 MB\n" " V mirror State: up Plexes: 2 Size: 512 MB\n" " V striped State: up Plexes: 1 Size: 512 MB\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:379 #, no-wrap msgid "" " P myvol.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB\n" " P striped.p1 State: up Subdisks: 1 Size: 512 MB\n" msgstr "" " P myvol.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p0 C State: up Subdisks: 1 Size: 512 MB\n" " P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB\n" " P striped.p1 State: up Subdisks: 1 Size: 512 MB\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:387 #, no-wrap msgid "" " S myvol.p0.s0 State: up PO: 0 B Size: 512 MB\n" " S mirror.p0.s0 State: up PO: 0 B Size: 512 MB\n" " S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB\n" " S striped.p0.s0 State: up PO: 0 B Size: 128 MB\n" " S striped.p0.s1 State: up PO: 512 kB Size: 128 MB\n" " S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB\n" " S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB\n" msgstr "" " S myvol.p0.s0 State: up PO: 0 B Size: 512 MB\n" " S mirror.p0.s0 State: up PO: 0 B Size: 512 MB\n" " S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB\n" " S striped.p0.s0 State: up PO: 0 B Size: 128 MB\n" " S striped.p0.s1 State: up PO: 512 kB Size: 128 MB\n" " S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB\n" " S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB\n" #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:390 #, no-wrap msgid "A Striped [.filename]#vinum# Volume" msgstr "Том [.filename]#vinum# с чередованием" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:391 #, no-wrap msgid "vinum-striped-vol.png" msgstr "vinum-striped-vol.png" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:395 msgid "" "This volume is represented in crossref:vinum[vinum-striped-vol, A Striped [." "filename]#vinum# Volume]. The darkness of the stripes indicates the " "position within the plex address space, where the lightest stripes come " "first and the darkest last." msgstr "" "Этот том представлен на схеме crossref:vinum[vinum-striped-vol, Том [." "filename]#vinum# с чередованием]. Темнота полос указывает на позицию в " "адресном пространстве плекса, где самые светлые полосы идут первыми, а самые " "темные — последними." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:396 #, no-wrap msgid "Resilience and Performance" msgstr "Устойчивость и производительность" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:400 msgid "" "[[vinum-resilience]]With sufficient hardware, it is possible to build " "volumes which show both increased resilience and increased performance " "compared to standard UNIX(R) partitions. A typical configuration file might " "be:" msgstr "" "[[vinum-resilience]]При достаточном аппаратном обеспечении можно создать " "тома, которые демонстрируют как повышенную отказоустойчивость, так и " "увеличенную производительность по сравнению со стандартными разделами " "UNIX(R). Типичный конфигурационный файл может выглядеть так:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:416 #, no-wrap msgid "" "\tvolume raid10\n" " plex org striped 512k\n" " sd length 102480k drive a\n" " sd length 102480k drive b\n" " sd length 102480k drive c\n" " sd length 102480k drive d\n" " sd length 102480k drive e\n" " plex org striped 512k\n" " sd length 102480k drive c\n" " sd length 102480k drive d\n" " sd length 102480k drive e\n" " sd length 102480k drive a\n" " sd length 102480k drive b\n" msgstr "" "\tvolume raid10\n" " plex org striped 512k\n" " sd length 102480k drive a\n" " sd length 102480k drive b\n" " sd length 102480k drive c\n" " sd length 102480k drive d\n" " sd length 102480k drive e\n" " plex org striped 512k\n" " sd length 102480k drive c\n" " sd length 102480k drive d\n" " sd length 102480k drive e\n" " sd length 102480k drive a\n" " sd length 102480k drive b\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:420 msgid "" "The subdisks of the second plex are offset by two drives from those of the " "first plex. This helps to ensure that writes do not go to the same subdisks " "even if a transfer goes over two drives." msgstr "" "Поддиски второго плекса смещены на два диска относительно поддисков первого " "плекса. Это помогает гарантировать, что записи не будут направляться на одни " "и те же поддиски, даже если передача затронет два диска." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:422 msgid "" "crossref:vinum[vinum-raid10-vol, A Mirrored, Striped [.filename]#vinum# " "Volume] represents the structure of this volume." msgstr "" "crossref:vinum[vinum-raid10-vol, Том [.filename]#vinum# c зеркалированием и " "чередованием] представляет структуру этого тома." #. type: Block title #: documentation/content/en/articles/vinum/_index.adoc:424 #, no-wrap msgid "A Mirrored, Striped [.filename]#vinum# Volume" msgstr "Том [.filename]#vinum# c зеркалированием и чередованием" #. type: Target for macro image #: documentation/content/en/articles/vinum/_index.adoc:425 #, no-wrap msgid "vinum-raid10-vol.png" msgstr "vinum-raid10-vol.png" #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:428 #, no-wrap msgid "Object Naming" msgstr "Именование объектов" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:432 msgid "" "[.filename]#vinum# assigns default names to plexes and subdisks, although " "they may be overridden. Overriding the default names is not recommended as " "it does not bring a significant advantage and it can cause confusion." msgstr "" "[.filename]#vinum# назначает стандартные имена для плексов и поддисков, хотя " "их можно изменить. Не рекомендуется изменять стандартные имена, так как это " -"не дает значительных преимуществ и может вызвать путаницу." +"не даёт значительных преимуществ и может вызвать путаницу." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:435 msgid "" "Names may contain any non-blank character, but it is recommended to restrict " "them to letters, digits and the underscore characters. The names of " "volumes, plexes, and subdisks may be up to 64 characters long, and the names " "of drives may be up to 32 characters long." msgstr "" "Имена могут содержать любые непустые символы, но рекомендуется " "ограничиваться буквами, цифрами и символами подчёркивания. Имена томов, " "плексов и поддисков могут быть длиной до 64 символов, а имена дисков — до 32 " "символов." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:438 msgid "" "[.filename]#vinum# objects are assigned device nodes in the hierarchy [." "filename]#/dev/gvinum#. The configuration shown above would cause [." "filename]#vinum# to create the following device nodes:" msgstr "" "Объектам [.filename]#vinum# назначаются узлы устройств в иерархии [." "filename]#/dev/gvinum#. Приведённая выше конфигурация приведёт к тому, что [." "filename]#vinum# создаст следующие узлы устройств:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:440 msgid "" "Device entries for each volume. These are the main devices used by [." "filename]#vinum#. The configuration above would include the devices [." "filename]#/dev/gvinum/myvol#, [.filename]#/dev/gvinum/mirror#, [.filename]#/" "dev/gvinum/striped#, [.filename]#/dev/gvinum/raid5# and [.filename]#/dev/" "gvinum/raid10#." msgstr "" "Записи устройств для каждого тома. Это основные устройства, используемые [." "filename]#vinum#. Приведённая конфигурация включает устройства [.filename]#/" "dev/gvinum/myvol#, [.filename]#/dev/gvinum/mirror#, [.filename]#/dev/gvinum/" "striped#, [.filename]#/dev/gvinum/raid5# и [.filename]#/dev/gvinum/raid10#." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:441 msgid "All volumes get direct entries under [.filename]#/dev/gvinum/#." msgstr "Все тома получают собственные записи в [.filename]#/dev/gvinum/#." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:442 msgid "" "The directories [.filename]#/dev/gvinum/plex#, and [.filename]#/dev/gvinum/" "sd#, which contain device nodes for each plex and for each subdisk, " "respectively." msgstr "" "Каталоги [.filename]#/dev/gvinum/plex# и [.filename]#/dev/gvinum/sd#, " "которые содержат узлы устройств для каждого плекса и каждого субдиска " "соответственно." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:444 msgid "For example, consider the following configuration file:" msgstr "Например, рассмотрим следующий конфигурационный файл:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:457 #, no-wrap msgid "" "\tdrive drive1 device /dev/sd1h\n" "\tdrive drive2 device /dev/sd2h\n" "\tdrive drive3 device /dev/sd3h\n" "\tdrive drive4 device /dev/sd4h\n" " volume s64 setupstate\n" " plex org striped 64k\n" " sd length 100m drive drive1\n" " sd length 100m drive drive2\n" " sd length 100m drive drive3\n" " sd length 100m drive drive4\n" msgstr "" "\tdrive drive1 device /dev/sd1h\n" "\tdrive drive2 device /dev/sd2h\n" "\tdrive drive3 device /dev/sd3h\n" "\tdrive drive4 device /dev/sd4h\n" " volume s64 setupstate\n" " plex org striped 64k\n" " sd length 100m drive drive1\n" " sd length 100m drive drive2\n" " sd length 100m drive drive3\n" " sd length 100m drive drive4\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:460 msgid "" "After processing this file, man:gvinum[8] creates the following structure in " "[.filename]#/dev/gvinum#:" msgstr "" "После обработки этого файла man:gvinum[8] создает следующую структуру в [." "filename]#/dev/gvinum#:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:467 #, no-wrap msgid "" "\tdrwxr-xr-x 2 root wheel 512 Apr 13\n" "16:46 plex\n" "\tcrwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64\n" "\tdrwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd\n" msgstr "" "\tdrwxr-xr-x 2 root wheel 512 Apr 13\n" "16:46 plex\n" "\tcrwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64\n" "\tdrwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:471 #, no-wrap msgid "" " /dev/vinum/plex:\n" " total 0\n" " crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0\n" msgstr "" " /dev/vinum/plex:\n" " total 0\n" " crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:478 #, no-wrap msgid "" " /dev/vinum/sd:\n" " total 0\n" " crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0\n" " crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1\n" " crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2\n" " crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3\n" msgstr "" " /dev/vinum/sd:\n" " total 0\n" " crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0\n" " crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1\n" " crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2\n" " crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:483 msgid "" "Although it is recommended that plexes and subdisks should not be allocated " "specific names, [.filename]#vinum# drives must be named. This makes it " "possible to move a drive to a different location and still recognize it " "automatically. Drive names may be up to 32 characters long." msgstr "" "Хотя рекомендуется не назначать конкретные имена плексам и поддискам, диски " "[.filename]#vinum# должны быть именованными. Это позволяет переместить диск " "в другое место и по-прежнему автоматически его распознавать. Имена дисков " "могут быть длиной до 32 символов." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:484 #, no-wrap msgid "Creating File Systems" msgstr "Создание файловых систем" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:492 msgid "" "Volumes appear to the system to be identical to disks, with one exception. " "Unlike UNIX(R) drives, [.filename]#vinum# does not partition volumes, which " "thus do not contain a partition table. This has required modification to " "some disk utilities, notably man:newfs[8], so that it does not try to " "interpret the last letter of a [.filename]#vinum# volume name as a partition " "identifier. For example, a disk drive may have a name like [.filename]#/dev/" "ad0a# or [.filename]#/dev/da2h#. These names represent the first partition " "([.filename]#a#) on the first (0) IDE disk ([.filename]#ad#) and the eighth " "partition ([.filename]#h#) on the third (2) SCSI disk ([.filename]#da#) " "respectively. By contrast, a [.filename]#vinum# volume might be called [." "filename]#/dev/gvinum/concat#, which has no relationship with a partition " "name." msgstr "" "Тома для системы выглядят идентично дискам, за одним исключением. В отличие " "от дисков UNIX(R), [.filename]#vinum# не разбивает тома на разделы, поэтому " "они не содержат таблицы разделов. Это потребовало внесения изменений в " "некоторые утилиты для работы с дисками, в частности, в man:newfs[8], чтобы " "они не пытались интерпретировать последнюю букву имени тома [." "filename]#vinum# как идентификатор раздела. Например, имя диска может " "выглядеть как [.filename]#/dev/ad0a# или [.filename]#/dev/da2h#. Эти имена " "обозначают первый раздел ([.filename]#a#) на первом (0) IDE-диске ([." "filename]#ad#) и восьмой раздел ([.filename]#h#) на третьем (2) SCSI-диске ([" ".filename]#da#), соответственно. В отличие от этого, том [.filename]#vinum# " "может называться [.filename]#/dev/gvinum/concat#, что не имеет отношения к " "имени раздела." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:494 msgid "To create a file system on this volume, use man:newfs[8]:" msgstr "Чтобы создать файловую систему на этом томе, используйте man:newfs[8]:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:498 #, no-wrap msgid "# newfs /dev/gvinum/concat\n" msgstr "# newfs /dev/gvinum/concat\n" #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:501 #, no-wrap msgid "Configuring [.filename]#vinum#" msgstr "Настройка [.filename]#vinum#" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:507 msgid "" "The [.filename]#GENERIC# kernel does not contain [.filename]#vinum#. It is " "possible to build a custom kernel which includes [.filename]#vinum#, but " "this is not recommended. The standard way to start [.filename]#vinum# is as " "a kernel module. man:kldload[8] is not needed because when man:gvinum[8] " "starts, it checks whether the module has been loaded, and if it is not, it " "loads it automatically." msgstr "" "Ядро [.filename]#GENERIC# не содержит [.filename]#vinum#. Можно собрать " "пользовательское ядро с включённым [.filename]#vinum#, но это не " "рекомендуется. Стандартный способ запуска [.filename]#vinum# — в качестве " "модуля ядра. Команда man:kldload[8] не требуется, так как при запуске man:" "gvinum[8] проверяет, загружен ли модуль, и если нет, загружает его " "автоматически." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:508 #, no-wrap msgid "Startup" msgstr "Запуск" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:513 msgid "" "[.filename]#vinum# stores configuration information on the disk slices in " "essentially the same form as in the configuration files. When reading from " "the configuration database, [.filename]#vinum# recognizes a number of " "keywords which are not allowed in the configuration files. For example, a " "disk configuration might contain the following text:" msgstr "" "[.filename]#vinum# хранит конфигурационную информацию на дисковых слайсах " "практически в той же форме, что и в конфигурационных файлах. При чтении из " "базы данных конфигурации [.filename]#vinum# распознаёт ряд ключевых слов, " "которые не допускаются в конфигурационных файлах. Например, конфигурация " "диска может содержать следующий текст:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:535 #, no-wrap msgid "" "volume myvol state up\n" "volume bigraid state down\n" "plex name myvol.p0 state up org concat vol myvol\n" "plex name myvol.p1 state up org concat vol myvol\n" "plex name myvol.p2 state init org striped 512b vol myvol\n" "plex name bigraid.p0 state initializing org raid5 512b vol bigraid\n" "sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b\n" "sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b\n" "sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b\n" "sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b\n" "sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b\n" "sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b\n" "sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b\n" "sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b\n" "sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b\n" "sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b\n" "sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b\n" "sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b\n" "sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b\n" msgstr "" "volume myvol state up\n" "volume bigraid state down\n" "plex name myvol.p0 state up org concat vol myvol\n" "plex name myvol.p1 state up org concat vol myvol\n" "plex name myvol.p2 state init org striped 512b vol myvol\n" "plex name bigraid.p0 state initializing org raid5 512b vol bigraid\n" "sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b\n" "sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b\n" "sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b\n" "sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b\n" "sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b\n" "sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b\n" "sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b\n" "sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b\n" "sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b\n" "sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b\n" "sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b\n" "sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b\n" "sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:541 msgid "" "The obvious differences here are the presence of explicit location " "information and naming, both of which are allowed but discouraged, and the " "information on the states. [.filename]#vinum# does not store information " "about drives in the configuration information. It finds the drives by " "scanning the configured disk drives for partitions with a [.filename]#vinum# " "label. This enables [.filename]#vinum# to identify drives correctly even if " "they have been assigned different UNIX(R) drive IDs." msgstr "" "Очевидные различия здесь — наличие явной информации о местоположении и " "именования, что разрешено, но не рекомендуется, а также информация о " "состояниях. [.filename]#vinum# не хранит сведения о дисках в " "конфигурационной информации. Он находит диски, сканируя настроенные дисковые " "накопители на наличие разделов с меткой [.filename]#vinum#. Это позволяет [." "filename]#vinum# корректно идентифицировать диски, даже если им были " "присвоены разные идентификаторы дисков UNIX(R)." #. type: Title ==== #: documentation/content/en/articles/vinum/_index.adoc:543 #, no-wrap msgid "Automatic Startup" msgstr "Автоматический запуск" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:547 msgid "" "_Gvinum_ always features an automatic startup once the kernel module is " "loaded, via man:loader.conf[5]. To load the _Gvinum_ module at boot time, " "add `geom_vinum_load=\"YES\"` to [.filename]#/boot/loader.conf#." msgstr "" "_Gvinum_ всегда запускается автоматически после загрузки модуля ядра через " "man:loader.conf[5]. Чтобы загрузить модуль _Gvinum_ при загрузке системы, " "добавьте `geom_vinum_load=\"YES\"` в [.filename]#/boot/loader.conf#." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:552 msgid "" "When [.filename]#vinum# is started with `gvinum start`, [.filename]#vinum# " "reads the configuration database from one of the [.filename]#vinum# drives. " "Under normal circumstances, each drive contains an identical copy of the " "configuration database, so it does not matter which drive is read. After a " "crash, however, [.filename]#vinum# must determine which drive was updated " "most recently and read the configuration from this drive. It then updates " "the configuration, if necessary, from progressively older drives." msgstr "" "Когда [.filename]#vinum# запускается командой `gvinum start`, [." "filename]#vinum# читает конфигурационную базу данных с одного из дисков [." "filename]#vinum#. В нормальных условиях каждый диск содержит идентичную " "копию конфигурационной базы данных, поэтому не имеет значения, с какого " "диска читать. Однако после сбоя [.filename]#vinum# должен определить, какой " "диск был обновлён последним, и прочитать конфигурацию с этого диска. Затем, " "если необходимо, он обновляет конфигурацию последовательно с более старых " "дисков." #. type: Title == #: documentation/content/en/articles/vinum/_index.adoc:554 #, no-wrap msgid "Using [.filename]#vinum# for the Root File System" msgstr "Использование [.filename]#vinum# для корневой файловой системы" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:558 msgid "" "For a machine that has fully-mirrored file systems using [.filename]#vinum#, " "it is desirable to also mirror the root file system. Setting up such a " "configuration is less trivial than mirroring an arbitrary file system " "because:" msgstr "" "Для машины с полностью зеркалированными файловыми системами с использованием " "[.filename]#vinum#, желательно также зеркалировать корневую файловую " "систему. Настройка такой конфигурации менее тривиальна, чем зеркалирование " "произвольной файловой системы, потому что:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:560 msgid "" "The root file system must be available very early during the boot process, " "so the [.filename]#vinum# infrastructure must already be available at this " "time." msgstr "" "Корневая файловая система должна быть доступна очень рано в процессе " "загрузки, поэтому инфраструктура [.filename]#vinum# должна быть уже доступна " "на этом этапе." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:561 msgid "" "The volume containing the root file system also contains the system " "bootstrap and the kernel. These must be read using the host system's native " "utilities, such as the BIOS, which often cannot be taught about the details " "of [.filename]#vinum#." msgstr "" "Том, содержащий корневую файловую систему, также включает системный " "загрузчик и ядро. Они должны быть прочитаны с использованием родных утилит " "хостовой системы, таких как BIOS, который зачастую нельзя обучить работе с " "деталями [.filename]#vinum#." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:563 msgid "" "In the following sections, the term \"root volume\" is generally used to " "describe the [.filename]#vinum# volume that contains the root file system." msgstr "" "В следующих разделах термин \"корневой том\" обычно используется для " "описания тома [.filename]#vinum#, который содержит корневую файловую систему." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:564 #, no-wrap msgid "Starting up [.filename]#vinum# Early Enough for the Root File System" msgstr "Запуск [.filename]#vinum# на раннем этапе для обеспечения доступа к корневой файловой системе" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:568 msgid "" "[.filename]#vinum# must be available early in the system boot as man:" "loader[8] must be able to load the vinum kernel module before starting the " "kernel. This can be accomplished by putting this line in [.filename]#/boot/" "loader.conf#:" msgstr "" "Файл `[.filename]#vinum#` должен быть доступен на раннем этапе загрузки " "системы, так как `man:loader[8]` должен загрузить модуль ядра `vinum` перед " "запуском ядра. Это можно сделать, добавив следующую строку в `[.filename]#/" "boot/loader.conf#`:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:572 #, no-wrap msgid "geom_vinum_load=\"YES\"\n" msgstr "geom_vinum_load=\"YES\"\n" #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:574 #, no-wrap msgid "Making a [.filename]#vinum#-based Root Volume Accessible to the Bootstrap" msgstr "Создание корневого тома на основе [.filename]#vinum#, доступного для загрузчика" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:579 msgid "" "The current FreeBSD bootstrap is only 7.5 KB of code and does not understand " "the internal [.filename]#vinum# structures. This means that it cannot parse " "the [.filename]#vinum# configuration data or figure out the elements of a " "boot volume. Thus, some workarounds are necessary to provide the bootstrap " "code with the illusion of a standard `a` partition that contains the root " "file system." msgstr "" "Текущая загрузочная запись FreeBSD занимает всего 7,5 КБ кода и не понимает " "внутренние структуры [.filename]#vinum#. Это означает, что она не может " "разобрать конфигурационные данные [.filename]#vinum# или определить элементы " "загрузочного тома. Таким образом, необходимы некоторые обходные решения, " "чтобы предоставить загрузочному коду иллюзию стандартного раздела `a`, " "содержащего корневую файловую систему." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:581 msgid "" "For this to be possible, the following requirements must be met for the root " "volume:" msgstr "Для этого должны быть выполнены следующие требования к корневому тому:" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:583 msgid "The root volume must not be a stripe or `RAID`-5." msgstr "Корневой том не должен быть чередующимся или `RAID`-5." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:584 msgid "" "The root volume must not contain more than one concatenated subdisk per plex." msgstr "" "Корневой том не должен содержать более одного объединённого поддиска на " "плекс." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:590 msgid "" "Note that it is desirable and possible to use multiple plexes, each " "containing one replica of the root file system. The bootstrap process will " "only use one replica for finding the bootstrap and all boot files, until the " "kernel mounts the root file system. Each single subdisk within these plexes " "needs its own `a` partition illusion, for the respective device to be " "bootable. It is not strictly needed that each of these faked `a` partitions " "is located at the same offset within its device, compared with other devices " "containing plexes of the root volume. However, it is probably a good idea " "to create the [.filename]#vinum# volumes that way so the resulting mirrored " "devices are symmetric, to avoid confusion." msgstr "" "Обратите внимание, что желательно и возможно использовать несколько плексов, " "каждый из которых содержит одну реплику корневой файловой системы. Процесс " "начальной загрузки будет использовать только одну реплику для поиска " "загрузчика и всех загрузочных файлов, пока ядро не смонтирует корневую " "файловую систему. Каждый отдельный поддиск в этих плексах должен иметь свою " "собственную иллюзию раздела `a`, чтобы соответствующее устройство было " "загрузочным. Не строго необходимо, чтобы каждый из этих фальшивых разделов " "`a` находился на том же смещении внутри своего устройства по сравнению с " "другими устройствами, содержащими плекс корневого тома. Однако, вероятно, " "хорошей идеей будет создавать тома [.filename]#vinum# таким образом, чтобы " "результирующие зеркальные устройства были симметричными, чтобы избежать " "путаницы." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:592 msgid "" "To set up these `a` partitions for each device containing part of the root " "volume, the following is required:" msgstr "" "Для настройки этих разделов `a` на каждом устройстве, содержащем часть " "корневого тома, требуется следующее:" #. type: delimited block = 4 #: documentation/content/en/articles/vinum/_index.adoc:596 msgid "" "The location, offset from the beginning of the device, and size of this " "device's subdisk that is part of the root volume needs to be examined, using " "the command:" msgstr "" "Местоположение, смещение от начала устройства и размер подобласти этого " "устройства, которая является частью корневого тома, необходимо проверить с " "помощью команды:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:600 #, no-wrap msgid "# gvinum l -rv root\n" msgstr "# gvinum l -rv root\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:604 msgid "" "[.filename]#vinum# offsets and sizes are measured in bytes. They must be " "divided by 512 to obtain the block numbers that are to be used by `bsdlabel`." msgstr "" "Смещения и размеры в [.filename]#vinum# измеряются в байтах. Их необходимо " "разделить на 512, чтобы получить номера блоков, которые будут использоваться " "в `bsdlabel`." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:605 msgid "Run this command for each device that participates in the root volume:" msgstr "" "Выполните эту команду для каждого устройства, участвующего в корневом томе:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:609 #, no-wrap msgid "# bsdlabel -e devname\n" msgstr "# bsdlabel -e devname\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:612 msgid "" "_devname_ must be either the name of the disk, like [.filename]#da0# for " "disks without a slice table, or the name of the slice, like [." "filename]#ad0s1#." msgstr "" "`_devname_` должен быть либо именем диска, например, [.filename]#da0# для " "дисков без таблицы разделов, либо именем раздела, например, [." "filename]#ad0s1#." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:615 msgid "" "If there is already an `a` partition on the device from a pre-[." "filename]#vinum# root file system, it should be renamed to something else so " "that it remains accessible (just in case), but will no longer be used by " "default to bootstrap the system. A currently mounted root file system " "cannot be renamed, so this must be executed either when being booted from a " "\"Fixit\" media, or in a two-step process where, in a mirror, the disk that " "is not been currently booted is manipulated first." msgstr "" "Если на устройстве уже существует раздел `a` из корневой файловой системы до " "[.filename]#vinum#, его следует переименовать во что-то другое, чтобы он " "оставался доступным (на всякий случай), но больше не использовался по " "умолчанию для загрузки системы. Текущий смонтированный корневой файловой " "системы нельзя переименовать, поэтому это должно выполняться либо при " "загрузке с \"Fixit\" носителя, либо в два этапа, когда в зеркале сначала " "обрабатывается диск, с которого в данный момент не загружаются." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:621 msgid "" "The offset of the [.filename]#vinum# partition on this device (if any) must " "be added to the offset of the respective root volume subdisk on this " "device. The resulting value will become the `offset` value for the new `a` " "partition. The `size` value for this partition can be taken verbatim from " "the calculation above. The `fstype` should be `4.2BSD`. The `fsize`, " "`bsize`, and `cpg` values should be chosen to match the actual file system, " "though they are fairly unimportant within this context." msgstr "" "Смещение раздела [.filename]#vinum# на этом устройстве (если есть) должно " "быть добавлено к смещению соответствующего поддиска корневого тома на этом " "устройстве. Полученное значение станет значением `offset` для нового раздела " "`a`. Значение `size` для этого раздела можно взять дословно из приведённых " "выше расчётов. Для `fstype` следует указать `4.2BSD`. Значения `fsize`, " "`bsize` и `cpg` должны быть выбраны в соответствии с реальной файловой " "системой, хотя в данном контексте они не слишком важны." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:624 msgid "" "That way, a new `a` partition will be established that overlaps the [." "filename]#vinum# partition on this device. `bsdlabel` will only allow for " "this overlap if the [.filename]#vinum# partition has properly been marked " "using the `vinum` fstype." msgstr "" "Таким образом, будет создан новый раздел `a`, который перекрывает раздел [." "filename]#vinum# на этом устройстве. `bsdlabel` разрешит это перекрытие " "только в том случае, если раздел [.filename]#vinum# был правильно помечен с " "использованием типа файловой системы `vinum`." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:625 msgid "" "A faked `a` partition now exists on each device that has one replica of the " "root volume. It is highly recommendable to verify the result using a command " "like:" msgstr "" "Поддельный раздел `a` теперь существует на каждом устройстве, имеющем одну " "реплику корневого тома. Настоятельно рекомендуется проверить результат с " "помощью команды, например:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:629 #, no-wrap msgid "# fsck -n /dev/devnamea\n" msgstr "# fsck -n /dev/devnamea\n" #. type: delimited block = 4 #: documentation/content/en/articles/vinum/_index.adoc:634 msgid "" "It should be remembered that all files containing control information must " "be relative to the root file system in the [.filename]#vinum# volume which, " "when setting up a new [.filename]#vinum# root volume, might not match the " "root file system that is currently active. So in particular, [.filename]#/" "etc/fstab# and [.filename]#/boot/loader.conf# need to be taken care of." msgstr "" "Следует помнить, что все файлы, содержащие управляющую информацию, должны " "быть относительны к корневой файловой системе в томе [.filename]#vinum#, " "которая при настройке нового корневого тома [.filename]#vinum# может не " "совпадать с текущей активной корневой файловой системой. Поэтому, в " "частности, необходимо позаботиться о [.filename]#/etc/fstab# и [.filename]#/" "boot/loader.conf#." #. type: delimited block = 4 #: documentation/content/en/articles/vinum/_index.adoc:637 msgid "" "At next reboot, the bootstrap should figure out the appropriate control " "information from the new [.filename]#vinum#-based root file system, and act " "accordingly. At the end of the kernel initialization process, after all " "devices have been announced, the prominent notice that shows the success of " "this setup is a message like:" msgstr "" "При следующей перезагрузке загрузчик должен определить соответствующую " "управляющую информацию из новой корневой файловой системы на основе [." "filename]#vinum# и действовать соответствующим образом. В конце процесса " "инициализации ядра, после объявления всех устройств, явным признаком " "успешного завершения настройки будет сообщение вида:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:641 #, no-wrap msgid "Mounting root from ufs:/dev/gvinum/root\n" msgstr "Mounting root from ufs:/dev/gvinum/root\n" #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:643 #, no-wrap msgid "Example of a [.filename]#vinum#-based Root Setup" msgstr "Пример настройки корневой системы на основе [.filename]#vinum#" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:646 msgid "" "After the [.filename]#vinum# root volume has been set up, the output of " "`gvinum l -rv root` could look like:" msgstr "" "После настройки корневого тома [.filename]#vinum#, вывод команды `gvinum l -" "rv root` может выглядеть следующим образом:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:655 #, no-wrap msgid "" "...\n" "Subdisk root.p0.s0:\n" "\t\tSize: 125829120 bytes (120 MB)\n" "\t\tState: up\n" "\t\tPlex root.p0 at offset 0 (0 B)\n" "\t\tDrive disk0 (/dev/da0h) at offset 135680 (132 kB)\n" msgstr "" "...\n" "Subdisk root.p0.s0:\n" "\t\tSize: 125829120 bytes (120 MB)\n" "\t\tState: up\n" "\t\tPlex root.p0 at offset 0 (0 B)\n" "\t\tDrive disk0 (/dev/da0h) at offset 135680 (132 kB)\n" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:661 #, no-wrap msgid "" "Subdisk root.p1.s0:\n" "\t\tSize: 125829120 bytes (120 MB)\n" "\t\tState: up\n" "\t\tPlex root.p1 at offset 0 (0 B)\n" "\t\tDrive disk1 (/dev/da1h) at offset 135680 (132 kB)\n" msgstr "" "Subdisk root.p1.s0:\n" "\t\tSize: 125829120 bytes (120 MB)\n" "\t\tState: up\n" "\t\tPlex root.p1 at offset 0 (0 B)\n" "\t\tDrive disk1 (/dev/da1h) at offset 135680 (132 kB)\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:667 msgid "" "The values to note are `135680` for the offset, relative to partition [." "filename]#/dev/da0h#. This translates to 265 512-byte disk blocks in " "`bsdlabel`'s terms. Likewise, the size of this root volume is 245760 512-" "byte blocks. [.filename]#/dev/da1h#, containing the second replica of this " "root volume, has a symmetric setup." msgstr "" "Значения, на которые следует обратить внимание: `135680` для смещения, " "относительного к разделу [.filename]#/dev/da0h#. Это соответствует 265 " "блокам диска по 512 байт в терминах `bsdlabel`. Аналогично, размер этого " "корневого тома составляет 245760 блоков по 512 байт. [.filename]#/dev/da1h#, " "содержащий вторую реплику этого корневого тома, имеет симметричную " "конфигурацию." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:669 msgid "The bsdlabel for these devices might look like:" msgstr "Метка bsdlabel для этих устройств может выглядеть следующим образом:" #. type: delimited block . 4 #: documentation/content/en/articles/vinum/_index.adoc:678 #, no-wrap msgid "" "...\n" "8 partitions:\n" "# size offset fstype [fsize bsize bps/cpg]\n" " a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*)\n" " c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*)\n" " h: 71771672 16 vinum # (Cyl. 0*- 4467*)\n" msgstr "" "...\n" "8 partitions:\n" "# size offset fstype [fsize bsize bps/cpg]\n" " a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*)\n" " c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*)\n" " h: 71771672 16 vinum # (Cyl. 0*- 4467*)\n" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:684 msgid "" "It can be observed that the `size` parameter for the faked `a` partition " "matches the value outlined above, while the `offset` parameter is the sum of " "the offset within the [.filename]#vinum# partition `h`, and the offset of " "this partition within the device or slice. This is a typical setup that is " "necessary to avoid the problem described in crossref:vinum[vinum-root-panic, " "Nothing Boots, the Bootstrap Panics]. The entire `a` partition is " "completely within the `h` partition containing all the [.filename]#vinum# " "data for this device." msgstr "" "Можно заметить, что параметр `size` для поддельного раздела `a` совпадает с " "указанным выше значением, в то время как параметр `offset` представляет " "собой сумму смещения внутри раздела [.filename]#vinum# `h` и смещения этого " "раздела в устройстве или слайсе. Это стандартная настройка, необходимая для " "избежания проблемы, описанной в crossref:vinum[vinum-root-panic, Nothing " "Boots, the Bootstrap Panics]. Весь раздел `a` полностью находится внутри " "раздела `h`, содержащего все данные [.filename]#vinum# для этого устройства." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:686 msgid "" "In the above example, the entire device is dedicated to [.filename]#vinum# " "and there is no leftover pre-[.filename]#vinum# root partition." msgstr "" -"В приведенном выше примере все устройство выделено под [.filename]#vinum#, и " +"В приведённом выше примере все устройство выделено под [.filename]#vinum#, и " "не осталось корневого раздела, существовавшего до [.filename]#vinum#." #. type: Title === #: documentation/content/en/articles/vinum/_index.adoc:687 #, no-wrap msgid "Troubleshooting" msgstr "Устранение неполадок" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:690 msgid "The following list contains a few known pitfalls and solutions." msgstr "" "Следующий список содержит несколько известных подводных камней и их решения." #. type: Title ==== #: documentation/content/en/articles/vinum/_index.adoc:691 #, no-wrap msgid "System Bootstrap Loads, but System Does Not Boot" msgstr "Загрузчик системы загружается, но система не запускается" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:695 msgid "" "If for any reason the system does not continue to boot, the bootstrap can be " "interrupted by pressing kbd:[space] at the 10-seconds warning. The loader " "variable `vinum.autostart` can be examined by typing `show` and manipulated " "using `set` or `unset`." msgstr "" "Если по какой-либо причине система не продолжает загрузку, процесс можно " "прервать, нажав kbd:[space] при появлении 10-секундного предупреждения. " "Переменную загрузчика `vinum.autostart` можно проверить, введя команду " "`show`, и изменить с помощью `set` или `unset`." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:697 msgid "" "If the [.filename]#vinum# kernel module was not yet in the list of modules " "to load automatically, type `load geom_vinum`." msgstr "" -"Если модуль ядра [.filename]#vinum# еще не был в списке модулей для " +"Если модуль ядра [.filename]#vinum# ещё не был в списке модулей для " "автоматической загрузки, введите `load geom_vinum`." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:700 msgid "" "When ready, the boot process can be continued by typing `boot -as` which `-" "as` requests the kernel to ask for the root file system to mount (`-a`) and " "make the boot process stop in single-user mode (`-s`), where the root file " "system is mounted read-only. That way, even if only one plex of a multi-" "plex volume has been mounted, no data inconsistency between plexes is being " "risked." msgstr "" "Когда всё готово, процесс загрузки можно продолжить, введя `boot -as`, где `-" "as` указывает ядру запросить корневую файловую систему для монтирования (`-" "a`) и остановить процесс загрузки в однопользовательском режиме (`-s`), при " "этом корневая файловая система монтируется в режиме только для чтения. Таким " "образом, даже если смонтирован только один слой многокомпонентного тома, не " "возникает риска несогласованности данных между слоями." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:706 msgid "" "At the prompt asking for a root file system to mount, any device that " "contains a valid root file system can be entered. If [.filename]#/etc/" "fstab# is set up correctly, the default should be something like `ufs:/dev/" "gvinum/root`. A typical alternate choice would be something like `ufs:da0d` " "which could be a hypothetical partition containing the pre-[." "filename]#vinum# root file system. Care should be taken if one of the alias " "`a` partitions is entered here, that it actually references the subdisks of " "the [.filename]#vinum# root device, because in a mirrored setup, this would " "only mount one piece of a mirrored root device. If this file system is to " "be mounted read-write later on, it is necessary to remove the other plex(es) " "of the [.filename]#vinum# root volume since these plexes would otherwise " "carry inconsistent data." msgstr "" "На запрос о корневой файловой системе для монтирования можно ввести любое " "устройство, содержащее действительную корневую файловую систему. Если [." "filename]#/etc/fstab# настроен правильно, по умолчанию должно быть что-то " "вроде `ufs:/dev/gvinum/root`. Типичным альтернативным выбором может быть что-" "то вроде `ufs:da0d`, что может быть гипотетическим разделом, содержащим " "корневую файловую систему до [.filename]#vinum#. Следует быть осторожным, " "если здесь вводится один из псевдонимов `a` разделов, чтобы он действительно " "ссылался на поддиски устройства [.filename]#vinum# root, потому что в " "зеркальной настройке это приведёт к монтированию только одной части " "зеркального корневого устройства. Если эта файловая система будет позже " "смонтирована в режиме чтения-записи, необходимо удалить другие плексы тома [." "filename]#vinum# root, так как в противном случае эти плексы будут содержать " "несогласованные данные." #. type: Title ==== #: documentation/content/en/articles/vinum/_index.adoc:707 #, no-wrap msgid "Only Primary Bootstrap Loads" msgstr "Только первичная загрузка Bootstrap" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:712 msgid "" "If [.filename]#/boot/loader# fails to load, but the primary bootstrap still " "loads (visible by a single dash in the left column of the screen right after " "the boot process starts), an attempt can be made to interrupt the primary " "bootstrap by pressing kbd:[space]. This will make the bootstrap stop in " "extref:{handbook}boot[stage two, boot-boot1]. An attempt can be made here " "to boot off an alternate partition, like the partition containing the " "previous root file system that has been moved away from `a`." msgstr "" "Если [.filename]#/boot/loader# не загружается, но первичная загрузка всё ещё " "работает (это видно по одному дефису в левой части экрана сразу после начала " "процесса загрузки), можно попытаться прервать первичную загрузку, нажав " "kbd:[space]. Это остановит загрузку на extref:{handbook}boot[втором этапе, " "boot-boot1]. Здесь можно попытаться загрузиться с альтернативного раздела, " "например, с раздела, содержащего предыдущую корневую файловую систему, " "которая была перемещена из `a`." #. type: Title ==== #: documentation/content/en/articles/vinum/_index.adoc:714 #, no-wrap msgid "Nothing Boots, the Bootstrap Panics" msgstr "Ничего не загружается, паника при загрузке" #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:720 msgid "" "This situation will happen if the bootstrap had been destroyed by the [." "filename]#vinum# installation. Unfortunately, [.filename]#vinum# " "accidentally leaves only 4 KB at the beginning of its partition free before " "starting to write its [.filename]#vinum# header information. However, the " "stage one and two bootstraps plus the bsdlabel require 8 KB. So if a [." "filename]#vinum# partition was started at offset 0 within a slice or disk " "that was meant to be bootable, the [.filename]#vinum# setup will trash the " "bootstrap." msgstr "" "Такая ситуация произойдет, если загрузчик был уничтожен при установке [." "filename]#vinum#. К сожалению, [.filename]#vinum# случайно оставляет " "свободными только первые 4 КБ в начале своего раздела перед записью " "заголовочной информации [.filename]#vinum#. Однако, первая и вторая стадии " "загрузчика вместе с bsdlabel требуют 8 КБ. Поэтому, если раздел [." "filename]#vinum# начинается со смещения 0 внутри слайса или диска, который " "должен быть загрузочным, установка [.filename]#vinum# повредит загрузчик." #. type: Plain text #: documentation/content/en/articles/vinum/_index.adoc:723 msgid "" "Similarly, if the above situation has been recovered, by booting from a " "\"Fixit\" media, and the bootstrap has been re-installed using `bsdlabel -B` " "as described in extref:{handbook}boot[stage two, boot-boot1], the bootstrap " "will trash the [.filename]#vinum# header, and [.filename]#vinum# will no " "longer find its disk(s). Though no actual [.filename]#vinum# configuration " "data or data in [.filename]#vinum# volumes will be trashed, and it would be " "possible to recover all the data by entering exactly the same [." "filename]#vinum# configuration data again, the situation is hard to fix. It " "is necessary to move the entire [.filename]#vinum# partition by at least 4 " "KB, to have the [.filename]#vinum# header and the system bootstrap no longer " "collide." msgstr "" "Аналогично, если описанная выше ситуация была исправлена загрузкой с \"Fixit" "\"-носителя, и загрузчик был переустановлен с помощью `bsdlabel -B`, как " "описано в extref:{handbook}boot[этапе два, boot-boot1], загрузчик повредит " "заголовок [.filename]#vinum#, и [.filename]#vinum# больше не сможет найти " "свои диски. Хотя фактические данные конфигурации [.filename]#vinum# или " "данные в томах [.filename]#vinum# не будут повреждены, и можно восстановить " "все данные, введя точно такую же конфигурацию [.filename]#vinum# снова, " "исправить ситуацию сложно. Необходимо переместить весь раздел [." "filename]#vinum# как минимум на 4 КБ, чтобы заголовок [.filename]#vinum# и " "системный загрузчик больше не конфликтовали." diff --git a/documentation/content/ru/articles/vm-design/_index.adoc b/documentation/content/ru/articles/vm-design/_index.adoc index e0847dea68..d852955a4f 100644 --- a/documentation/content/ru/articles/vm-design/_index.adoc +++ b/documentation/content/ru/articles/vm-design/_index.adoc @@ -1,206 +1,206 @@ --- authors: - author: 'Matthew Dillon' email: dillon@apollo.backplane.com description: 'Простое и понятное описание архитектуры системы виртуальной памяти FreeBSD' tags: ["Design", "virtual machine", "FreeBSD"] title: 'Элементы архитектуры системы виртуальной памяти во FreeBSD' trademarks: ["freebsd", "linux", "microsoft", "opengroup", "daemon-news", "general"] --- = Элементы архитектуры системы виртуальной памяти во FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/vm-design/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [NOTE] ==== Этот документ устарел, и некоторые разделы больше не соответствуют текущему состоянию системы виртуальной памяти. Он сохранён в исторических целях и может быть обновлён в будущем. ==== [.abstract-title] Аннотация Matthew Dillon Это название — просто замысловатый способ сказать, что я попытаюсь описать всю систему виртуальной памяти (VM) целиком, по возможности так, чтобы это было понятно каждому.В течение последнего года я сосредоточился на нескольких основных подсистемах ядра FreeBSD. Наиболее интересными из них стали подсистемы VM и подкачки (Swap), тогда как работа с NFS оказалась, скорее, «необходимой рутиной». Я переписал лишь небольшие части кода. В области VM моей единственной крупной переработкой стала подсистема подкачки. В основном моя работа заключалась в очистке и поддержке кода, с умеренными правками и без серьёзных изменений алгоритмов в подсистеме VM. Теоретическая основа VM-подсистемы осталась неизменной, и львиная доля заслуг в её модернизации за последние годы принадлежит Джону Дайсону и Дэвиду Гринману. Я не историк, в отличие от Кирка, поэтому не стану приписывать различные функции конкретным людям — всё равно где-нибудь ошибусь. ''' 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, то читатель должен всегда иметь в виду два обстоятельства: -. Самым важным аспектом при проектировании производительности является то, что называется "оптимизацией критического маршрута". Часто случается, что оптимизация производительности дает прирост объема кода ради того, чтобы критический маршрут работал быстрее. +. Самым важным аспектом при проектировании производительности является то, что называется "оптимизацией критического маршрута". Часто случается, что оптимизация производительности даёт прирост объёма кода ради того, чтобы критический маршрут работал быстрее. . Четкость общей архитектуры оказывается лучше сильно оптимизированной архитектуры с течением времени. Когда как обобщенная архитектура может быть медленнее, чем оптимизированная архитектура, при первой реализации, при обобщенной архитектуре легче подстраиваться под изменяющиеся условия и чрезмерно оптимизированная архитектура оказывается непригодной. Любой код, который должен выжить и поддаваться поддержке годы, должен поэтому быть тщательно продуман с самого начала, даже если это стоит потери производительности. Двадцать лет назад были те, кто отстаивал преимущество программирования на языке ассемблера перед программированием на языке высокого уровня, потому что первый генерировал в десять раз более быстрый код. В наши дни ошибочность этого аргумента очевидна - можно провести параллели с построением алгоритмов и обобщением кода. [[vm-objects]] == Объекты VM -Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на нее с точки зрения пользовательского процесса. Каждый пользовательский процесс имеет единое, принадлежащее только ему и неразрывное адресное пространство VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные характеристики. Код программы и ее данные являются единым файлом, отображаемым в память (это выполняющийся двоичный файл), однако код программы доступен только для чтения, когда как данные программы размещаются в режиме копирования-при-записи. BSS программы представляет собой всего лишь выделенную область памяти, заполненную, если это требовалось, нулями, что называется обнулением страниц памяти по требованию. Отдельные файлы могут также отображаться в адресное пространство, именно так работают динамические библиотеки. Такие отображения требуют изменений, чтобы оставаться принадлежащими процессу, который их выполнил. Системный вызов fork добавляет переводит проблему управления VM полностью в новую плоскость, вдобавок к уже имеющимся сложностям. +Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на нее с точки зрения пользовательского процесса. Каждый пользовательский процесс имеет единое, принадлежащее только ему и неразрывное адресное пространство VM, содержащее несколько типов объектов памяти. Эти объекты имеют различные характеристики. Код программы и её данные являются единым файлом, отображаемым в память (это выполняющийся двоичный файл), однако код программы доступен только для чтения, когда как данные программы размещаются в режиме копирования-при-записи. BSS программы представляет собой всего лишь выделенную область памяти, заполненную, если это требовалось, нулями, что называется обнулением страниц памяти по требованию. Отдельные файлы могут также отображаться в адресное пространство, именно так работают динамические библиотеки. Такие отображения требуют изменений, чтобы оставаться принадлежащими процессу, который их выполнил. Системный вызов fork добавляет переводит проблему управления VM полностью в новую плоскость, вдобавок к уже имеющимся сложностям. -Иллюстрирует сложность страница данных двоичной программы (которая является страницей копируемой-при-записи). Двоичная программа содержит секцию предварительно инициализированных данных, которая первоначально отображается непосредственно из файла программы. Когда программа загружается в Vm-пространство процесса, эта область сначала отображается в память и поддерживается бинарным файлом программы, позволяя VM-системе освобождать/повторно использовать страницу, а потом загружать ее снова из бинарного файла. Однако в момент, когда процесс изменяет эти данные, VM-система должна сделать копию страницы, принадлежащую только этому процессу. Так как эта копия была изменена, то VM-система не может больше освобождать эту страницу, так как впоследствии ее невозможно будет восстановить. +Иллюстрирует сложность страница данных двоичной программы (которая является страницей копируемой-при-записи). Двоичная программа содержит секцию предварительно инициализированных данных, которая первоначально отображается непосредственно из файла программы. Когда программа загружается в Vm-пространство процесса, эта область сначала отображается в память и поддерживается бинарным файлом программы, позволяя VM-системе освобождать/повторно использовать страницу, а потом загружать её снова из бинарного файла. Однако в момент, когда процесс изменяет эти данные, VM-система должна сделать копию страницы, принадлежащую только этому процессу. Так как эта копия была изменена, то VM-система не может больше освобождать эту страницу, так как впоследствии её невозможно будет восстановить. -Вы тут же заметите, что то, что сначала было простым отображением файла в память, становится гораздо более сложным предметом. Данные могут модифицироваться постранично, когда как отображение файла выполняется для многих страниц за раз. Сложность еще более увеличивается, когда процесс выполняет вызов fork. При этом порождаются два процесса-каждый со с собственным адресным пространством, включающим все изменения, выполненные исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы делать полную копию данных во время вызова `fork()`, так как весьма вероятно, что один из двух процессов будет нужен только для чтения из той страницы, что позволяет использование исходной страницы. То, что было страницей, принадлежащей только процессу, сделается снова страницей, копируемой при записи, так как каждый из процессов (и родитель, и потомок) полагают, что их собственные изменения после разветвления будут принадлежать только им, и не затронут родственный процесс. +Вы тут же заметите, что то, что сначала было простым отображением файла в память, становится гораздо более сложным предметом. Данные могут модифицироваться постранично, когда как отображение файла выполняется для многих страниц за раз. Сложность ещё более увеличивается, когда процесс выполняет вызов fork. При этом порождаются два процесса-каждый со с собственным адресным пространством, включающим все изменения, выполненные исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы делать полную копию данных во время вызова `fork()`, так как весьма вероятно, что один из двух процессов будет нужен только для чтения из той страницы, что позволяет использование исходной страницы. То, что было страницей, принадлежащей только процессу, сделается снова страницей, копируемой при записи, так как каждый из процессов (и родитель, и потомок) полагают, что их собственные изменения после разветвления будут принадлежать только им, и не затронут родственный процесс. FreeBSD управляет всем этим при помощи многоуровневой модели VM-объектов. Исходный файл с двоичной программой переносится на самый нижний уровень объектов VM. Уровень страниц, копируемых при записи, находится выше него, и хранит те страницы, которые были скопированы из исходного файла. Если программа модифицирует страницы данных, относящиеся к исходному файлу, то система VM обнаруживает это и переносит копию этой страницы на более высокий уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. Это можно показать на простом примере. Функция `fork()` является общей операцией для всех систем *BSD, так что в этом примере будет рассматриваться программа, которая запускается, а затем разветвляется. Когда процесс запускается, VM-система создает некоторый уровень объектов, обозначим его A: image::fig1.png["Рисунок"] A соответствует файлу-по необходимости страницы памяти могут высвобождаться и подгружаться с носителя файла. Подгрузка с диска может потребоваться программе, однако на самом деле мы не хотим, чтобы она записывалась обратно в файл. Поэтому VM-система создает второй уровень, B, который физически поддерживается дисковым пространством подкачки: image::fig2.png[] При первой записи в страницу после выполнения этой операции, в B создается новая страница, содержимое которой берется из A. Все страницы в B могут сбрасываться и считываться из устройства подкачки. Когда программа ветвится, VM-система создает два новых уровня объектов-C1 для порождающего процесса и C2 для порожденного-они располагаются поверх B: image::fig3.png[] В этом случае, допустим, что страница в B была изменена начальным родительским процессом. В процессе возникнет ситуация копирования при записи и страница скопируется в C1, при этом исходная страница останется в B нетронутой. Теперь допустим, что та же самая страница в B изменяется порожденным процессом. В процессе возникнет ситуация копирования при записи и страница скопируется в C2. Исходная страница в B теперь полностью скрыта, так как и C1, и C2 имеют копии, а B теоретически может быть уничтожена, если она не представляет собой "реального" файла). Однако такую оптимизацию не так уж просто осуществить, потому что она делается на уровне мелких единиц. Во FreeBSD такая оптимизация не выполняется. Теперь положим (а это часто случается), что порожденный процесс выполняет вызов `exec()`. Его текущее адресное пространство обычно заменяется новым адресным пространством, представляющим новый файл. В этом случае уровень C2 уничтожается: image::fig4.png[] В этом случае количество потомков B становится равным одному и все обращения к B теперь выполняются через C1. Это означает, что B и C1 могут быть объединены. Все страницы в B, которые также существуют и в C1, во время объединения из B удаляются. Таким образом, хотя оптимизация на предыдущем шаге может не делаться, мы можем восстановить мертвые страницы при окончании работы процессов или при вызове `exec()`. -Такая модель создает некоторое количество потенциальных проблем. Первая, с которой вы можете столкнуться, заключается в сравнительно большой последовательности уровней объектов VM, на сканирование которых тратится время и память. Большое количество уровней может возникнуть, когда процессы разветвляются, а затем разветвляются еще раз (как порожденные, так и порождающие). Вторая проблема заключается в том, что вы можете столкнуться с мертвыми, недоступными страницами глубоко в иерархии объектов VM. В нашем последнем примере если как родитель, так и потомок изменяют одну и ту же страницу, они оба получают собственные копии страницы, а исходная страница в B становится никому не доступной. такая страница в B может быть высвобождена. +Такая модель создает некоторое количество потенциальных проблем. Первая, с которой вы можете столкнуться, заключается в сравнительно большой последовательности уровней объектов VM, на сканирование которых тратится время и память. Большое количество уровней может возникнуть, когда процессы разветвляются, а затем разветвляются ещё раз (как порожденные, так и порождающие). Вторая проблема заключается в том, что вы можете столкнуться с мертвыми, недоступными страницами глубоко в иерархии объектов 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, позволяют снизить значимость этих проблем до степени, когда их можно без особых потерь игнорировать. [[swap-layers]] == Уровни области подкачки -Страницы с собственными данными первоначально являются страницами, копируемыми при записи или заполняемыми нулями. Когда выполняется изменение, и, соответственно, копирование, начальное хранилище объекта (обычно файл) не может больше использоваться для хранения копии страницы, когда VM-системе нужно использовать ее повторно для других целей. В этот момент на помощь приходит область подкачки. Область подкачки выделяется для организации хранилища памяти, которая иначе не может быть доступна. FreeBSD создает структуру управления подкачкой для объекта VM, только когда это действительно нужно. Однако структура управления подкачкой исторически имела некоторые проблемы: +Страницы с собственными данными первоначально являются страницами, копируемыми при записи или заполняемыми нулями. Когда выполняется изменение, и, соответственно, копирование, начальное хранилище объекта (обычно файл) не может больше использоваться для хранения копии страницы, когда VM-системе нужно использовать её повторно для других целей. В этот момент на помощь приходит область подкачки. Область подкачки выделяется для организации хранилища памяти, которая иначе не может быть доступна. FreeBSD создает структуру управления подкачкой для объекта VM, только когда это действительно нужно. Однако структура управления подкачкой исторически имела некоторые проблемы: -* Во FreeBSD 3.X в структуре управления областью подкачки предварительно выделяется массив, который представляет целый объект, требующий хранения в области подкачки-даже если только несколько страниц этого объекта хранятся в области подкачки. Это создает проблему фрагментации памяти ядра в случае, когда в память отображаются большие объекты или когда ветвятся процессы, занимающие большой объем памяти при работе (RSS). -* Также для отслеживания памяти подкачки в памяти ядра поддерживается "список дыр", и он также несколько фрагментирован. Так как "список дыр" является последовательным списком, то производительность при распределении и высвобождении памяти в области подкачки неоптимально и ее сложность зависит от количества страниц как O(n). +* Во FreeBSD 3.X в структуре управления областью подкачки предварительно выделяется массив, который представляет целый объект, требующий хранения в области подкачки-даже если только несколько страниц этого объекта хранятся в области подкачки. Это создает проблему фрагментации памяти ядра в случае, когда в память отображаются большие объекты или когда ветвятся процессы, занимающие большой объём памяти при работе (RSS). +* Также для отслеживания памяти подкачки в памяти ядра поддерживается "список дыр", и он также несколько фрагментирован. Так как "список дыр" является последовательным списком, то производительность при распределении и высвобождении памяти в области подкачки неоптимально и её сложность зависит от количества страниц как O(n). * Также в процессе высвобождения памяти в области подкачки требуется выделение памяти в ядре, и это приводит к проблемам блокировки при недостатке памяти. -* Проблема еще более обостряется из-за дыр, создаваемых по чередующемуся алгоритму. +* Проблема ещё более обостряется из-за дыр, создаваемых по чередующемуся алгоритму. * Кроме того, список распределения блоков в области подкачки легко оказывается фрагментированным, что приводит к распределению непоследовательных областей. * Память ядра также должна распределяться по ходу работы для дополнительных структур по управлению областью подкачки при выгрузке страниц памяти в эту область. Очевидно, что мест для усовершенствований предостаточно. Во FreeBSD 4.X подсистема управления областью подкачки была полностью переписана мною: -* Структуры управления областью подкачки распределяются при помощи хэш-таблицы, а не через линейный массив, что дает им фиксированный размер при распределении и работу с гораздо меньшими структурами. +* Структуры управления областью подкачки распределяются при помощи хэш-таблицы, а не через линейный массив, что даёт им фиксированный размер при распределении и работу с гораздо меньшими структурами. * Вместо того, чтобы использовать однонаправленный связный список для отслеживания выделения пространства в области подкачки, теперь используется побитовая карта блоков области подкачки, выполненная в основном в виде древовидной структуры с информацией о свободном пространстве, находящейся в узлах структур. Это приводит к тому, что выделение и высвобождение памяти в области подкачки становится операцией сложности O(1). -* Все дерево также распределяется заранее для того, чтобы избежать распределения памяти ядра во время операций с областью подкачки при критически малом объеме свободной памяти. В конце концов, система обращается к области подкачки при нехватке памяти, так что мы должны избежать распределения памяти ядра в такие моменты для избежания потенциальных блокировок. +* Все дерево также распределяется заранее для того, чтобы избежать распределения памяти ядра во время операций с областью подкачки при критически малом объёме свободной памяти. В конце концов, система обращается к области подкачки при нехватке памяти, так что мы должны избежать распределения памяти ядра в такие моменты для избежания потенциальных блокировок. * Для уменьшения фрагментации дерево может распределять большой последовательный кусок за раз, пропуская меньшие фрагментированные области. Я не сделал последний шаг к заведению "указателя на распределение", который будет передвигаться по участку области подкачки при выделении памяти для обеспечения в будущем распределения последовательных участков, или по крайней мере местоположения ссылки, но я убежден, что это может быть сделано. [[freeing-pages]] == Когда освобождать страницу Так как система VM использует всю доступную память для кэширования диска, то обычно действительно незанятых страниц очень мало. Система VM зависит от того, как она точно выбирает незанятые страницы для повторного использования для новых распределений. Оптимальный выбор страниц для высвобождения, возможно, является самой важной функцией любой VM-системы, из тех, что она может выполнять, потому что при неправильном выборе система VM вынуждена будет запрашивать страницы с диска, значительно снижая производительность всей системы. Какую дополнительную нагрузку мы может выделить в критическом пути для избежания высвобождения не той страницы? Каждый неправильный выбор будет стоить нам сотни тысяч тактов работы центрального процессора и заметное замедление работы затронутых процессов, так что мы должны смириться со значительными издержками для того, чтобы была заведомо выбрана правильная страница. Вот почему FreeBSD превосходит другие системы в производительности при нехватке ресурсов памяти. Алгоритм определения свободной страницы написан на основе истории использования страниц памяти. Для получения этой истории система использует возможности бита использования памяти, которые имеются в большинстве аппаратных таблицах страниц памяти. В любом случае, бит использования страницы очищается, и в некоторый более поздний момент VM-система обращается к странице снова и обнаруживает, что этот бит установлен. Это указывает на то, что страница активно используется. Периодически проверяя этот бит, накапливается история использования (в виде счетчика) физической страницы. Когда позже VM-системе требуется высвободить некоторые страницы, проверка истории выступает указателем при определении наиболее вероятной кандидатуры для повторного использования. -Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. Она снимает отображение или защищает страницу, что приводит к ошибке доступа к странице, если к странице выполняется повторное обращение. При возникновении этой ошибки система просто помечает страницу как используемую и снимает защиту со страницы, так что она может использоваться. Хотя использование такого приема только для определения использования страницы весьма накладно, это выгоднее, чем повторно использовать страницу для других целей и обнаружить, что она снова нужна процессу и подгружать ее с диска. +Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. Она снимает отображение или защищает страницу, что приводит к ошибке доступа к странице, если к странице выполняется повторное обращение. При возникновении этой ошибки система просто помечает страницу как используемую и снимает защиту со страницы, так что она может использоваться. Хотя использование такого приема только для определения использования страницы весьма накладно, это выгоднее, чем повторно использовать страницу для других целей и обнаружить, что она снова нужна процессу и подгружать её с диска. -FreeBSD использует несколько очередей страниц для обновления выбора страниц для повторного использования, а также для определения того, когда же грязные страницы должны быть сброшены в хранилище. Так как таблицы страниц во FreeBSD являются динамическими объектами, практически ничего не стоит вырезать страницу из адресного пространства любого использующего ее процесса. После того, как подходящая страница, на основе счетчика использования, выбрана, именно это и выполняется. Система должна отличать между чистыми страницами, которые теоретически могут быть высвобождены в любое время, и грязными страницами, которые сначала должны быть переписаны в хранилище перед тем, как их можно будет использовать повторно. После нахождения подходящей страницы она перемещается в неактивную очередь, если она является грязной, или в очередь кэша, если она чистая. Отдельный алгоритм, основывающийся на отношении количества грязных страниц к чистым, определяет, когда грязные страницы в неактивной очереди должны быть сброшены на диск. Когда это выполнится, сброшенные страницы перемещаются из неактивной очереди в очередь кэша. В этот момент страницы в очереди кэша могут быть повторно активизированы VM со сравнительно малыми накладными расходами. Однако страницы в очереди кэша предполагается "высвобождать немедленно" и повторно использовать в LRU-порядке (меньше всего используемый), когда системе потребуется выделение дополнительной памяти. +FreeBSD использует несколько очередей страниц для обновления выбора страниц для повторного использования, а также для определения того, когда же грязные страницы должны быть сброшены в хранилище. Так как таблицы страниц во FreeBSD являются динамическими объектами, практически ничего не стоит вырезать страницу из адресного пространства любого использующего её процесса. После того, как подходящая страница, на основе счетчика использования, выбрана, именно это и выполняется. Система должна отличать между чистыми страницами, которые теоретически могут быть высвобождены в любое время, и грязными страницами, которые сначала должны быть переписаны в хранилище перед тем, как их можно будет использовать повторно. После нахождения подходящей страницы она перемещается в неактивную очередь, если она является грязной, или в очередь кэша, если она чистая. Отдельный алгоритм, основывающийся на отношении количества грязных страниц к чистым, определяет, когда грязные страницы в неактивной очереди должны быть сброшены на диск. Когда это выполнится, сброшенные страницы перемещаются из неактивной очереди в очередь кэша. В этот момент страницы в очереди кэша могут быть повторно активизированы VM со сравнительно малыми накладными расходами. Однако страницы в очереди кэша предполагается "высвобождать немедленно" и повторно использовать в LRU-порядке (меньше всего используемый), когда системе потребуется выделение дополнительной памяти. Стоит отметить, что во FreeBSD VM-система пытается разделить чистые и грязные страницы во избежание срочной необходимости в ненужных сбросах грязных страниц (что отражается на пропускной способности ввода/вывода) и не перемещает беспричинно страницы между разными очередями, когда подсистема управления памятью не испытывает нехватку ресурсов. Вот почему вы можете видеть, что при выполнении команды `systat -vm` в некоторых системах значение счетчика очереди кэша мало, а счетчик активной очереди большой. При повышении нагрузки на VM-систему она прилагает большие усилия на поддержку различных очередей страниц в соотношениях, которые являются наиболее эффективными. -Годами ходили современные легенды, что Linux выполняет работу по предотвращению выгрузки на диск лучше, чем FreeBSD, но это не так. На самом деле FreeBSD старается сбросить на диск неиспользуемые страницы для освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я не знаю, остается ли это правдой на сегодняшний день. +Годами ходили современные легенды, что Linux выполняет работу по предотвращению выгрузки на диск лучше, чем FreeBSD, но это не так. На самом деле FreeBSD старается сбросить на диск неиспользуемые страницы для освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я не знаю, остаётся ли это правдой на сегодняшний день. [[prefault-optimizations]] == Оптимизация ошибок доступа к страницам и их обнуления -Полагая, что ошибка доступа к странице памяти в VM не является операцией с большими накладными расходами, если страница уже находится в основной памяти и может быть просто отображена в адресное пространство процесса, может оказаться, что это станет весьма накладно, если их будет оказываться регулярно много. Хорошим примером этой ситуации является запуск таких программ, как man:ls[1] или man:ps[1], снова и снова. Если бинарный файл программы отображен в память, но не отображен в таблицу страниц, то все страницы, к которым обращалась программа, окажутся недоступными при каждом запуске программы. Это не так уж необходимо, если эти страницы уже присутствуют в кэше VM, так что FreeBSD будет пытаться восстанавливать таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. Однако во FreeBSD пока не выполняется предварительное копирование при записи определенных страниц при выполнении вызова exec. Например, если вы запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то заметите, что она всегда выдает некоторое количество ошибок доступа к страницам, даже когда вы запускаете ее снова и снова. Это ошибки заполнения нулями, а не ошибки кода программы (которые уже были обработаны). Предварительное копирование страниц при выполнении вызовов exec или fork находятся в области, требующей более тщательного изучения. +Полагая, что ошибка доступа к странице памяти в VM не является операцией с большими накладными расходами, если страница уже находится в основной памяти и может быть просто отображена в адресное пространство процесса, может оказаться, что это станет весьма накладно, если их будет оказываться регулярно много. Хорошим примером этой ситуации является запуск таких программ, как man:ls[1] или man:ps[1], снова и снова. Если бинарный файл программы отображен в память, но не отображен в таблицу страниц, то все страницы, к которым обращалась программа, окажутся недоступными при каждом запуске программы. Это не так уж необходимо, если эти страницы уже присутствуют в кэше VM, так что FreeBSD будет пытаться восстанавливать таблицы страниц процесса из тех страниц, что уже располагаются в VM-кэше. Однако во FreeBSD пока не выполняется предварительное копирование при записи определённых страниц при выполнении вызова exec. Например, если вы запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то заметите, что она всегда выдает некоторое количество ошибок доступа к страницам, даже когда вы запускаете её снова и снова. Это ошибки заполнения нулями, а не ошибки кода программы (которые уже были обработаны). Предварительное копирование страниц при выполнении вызовов exec или fork находятся в области, требующей более тщательного изучения. -Большой процент ошибок доступа к страницам, относится к ошибкам при заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды `vmstat -s`. Это происходит, когда процесс обращается к страницам в своей области BSS. Область BSS предполагается изначально заполненной нулями, но VM-система не заботится о выделении памяти до тех пор, пока процесс реально к ней не обратится. При возникновении ошибки VM-система должна не только выделить новую страницу, но и заполнить ее нулями. Для оптимизации операции по заполнению нулями в системе VM имеется возможность предварительно обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при возникновении ошибок заполнения нулями. Предварительное заполнение нулями происходит, когда CPU простаивает, однако количество страниц, которые система заранее заполняет нулями, ограничено, для того, чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради оптимизации критического пути. +Большой процент ошибок доступа к страницам, относится к ошибкам при заполнении нулями. Вы можете обычно видеть это, просматривая вывод команды `vmstat -s`. Это происходит, когда процесс обращается к страницам в своей области BSS. Область BSS предполагается изначально заполненной нулями, но VM-система не заботится о выделении памяти до тех пор, пока процесс реально к ней не обратится. При возникновении ошибки VM-система должна не только выделить новую страницу, но и заполнить её нулями. Для оптимизации операции по заполнению нулями в системе VM имеется возможность предварительно обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при возникновении ошибок заполнения нулями. Предварительное заполнение нулями происходит, когда CPU простаивает, однако количество страниц, которые система заранее заполняет нулями, ограничено, для того, чтобы не переполнить кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради оптимизации критического пути. [[page-table-optimizations]] == Оптимизация таблицы страниц -Оптимизация таблицы страниц составляет самую содержательную часть архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при значительном использовании `mmap()`. Я думаю, что это на самом деле особенность работы большинства BSD-систем, хотя я не уверен, когда это проявилось впервые. Есть два основных подхода к оптимизации. Первый заключается в том, что аппаратные таблицы страниц не содержат постоянного состояния, а вместо этого могут быть сброшены в любой момент с малыми накладными расходами. Второй подход состоит в том, что каждая активная таблица страниц в системе имеет управляющую структуру `pv_entry`, которая связана в структуру `vm_page`. FreeBSD может просто просматривать эти отображения, которые существуют, когда как в Linux должны проверяться все таблицы страниц, которые _могут_ содержать нужное отображение, что в некоторых ситуация дает увеличение сложности O(n^2). Из-за того, что FreeBSD стремится выбрать наиболее подходящую к повторному использованию или сбросу в область подкачки страницу, когда ощущается нехватка памяти, система дает лучшую производительность при нагрузке. Однако во FreeBSD требуется тонкая настройка ядра для соответствия ситуациям с большим совместно используемым адресным пространством, которые могут случиться в системе, обслуживающей сервер телеконференций, потому что структуры `pv_entry` могут оказаться исчерпанными. +Оптимизация таблицы страниц составляет самую содержательную часть архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при значительном использовании `mmap()`. Я думаю, что это на самом деле особенность работы большинства BSD-систем, хотя я не уверен, когда это проявилось впервые. Есть два основных подхода к оптимизации. Первый заключается в том, что аппаратные таблицы страниц не содержат постоянного состояния, а вместо этого могут быть сброшены в любой момент с малыми накладными расходами. Второй подход состоит в том, что каждая активная таблица страниц в системе имеет управляющую структуру `pv_entry`, которая связана в структуру `vm_page`. FreeBSD может просто просматривать эти отображения, которые существуют, когда как в Linux должны проверяться все таблицы страниц, которые _могут_ содержать нужное отображение, что в некоторых ситуация даёт увеличение сложности O(n^2). Из-за того, что FreeBSD стремится выбрать наиболее подходящую к повторному использованию или сбросу в область подкачки страницу, когда ощущается нехватка памяти, система даёт лучшую производительность при нагрузке. Однако во FreeBSD требуется тонкая настройка ядра для соответствия ситуациям с большим совместно используемым адресным пространством, которые могут случиться в системе, обслуживающей сервер телеконференций, потому что структуры `pv_entry` могут оказаться исчерпанными. И в Linux, и во FreeBSD требуются доработки в этой области. FreeBSD пытается максимизировать преимущества от потенциально редко применяемой модели активного отображения (к примеру, не всем процессам нужно отображать все страницы динамической библиотеки), когда как Linux пытается упростить свои алгоритмы. FreeBSD имеет здесь общее преимущество в производительности за счет использования дополнительной памяти, но FreeBSD выглядит хуже в случае, когда большой файл совместно используется сотнями процессов. Linux, с другой стороны, выглядит хуже в случае, когда много процессов частично используют одну и ту же динамическую библиотеку, а также работает неоптимально при попытке определить, может ли страница повторно использоваться, или нет. [[conclusion]] == Заключение Виртуальная память в современных операционных системах должна решать несколько различных задач эффективно и при разных условиях. Модульный и алгоритмический подход, которому исторически следует BSD, позволяет нам изучить и понять существующую реализацию, а также сравнительно легко изменить большие блоки кода. За несколько последних лет в VM-системе FreeBSD было сделано некоторое количество усовершенствований, и работа над ними продолжается. [[allen-briggs-qa]] == Дополнительный сеанс вопросов и ответов от Аллена Бриггса (Allen Briggs) === Что это за алгоритм чередования, который вы упоминали в списке недостатков подсистемы управления разделом подкачки во FreeBSD 3.X? -FreeBSD использует в области подкачки механизм чередования, с индексом по умолчанию, равным четырем. Это означает, что FreeBSD резервирует пространство для четырех областей подкачки, даже если у вас имеется всего лишь одна, две или три области. Так как в области подкачки имеется чередование, то линейное адресное пространство, представляющее "четыре области подкачки", будет фрагментироваться, если у вас нет на самом деле четырех областей подкачки. Например, если у вас две области A и B, то представление адресного пространства для этой области подкачки во FreeBSD будет организовано с чередованием блоков из 16 страниц: +FreeBSD использует в области подкачки механизм чередования, с индексом по умолчанию, равным четырем. Это означает, что FreeBSD резервирует пространство для четырёх областей подкачки, даже если у вас имеется всего лишь одна, две или три области. Так как в области подкачки имеется чередование, то линейное адресное пространство, представляющее "четыре области подкачки", будет фрагментироваться, если у вас нет на самом деле четырёх областей подкачки. Например, если у вас две области A и B, то представление адресного пространства для этой области подкачки во FreeBSD будет организовано с чередованием блоков из 16 страниц: .... A B C D A B C D A B C D A B C D .... -FreeBSD 3.X использует "последовательный список свободных областей" для управления свободными областями в разделе подкачки. Идея состоит в том, что большие последовательные блоки свободного пространства могут быть представлены при помощи узла односвязного списка ([.filename]#kern/subr_rlist.c#). Но из-за фрагментации последовательный список сам становится фрагментированным. В примере выше полностью неиспользуемое пространство в A и B будет показано как "свободное", а C и D как "полностью занятое". Каждой последовательности A-B требуется для учета узел списка, потому что C и D являются дырами, так что узел списка не может быть связан со следующей последовательностью A-B. +FreeBSD 3.X использует "последовательный список свободных областей" для управления свободными областями в разделе подкачки. Идея состоит в том, что большие последовательные блоки свободного пространства могут быть представлены при помощи узла односвязного списка ([.filename]#kern/subr_rlist.c#). Но из-за фрагментации последовательный список сам становится фрагментированным. В примере выше полностью неиспользуемое пространство в A и B будет показано как "свободное", а C и D как "полностью занятое". Каждой последовательности A-B требуется для учёта узел списка, потому что C и D являются дырами, так что узел списка не может быть связан со следующей последовательностью A-B. Почему мы организуем чередование в области подкачки вместо того, чтобы просто объединить области подкачки в одно целое и придумать что-то более умное? Потому что гораздо легче выделять последовательные полосы адресного пространства и получать в результате автоматическое чередование между несколькими дисками, чем пытаться выдумывать сложности в другом месте. Фрагментация вызывает другие проблемы. Являясь последовательным списком в 3.X и имея такое огромную фрагментацию, выделение и освобождение в области подкачки становится алгоритмом сложности O(N), а не O(1). Вместе с другими факторами (частое обращение к области подкачки) вы получаете сложность уровней O(N^2) и O(N^3), что плохо. В системе 3.X также может потребоваться выделение KVM во время работы с областью подкачки для создания нового узла списка, что в условии нехватки памяти может привести к блокировке, если система попытается сбросить страницы в область подкачки. -В 4.X мы не используем последовательный список. Вместо этого мы используем базисное дерево и битовые карты блоков области подкачки, а не ограниченный список узлов. Мы принимаем предварительное выделение всех битовых карт, требуемых для всей области подкачки, но при этом тратится меньше памяти, потому что мы используем битовые карты (один бит на блок), а не связанный список узлов. Использование базисного дерева вместо последовательного списка дает нам производительность O(1) вне зависимости от фрагментации дерева. +В 4.X мы не используем последовательный список. Вместо этого мы используем базисное дерево и битовые карты блоков области подкачки, а не ограниченный список узлов. Мы принимаем предварительное выделение всех битовых карт, требуемых для всей области подкачки, но при этом тратится меньше памяти, потому что мы используем битовые карты (один бит на блок), а не связанный список узлов. Использование базисного дерева вместо последовательного списка даёт нам производительность O(1) вне зависимости от фрагментации дерева. === Как разделение чистых и грязных (неактивных) страниц связано с ситуацией, когда вы видите маленький счетчик очереди кэша и большой счетчик активной очереди в выдаче команды systat -vm? Разве системная статистика не считает активные и грязные страницы вместе за счетчик активной очереди? Да, это запутывает. Связь заключается в "желаемом" и "действительном". Мы желаем разделить страницы, но реальность такова, что пока у нас нет проблем с памятью, нам это на самом деле не нужно. Это означает, что FreeBSD не будет очень сильно стараться над отделением грязных страниц (неактивная очередь) от чистых страниц (очередь кэша), когда система не находится под нагрузкой, и не будет деактивировать страницы (активная очередь -> неактивная очередь), когда система не нагружена, даже если они не используются. === В примере с / 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)? А именно какое действие/реакцию должно потребоваться для сканирования отображений? -`vm_page` представляет собой пару (object,index#). `pv_entry` является записью из аппаратной таблицы страниц (pte). Если у вас имеется пять процессов, совместно использующих одну и ту же физическую страницу, и в трех таблицах страниц этих процессов на самом деле отображается страница, то страница будет представляться одной структурой `vm_page` и тремя структурами `pv_entry`. +`vm_page` представляет собой пару (object,index#). `pv_entry` является записью из аппаратной таблицы страниц (pte). Если у вас имеется пять процессов, совместно использующих одну и ту же физическую страницу, и в трёх таблицах страниц этих процессов на самом деле отображается страница, то страница будет представляться одной структурой `vm_page` и тремя структурами `pv_entry`. -Структуры `pv_entry` представляют страницы, отображаемые MMU (одна структура `pv_entry` соответствует одной pte). Это означает, что, когда нам нужно убрать все аппаратные ссылки на `vm_page` (для того, чтобы повторно использовать страницу для чего-то еще, выгрузить ее, очистить, пометить как грязную и так далее), мы можем просто просмотреть связный список структур `pv_entry`, связанных с этой `vm_page`, для того, чтобы удалить или изменить pte из их таблиц страниц. +Структуры `pv_entry` представляют страницы, отображаемые MMU (одна структура `pv_entry` соответствует одной pte). Это означает, что, когда нам нужно убрать все аппаратные ссылки на `vm_page` (для того, чтобы повторно использовать страницу для чего-то ещё, выгрузить её, очистить, пометить как грязную и так далее), мы можем просто просмотреть связный список структур `pv_entry`, связанных с этой `vm_page`, для того, чтобы удалить или изменить pte из их таблиц страниц. В Linux нет такого связного списка. Для того, чтобы удалить все отображения аппаратной таблицы страниц для `vm_page`, linux должен пройти по индексу каждого объекта VM, который _может_ отображать страницу. К примеру, если у вас имеется 50 процессов, которые все отображают ту же самую динамическую библиотеку и хотите избавиться от страницы X в этой библиотеке, то вам нужно пройтись по индексу всей таблицы страниц для каждого из этих 50 процессов, даже если только 10 из них на самом деле отображают страницу. Так что Linux использует простоту подхода за счет производительности. Многие алгоритмы VM, которые имеют сложность O(1) или (N малое) во FreeBSD, в Linux приобретают сложность O(N), O(N^2) или хуже. Так как pte, представляющий конкретную страницу в объекте, скорее всего, будет с тем же смещением во всех таблицах страниц, в которых они отображаются, то уменьшение количества обращений в таблицы страниц по тому же самому смещению часто позволяет избежать разрастания кэша L1 для этого смещения, что приводит к улучшению производительности. Во FreeBSD введены дополнительные сложности (схема с `pv_entry`) для увеличения производительности (уменьшая количество обращений _только_ к тем pte, которые нужно модифицировать). -Но во FreeBSD имеется проблема масштабирования, которой нет в Linux, потому что имеется ограниченное число структур `pv_entry`, и это приводит к возникновению проблем при большом объеме совместно используемых данных. В этом случае у вас может возникнуть нехватка структур `pv_entry`, даже если свободной памяти хватает. Это может быть достаточно легко исправлено увеличением количества структур `pv_entry` при настройке, но на самом деле нам нужно найти лучший способ делать это. +Но во FreeBSD имеется проблема масштабирования, которой нет в Linux, потому что имеется ограниченное число структур `pv_entry`, и это приводит к возникновению проблем при большом объёме совместно используемых данных. В этом случае у вас может возникнуть нехватка структур `pv_entry`, даже если свободной памяти хватает. Это может быть достаточно легко исправлено увеличением количества структур `pv_entry` при настройке, но на самом деле нам нужно найти лучший способ делать это. Что касается использования памяти под таблицу страниц против схемы с `pv_entry`: Linux использует "постоянные" таблицы страниц, которые не сбрасываются, но ему не нужны `pv_entry` для каждого потенциально отображаемого pte. FreeBSD использует "сбрасываемые" таблицы страниц, но для каждого реально отображаемого pte добавляется структура `pv_entry`. Я думаю, что использование памяти будет примерно одинакова, тем более что у FreeBSD есть алгоритмическое преимущество, заключающееся в способности сбрасывать таблицы страниц с очень малыми накладными расходами. diff --git a/documentation/content/ru/articles/vm-design/_index.po b/documentation/content/ru/articles/vm-design/_index.po index 089a4d860c..5127516f19 100644 --- a/documentation/content/ru/articles/vm-design/_index.po +++ b/documentation/content/ru/articles/vm-design/_index.po @@ -1,1373 +1,1373 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov , 2025. +# Vladlen Popolitov , 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-06-29 21:20+0100\n" -"PO-Revision-Date: 2025-07-05 04:45+0000\n" +"PO-Revision-Date: 2026-03-08 09:11+0000\n" "Last-Translator: Vladlen Popolitov \n" "Language-Team: Russian \n" "Language: ru\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && " "n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" "X-Generator: Weblate 4.17\n" #. type: YAML Front Matter: description #: documentation/content/en/articles/vm-design/_index.adoc:1 #, no-wrap msgid "An easy to follow description of the design of the FreeBSD virtual memory system" msgstr "" "Простое и понятное описание архитектуры системы виртуальной памяти FreeBSD" #. type: Title = #: documentation/content/en/articles/vm-design/_index.adoc:1 #: documentation/content/en/articles/vm-design/_index.adoc:11 #, no-wrap msgid "Design elements of the FreeBSD VM system" msgstr "Элементы архитектуры системы виртуальной памяти во FreeBSD" #. type: delimited block = 4 #: documentation/content/en/articles/vm-design/_index.adoc:46 msgid "" "This document is outdated and some sections do not accurately describe the " "current state of the VM system. It is retained for historical purposes and " "may be updated over time." msgstr "" "Этот документ устарел, и некоторые разделы больше не соответствуют текущему " "состоянию системы виртуальной памяти. Он сохранён в исторических целях и " "может быть обновлён в будущем." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:50 msgid "Abstract" msgstr "Аннотация" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:52 msgid "Matthew Dillon " msgstr "Matthew Dillon " #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:59 msgid "" "The title is really just a fancy way of saying that I am going to attempt to " "describe the whole VM enchilada, hopefully in a way that everyone can " "follow. For the last year I have concentrated on a number of major kernel " "subsystems within FreeBSD, with the VM and Swap subsystems being the most " "interesting and NFS being \"a necessary chore\". I rewrote only small " "portions of the code. In the VM arena the only major rewrite I have done is " "to the swap subsystem. Most of my work was cleanup and maintenance, with " "only moderate code rewriting and no major algorithmic adjustments within the " "VM subsystem. The bulk of the VM subsystem's theoretical base remains " "unchanged and a lot of the credit for the modernization effort in the last " "few years belongs to John Dyson and David Greenman. Not being a historian " "like Kirk I will not attempt to tag all the various features with peoples " "names, since I will invariably get it wrong." msgstr "" "Это название — просто замысловатый способ сказать, что я попытаюсь описать " "всю систему виртуальной памяти (VM) целиком, по возможности так, чтобы это " "было понятно каждому.В течение последнего года я сосредоточился на " "нескольких основных подсистемах ядра FreeBSD. Наиболее интересными из них " "стали подсистемы VM и подкачки (Swap), тогда как работа с NFS оказалась, " "скорее, «необходимой рутиной». Я переписал лишь небольшие части кода. В " "области VM моей единственной крупной переработкой стала подсистема подкачки. " "В основном моя работа заключалась в очистке и поддержке кода, с умеренными " "правками и без серьёзных изменений алгоритмов в подсистеме VM. Теоретическая " "основа VM-подсистемы осталась неизменной, и львиная доля заслуг в её " "модернизации за последние годы принадлежит Джону Дайсону и Дэвиду Гринману. " "Я не историк, в отличие от Кирка, поэтому не стану приписывать различные " "функции конкретным людям — всё равно где-нибудь ошибусь." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:61 msgid "'''" msgstr "'''" #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:65 #, no-wrap msgid "Introduction" msgstr "Введение" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:81 msgid "" "Before moving along to the actual design let's spend a little time on the " "necessity of maintaining and modernizing any long-living codebase. In the " "programming world, algorithms tend to be more important than code and it is " "precisely due to BSD's academic roots that a great deal of attention was " "paid to algorithm design from the beginning. More attention paid to the " "design generally leads to a clean and flexible codebase that can be fairly " "easily modified, extended, or replaced over time. While BSD is considered " "an \"old\" operating system by some people, those of us who work on it tend " "to view it more as a \"mature\" codebase which has various components " "modified, extended, or replaced with modern code. It has evolved, and " "FreeBSD is at the bleeding edge no matter how old some of the code might " "be. This is an important distinction to make and one that is unfortunately " "lost to many people. The biggest error a programmer can make is to not " "learn from history, and this is precisely the error that many other modern " "operating systems have made. Windows NT(R) is the best example of this, and " "the consequences have been dire. Linux also makes this mistake to some " "degree-enough that we BSD folk can make small jokes about it every once in a " "while, anyway. Linux's problem is simply one of a lack of experience and " "history to compare ideas against, a problem that is easily and rapidly being " "addressed by the Linux community in the same way it has been addressed in " "the BSD community-by continuous code development. The Windows NT(R) folk, " "on the other hand, repeatedly make the same mistakes solved by UNIX(R) " "decades ago and then spend years fixing them. Over and over again. They " "have a severe case of \"not designed here\" and \"we are always right " "because our marketing department says so\". I have little tolerance for " "anyone who cannot learn from history." msgstr "" "Перед тем, как перейти непосредственно к существующей архитектуре, потратим " "немного времени на рассмотрение вопроса о необходимости поддержки и " "модернизации любого длительно живущего кода. В мире программирования " "алгоритмы становятся более важными, чем код, и именно из-за академических " "корней BSD изначально большое внимание уделялось проработке алгоритмов. " "Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости " "кода, который может быть достаточно легко изменен, расширен или с течением " "времени заменен. Хотя некоторые считают BSD \"старой\" операционной " -"системой, те их нас, кто работает над ней, видят ее скорее системой со " +"системой, те их нас, кто работает над ней, видят её скорее системой со " "\"зрелым\" кодом с различными компонентами, которые были заменены, расширены " -"или изменены современным кодом. Он развивается, и FreeBSD остается передовой " +"или изменены современным кодом. Он развивается, и 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 msgid "" "Much of the apparent complexity of the FreeBSD design, especially in the VM/" "Swap subsystem, is a direct result of having to solve serious performance " "issues that occur under various conditions. These issues are not due to bad " "algorithmic design but instead rise from environmental factors. In any " "direct comparison between platforms, these issues become most apparent when " "system resources begin to get stressed. As I describe FreeBSD's VM/Swap " "subsystem the reader should always keep two points in mind:" msgstr "" "Большинство очевидной сложности архитектуры FreeBSD, особенно в подсистеме " "VM/Swap, является прямым следствием того, что она решает серьезные проблемы " "с производительностью, которые проявляются при различных условиях. Эти " "проблемы вызваны не плохой проработкой алгоритмов, а возникают из окружающих " "факторов. В любом прямом сравнении между платформами эти проблемы " "проявляются, когда системные ресурсы начинают истощаться. Так как я описываю " "подсистему VM/Swap во FreeBSD, то читатель должен всегда иметь в виду два " "обстоятельства:" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:88 msgid "" "The most important aspect of performance design is what is known as " "\"Optimizing the Critical Path\". It is often the case that performance " "optimizations add a little bloat to the code to make the critical path " "perform better." msgstr "" "Самым важным аспектом при проектировании производительности является то, что " "называется \"оптимизацией критического маршрута\". Часто случается, что " -"оптимизация производительности дает прирост объема кода ради того, чтобы " +"оптимизация производительности даёт прирост объёма кода ради того, чтобы " "критический маршрут работал быстрее." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:89 msgid "" "A solid, generalized design outperforms a heavily-optimized design over the " "long run. While a generalized design may end up being slower than an heavily-" "optimized design when they are first implemented, the generalized design " "tends to be easier to adapt to changing conditions and the heavily-optimized " "design winds up having to be thrown away." msgstr "" "Четкость общей архитектуры оказывается лучше сильно оптимизированной " "архитектуры с течением времени. Когда как обобщенная архитектура может быть " "медленнее, чем оптимизированная архитектура, при первой реализации, при " "обобщенной архитектуре легче подстраиваться под изменяющиеся условия и " "чрезмерно оптимизированная архитектура оказывается непригодной." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:93 msgid "" "Any codebase that will survive and be maintainable for years must therefore " "be designed properly from the beginning even if it costs some performance. " "Twenty years ago people were still arguing that programming in assembly was " "better than programming in a high-level language because it produced code " "that was ten times as fast. Today, the fallibility of that argument is " "obvious - as are the parallels to algorithmic design and code generalization." msgstr "" "Любой код, который должен выжить и поддаваться поддержке годы, должен " "поэтому быть тщательно продуман с самого начала, даже если это стоит потери " "производительности. Двадцать лет назад были те, кто отстаивал преимущество " "программирования на языке ассемблера перед программированием на языке " "высокого уровня, потому что первый генерировал в десять раз более быстрый " "код. В наши дни ошибочность этого аргумента очевидна - можно провести " "параллели с построением алгоритмов и обобщением кода." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:95 #, no-wrap msgid "VM Objects" msgstr "Объекты VM" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:105 msgid "" "The best way to begin describing the FreeBSD VM system is to look at it from " "the perspective of a user-level process. Each user process sees a single, " "private, contiguous VM address space containing several types of memory " "objects. These objects have various characteristics. Program code and " "program data are effectively a single memory-mapped file (the binary file " "being run), but program code is read-only while program data is copy-on-" "write. Program BSS is just memory allocated and filled with zeros on " "demand, called demand zero page fill. Arbitrary files can be memory-mapped " "into the address space as well, which is how the shared library mechanism " "works. Such mappings can require modifications to remain private to the " "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, содержащее несколько типов объектов памяти. Эти объекты имеют различные " -"характеристики. Код программы и ее данные являются единым файлом, " +"характеристики. Код программы и её данные являются единым файлом, " "отображаемым в память (это выполняющийся двоичный файл), однако код " "программы доступен только для чтения, когда как данные программы размещаются " "в режиме копирования-при-записи. BSS программы представляет собой всего лишь " "выделенную область памяти, заполненную, если это требовалось, нулями, что " "называется обнулением страниц памяти по требованию. Отдельные файлы могут " "также отображаться в адресное пространство, именно так работают динамические " "библиотеки. Такие отображения требуют изменений, чтобы оставаться " "принадлежащими процессу, который их выполнил. Системный вызов fork добавляет " "переводит проблему управления VM полностью в новую плоскость, вдобавок к уже " "имеющимся сложностям." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:111 msgid "" "A program binary data page (which is a basic copy-on-write page) illustrates " "the complexity. A program binary contains a preinitialized data section " "which is initially mapped directly from the program file. When a program is " "loaded into a process's VM space, this area is initially memory-mapped and " "backed by the program binary itself, allowing the VM system to free/reuse " "the page and later load it back in from the binary. The moment a process " "modifies this data, however, the VM system must make a private copy of the " "page for that process. Since the private copy has been modified, the VM " "system may no longer free it, because there is no longer any way to restore " "it later on." msgstr "" "Иллюстрирует сложность страница данных двоичной программы (которая является " "страницей копируемой-при-записи). Двоичная программа содержит секцию " "предварительно инициализированных данных, которая первоначально отображается " "непосредственно из файла программы. Когда программа загружается в Vm-" "пространство процесса, эта область сначала отображается в память и " "поддерживается бинарным файлом программы, позволяя VM-системе освобождать/" -"повторно использовать страницу, а потом загружать ее снова из бинарного " +"повторно использовать страницу, а потом загружать её снова из бинарного " "файла. Однако в момент, когда процесс изменяет эти данные, VM-система должна " "сделать копию страницы, принадлежащую только этому процессу. Так как эта " "копия была изменена, то VM-система не может больше освобождать эту страницу, " -"так как впоследствии ее невозможно будет восстановить." +"так как впоследствии её невозможно будет восстановить." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:118 msgid "" "You will notice immediately that what was originally a simple file mapping " "has become much more complex. Data may be modified on a page-by-page basis " "whereas the file mapping encompasses many pages at once. The complexity " "further increases when a process forks. When a process forks, the result is " "two processes-each with their own private address spaces, including any " "modifications made by the original process prior to the call to `fork()`. " "It would be silly for the VM system to make a complete copy of the data at " "the time of the `fork()` because it is quite possible that at least one of " "the two processes will only need to read from that page from then on, " "allowing the original page to continue to be used. What was a private page " "is made copy-on-write again, since each process (parent and child) expects " "their own personal post-fork modifications to remain private to themselves " "and not affect the other." msgstr "" "Вы тут же заметите, что то, что сначала было простым отображением файла в " "память, становится гораздо более сложным предметом. Данные могут " "модифицироваться постранично, когда как отображение файла выполняется для " -"многих страниц за раз. Сложность еще более увеличивается, когда процесс " +"многих страниц за раз. Сложность ещё более увеличивается, когда процесс " "выполняет вызов fork. При этом порождаются два процесса-каждый со с " "собственным адресным пространством, включающим все изменения, выполненные " "исходным процессом до вызова функции `fork()`. Было бы глупо для VM-системы " "делать полную копию данных во время вызова `fork()`, так как весьма " "вероятно, что один из двух процессов будет нужен только для чтения из той " "страницы, что позволяет использование исходной страницы. То, что было " "страницей, принадлежащей только процессу, сделается снова страницей, " "копируемой при записи, так как каждый из процессов (и родитель, и потомок) " "полагают, что их собственные изменения после разветвления будут принадлежать " "только им, и не затронут родственный процесс." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:127 msgid "" "FreeBSD manages all of this with a layered VM Object model. The original " "binary program file winds up being the lowest VM Object layer. A copy-on-" "write layer is pushed on top of that to hold those pages which had to be " "copied from the original file. If the program modifies a data page " "belonging to the original file the VM system takes a fault and makes a copy " "of the page in the higher layer. When a process forks, additional VM Object " "layers are pushed on. This might make a little more sense with a fairly " "basic example. A `fork()` is a common operation for any *BSD system, so " "this example will consider a program that starts up, and forks. When the " "process starts, the VM system creates an object layer, let's call this A:" msgstr "" "FreeBSD управляет всем этим при помощи многоуровневой модели VM-объектов. " "Исходный файл с двоичной программой переносится на самый нижний уровень " "объектов VM. Уровень страниц, копируемых при записи, находится выше него, и " "хранит те страницы, которые были скопированы из исходного файла. Если " "программа модифицирует страницы данных, относящиеся к исходному файлу, то " "система VM обнаруживает это и переносит копию этой страницы на более высокий " "уровень. Когда процесс разветвляется, добавляются новые уровни VM-объектов. " "Это можно показать на простом примере. Функция `fork()` является общей " "операцией для всех систем *BSD, так что в этом примере будет рассматриваться " "программа, которая запускается, а затем разветвляется. Когда процесс " "запускается, VM-система создает некоторый уровень объектов, обозначим его A:" #. type: Positional ($1) AttributeList argument for macro 'image' #: documentation/content/en/articles/vm-design/_index.adoc:128 #, no-wrap msgid "A picture" msgstr "Рисунок" #. type: Target for macro image #: documentation/content/en/articles/vm-design/_index.adoc:128 #, no-wrap msgid "fig1.png" msgstr "fig1.png" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:133 msgid "" "A represents the file-pages may be paged in and out of the file's physical " "media as necessary. Paging in from the disk is reasonable for a program, " "but we really do not want to page back out and overwrite the executable. " "The VM system therefore creates a second layer, B, that will be physically " "backed by swap space:" msgstr "" "A соответствует файлу-по необходимости страницы памяти могут высвобождаться " "и подгружаться с носителя файла. Подгрузка с диска может потребоваться " "программе, однако на самом деле мы не хотим, чтобы она записывалась обратно " "в файл. Поэтому VM-система создает второй уровень, B, который физически " "поддерживается дисковым пространством подкачки:" #. type: Target for macro image #: documentation/content/en/articles/vm-design/_index.adoc:134 #, no-wrap msgid "fig2.png" msgstr "fig2.png" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:139 msgid "" "On the first write to a page after this, a new page is created in B, and its " "contents are initialized from A. All pages in B can be paged in or out to a " "swap device. When the program forks, the VM system creates two new object " "layers-C1 for the parent, and C2 for the child-that rest on top of B:" msgstr "" "При первой записи в страницу после выполнения этой операции, в B создается " "новая страница, содержимое которой берется из A. Все страницы в B могут " "сбрасываться и считываться из устройства подкачки. Когда программа ветвится, " "VM-система создает два новых уровня объектов-C1 для порождающего процесса и " "C2 для порожденного-они располагаются поверх B:" #. type: Target for macro image #: documentation/content/en/articles/vm-design/_index.adoc:140 #, no-wrap msgid "fig3.png" msgstr "fig3.png" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:151 msgid "" "In this case, let's say a page in B is modified by the original parent " "process. The process will take a copy-on-write fault and duplicate the page " "in C1, leaving the original page in B untouched. Now, let's say the same " "page in B is modified by the child process. The process will take a copy-on-" "write fault and duplicate the page in C2. The original page in B is now " "completely hidden since both C1 and C2 have a copy and B could theoretically " "be destroyed if it does not represent a \"real\" file; however, this sort of " "optimization is not trivial to make because it is so fine-grained. FreeBSD " "does not make this optimization. Now, suppose (as is often the case) that " "the child process does an `exec()`. Its current address space is usually " "replaced by a new address space representing a new file. In this case, the " "C2 layer is destroyed:" msgstr "" "В этом случае, допустим, что страница в B была изменена начальным " "родительским процессом. В процессе возникнет ситуация копирования при записи " "и страница скопируется в C1, при этом исходная страница останется в B " "нетронутой. Теперь допустим, что та же самая страница в B изменяется " "порожденным процессом. В процессе возникнет ситуация копирования при записи " "и страница скопируется в C2. Исходная страница в B теперь полностью скрыта, " "так как и C1, и C2 имеют копии, а B теоретически может быть уничтожена, если " "она не представляет собой \"реального\" файла). Однако такую оптимизацию не " "так уж просто осуществить, потому что она делается на уровне мелких единиц. " "Во FreeBSD такая оптимизация не выполняется. Теперь положим (а это часто " "случается), что порожденный процесс выполняет вызов `exec()`. Его текущее " "адресное пространство обычно заменяется новым адресным пространством, " "представляющим новый файл. В этом случае уровень C2 уничтожается:" #. type: Target for macro image #: documentation/content/en/articles/vm-design/_index.adoc:152 #, no-wrap msgid "fig4.png" msgstr "fig4.png" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:158 msgid "" "In this case, the number of children of B drops to one, and all accesses to " "B now go through C1. This means that B and C1 can be collapsed together. " "Any pages in B that also exist in C1 are deleted from B during the " "collapse. Thus, even though the optimization in the previous step could not " "be made, we can recover the dead pages when either of the processes exit or " "`exec()`." msgstr "" "В этом случае количество потомков B становится равным одному и все обращения " "к B теперь выполняются через C1. Это означает, что B и C1 могут быть " "объединены. Все страницы в B, которые также существуют и в C1, во время " "объединения из B удаляются. Таким образом, хотя оптимизация на предыдущем " "шаге может не делаться, мы можем восстановить мертвые страницы при окончании " "работы процессов или при вызове `exec()`." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:165 msgid "" "This model creates a number of potential problems. The first is that you " "can wind up with a relatively deep stack of layered VM Objects which can " "cost scanning time and memory when you take a fault. Deep layering can " "occur when processes fork and then fork again (either parent or child). The " "second problem is that you can wind up with dead, inaccessible pages deep in " "the stack of VM Objects. In our last example if both the parent and child " "processes modify the same page, they both get their own private copies of " "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 может быть высвобождена." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:176 msgid "" "FreeBSD solves the deep layering problem with a special optimization called " "the \"All Shadowed Case\". This case occurs if either C1 or C2 take " "sufficient COW faults to completely shadow all pages in B. Lets say that C1 " "achieves this. C1 can now bypass B entirely, so rather then have C1->B->A " "and C2->B->A we now have C1->A and C2->B->A. But look what also happened-" "now B has only one reference (C2), so we can collapse B and C2 together. " "The end result is that B is deleted entirely and we have C1->A and C2->A. " "It is often the case that B will contain a large number of pages and neither " "C1 nor C2 will be able to completely overshadow it. If we fork again and " "create a set of D layers, however, it is much more likely that one of the D " "layers will eventually be able to completely overshadow the much smaller " "dataset represented by C1 or C2. The same optimization will work at any " "point in the graph and the grand result of this is that even on a heavily " "forked machine VM Object stacks tend to not get much deeper then 4. This is " "true of both the parent and the children and true whether the parent is " "doing the forking or whether the children cascade forks." msgstr "" "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 не " -"часто бывают глубже четырех уровней. Это так как для порождающего, так и для " -"порожденного процессов, и остается в силе как в случае, когда ветвление " +"часто бывают глубже четырёх уровней. Это так как для порождающего, так и для " +"порожденного процессов, и остаётся в силе как в случае, когда ветвление " "делает родитель, так и в случае, когда ветвление выполняет потомок." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:180 msgid "" "The dead page problem still exists in the case where C1 or C2 do not " "completely overshadow B. Due to our other optimizations this case does not " "represent much of a problem and we simply allow the pages to be dead. If " "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. Из-за других применяемых нами методов оптимизации " "этот случай не представляет большой проблемы и мы просто позволяем таким " "страницам существовать. Если система испытывает нехватку оперативной памяти, " "она выполняет их выгрузку в область подкачки, что занимает некоторое " "пространство в области подкачки, но это все." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:184 msgid "" "The advantage to the VM Object model is that `fork()` is extremely fast, " "since no real data copying need take place. The disadvantage is that you " "can build a relatively complex VM Object layering that slows page fault " "handling down a little, and you spend memory managing the VM Object " "structures. The optimizations FreeBSD makes proves to reduce the problems " "enough that they can be ignored, leaving no real disadvantage." msgstr "" "Преимущество модели VM-объектов заключается в очень быстром выполнении " "функции `fork()`, так как при этом не выполняется реального копирования " "данных. Минусом этого подхода является то, что вы можете построить " "сравнительно сложную иерархию объектов VM, которая несколько замедляет " "обработку ситуаций отсутствия страниц памяти, и к тому же тратится память на " "управление структурами объектов VM. Приемы оптимизации, применяемые во " "FreeBSD, позволяют снизить значимость этих проблем до степени, когда их " "можно без особых потерь игнорировать." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:186 #, no-wrap msgid "SWAP Layers" msgstr "Уровни области подкачки" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:194 msgid "" "Private data pages are initially either copy-on-write or zero-fill pages. " "When a change, and therefore a copy, is made, the original backing object " "(usually a file) can no longer be used to save a copy of the page when the " "VM system needs to reuse it for other purposes. This is where SWAP comes " "in. SWAP is allocated to create backing store for memory that does not " "otherwise have it. FreeBSD allocates the swap management structure for a VM " "Object only when it is actually needed. However, the swap management " "structure has had problems historically:" msgstr "" "Страницы с собственными данными первоначально являются страницами, " "копируемыми при записи или заполняемыми нулями. Когда выполняется изменение, " "и, соответственно, копирование, начальное хранилище объекта (обычно файл) не " "может больше использоваться для хранения копии страницы, когда VM-системе " -"нужно использовать ее повторно для других целей. В этот момент на помощь " +"нужно использовать её повторно для других целей. В этот момент на помощь " "приходит область подкачки. Область подкачки выделяется для организации " "хранилища памяти, которая иначе не может быть доступна. FreeBSD создает " "структуру управления подкачкой для объекта VM, только когда это " "действительно нужно. Однако структура управления подкачкой исторически имела " "некоторые проблемы:" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:196 msgid "" "Under FreeBSD 3.X the swap management structure preallocates an array that " "encompasses the entire object requiring swap backing store-even if only a " "few pages of that object are swap-backed. This creates a kernel memory " "fragmentation problem when large objects are mapped, or processes with large " "runsizes (RSS) fork." msgstr "" "Во FreeBSD 3.X в структуре управления областью подкачки предварительно " "выделяется массив, который представляет целый объект, требующий хранения в " "области подкачки-даже если только несколько страниц этого объекта хранятся в " "области подкачки. Это создает проблему фрагментации памяти ядра в случае, " "когда в память отображаются большие объекты или когда ветвятся процессы, " -"занимающие большой объем памяти при работе (RSS)." +"занимающие большой объём памяти при работе (RSS)." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:197 msgid "" "Also, to keep track of swap space, a \"list of holes\" is kept in kernel " "memory, and this tends to get severely fragmented as well. Since the \"list " "of holes\" is a linear list, the swap allocation and freeing performance is " "a non-optimal O(n)-per-page." msgstr "" "Также для отслеживания памяти подкачки в памяти ядра поддерживается \"список " "дыр\", и он также несколько фрагментирован. Так как \"список дыр\" является " "последовательным списком, то производительность при распределении и " -"высвобождении памяти в области подкачки неоптимально и ее сложность зависит " +"высвобождении памяти в области подкачки неоптимально и её сложность зависит " "от количества страниц как O(n)." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:198 msgid "" "It requires kernel memory allocations to take place during the swap freeing " "process, and that creates low memory deadlock problems." msgstr "" "Также в процессе высвобождения памяти в области подкачки требуется выделение " "памяти в ядре, и это приводит к проблемам блокировки при недостатке памяти." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:199 msgid "" "The problem is further exacerbated by holes created due to the interleaving " "algorithm." msgstr "" -"Проблема еще более обостряется из-за дыр, создаваемых по чередующемуся " +"Проблема ещё более обостряется из-за дыр, создаваемых по чередующемуся " "алгоритму." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:200 msgid "" "Also, the swap block map can become fragmented fairly easily resulting in " "non-contiguous allocations." msgstr "" "Кроме того, список распределения блоков в области подкачки легко оказывается " "фрагментированным, что приводит к распределению непоследовательных областей." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:201 msgid "" "Kernel memory must also be allocated on the fly for additional swap " "management structures when a swapout occurs." msgstr "" "Память ядра также должна распределяться по ходу работы для дополнительных " "структур по управлению областью подкачки при выгрузке страниц памяти в эту " "область." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:204 msgid "" "It is evident from that list that there was plenty of room for improvement. " "For FreeBSD 4.X, I completely rewrote the swap subsystem:" msgstr "" "Очевидно, что мест для усовершенствований предостаточно. Во FreeBSD 4.X " "подсистема управления областью подкачки была полностью переписана мною:" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:206 msgid "" "Swap management structures are allocated through a hash table rather than a " "linear array giving them a fixed allocation size and much finer granularity." msgstr "" "Структуры управления областью подкачки распределяются при помощи хэш-" -"таблицы, а не через линейный массив, что дает им фиксированный размер при " +"таблицы, а не через линейный массив, что даёт им фиксированный размер при " "распределении и работу с гораздо меньшими структурами." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:207 msgid "" "Rather then using a linearly linked list to keep track of swap space " "reservations, it now uses a bitmap of swap blocks arranged in a radix tree " "structure with free-space hinting in the radix node structures. This " "effectively makes swap allocation and freeing an O(1) operation." msgstr "" "Вместо того, чтобы использовать однонаправленный связный список для " "отслеживания выделения пространства в области подкачки, теперь используется " "побитовая карта блоков области подкачки, выполненная в основном в виде " "древовидной структуры с информацией о свободном пространстве, находящейся в " "узлах структур. Это приводит к тому, что выделение и высвобождение памяти в " "области подкачки становится операцией сложности O(1)." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:208 msgid "" "The entire radix tree bitmap is also preallocated to avoid having to " "allocate kernel memory during critical low memory swapping operations. After " "all, the system tends to swap when it is low on memory so we should avoid " "allocating kernel memory at such times to avoid potential deadlocks." msgstr "" "Все дерево также распределяется заранее для того, чтобы избежать " "распределения памяти ядра во время операций с областью подкачки при " -"критически малом объеме свободной памяти. В конце концов, система обращается " +"критически малом объёме свободной памяти. В конце концов, система обращается " "к области подкачки при нехватке памяти, так что мы должны избежать " "распределения памяти ядра в такие моменты для избежания потенциальных " "блокировок." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:209 msgid "" "To reduce fragmentation the radix tree is capable of allocating large " "contiguous chunks at once, skipping over smaller fragmented chunks." msgstr "" "Для уменьшения фрагментации дерево может распределять большой " "последовательный кусок за раз, пропуская меньшие фрагментированные области." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:211 msgid "" "I did not take the final step of having an \"allocating hint pointer\" that " "would trundle through a portion of swap as allocations were made to further " "guarantee contiguous allocations or at least locality of reference, but I " "ensured that such an addition could be made." msgstr "" "Я не сделал последний шаг к заведению \"указателя на распределение\", " "который будет передвигаться по участку области подкачки при выделении памяти " "для обеспечения в будущем распределения последовательных участков, или по " "крайней мере местоположения ссылки, но я убежден, что это может быть сделано." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:213 #, no-wrap msgid "When to free a page" msgstr "Когда освобождать страницу" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:218 msgid "" "Since the VM system uses all available memory for disk caching, there are " "usually very few truly-free pages. The VM system depends on being able to " "properly choose pages which are not in use to reuse for new allocations. " "Selecting the optimal pages to free is possibly the single-most important " "function any VM system can perform because if it makes a poor selection, the " "VM system may be forced to unnecessarily retrieve pages from disk, seriously " "degrading system performance." msgstr "" "Так как система VM использует всю доступную память для кэширования диска, то " "обычно действительно незанятых страниц очень мало. Система VM зависит от " "того, как она точно выбирает незанятые страницы для повторного использования " "для новых распределений. Оптимальный выбор страниц для высвобождения, " "возможно, является самой важной функцией любой VM-системы, из тех, что она " "может выполнять, потому что при неправильном выборе система VM вынуждена " "будет запрашивать страницы с диска, значительно снижая производительность " "всей системы." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:221 msgid "" "How much overhead are we willing to suffer in the critical path to avoid " "freeing the wrong page? Each wrong choice we make will cost us hundreds of " "thousands of CPU cycles and a noticeable stall of the affected processes, so " "we are willing to endure a significant amount of overhead to be sure that " "the right page is chosen. This is why FreeBSD tends to outperform other " "systems when memory resources become stressed." msgstr "" "Какую дополнительную нагрузку мы может выделить в критическом пути для " "избежания высвобождения не той страницы? Каждый неправильный выбор будет " "стоить нам сотни тысяч тактов работы центрального процессора и заметное " "замедление работы затронутых процессов, так что мы должны смириться со " "значительными издержками для того, чтобы была заведомо выбрана правильная " "страница. Вот почему FreeBSD превосходит другие системы в производительности " "при нехватке ресурсов памяти." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:224 msgid "" "The free page determination algorithm is built upon a history of the use of " "memory pages. To acquire this history, the system takes advantage of a page-" "used bit feature that most hardware page tables have." msgstr "" "Алгоритм определения свободной страницы написан на основе истории " "использования страниц памяти. Для получения этой истории система использует " "возможности бита использования памяти, которые имеются в большинстве " "аппаратных таблицах страниц памяти." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:230 msgid "" "In any case, the page-used bit is cleared and at some later point the VM " "system comes across the page again and sees that the page-used bit has been " "set. This indicates that the page is still being actively used. If the bit " "is still clear it is an indication that the page is not being actively " "used. By testing this bit periodically, a use history (in the form of a " "counter) for the physical page is developed. When the VM system later needs " "to free up some pages, checking this history becomes the cornerstone of " "determining the best candidate page to reuse." msgstr "" "В любом случае, бит использования страницы очищается, и в некоторый более " "поздний момент VM-система обращается к странице снова и обнаруживает, что " "этот бит установлен. Это указывает на то, что страница активно используется. " "Периодически проверяя этот бит, накапливается история использования (в виде " "счетчика) физической страницы. Когда позже VM-системе требуется высвободить " "некоторые страницы, проверка истории выступает указателем при определении " "наиболее вероятной кандидатуры для повторного использования." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:235 msgid "" "For those platforms that do not have this feature, the system actually " "emulates a page-used bit. It unmaps or protects a page, forcing a page " "fault if the page is accessed again. When the page fault is taken, the " "system simply marks the page as having been used and unprotects the page so " "that it may be used. While taking such page faults just to determine if a " "page is being used appears to be an expensive proposition, it is much less " "expensive than reusing the page for some other purpose only to find that a " "process needs it back and then have to go to disk." msgstr "" "Для тех платформ, что не имеют этой возможности, система эмулирует этот бит. " "Она снимает отображение или защищает страницу, что приводит к ошибке доступа " "к странице, если к странице выполняется повторное обращение. При " "возникновении этой ошибки система просто помечает страницу как используемую " "и снимает защиту со страницы, так что она может использоваться. Хотя " "использование такого приема только для определения использования страницы " "весьма накладно, это выгоднее, чем повторно использовать страницу для других " -"целей и обнаружить, что она снова нужна процессу и подгружать ее с диска." +"целей и обнаружить, что она снова нужна процессу и подгружать её с диска." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:245 msgid "" "FreeBSD makes use of several page queues to further refine the selection of " "pages to reuse as well as to determine when dirty pages must be flushed to " "their backing store. Since page tables are dynamic entities under FreeBSD, " "it costs virtually nothing to unmap a page from the address space of any " "processes using it. When a page candidate has been chosen based on the page-" "use counter, this is precisely what is done. The system must make a " "distinction between clean pages which can theoretically be freed up at any " "time, and dirty pages which must first be written to their backing store " "before being reusable. When a page candidate has been found it is moved to " "the inactive queue if it is dirty, or the cache queue if it is clean. A " "separate algorithm based on the dirty-to-clean page ratio determines when " "dirty pages in the inactive queue must be flushed to disk. Once this is " "accomplished, the flushed pages are moved from the inactive queue to the " "cache queue. At this point, pages in the cache queue can still be " "reactivated by a VM fault at relatively low cost. However, pages in the " "cache queue are considered to be \"immediately freeable\" and will be reused " "in an LRU (least-recently used) fashion when the system needs to allocate " "new memory." msgstr "" "FreeBSD использует несколько очередей страниц для обновления выбора страниц " "для повторного использования, а также для определения того, когда же грязные " "страницы должны быть сброшены в хранилище. Так как таблицы страниц во " "FreeBSD являются динамическими объектами, практически ничего не стоит " -"вырезать страницу из адресного пространства любого использующего ее " +"вырезать страницу из адресного пространства любого использующего её " "процесса. После того, как подходящая страница, на основе счетчика " "использования, выбрана, именно это и выполняется. Система должна отличать " "между чистыми страницами, которые теоретически могут быть высвобождены в " "любое время, и грязными страницами, которые сначала должны быть переписаны в " "хранилище перед тем, как их можно будет использовать повторно. После " "нахождения подходящей страницы она перемещается в неактивную очередь, если " "она является грязной, или в очередь кэша, если она чистая. Отдельный " "алгоритм, основывающийся на отношении количества грязных страниц к чистым, " "определяет, когда грязные страницы в неактивной очереди должны быть сброшены " "на диск. Когда это выполнится, сброшенные страницы перемещаются из " "неактивной очереди в очередь кэша. В этот момент страницы в очереди кэша " "могут быть повторно активизированы VM со сравнительно малыми накладными " "расходами. Однако страницы в очереди кэша предполагается \"высвобождать " "немедленно\" и повторно использовать в LRU-порядке (меньше всего " "используемый), когда системе потребуется выделение дополнительной памяти." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:249 msgid "" "It is important to note that the FreeBSD VM system attempts to separate " "clean and dirty pages for the express reason of avoiding unnecessary flushes " "of dirty pages (which eats I/O bandwidth), nor does it move pages between " "the various page queues gratuitously when the memory subsystem is not being " "stressed. This is why you will see some systems with very low cache queue " "counts and high active queue counts when doing a `systat -vm` command. As " "the VM system becomes more stressed, it makes a greater effort to maintain " "the various page queues at the levels determined to be the most effective." msgstr "" "Стоит отметить, что во FreeBSD VM-система пытается разделить чистые и " "грязные страницы во избежание срочной необходимости в ненужных сбросах " "грязных страниц (что отражается на пропускной способности ввода/вывода) и не " "перемещает беспричинно страницы между разными очередями, когда подсистема " "управления памятью не испытывает нехватку ресурсов. Вот почему вы можете " "видеть, что при выполнении команды `systat -vm` в некоторых системах " "значение счетчика очереди кэша мало, а счетчик активной очереди большой. При " "повышении нагрузки на VM-систему она прилагает большие усилия на поддержку " "различных очередей страниц в соотношениях, которые являются наиболее " "эффективными." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:253 msgid "" "An urban myth has circulated for years that Linux did a better job avoiding " "swapouts than FreeBSD, but this in fact is not true. What was actually " "occurring was that FreeBSD was proactively paging out unused pages to make " "room for more disk cache while Linux was keeping unused pages in core and " "leaving less memory available for cache and process pages. I do not know " "whether this is still true today." msgstr "" "Годами ходили современные легенды, что Linux выполняет работу по " "предотвращению выгрузки на диск лучше, чем FreeBSD, но это не так. На самом " "деле FreeBSD старается сбросить на диск неиспользуемые страницы для " "освобождения места под дисковый кэш, когда как Linux хранит неиспользуемые " "страницы в памяти и оставляет под кэш и страницы процессов меньше памяти. Я " -"не знаю, остается ли это правдой на сегодняшний день." +"не знаю, остаётся ли это правдой на сегодняшний день." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:255 #, no-wrap msgid "Pre-Faulting and Zeroing Optimizations" msgstr "Оптимизация ошибок доступа к страницам и их обнуления" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:265 msgid "" "Taking a VM fault is not expensive if the underlying page is already in core " "and can simply be mapped into the process, but it can become expensive if " "you take a whole lot of them on a regular basis. A good example of this is " "running a program such as man:ls[1] or man:ps[1] over and over again. If " "the program binary is mapped into memory but not mapped into the page table, " "then all the pages that will be accessed by the program will have to be " "faulted in every time the program is run. This is unnecessary when the " "pages in question are already in the VM Cache, so FreeBSD will attempt to " "pre-populate a process's page tables with those pages that are already in " "the VM Cache. One thing that FreeBSD does not yet do is pre-copy-on-write " "certain pages on exec. For example, if you run the man:ls[1] program while " "running `vmstat 1` you will notice that it always takes a certain number of " "page faults, even when you run it over and over again. These are zero-fill " "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. Например, если вы " +"определённых страниц при выполнении вызова exec. Например, если вы " "запускаете программу man:ls[1] одновременно с работающей `vmstat 1`, то " "заметите, что она всегда выдает некоторое количество ошибок доступа к " -"страницам, даже когда вы запускаете ее снова и снова. Это ошибки заполнения " +"страницам, даже когда вы запускаете её снова и снова. Это ошибки заполнения " "нулями, а не ошибки кода программы (которые уже были обработаны). " "Предварительное копирование страниц при выполнении вызовов exec или fork " "находятся в области, требующей более тщательного изучения." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:274 msgid "" "A large percentage of page faults that occur are zero-fill faults. You can " "usually see this by observing the `vmstat -s` output. These occur when a " "process accesses pages in its BSS area. The BSS area is expected to be " "initially zero but the VM system does not bother to allocate any memory at " "all until the process actually accesses it. When a fault occurs the VM " "system must not only allocate a new page, it must zero it as well. To " "optimize the zeroing operation the VM system has the ability to pre-zero " "pages and mark them as such, and to request pre-zeroed pages when zero-fill " "faults occur. The pre-zeroing occurs whenever the CPU is idle but the " "number of pages the system pre-zeros is limited to avoid blowing away the " "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 имеется возможность предварительно " "обнулять страницы и помечать их, и запрашивать уже обнуленные страницы при " "возникновении ошибок заполнения нулями. Предварительное заполнение нулями " "происходит, когда CPU простаивает, однако количество страниц, которые " "система заранее заполняет нулями, ограничено, для того, чтобы не переполнить " "кэши памяти. Это прекрасный пример добавления сложности в VM-систему ради " "оптимизации критического пути." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:276 #, no-wrap msgid "Page Table Optimizations" msgstr "Оптимизация таблицы страниц" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:286 msgid "" "The page table optimizations make up the most contentious part of the " "FreeBSD VM design and they have shown some strain with the advent of serious " "use of `mmap()`. I think this is actually a feature of most BSDs though I " "am not sure when it was first introduced. There are two major " "optimizations. The first is that hardware page tables do not contain " "persistent state but instead can be thrown away at any time with only a " "minor amount of management overhead. The second is that every active page " "table entry in the system has a governing `pv_entry` structure which is tied " "into the `vm_page` structure. FreeBSD can simply iterate through those " "mappings that are known to exist while Linux must check all page tables that " "_might_ contain a specific mapping to see if it does, which can achieve " "O(n^2) overhead in certain situations. It is because of this that FreeBSD " "tends to make better choices on which pages to reuse or swap when memory is " "stressed, giving it better performance under load. However, FreeBSD " "requires kernel tuning to accommodate large-shared-address-space situations " "such as those that can occur in a news system because it may run out of " "`pv_entry` structures." msgstr "" "Оптимизация таблицы страниц составляет самую содержательную часть " "архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при " "значительном использовании `mmap()`. Я думаю, что это на самом деле " "особенность работы большинства BSD-систем, хотя я не уверен, когда это " "проявилось впервые. Есть два основных подхода к оптимизации. Первый " "заключается в том, что аппаратные таблицы страниц не содержат постоянного " "состояния, а вместо этого могут быть сброшены в любой момент с малыми " "накладными расходами. Второй подход состоит в том, что каждая активная " "таблица страниц в системе имеет управляющую структуру `pv_entry`, которая " "связана в структуру `vm_page`. FreeBSD может просто просматривать эти " "отображения, которые существуют, когда как в Linux должны проверяться все " "таблицы страниц, которые _могут_ содержать нужное отображение, что в " -"некоторых ситуация дает увеличение сложности O(n^2). Из-за того, что FreeBSD " +"некоторых ситуация даёт увеличение сложности O(n^2). Из-за того, что FreeBSD " "стремится выбрать наиболее подходящую к повторному использованию или сбросу " -"в область подкачки страницу, когда ощущается нехватка памяти, система дает " +"в область подкачки страницу, когда ощущается нехватка памяти, система даёт " "лучшую производительность при нагрузке. Однако во FreeBSD требуется тонкая " "настройка ядра для соответствия ситуациям с большим совместно используемым " "адресным пространством, которые могут случиться в системе, обслуживающей " "сервер телеконференций, потому что структуры `pv_entry` могут оказаться " "исчерпанными." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:291 msgid "" "Both Linux and FreeBSD need work in this area. FreeBSD is trying to " "maximize the advantage of a potentially sparse active-mapping model (not all " "processes need to map all pages of a shared library, for example), whereas " "Linux is trying to simplify its algorithms. FreeBSD generally has the " "performance advantage here at the cost of wasting a little extra memory, but " "FreeBSD breaks down in the case where a large file is massively shared " "across hundreds of processes. Linux, on the other hand, breaks down in the " "case where many processes are sparsely-mapping the same shared library and " "also runs non-optimally when trying to determine whether a page can be " "reused or not." msgstr "" "И в Linux, и во FreeBSD требуются доработки в этой области. FreeBSD пытается " "максимизировать преимущества от потенциально редко применяемой модели " "активного отображения (к примеру, не всем процессам нужно отображать все " "страницы динамической библиотеки), когда как Linux пытается упростить свои " "алгоритмы. FreeBSD имеет здесь общее преимущество в производительности за " "счет использования дополнительной памяти, но FreeBSD выглядит хуже в случае, " "когда большой файл совместно используется сотнями процессов. Linux, с другой " "стороны, выглядит хуже в случае, когда много процессов частично используют " "одну и ту же динамическую библиотеку, а также работает неоптимально при " "попытке определить, может ли страница повторно использоваться, или нет." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:293 #, no-wrap msgid "Conclusion" msgstr "Заключение" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:298 msgid "" "Virtual memory in modern operating systems must address a number of " "different issues efficiently and for many different usage patterns. The " "modular and algorithmic approach that BSD has historically taken allows us " "to study and understand the current implementation as well as relatively " "cleanly replace large sections of the code. There have been a number of " "improvements to the FreeBSD VM system in the last several years, and work is " "ongoing." msgstr "" "Виртуальная память в современных операционных системах должна решать " "несколько различных задач эффективно и при разных условиях. Модульный и " "алгоритмический подход, которому исторически следует BSD, позволяет нам " "изучить и понять существующую реализацию, а также сравнительно легко " "изменить большие блоки кода. За несколько последних лет в VM-системе FreeBSD " "было сделано некоторое количество усовершенствований, и работа над ними " "продолжается." #. type: Title == #: documentation/content/en/articles/vm-design/_index.adoc:300 #, no-wrap msgid "Bonus QA session by Allen Briggs" msgstr "" "Дополнительный сеанс вопросов и ответов от Аллена Бриггса (Allen Briggs)" #. type: Title === #: documentation/content/en/articles/vm-design/_index.adoc:302 #, no-wrap msgid "What is the interleaving algorithm that you refer to in your listing of the ills of the FreeBSD 3.X swap arrangements?" msgstr "" "Что это за алгоритм чередования, который вы упоминали в списке недостатков " "подсистемы управления разделом подкачки во FreeBSD 3.X?" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:308 msgid "" "FreeBSD uses a fixed swap interleave which defaults to 4. This means that " "FreeBSD reserves space for four swap areas even if you only have one, two, " "or three. Since swap is interleaved the linear address space representing " "the \"four swap areas\" will be fragmented if you do not actually have four " "swap areas. For example, if you have two swap areas A and B FreeBSD's " "address space representation for that swap area will be interleaved in " "blocks of 16 pages:" msgstr "" "FreeBSD использует в области подкачки механизм чередования, с индексом по " "умолчанию, равным четырем. Это означает, что FreeBSD резервирует " -"пространство для четырех областей подкачки, даже если у вас имеется всего " +"пространство для четырёх областей подкачки, даже если у вас имеется всего " "лишь одна, две или три области. Так как в области подкачки имеется " "чередование, то линейное адресное пространство, представляющее \"четыре " "области подкачки\", будет фрагментироваться, если у вас нет на самом деле " -"четырех областей подкачки. Например, если у вас две области A и B, то " +"четырёх областей подкачки. Например, если у вас две области A и B, то " "представление адресного пространства для этой области подкачки во FreeBSD " "будет организовано с чередованием блоков из 16 страниц:" #. type: delimited block . 4 #: documentation/content/en/articles/vm-design/_index.adoc:311 #, no-wrap msgid "A B C D A B C D A B C D A B C D\n" msgstr "A B C D A B C D A B C D A B C D\n" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:318 msgid "" "FreeBSD 3.X uses a \"sequential list of free regions\" approach to " "accounting for the free swap areas. The idea is that large blocks of free " "linear space can be represented with a single list node ([.filename]#kern/" "subr_rlist.c#). But due to the fragmentation the sequential list winds up " "being insanely fragmented. In the above example, completely unused swap " "will have A and B shown as \"free\" and C and D shown as \"all allocated\". " "Each A-B sequence requires a list node to account for because C and D are " "holes, so the list node cannot be combined with the next A-B sequence." msgstr "" "FreeBSD 3.X использует \"последовательный список свободных областей\" для " "управления свободными областями в разделе подкачки. Идея состоит в том, что " "большие последовательные блоки свободного пространства могут быть " "представлены при помощи узла односвязного списка ([.filename]#kern/subr_rlist" ".c#). Но из-за фрагментации последовательный список сам становится " "фрагментированным. В примере выше полностью неиспользуемое пространство в A " "и B будет показано как \"свободное\", а C и D как \"полностью занятое\". " -"Каждой последовательности A-B требуется для учета узел списка, потому что C " +"Каждой последовательности A-B требуется для учёта узел списка, потому что C " "и D являются дырами, так что узел списка не может быть связан со следующей " "последовательностью A-B." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:320 msgid "" "Why do we interleave our swap space instead of just tack swap areas onto the " "end and do something fancier? It is a whole lot easier to allocate linear " "swaths of an address space and have the result automatically be interleaved " "across multiple disks than it is to try to put that sophistication elsewhere." msgstr "" "Почему мы организуем чередование в области подкачки вместо того, чтобы " "просто объединить области подкачки в одно целое и придумать что-то более " "умное? Потому что гораздо легче выделять последовательные полосы адресного " "пространства и получать в результате автоматическое чередование между " "несколькими дисками, чем пытаться выдумывать сложности в другом месте." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:325 msgid "" "The fragmentation causes other problems. Being a linear list under 3.X, and " "having such a huge amount of inherent fragmentation, allocating and freeing " "swap winds up being an O(N) algorithm instead of an O(1) algorithm. " "Combined with other factors (heavy swapping) and you start getting into " "O(N^2) and O(N^3) levels of overhead, which is bad. The 3.X system may also " "need to allocate KVM during a swap operation to create a new list node which " "can lead to a deadlock if the system is trying to pageout pages in a low-" "memory situation." msgstr "" "Фрагментация вызывает другие проблемы. Являясь последовательным списком в " "3.X и имея такое огромную фрагментацию, выделение и освобождение в области " "подкачки становится алгоритмом сложности O(N), а не O(1). Вместе с другими " "факторами (частое обращение к области подкачки) вы получаете сложность " "уровней O(N^2) и O(N^3), что плохо. В системе 3.X также может потребоваться " "выделение KVM во время работы с областью подкачки для создания нового узла " "списка, что в условии нехватки памяти может привести к блокировке, если " "система попытается сбросить страницы в область подкачки." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:330 msgid "" "Under 4.X we do not use a sequential list. Instead we use a radix tree and " "bitmaps of swap blocks rather than ranged list nodes. We take the hit of " "preallocating all the bitmaps required for the entire swap area up front but " "it winds up wasting less memory due to the use of a bitmap (one bit per " "block) instead of a linked list of nodes. The use of a radix tree instead " "of a sequential list gives us nearly O(1) performance no matter how " "fragmented the tree becomes." msgstr "" "В 4.X мы не используем последовательный список. Вместо этого мы используем " "базисное дерево и битовые карты блоков области подкачки, а не ограниченный " "список узлов. Мы принимаем предварительное выделение всех битовых карт, " "требуемых для всей области подкачки, но при этом тратится меньше памяти, " "потому что мы используем битовые карты (один бит на блок), а не связанный " "список узлов. Использование базисного дерева вместо последовательного списка " -"дает нам производительность O(1) вне зависимости от фрагментации дерева." +"даёт нам производительность O(1) вне зависимости от фрагментации дерева." #. type: Title === #: documentation/content/en/articles/vm-design/_index.adoc:331 #, no-wrap msgid "How is the separation of clean and dirty (inactive) pages related to the situation where you see low cache queue counts and high active queue counts in systat -vm? Do the systat stats roll the active and dirty pages together for the active queue count?" msgstr "" "Как разделение чистых и грязных (неактивных) страниц связано с ситуацией, " "когда вы видите маленький счетчик очереди кэша и большой счетчик активной " "очереди в выдаче команды systat -vm? Разве системная статистика не считает " "активные и грязные страницы вместе за счетчик активной очереди?" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:336 msgid "" "Yes, that is confusing. The relationship is \"goal\" verses \"reality\". " "Our goal is to separate the pages but the reality is that if we are not in a " "memory crunch, we do not really have to." msgstr "" "Да, это запутывает. Связь заключается в \"желаемом\" и \"действительном\". " "Мы желаем разделить страницы, но реальность такова, что пока у нас нет " "проблем с памятью, нам это на самом деле не нужно." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:338 msgid "" "What this means is that FreeBSD will not try very hard to separate out dirty " "pages (inactive queue) from clean pages (cache queue) when the system is not " "being stressed, nor will it try to deactivate pages (active queue -> " "inactive queue) when the system is not being stressed, even if they are not " "being used." msgstr "" "Это означает, что FreeBSD не будет очень сильно стараться над отделением " "грязных страниц (неактивная очередь) от чистых страниц (очередь кэша), когда " "система не находится под нагрузкой, и не будет деактивировать страницы (" "активная очередь -> неактивная очередь), когда система не нагружена, даже " "если они не используются." #. type: Title === #: documentation/content/en/articles/vm-design/_index.adoc:339 #, 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 "" "В примере с / vmstat 1 могут ли некоторые ошибки доступа к странице быть " "ошибками страниц данных (COW из выполнимого файла в приватные страницы)? То " "есть я полагаю, что ошибки доступа к страницам являются частично ошибками " "при заполнении нулями, а частично данных программы. Или вы гарантируете, что " "FreeBSD выполняет предварительно COW для данных программы?" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:345 msgid "" "A COW fault can be either zero-fill or program-data. The mechanism is the " "same either way because the backing program-data is almost certainly already " "in the cache. I am indeed lumping the two together. FreeBSD does not pre-" "COW program data or zero-fill, but it _does_ pre-map pages that exist in its " "cache." msgstr "" "Ошибка COW может быть ошибкой при заполнении нулями или данных программы. " "Механизм в любом случае один и тот же, потому что хранилище данных программы " "уже в кэше. Я на самом деле не рад ни тому, ни другому. FreeBSD не выполняет " "предварительное COW данных программы и заполнение нулями, но она _выполняет_ " -"предварительно отображение страниц, которые имеются в ее кэше." +"предварительно отображение страниц, которые имеются в её кэше." #. type: Title === #: documentation/content/en/articles/vm-design/_index.adoc:346 #, no-wrap msgid "In your section on page table optimizations, can you give a little more detail about pv_entry and vm_page (or should vm_page be vm_pmap-as in 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? Specifically, what kind of operation/reaction would require scanning the mappings?" msgstr "" "В вашем разделе об оптимизации таблицы страниц, не могли бы вы более " "подробно рассказать о pv_entry и vm_page (или vm_page должна быть vm_pmap-" "как в 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? А именно " "какое действие/реакцию должно потребоваться для сканирования отображений?" #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:350 msgid "" "A `vm_page` represents an (object,index#) tuple. A `pv_entry` represents a " "hardware page table entry (pte). If you have five processes sharing the " "same physical page, and three of those processes's page tables actually map " "the page, that page will be represented by a single `vm_page` structure and " "three `pv_entry` structures." msgstr "" "`vm_page` представляет собой пару (object,index#). `pv_entry` является " "записью из аппаратной таблицы страниц (pte). Если у вас имеется пять " -"процессов, совместно использующих одну и ту же физическую страницу, и в трех " +"процессов, совместно использующих одну и ту же физическую страницу, и в трёх " "таблицах страниц этих процессов на самом деле отображается страница, то " "страница будет представляться одной структурой `vm_page` и тремя структурами " "`pv_entry`." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:353 msgid "" "`pv_entry` structures only represent pages mapped by the MMU (one `pv_entry` " "represents one pte). This means that when we need to remove all hardware " "references to a `vm_page` (to reuse the page for something else, page it " "out, clear it, dirty it, and so forth) we can simply scan the linked list of " "pv_entry's associated with that vm_page to remove or modify the pte's from " "their page tables." msgstr "" "Структуры `pv_entry` представляют страницы, отображаемые MMU (одна структура " "`pv_entry` соответствует одной pte). Это означает, что, когда нам нужно " "убрать все аппаратные ссылки на `vm_page` (для того, чтобы повторно " -"использовать страницу для чего-то еще, выгрузить ее, очистить, пометить как " +"использовать страницу для чего-то ещё, выгрузить её, очистить, пометить как " "грязную и так далее), мы можем просто просмотреть связный список структур " "`pv_entry`, связанных с этой `vm_page`, для того, чтобы удалить или изменить " "pte из их таблиц страниц." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:360 msgid "" "Under Linux there is no such linked list. To remove all the hardware page " "table mappings for a `vm_page` linux must index into every VM object that " "_might_ have mapped the page. For example, if you have 50 processes all " "mapping the same shared library and want to get rid of page X in that " "library, you need to index into the page table for each of those 50 " "processes even if only 10 of them have actually mapped the page. So Linux " "is trading off the simplicity of its design against performance. Many VM " "algorithms which are O(1) or (small N) under FreeBSD wind up being O(N), " "O(N^2), or worse under Linux. Since the pte's representing a particular " "page in an object tend to be at the same offset in all the page tables they " "are mapped in, reducing the number of accesses into the page tables at the " "same pte offset will often avoid blowing away the L1 cache line for that " "offset, which can lead to better performance." msgstr "" "В Linux нет такого связного списка. Для того, чтобы удалить все отображения " "аппаратной таблицы страниц для `vm_page`, linux должен пройти по индексу " "каждого объекта VM, который _может_ отображать страницу. К примеру, если у " "вас имеется 50 процессов, которые все отображают ту же самую динамическую " "библиотеку и хотите избавиться от страницы X в этой библиотеке, то вам нужно " "пройтись по индексу всей таблицы страниц для каждого из этих 50 процессов, " "даже если только 10 из них на самом деле отображают страницу. Так что Linux " "использует простоту подхода за счет производительности. Многие алгоритмы VM, " "которые имеют сложность O(1) или (N малое) во FreeBSD, в Linux приобретают " "сложность O(N), O(N^2) или хуже. Так как pte, представляющий конкретную " "страницу в объекте, скорее всего, будет с тем же смещением во всех таблицах " "страниц, в которых они отображаются, то уменьшение количества обращений в " "таблицы страниц по тому же самому смещению часто позволяет избежать " "разрастания кэша L1 для этого смещения, что приводит к улучшению " "производительности." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:362 msgid "" "FreeBSD has added complexity (the `pv_entry` scheme) to increase performance " "(to limit page table accesses to _only_ those pte's that need to be " "modified)." msgstr "" "Во FreeBSD введены дополнительные сложности (схема с `pv_entry`) для " "увеличения производительности (уменьшая количество обращений _только_ к тем " "pte, которые нужно модифицировать)." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:366 msgid "" "But FreeBSD has a scaling problem that Linux does not in that there are a " "limited number of `pv_entry` structures and this causes problems when you " "have massive sharing of data. In this case you may run out of `pv_entry` " "structures even though there is plenty of free memory available. This can " "be fixed easily enough by bumping up the number of `pv_entry` structures in " "the kernel config, but we really need to find a better way to do it." msgstr "" "Но во FreeBSD имеется проблема масштабирования, которой нет в Linux, потому " "что имеется ограниченное число структур `pv_entry`, и это приводит к " -"возникновению проблем при большом объеме совместно используемых данных. В " +"возникновению проблем при большом объёме совместно используемых данных. В " "этом случае у вас может возникнуть нехватка структур `pv_entry`, даже если " "свободной памяти хватает. Это может быть достаточно легко исправлено " "увеличением количества структур `pv_entry` при настройке, но на самом деле " "нам нужно найти лучший способ делать это." #. type: Plain text #: documentation/content/en/articles/vm-design/_index.adoc:369 msgid "" "In regards to the memory overhead of a page table verses the `pv_entry` " "scheme: Linux uses \"permanent\" page tables that are not throw away, but " "does not need a `pv_entry` for each potentially mapped pte. FreeBSD uses " "\"throw away\" page tables but adds in a `pv_entry` structure for each " "actually-mapped pte. I think memory utilization winds up being about the " "same, giving FreeBSD an algorithmic advantage with its ability to throw away " "page tables at will with very low overhead." msgstr "" "Что касается использования памяти под таблицу страниц против схемы с " "`pv_entry`: Linux использует \"постоянные\" таблицы страниц, которые не " "сбрасываются, но ему не нужны `pv_entry` для каждого потенциально " "отображаемого pte. FreeBSD использует \"сбрасываемые\" таблицы страниц, но " "для каждого реально отображаемого pte добавляется структура `pv_entry`. Я " "думаю, что использование памяти будет примерно одинакова, тем более что у " "FreeBSD есть алгоритмическое преимущество, заключающееся в способности " "сбрасывать таблицы страниц с очень малыми накладными расходами."