Я читал, что вам нужно разместить раздел подкачки на жестком диске, а не на SSD.

Мои вопросы следующие:

• Когда и как «проверка» выполняется дистрибутивом (или чем-то еще), чтобы найти его раздел Swap?
• Это происходит во время загрузки?
• Он просто проверяет все доступные диски и ищет раздел с флагом 'swap'?
• Что произойдет, если будет несколько таких разделов?
• Кроме того, сколько разделов подкачки мне нужно иметь, если я запускаю, например, два разных дистрибутива на одном диске, скажем, Fedora и Ubuntu?

Статически настроенное пространство подкачки (тип, который используется почти во всех дистрибутивах) настраивается так /etc/fstabже, как и файловые системы.

Типичная запись выглядит примерно так:

UUID=21618415-7989-46aa-8e49-881efa488132    none    swap     sw      0  0

Вы также можете увидеть либо discardили nofailуказано в поле флагов (четвертое поле). Каждая такая строка соответствует одной области подкачки (это не обязательно должен быть раздел, вы можете иметь файлы подкачки или даже целые диски подкачки).

В некоторых действительно специфических случаях вы могли бы вместо этого динамически настраивать пространство подкачки, хотя это довольно редко, потому что это может вызвать проблемное поведение, связанное с управлением памятью. В этом случае конфигурация полностью обрабатывается компонентом пользовательского пространства, который создает и включает файлы подкачки по мере необходимости во время выполнения.

Насколько вам нужно, это сложный вопрос, но количество различных дистрибутивов Linux, которые вы планируете запустить, не окажет на это никакого влияния, если только вы не захотите запустить один дистрибутив, пока у вас есть другой в спящем режиме (и вы вероятно, не хочу этого делать, так как это действительно простой способ испортить вашу систему).

Когда вы запустите установщик практически для любого крупного дистрибутива (включая Fedora, OpenSUSE, Linux Mint, Debian и Ubuntu), он обнаружит любые существующие разделы подкачки в системе и добавит их в конфигурацию для дистрибутива, который вы используете. установка (за исключением, возможно, если вы выберете разделение вручную), и в большинстве случаев это приведет к разумной настройке системы.

Несмотря на это, я бы лично предложил избегать использования нескольких разделов подкачки, если вы не говорите о серверной системе с большим количеством дисков, и даже тогда вам действительно нужно знать, что вы делаете, чтобы настроить его так, чтобы он работал хорошо. ,

скажем Fedora и Ubuntu?

… Обе из которых в настоящее время являются системными операционными системами.

Что происходит в системных операционных системах

родной механизм

Systemd использует различные виды устройств. .mountмодульные файлы дают команду монтировать тома. .swapмодульные файлы инструктируют его сообщать ядру о разделах подкачки. ( .serviceЕдиничные файлы инструктируют его, как запускать сервисы. И так далее.) Это родные механизмы systemd. Чтобы принять их, сама systemd разветвляет дочерние процессы, которые выполняют соответствующие системные вызовы.

Если вы используете systemctlкоманду (с --all) в такой операционной системе systemd, она расскажет вам о загруженных .swapмодулях. Например:

dev-disk-by \ x2dpartuuid-40549710 \ x2d05.swap загружен активный активный / dev / disk / by-partuuid / 40549710-05
dev-disk-by \ x2duuid-1bb589e8 \ x2d929f \ x2d4041 \ x2d81f4 \ x2dff2b339b4e2a.swap загружен активный активный / dev / disk / by-uuid / 1bb589e8-929f-4041-81f4-ff2b33a44
dev-sda5.swap загружен активный активный / dev / sda5

Он также расскажет вам о .mountподразделениях.

Системный администратор может на самом деле писать такие .swapфайлы модулей вручную, точно так же, как может писать xe .service, .socketи другие файлы модулей вручную. Сама systemd просто ищет файлы модулей в файловой системе. Они его родной механизм.

