Systemd-swap: A hibernação realmente não é possível?

@TeslaBargain , algum tipo de magia vodu negra.

Claro que é possível fazer isso sozinho - então você pode fazer isso sozinho.

Para zram, você precisa fazer todas as coisas acontecerem antes da hibernação:

1. Adicionar novo arquivo de troca
2. Formatar e trocar
3. Adicione todas as informações para acessar os dados no arquivo de swap ao cmdline do kernel (mude a configuração do grub, ou systemd-boot, ou lilo, ou u-boot & etc?)
4. Trocar zram
5. Hibernar (acho que você não sabe quanto tempo você perdeu antes de tudo isso acontecer, para tornar a hibernação possível)
6. Após reiniciar / sair da hibernação, você deve fazer tudo isso na ordem inversa.

E isso só funcionará em fs que suportam esse tipo de arquivos de troca, ou seja, para btrfs isso não é possível.

@ Nefelim4ag , obrigado por me avisar. De modo geral, é muito trabalho para valer a pena. Com uma solução out-of-the-box eu usaria, mas dessa forma ficarei apenas com a minha partição swap e uso regular de swap + hibernação.

E se houvesse uma opção para formatar e trocar em arquivos de troca suficientes para o sistema hibernar toda a sua memória disponível quando o systemd-swap é inicializado? e realizar chamadas bootctl , ou usar algum tipo de local fixo para testar, para obter informações para acessar dados no arquivo de swap para cmdline do kernel em systemctl-boot ou rEFInd ou grub ou qualquer outro?

Dessa forma, o único atraso real seria trocar o zram, algo que é apenas uma parte inevitável do uso do zram.

Do jeito que eu imaginei, se você já vai pré-alocar swap na inicialização , você pode também alocar o suficiente para ser útil.

Oi. Estou disposto a saber se o cenário em que você define uma partição de swap na instalação e usa aquela para hibernação (não tenho certeza de como indicar o kernel para usar isso apenas para hibernar) e então usa zram para o resto das operações de swap (e ganho em performances). É algo a se considerar? Alguma ideia?

EDITAR: este https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
mais troca de systemd (zram)

Acho que isso pode ser feito por meio de prioridades de troca + ganchos para hibernação do systemd. Examinar rapidamente várias questões de stackoverflow não respondeu a isso, então eu teria que testá-lo manualmente. Na verdade, esta é uma correção muito mais fácil do que a que eu estava pensando e, portanto, pode ser implementada antes do 5.0 (embora a correção completa deva estar no 5.0)

IIRC, a hibernação requer um único dispositivo de troca, portanto, deve ser grande o suficiente para armazenar toda a memória alocada na RAM / troca em outro lugar? (mas esta imagem de hibernação que é gravada deve, por padrão, usar compactação com uma meta de cerca de 40%).

Eu não tentei fazer isso sozinho, a hibernação não retém os arquivos de troca no disco ou dispositivo (s) zram na RAM como se estivessem alocados como qualquer outro software? Você está retomando um estado do sistema, desde que a memória seja gravada na imagem de hibernação, ela deve restaurar / retomar os dispositivos de troca atribuídos anteriormente em vez de inicializá-los como uma nova inicialização faria? Portanto, nenhuma troca de ligar / desligar deve ser necessária além de alternar um dispositivo de troca de hibernação.

Eu sempre hibernei com um único dispositivo de troca (sem zswap ou zram). Não tenho certeza do que acontece com a troca de disco (já que existe mais de um dispositivo de troca) nesse caso (se ele precisa caber na imagem de hibernação, isso parece redundante?), Da mesma forma suponho que zram teria sua memória alocada escrito na imagem de hibernação como qualquer outra memória alocada pelo software, não tenho certeza de como a parte de troca é tratada, se dispositivos de troca adicionais precisam ser gravados na imagem de hibernação, então eu acho que zram e o cache de zswap na RAM descompactariam e depois o currículo precisa ser recompactado.

Não consigo testar o cenário atm para saber o que acontece. Provavelmente não é muito difícil de testar via VM?

Vale a pena notar, a maioria das distros que usam o systemd deveriam adiar a hibernação para systemd-sleep hibernate atualmente? Desde 2019-2020 (na versão v239 +, eu acho?) Tem a capacidade de retomar da hibernação sem exigir parâmetros do kernel para especificar o dispositivo de troca de destino (partição apenas neste caso iirc) e adivinhará qual dispositivo de troca usar implicitamente. Se houver apenas uma partição swap, então ela deve ser confiável sem a necessidade de definir / atualizar resume (e resume_offset se estiver usando o arquivo swap) para os parâmetros de inicialização do kernel.

Novamente, não é algo que testei ainda para verificar.

Problema de rastreamento upstream: https://github.com/systemd/systemd/issues/16708