O espaço de swap configurado estaticamente (o tipo que praticamente todas as distribuições usam) é configurado /etc/fstabexatamente como os sistemas de arquivos.

Uma entrada típica se parece com:

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

Você também pode ver discardou nofailespecificado no campo sinalizadores (o quarto campo). Cada uma dessas linhas corresponde a uma área de troca (não precisa ser uma partição, você pode ter arquivos de troca ou até mesmo discos de troca inteiros).

Em alguns casos realmente específicos, você pode ter um espaço de troca configurado dinamicamente, embora isso seja bastante raro porque pode causar um comportamento problemático relacionado ao gerenciamento de memória. Nesse caso, a configuração é realizada inteiramente por um componente de espaço do usuário que cria e habilita arquivos de troca conforme necessário em tempo de execução.

Quanto a quantas você precisa, é uma pergunta complicada de responder, mas o número de diferentes distribuições Linux que você planeja executar tem impacto zero nisso, a menos que você queira executar uma distribuição enquanto tem outra em hibernação (e você provavelmente não quer fazer isso, pois é uma maneira muito fácil de estragar seu sistema).

Quando você for executar o instalador para quase todas as principais distribuições (incluindo Fedora, OpenSUSE, Linux Mint, Debian e Ubuntu), ele detectará todas as partições swap existentes no sistema e as adicionará à configuração da distribuição que você está instalação (exceto possivelmente se você selecionar o particionamento manual) e, na maioria dos casos, isso resultará na configuração do sistema de maneira sensata.

Além disso, eu pessoalmente sugiro evitar ter várias partições de troca, a menos que você esteja falando sobre um sistema de servidor com muitos discos e, mesmo assim, você realmente precisa saber o que está fazendo para configurá-lo para que funcione bem .

digamos Fedora e Ubuntu?

… ambos são atualmente sistemas operacionais systemd.

O que acontece nos sistemas operacionais systemd

o mecanismo nativo

Systemd emprega vários tipos de unidades. .mountarquivos de unidade instruem-no a montar volumes. .swapOs arquivos de unidade o instruem a informar ao kernel sobre as partições de troca. ( .servicearquivos de unidade instruem como executar serviços. E assim por diante.) Esses são os mecanismos nativos do systemd. Para aplicá-los, o próprio systemd separa os processos filhos que fazem as chamadas de sistema relevantes.

Se você usar o systemctlcomando (com --all) em um sistema operacional systemd, ele informará sobre as .swapunidades carregadas. Por exemplo:

dev-disk-by\x2dpartuuid-40549710\x2d05.swap carregado ativo ativo /dev/disk/by-partuuid/40549710-05
dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap carregado ativo ativo /dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
dev-sda5.swap carregado ativo ativo /dev/sda5

Ele também informará sobre as .mountunidades.

Um administrador de sistema pode realmente escrever esses .swaparquivos de unidade manualmente, assim como xe pode escrever .service, .sockete outros arquivos de unidade manualmente. O próprio systemd apenas procura por arquivos unitários no sistema de arquivos. Eles são seu mecanismo nativo.

Pode-se até obter o systemd para mostrar o que há nesses arquivos de unidade e onde eles podem ser encontrados no sistema de arquivos:

$ 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
# Gerado automaticamente pelo systemd-fstab-generator

[Unidade]
SourcePath=/etc/fstab
Documentação=man:fstab(5) man:systemd-fstab-generator(8)

[Troca]
What=/dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
Opções=sw
$

arquivos unitários gerados automaticamente

Pode-se escrevê-los à mão. Normalmente , no entanto, esses arquivos .mounte .swapunidades são gerados automaticamente por programas conhecidos como geradores . Dois desses geradores são systemd-fstab-generatore systemd-gpt-auto-generator. Ambos são executados no início do processo de bootstrap e em resposta a um systemctl daemon-reloadcomando, e (como você pode ver acima) eles geram toda uma carga de arquivos de unidade em um subdiretório não documentado em /run/systemd/. O próprio systemd usa apenas os arquivos de unidade gerados .

O antigo gerador lê /etc/fstab, reconhecendo várias extensões systemd para esse formato de arquivo. Como indiquei em um comentário de resposta, tradicionalmente as partições de troca têm o tipo de montagem de swe é assim que se descobrirá que outros sistemas operacionais reconhecem os registros de troca nesta tabela. Mas os softwares Linux adotaram a abordagem alternativa de reconhecer o tipo VFS , procurando pelo swaptipo VFS. systemd-fstab-generatornão é exceção aqui, e é assim que interpreta /etc/fstabao convertê-lo nos mecanismos nativos.

O último gerador processa a tabela de partição EFI que está no mesmo disco que contém a partição do sistema EFI, procurando por entradas da tabela de partição EFI que possuem vários GUIDs de tipo de partição conhecidos . Um desses GUIDs é o GUID convencional atribuído às partições swap do Linux; e se systemd-gpt-auto-generatorencontrar uma partição com esse GUID (que satisfaça os critérios fornecidos no systemd doco) fará uma .swapunidade para ela; nenhum /etc/fstabenvolvido em tudo .