Можно даже заставить systemd показать вам, что находится в этих единичных файлах и где в файловой системе их можно найти:

$ systemctl cat dev-disk-by \\ x2duuid-1bb589e8 \\ x2d929f \\ x2d4041 \\ x2d81f4 \\ x2dff2b339b4e2a.swap 
# /run/systemd/generator/dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap
# Автоматически генерируется systemd-fstab-generator

[Единица измерения]
SourcePath = / и т.д. / Fstab
Документация = man: fstab (5) man: systemd-fstab-generator (8)

[Обмен]
Что = / DEV / диск / по-UUID / 1bb589e8-929f-4041-81f4-ff2b339b4e2a
Параметры = SW
$ 

автоматически сгенерированные файлы юнитов

Можно написать их от руки. Обычно, однако, такие .mountи .swapфайлы модулей автоматически генерируются программами, известными как генераторы . Два таких генератора есть systemd-fstab-generatorи systemd-gpt-auto-generator. Они оба запускаются рано в процессе начальной загрузки и в ответ на systemctl daemon-reloadкоманду, и (как вы можете видеть выше) они генерируют целую загрузку файлов модулей в недокументированный подкаталог в /run/systemd/. Сам systemd просто использует эти сгенерированные файлы модулей .

Прежний генератор читает /etc/fstab, распознавая несколько расширений systemd для этого формата файла. Как я указал в ответ комментарии, традиционно раздел подкачки имеет тип монтирования из swи как один обнаружат , что другие операционные системы распознают подкачки записей в этой таблице. Но программное обеспечение Linux взяло альтернативный способ распознавания типа VFS вместо этого, ища swapкак тип VFS. systemd-fstab-generatorздесь не исключение, и именно так оно интерпретируется /etc/fstabпри преобразовании его в нативные механизмы.

Последний генератор обрабатывает таблицу разделов EFI, которая находится на том же диске, на котором находится системный раздел EFI, и ищет записи таблицы разделов EFI, которые имеют различные общеизвестные идентификаторы GUID типа раздела . Одним из таких идентификаторов GUID является обычный идентификатор GUID, назначаемый разделам подкачки Linux; и если systemd-gpt-auto-generatorнайдет раздел с этим GUID (который удовлетворяет критериям, указанным в systemd doco), он создаст .swapдля него блок; не /etc/fstabучаствует вообще .

Конечно, у этого процесса есть много побочных эффектов. Например, поскольку /etc/fstabпервичный ключ к таблице отсутствует, записи могут иметь повторяющиеся поля «spec» и «file» (то есть «что» и «где»). В нативном механизме systemd, тем не менее, поле «файл» (то есть «где») является уникальным ключом для .mountединиц, встроенным в имена единиц. Никакие две .mountединицы не могут делиться этим. Для .swapединиц измерения поле «spec» (т.е. «что») является уникальным ключом для единиц измерения. Никакие две .swapединицы не могут поделиться этим. Поэтому не все записи в нем /etc/fstabобязательно конвертируются в собственные механизмы и будут работать, особенно если люди делают такие вещи, как перечисление одной и той же точки монтирования для двух разных целей или один и тот же раздел подкачки двумя разными способами.

Точно так же, поскольку он переведен /etc/fstabна собственный механизм, а собственный механизм systemd имеет другие способы активации модулей , его поведение несколько отличается от поведения несистемных операционных систем. По .mountумолчанию устройство автоматически активируетсяsystemd-udevd даже после начальной загрузки в ответ на появление смонтированного запоминающего устройства. Или он может быть указан в качестве Wants=или Requires=некоторых .serviceили .socketединиц, это означает , что она будет (пером) активируется , когда они есть. Есть даже RequiresMountsFor=.

установщик программ и системный путь

Традиционно программы установки операционной системы и администратор systemd после перенастройки системы записывают swзаписи в /etc/fstab. И вот как натив .mountи .swapединицы в конечном итоге автоматически генерируются. Утилита установки / конфигурирования «знает», куда был помещен файл подкачки, потому что в своем пользовательском интерфейсе системный администратор сделал какой-то выбор и пишет /etc/fstabдля соответствия. Иногда этот выбор мне нужен, чтобы сделать раздел подкачки как часть установки. ; иногда это просто использовать раздел подкачки, который вы уже нашли на диске. (установщики тоже смотрят на типы разделов).

Но у системных людей есть представление об операционных системах, которые автоматически конфигурируют себя из практически пустого /etcдерева, так называемых систем без состояний , и именно в этом и заключаются такие механизмы, как генератор, который читает таблицу разделов EFI. В плане системных пользователей нет /etc/fstabи, действительно, нет постоянных данных конфигурации /etcвообще, и все эти вещи выводятся из содержимого таблицы разделов на диске , при каждой загрузке и при каждом systemctl daemon-reload. В настоящее время они продвигают программы установки операционной системы, чем не пишут/etc/fstab .

Конечно, в традиционной схеме у каждой операционной системы может быть свой собственный раздел подкачки, и они не могут касаться разделов подкачки друг друга. И действительно, если вы используете hibernate на диск через раздел подкачки и ожидаете возможности мультизагрузки с другой операционной системой во время гибернации ( что является очень плохой идеей, потому что так легко вызвать повреждение файловой системы ), это будет необходимо.

В схеме systemd, даже если операционная система еще не так, как это предполагают люди, работающие с systemd, и «не имеет состояния», вышеупомянутые генераторы работают; и, таким образом, все разделы подкачки (на ESP / корневом диске) с требуемым типом раздела автоматически используются всеми системными операционными системами. Поскольку они будут совместно использовать все автоматически обнаруживаемые разделы подкачки, на самом деле не нужно создавать один раздел подкачки для каждой установленной операционной системы.

дальнейшее чтение

• /unix//a/332797/5132
• /unix//a/233581/5132
• Lennart Poettering et al. (2016). Спецификация обнаруживаемых разделов . freedesktop.org.
• Lennart Poettering et al. (2017). systemd.swap, Системные справочные страницы . freedesktop.org.
• Lennart Poettering et al. (2017). systemd-fstab-generator, Системные справочные страницы . freedesktop.org.
• Lennart Poettering et al. (2017). systemd-gpt-auto-generator, Системные справочные страницы . freedesktop.org.
• Леннарт Поэттеринг (2014-06-17). Восстановление заводских настроек, системы без состояния, воспроизводимые системы и проверяемые системы . 0pointer.net.
• Леннарт Поэттеринг (2014-09-01). Пересматривая, как мы собираем системы Linux . 0pointer.net.
• Леннарт Поэттеринг (2017-06-28). mkosi - инструмент для генерации образов ОС . 0pointer.net.

Исторически раздел подкачки указывается /etc/fstabс записью типа swap. При загрузке процессы запуска считывают этот файл и помещают эту конфигурацию в ядро.

Пример записи в /etc/fstab:

/dev/sdb    none    swap     sw      0  0

Я не знаком с тем, как systemdуправлять свопом, но я верю, что конечный результат один и тот же: процесс пользовательского пространства знает, какое место выделено для свопа, а процесс пользовательского пространства информирует ядро.

Все остальные ответы упоминают, как указать на файловую систему подкачки при загрузке.

Тем не менее, несколько моментов, которые нужно добавить к другим ответам:

• пространство подкачки также может быть файлом;
• раздел подкачки обычно помечается как тип 0x82;
• вы можете смонтировать пространство подкачки в любой момент времени выполнения;
• для маркировки / инициализации раздела / файла, чтобы он был распознан и позже использовался / смонтирован как пространство подкачки, вам нужно использовать команду mkswap;
• для активации / использования раздела / файла подкачки вручную вы используете команду swapon;
• аналогично для того, чтобы поменять его, вы идете с swapoff.