Claro, esse processo tem muitos efeitos colaterais. Por exemplo, como /etc/fstabnão há chave primária para a tabela, os registros podem ter campos "spec" e "arquivo" duplicados (ou seja, "o que" e "onde"). No mecanismo systemd nativo, porém, o campo "arquivo" (ou seja, "onde") é uma chave exclusiva para .mountunidades, incorporada aos nomes das unidades. Duas .mountunidades não podem compartilhá-lo. Para .swapunidades, o campo "spec" (ou seja, "o que") é a chave exclusiva para unidades. Duas .swapunidades não podem compartilhar isso. Portanto, nem todos os registros /etc/fstabsão necessariamente conversíveis para os mecanismos nativos e funcionarão, especialmente se as pessoas fizerem coisas como listar o mesmo ponto de montagem para duas finalidades diferentes ou listar a mesma partição de troca de duas maneiras diferentes.

Da mesma forma, como foi traduzido /etc/fstabpara o mecanismo nativo e o mecanismo nativo do systemd tem outras maneiras de ativar units , o comportamento é sutilmente diferente daquele dos sistemas operacionais não systemd. Uma .mountunidade será, por padrão, ativada automaticamente porsystemd-udevd , mesmo após o bootstrap, em resposta à aparência do dispositivo de armazenamento montado. Ou pode ser listado como um Wants=ou Requires=de algum .serviceou .socketunidade, o que significa que será (re)ativado quando eles forem. Existe mesmo RequiresMountsFor=.

programas de instalação e o modo systemd

Tradicionalmente, os programas de instalação do sistema operacional e o administrador do systemd depois de reconfigurar o sistema gravam swentradas em arquivos /etc/fstab. E é assim que o nativo .mounte as .swapunidades acabam sendo gerados automaticamente. O utilitário de instalação/configuração "sabe" onde o arquivo de troca foi colocado, porque em sua interface de usuário o administrador do sistema fez algum tipo de escolha e gravou um /etc/fstabcorrespondente. Às vezes, essa escolha é : preciso que você crie uma partição de troca como parte da instalação. ; às vezes é apenas usar a partição swap que você já encontrou no disco. (instaladores olhando para os tipos de partição também).

Mas o pessoal do systemd tem essa ideia de sistemas operacionais que se configuram automaticamente a partir de uma /etcárvore amplamente vazia, os chamados sistemas sem estado , e é disso que tratam mecanismos como o gerador que lê a tabela de partições EFI. No plano do pessoal do systemd, não há /etc/fstab, e de fato não há dados de configuração persistentes /etc, e todas essas coisas são deduzidas do conteúdo da tabela de partição no disco , em cada inicialização e em cada arquivo systemctl daemon-reload. Atualmente, eles estão promovendo programas de instalação de sistema operacional que não escrevem um arquivo/etc/fstab .

No esquema tradicional, é claro que você pode de fato fazer com que cada sistema operacional tenha sua própria partição swap privada, sem que eles toquem nas partições swap um do outro. E, de fato, se você estiver usando o hibernate para o disco por meio de uma partição swap e esperando ser capaz de inicializar em outro sistema operacional durante a hibernação ( o que é uma péssima ideia porque é muito fácil causar corrupção no sistema de arquivos dessa maneira ), isso será necessário.

No esquema systemd, mesmo que o sistema operacional ainda não seja como o pessoal do systemd o imagina e "sem estado", os geradores mencionados funcionam; e assim todas as partições swap (no disco ESP/raiz) com o tipo de partição necessário são automaticamente empregadas por todos os sistemas operacionais systemd. Como eles estarão compartilhando todas as partições swap descobertas automaticamente, não é realmente necessário criar uma partição swap por sistema operacional instalado.

Leitura adicional

• https://unix.stackexchange.com/a/332797/5132
• https://unix.stackexchange.com/a/233581/5132
• Lennart Poettering et ai. (2016). A especificação de partições detectáveis . freedesktop.org.
• Lennart Poettering et ai. (2017). systemd.swap. páginas de manual do systemd . freedesktop.org.
• Lennart Poettering et ai. (2017). systemd-fstab-generator. páginas de manual do systemd . freedesktop.org.
• Lennart Poettering et ai. (2017). systemd-gpt-auto-generator. páginas de manual do systemd . freedesktop.org.
• Lennart Poettering (2014-06-17). Redefinição de fábrica, sistemas sem estado, sistemas reproduzíveis e sistemas verificáveis ​​. 0pointer.net.
• Lennart Poettering (2014-09-01). Revisitando como montamos os sistemas Linux . 0pointer.net.
• Lennart Poettering (2017-06-28). mkosi — Uma ferramenta para gerar imagens do sistema operacional . 0pointer.net.

Historicamente, a partição swap é especificada /etc/fstabcom uma entrada do tipo swap. Na inicialização, os processos de inicialização lerão esse arquivo e enviarão essa configuração para o kernel.

Um exemplo da entrada em /etc/fstabé:

/dev/sdb    none    swap     sw      0  0

Não estou familiarizado com como systemdgerencia a troca, mas acredito que o resultado final é o mesmo: um processo de espaço de usuário está ciente de qual espaço é alocado para troca e o processo de espaço de usuário informa o kernel.

Todas as outras respostas mencionam como apontar para um sistema de arquivos swap na inicialização.

No entanto, vários pontos a serem adicionados às outras respostas:

• o espaço de troca também pode ser um arquivo;
• uma partição de espaço de troca é marcada geralmente como tipo 0x82;
• você pode montar um espaço de troca em qualquer ponto do tempo de execução;
• para marcar/inicializar uma partição/arquivo, para que seja reconhecido e usado/montado posteriormente como espaço de troca, você precisa usar o comando mkswap;
• para ativar/usar uma partição/arquivo swap manualmente, você usa o comando swapon;
• da mesma forma para trocá-lo, você vai com swapoff.