Philip Couling's questions

Eu tenho um sistema que trava quando o systemd tenta montar um sistema de arquivos. Ele falha quando uma dependência atinge o tempo limite. A dependência é dev-disk-by\x2dlabel-cb\x2drootfs.deviceonde está o dispositivo que está sendo montado /dev/disk/by-label/cb-rootfs.

systemd[1]: dev-disk-by\x2dlabel-cb\x2drootfs.device: Job dev-disk-by\x2dlabel-cb\x2drootfs.device/start timed out.

Nada me impede de montar o sistema com:

mount -av

Portanto, neste caso, parece que o systemd está esperando a coisa errada, já que o dispositivo está obviamente lá e pronto para ser montado.

O que pode tornar isso complexo é que o sistema de arquivos raiz é um overlayfs envolvendo o mesmo dispositivo. Em termos simples, o initramfs está fazendo isso:

mount /dev/disk/by-label/cb-rootfs /host
mount -o loop /host/rootfs/foo.squashfs /ro
mount -t overlay overlay lowerdir=/ro,upperdir=/host/writable,workdir=/host/workdir /root

/rootentão o sistema de arquivos raiz está pronto para o systemd iniciar a montagem /etc/fstab:

Então /etc/fstabtenta montar

/dev/disk/by-label/cb-rootfs /host ext4 defaults 0 0

Como eu disse, posso mount -ave o Linux não tem absolutamente nenhum problema em montar `/dev/disk/by-label/cb-rootfs. Mas o systemd aparentemente está esperando indefinidamente que fique pronto de alguma forma.

O que o systemd está esperando? como posso evitar esperar assim?

Estou tentando descobrir uma maneira limpa e segura de usar dispositivos de loop dentro de um script de construção. Pelo que sei, são necessários dispositivos de loop se você deseja particionar (GPT) e (FAT32, EXT3) formatar um arquivo esparso ¹ .

Por exemplo: digamos que eu tenha este script:

#!/bin/bash
set -ex
truncate --size 4G target.img
sfdisk target.img < partitions
loop_device=$(losetup -f --show target.img)
trap "losetup -d $loop_device" EXIT
partx -u $(loop_device)
mkfs.vfat ${loop_device}p1
mkfs.ext4 ${loop_device}p2

Na maioria dos caminhos felizes e infelizes, o dispositivo de loop será limpo por bash chamando losetup. Mas existem alguns caminhos infelizes ² que fazem com que o dispositivo de loop seja deixado para trás.

Se esta fosse uma questão sobre montagens, a solução simples seria executar em um namespace de montagem com unshare -m. Isso resultaria na limpeza do ponto de montagem pelo kernel quando o processo fosse encerrado, sem que o processo executasse explicitamente a mesma ação.

Além disso, se o dispositivo de loop fosse criado com uma montagem em primeiro lugar, mount -o loopo dispositivo de loop seria limpo quando o ponto de montagem fosse criado e, portanto, por proxy, um namespace de montagem também poderia ser usado para limpar o dispositivo de loop.

Mas como o que procuro é uma tabela de partição GPT em um arquivo com zeros, nenhum sistema de arquivos seria montado com êxito nele (AFAIK).

Então, existe alguma outra maneira de fazer com que o kernel limpe um dispositivo de loop quando um processo, grupo de processos, namespace, ... é limpo?

• ¹ Estou ciente de que existem soluções, como formatar um arquivo separado e depois usá-lo ddpara copiar com um deslocamento, mas isso resulta na gravação de vários GB de zeros no disco, em vez de permanecer como um arquivo esparso. Então aqui a palavra "esparso" é muito importante
• ² Uma coisa óbvia é o que acontece quando o bash é morto comkill -9

Os TPMs devem resolver um problema de ovo e galinha de onde armazenar chaves de criptografia de disco não criptografadas, de modo que alguém não possa simplesmente inserir outro disco rígido na máquina, inicializar um sistema operacional diferente e ler as chaves diretamente do disco / flash / BIOS / ...

Os AFAIK TPMs basicamente fazem isso verificando qual software inicializou e, se esse software não corresponder a um hash predefinido, ele permanecerá bloqueado e se recusará a fornecer as chaves de criptografia de disco.

Eu li vários artigos apontando para o fato de que systemd pode ajudar a incorporar minhas chaves LUKS em um TPM com systemd-cryptenroll . Mas eles falam apenas em incorporar a chave no TPM e não impedir que invasores leiam essas chaves.

Onde estou preso é descobrir como garantir que haja uma sólida cadeia de confiança do firmware do BIOS para o login, garantindo que, se o sistema operacional for adulterado, ele não inicialize ou o TPM se recuse a entregar a chave de criptografia.

Por exemplo, não há muito uso em criptografar meu disco rígido se alguém no terminal puder simplesmente pressionar Eno prompt do grub e inicializar o Linux init=/bin/bashpara obter um login root sem precisar de uma senha. A criptografia seria totalmente inútil nessa situação.

Estou preso em dois pontos bastante específicos:

• O que uma distribuição típica baseada em systemd (Debian ou Ubuntu) faz para bloquear o TPM em primeiro lugar. Quais arquivos isso protege contra adulteração?
• Que outras coisas na sequência de inicialização devo proteger contra adulteração?
  • por exemplo: grub EFI binary, grub.cfg in EFI, grub passwordles editando entradas de inicialização, initramfs, ...

Estou curioso sobre o arquivo ou link simbólico /etc/mtab. Eu acredito que este é um mecanismo herdado . Em todo Linux moderno que usei, este é um link simbólico para /proc/mountse, se mtabfosse um arquivo regular em um sistema de arquivos "normal", /etchaveria desafios em fazer o software funcionar com namespaces de montagem.

Por muito tempo presumi que uma de duas coisas fosse verdade. Qualquer:

• Estamos aguardando a referência do software /etc/mtabexpirar ou ser atualizada
• Outros sistemas operacionais não Linux ainda usam o mesmo nome de arquivo e o link está lá para compatibilidade entre plataformas

No entanto, ambos parecem idéias instáveis. Não consigo encontrar uma boa referência a nenhum sistema operacional moderno que mantenha o mesmo nome de arquivo fora do Linux. E parece ter vivido por muito tempo para ser simplesmente um problema de compatibilidade com versões anteriores; mudanças muito mais significativas parecem ter surgido e desaparecido ao mesmo tempo.

Então, fico me perguntando se /etc/mtabrealmente está lá apenas por razões históricas. É de alguma forma oficialmente obsoleto? Existe alguma razão moderna sólida [a partir de 2023] para mantê-lo?

Não quero excluí-lo do meu sistema, mas como desenvolvedor de software, gostaria de entender sua utilidade e se devo evitá-lo.

Estou curioso para entender como ~é processado em uma dependência pelo Apt ou como é definido para arquivos deb (não tenho certeza exatamente onde a sintaxe é definida).

Eu o encontrei em relação às dependências do metapacote Ubuntu (Focal) python3que tem a restrição de dependência: python3.8 >= 3.8.2-1~(veja aqui ).

Eu acredito que as versões do pacote são definidas para que eles classifiquem lexicalmente em ordem, mas quando eu verifiquei o ubuntu focal, não há uma versão python3.8que classifique lexicalmente >= 3.8.2-1~, mas há uma versão 3.8.10-0ubuntu1~20.04.4inferindo que as dependências do Ubuntu Focal estão quebradas ( não são ) ou há algum significado especial para ~uma dependência.

A única documentação que posso encontrar sobre o tópico é Debian's Declaring relations between packages . Mas isso não menciona a ~ou correspondência de padrões.

Então, qual é o significado do trailing ~em uma dependência .deb?

Hoje encontrei algum código que está escrevendo um caractere de nova linha explicitamente em um arquivo sysctl. Veja o código fonte do moby/docker . Meu primeiro pensamento é que o autor copiou diligentemente o comportamento do shell em go, apesar da nova linha ser redundante.

Mas então comecei a procurar documentação sobre o assunto e achei muito difícil encontrar informações de qualquer maneira. Não consegui inventar nada até agora.

Ao escrever arquivos sysctl em /proc/sys/muitos dos valores são inteiros escritos em ASCII. Por exemplo, para ativar ou desativar algo, você precisa escrever 1ou 0como texto em um arquivo.

Muitas vezes, o conselho aqui no U&L e em blogs etc. é fazer isso no shell usando echo. Por exemplo, ativando o encaminhamento IPv4:

echo 1 > /proc/sys/net/ipv4/ip_forward

Mas este conselho faz algo sutilmente diferente de seu objetivo declarado. Ele não grava um único byte 0x31 no arquivo. Ele escreve dois: 0x31 0x0A também conhecido como 1\n. Eu sempre assumi que a nova linha (0x0A) era simplesmente ignorada pelo kernel.

Escrever um caractere de nova linha em um arquivo sysctl (por exemplo /proc/sys/net/ipv4/ip_forward, ) tem algum efeito? As referências são bem-vindas, mesmo que sejam links para o código-fonte.

Seguindo os tópicos levantados em outras questões, acredito que quando o Linux Kernel está tentando liberar RAM física, ele toma algum tipo de decisão entre descartar páginas de seu cache de disco ou liberar outras páginas para swap. Não tenho certeza disso, talvez eu tenha entendido mal o mecanismo.

Em qualquer caso, há sinergia entre:

• o kernel mantendo seu próprio cache de disco interno
• programas arquivos de mapeamento de memória
• memória de aplicativo "regular" sendo colocada em um arquivo de troca

Todos os três podem ser usados ​​para liberar RAM física, todos os três dependem de gravar páginas "sujas" no disco ou simplesmente saber que as páginas já estão duplicadas no disco e descartá-las da alocação física de RAM.

Com o espaço de troca, partições e arquivos de troca individuais podem ter prioridade para que dispositivos mais rápidos sejam usados ​​antes de dispositivos mais lentos. Não tenho conhecimento de tais configurações para outros dispositivos que não sejam de troca.

Minha pergunta é: Como o Kernel decide qual RAM liberar?

• É puramente baseado no último acesso?
• O Kernel usa todos os três acima igualmente?
  • existe alguma priorização entre eles (e discos individuais)
  • é configurável?

Esta pergunta é impulsionada por experiências semelhantes a esta, mas quero que essa pergunta se concentre no mecanismo subjacente NÃO na solução de um problema específico.

Não tenho 100% de certeza se esta é uma pergunta U&L ou SO . No geral, estou postando no U&L, pois é relacionado ao sistema operacional .

Fundo

Até onde eu sei, o Linux carregará bibliotecas compartilhadas (arquivos .so) mapeando-as na memória como copy-on-write. Uma vantagem disso é que vários processos que compartilham a mesma biblioteca grande compartilharão a mesma RAM física para grande parte do conteúdo dessa biblioteca.

Isso não acontece necessariamente com o Docker porque os processos são executados em seu próprio "contêiner" com base em uma "imagem" e cada imagem contém sua própria cópia de bibliotecas compartilhadas. Isso é deliberado. Ele permite que os programas sejam enviados com suas próprias dependências (bibliotecas) que podem ser substancialmente diferentes das bibliotecas já instaladas no sistema.

Portanto, um programa executado nativamente em um host do Docker não compartilhará a mesma memória para bibliotecas que um programa executado em um contêiner do Docker porque o programa no contêiner do Docker foi mapeado para diferentes cópias das bibliotecas.

Camadas do Docker explicadas

As imagens do Docker são criadas em camadas. Cada camada adiciona à inferior, às vezes substituindo os arquivos existentes. Nem todo arquivo é alterado em todas as camadas.

O Docker permite criar novas imagens adicionando novas camadas a uma imagem mais antiga. Quando isso acontece, você acaba com várias imagens compartilhando as mesmas camadas. As imagens compartilham cópias idênticas de alguns dos mesmos arquivos.

O Docker mantém as camadas separadamente, pelo menos antes do tempo de execução. Por exemplo: ao puxar uma imagem do Docker Hub, o Docker busca as imagens buscando as camadas constituintes de cada imagem. Ele apenas busca as camadas que ainda não possui.

O que eu não sei

Ao criar ou executar um contêiner, o Docker deve montar as camadas em um único sistema de arquivos coerente. Não sei como faz isso. Poderia:

• Copie os arquivos em um só lugar
• Crie links físicos em um só lugar
• Use um sistema de arquivos de sobreposição

Dependendo do que ele faz, os arquivos originados da mesma camada podem ser cópias idênticas ou podem ser exatamente o mesmo arquivo no sistema de arquivos.

Em última análise, isso afetará o que acontece quando os arquivos são mapeados na memória por vários processos.

O que estou realmente tentando descobrir?

Eu quero saber se a execução de dois contêineres de duas imagens diferentes compartilhará a mesma RAM para uma única biblioteca compartilhada originada em uma única camada.

O que especificamente o Linux pode fazer quando tem swap que não pode sem swap?

Para esta pergunta, quero focar na diferença entre, por exemplo, um PC Linux com 32 GB de RAM e sem swap versus um PC Linux quase idêntico com 16 GB de RAM com 16 GB de swap. Observe que não estou interessado no "sim, mas você pode ver uma melhoria no X se adicionar swap ao PC de 32 GB" . Isso é off-topic para esta pergunta.

Eu encontrei pela primeira vez a opinião de que adicionar swap pode ser melhor do que adicionar RAM em comentários para um problema anterior .

É claro que li isso: Preciso de espaço de troca se tiver uma quantidade de RAM mais do que suficiente? e...

• As respostas são principalmente focadas na adição de swap, por exemplo, discutindo o cache de disco, onde a adição de RAM também estenderia o cache de disco.
• Há alguma menção de que a desfragmentação só é possível com troca, mas não consigo encontrar evidências para fazer backup disso.
• Eu vejo alguma referência a MAP_NORESERVE para mmap, mas isso parece um risco muito específico e obscuro associado apenas a situações OOM e possivelmente apenas mmap privado .

A troca é frequentemente vista como uma maneira barata de estender a memória ou melhorar o desempenho. Mas quando a produção em massa de dispositivos Linux embutidos, isso é virado de cabeça para baixo ...

... Nesse caso, a troca irá desgastar a memória flash, fazendo com que ela falhe anos antes do final da garantia. Onde dobrar a RAM é um par de dólares extras no dispositivo.

Observe que é flash eMMC NÃO é um SSD! . Normalmente, o flash eMMC não possui tecnologia de nivelamento de desgaste, o que significa que ele se desgasta MUITO mais rápido que os SSDs

Parece haver muita opinião contestada sobre este assunto . Estou realmente procurando por fatos secos sobre capacidades, não por opiniões do tipo "você deveria / não deveria".

O que pode ser feito com o swap que também não seria feito adicionando RAM?

Em alguns dos meus scripts de compilação, tenho usado namespaces de montagem como um mecanismo para montar com segurança sem nunca deixar essas montagens para trás quando o script termina. Os pontos de montagem não compartilhados são desmontados implicitamente quando o último processo nesse namespace é encerrado .

Meus scripts geralmente incluem uma stansa como esta:

#!/bin/bash
self_ns=$(ls -lh /proc/self/ns/mnt)
init_ns=$(ls -lh /proc/$PPID/ns/mnt)
if [ "${self_ns#*mnt:}" = "${init_ns#*mnt:}" ] ; then
    unshare --mount $0 "$@"
    exit $?
fi

Embora isso tenha funcionado bem para mim por algum tempo, recentemente encontrei um problema em um servidor de compilação jenkins.

Eu acredito que o problema é que o próprio script de compilação está sendo executado dentro de um ambiente chroot jenkins . Então, quando o script é executado unshare --mount ..., ele falha com o erro:

unshare: cannot change root filesystem propagation: Invalid argument

Infelizmente, eu realmente não entendo essa restrição ou como contorná-la. Quando tento um chroot na linha de comando, não consigo replicar esse erro. Eu não sei o que o plugin jenkins fez para causar isso.

O mais importante é que esses pontos de montagem sejam removidos na saída todas as vezes, sem falhas .

Como você pode determinar o nome do host associado a um IP na rede? (sem configurar um DNS reverso)

Isso era algo que eu achava impossível. No entanto, eu tenho usado o Fing no meu celular. Ele é capaz de encontrar todos os dispositivos na minha rede (presumivelmente usando um arp-scan) e listá-los com um nome de host.

Por exemplo, este aplicativo é capaz de encontrar dispositivos Debian Linux recém-instalados conectados a um roteador doméstico, sem DNS reverso aparente.

Até onde eu sei, nem ping , nem Neighbor Discovery , nem arp incluem um nome de host. Então, como o fing pode obter isso para um PC Linux recém-instalado? Que outro protocolo em uma máquina Linux forneceria o nome de host configurado da máquina?

Estou investigando um efeito muito estranho em algumas placas Beagle Bone Black (BBB) . Estamos vendo saltos ocasionais de alguns meses no relógio do sistema que sempre se correlacionam com systemd-timesyncda atualização do relógio do sistema. Vemos de 2 a 3 deles por semana em uma frota de 2.000 dispositivos em diversos locais.

Passamos muito tempo verificando o SNTP, mas parece estar se comportando normalmente.

Finalmente encontramos um problema de hardware com o relógio de tempo real integrado que pode fazer com que ele salte aleatoriamente 131072 segundos (36 horas) devido ao ruído eletrônico. Isso não se encaixa imediatamente, o salto no tempo relatado é bastante específico e muito menor do que observamos, no entanto, uma leitura mais profunda sobre o problema sugere que os saltos podem ser mais aleatórios e podem até retroceder.

Minha pergunta é... Como o linux usa um relógio de tempo real para manter o relógio do sistema ?

Eu quero saber se um erro com o relógio de tempo real só se apresentaria no relógio do sistema quando um agente de sincronização de tempo (ntpd ou systemd-timesyncd) for atualizado. Existe algum link direto entre o relógio do sistema e um RTC ou é usado apenas por um agente?

Nota: No primeiro parágrafo mencionei que estamos vendo saltos de alguns meses no relógio do sistema que sempre se correlacionam com systemd-timesyncda atualização do relógio do sistema. Com isso quero dizer que a primeira mensagem do syslog após um salto de tempo é uma Time has been changedmensagem do syslog:

grep 'Time has been changed' /var/log/syslog
Oct  2 23:53:33 hostname systemd[1]: Time has been changed
Nov 21 00:07:05 hostname systemd[1]: Time has been changed
Nov 21 00:05:17 hostname systemd[1]: Time has been changed
Nov 21 00:03:29 hostname systemd[1]: Time has been changed
Nov 21 00:01:43 hostname systemd[1]: Time has been changed
Oct  3 02:07:20 hostname systemd[1]: Time has been changed
Oct  3 06:37:04 hostname systemd[1]: Time has been changed

Até onde sei, a única coisa que emite essas mensagens é o systemd-timesycnd ( consulte o código-fonte ). Obviamente, se alguém souber de outras systemdmensagens regulares do syslog que correspondam a essas, estou aberto a sugestões.

Estou tentando entender a relação entre os cabeçalhos destacados do LUKS e seu respectivo dispositivo de bloco. Pelo que entendi, "formatar" com um cabeçalho separado não altera o conteúdo do respectivo dispositivo de bloco, isso só ocorre quando você começa a gravar na cryptsetup luksOpenpartição aberta ( ).

Então gostaria de saber:

• Uma única partição criptografada pode ter dois cabeçalhos independentes. Por exemplo, se eu tivesse uma unidade removível conectada intermitentemente a dois computadores diferentes, cada computador poderia ter sua própria cópia independente do cabeçalho sem a necessidade de sincronizar novamente as duas cópias do cabeçalho.
• Um único cabeçalho destacado pode ser usado para duas unidades separadas. Por exemplo, se eu tivesse duas unidades de backup criptografadas, um único cabeçalho poderia ser usado para ambos ou o cabeçalho de alguma forma está vinculado à partição?

Seguindo a pergunta de outro usuário, me deparei com uma peculiaridade das permissões do sistema de arquivos Linux que não consigo racionalizar facilmente:

sudo mkdir ~/foo ~/foo/bar
sudo touch ~/baz
mkdir ~/my_dir
chown 700 ~/my_dir
# this is fine
mv ~/baz ~/my_dir
# renaming is fine
mv ~/foo ~/bob
# Moving caused: Permission denied
mv ~/bob ~/my_dir/

Para maior clareza foo foo/bar bazsão de propriedade da raiz. my_diré de propriedade do meu próprio usuário e, claro, ~é de propriedade do meu próprio usuário. Posso renomear e mover um arquivo pertencente a outro usuário. Posso renomear um diretório pertencente a outro usuário, mas não posso mover um diretório pertencente a outro usuário.

Isso parece uma restrição muito específica e não entendo contra qual perigo está sendo protegido ou qual mecanismo subjacente significa que só pode funcionar dessa maneira.

Por que os diretórios de outros usuários não podem ser movidos?

Percebo que em sistemas relacionados ao Debian, scripts crontab em nível de sistema em /etc/cron.hourly, /etc/cron.daily... estão sendo gradualmente desativados em favor de timers systemd. Por exemplo:

$ cat logrotate
#!/bin/sh

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi

...

Presumo que um objetivo seja desativar gradualmente o cron e o anacron. (Ver nota 1)

Para mim, um caso de uso crítico do cron são os crontabs definidos pelo usuário ( crontab -e) que permitem que um usuário agende seus próprios trabalhos para serem executados como seu próprio usuário sem exigir privilégios de administrador do sistema.

Existem recursos no systemd, atuais ou planejados, que permitem que usuários não administradores agendem tarefas repetitivas?

Nota 1:

Enfraquecendo um pouco a declaração anterior, não encontrei nenhuma discussão particularmente boa, exceto aquelas que falam mal do cron e elogiam os timers do systemd. Não encontrei nenhuma evidência de que essa direção de viagem tenha sido transmitida pelos deuses da distribuição Linux. No entanto, eu noto isso como uma direção de viagem. Portanto, esta afirmação é baseada apenas na ideia de que se esta é uma direção de viagem e com o tempo eu esperaria que a maioria / todos os pacotes eventualmente seguissem o mesmo caminho e tornassem um sistema (cron) redundante.

Eu gostaria de saber se as cadeias longas no iptables podem causar um problema de desempenho. Aqui, uma longa cadeia pode ser > 2.500 banimentos de IP individuais.

Minha preocupação é que meu conhecimento limitado de iptables sugere que isso resultará em 2.500 regras sendo verificadas para cada pacote que o servidor recebe.

Meu caso de uso é este:

Estou usando o iptables para bloquear IPs repetidamente cutucando meu servidor de maneiras que não deveriam (por exemplo, logins SSH repetidos com falha). Estou usando um script python semelhante ao fail2ban .

Mais recentemente, esses "ataques" começaram a ser mais inteligentes, diminuindo a velocidade do ataque. Suspeito que eles tenham invertido o loop aninhado de IP/nome de usuário para nome de usuário/IP. Então, para combater isso, tive que estender massivamente o tempo de banimento. Eu tomo uma atitude bastante robusta em relação a isso, então meu novo tempo de banimento é de 1 ano ou o dobro se eles tentarem novamente durante um período de experiência de dois meses.

Encontrei evidências anedóticas de que esse tipo de banimento resultou em aproximadamente 2.500 banimentos. Se eu pegasse a taxa de novos banimentos atualmente, seria mais de 8.000, mas espero que essa taxa diminua à medida que o servidor começar a bloquear com mais precisão o tráfego malicioso.

Eu tenho um laptop Debian (Buster) com 8 GB de RAM e 16 GB de swap. Estou executando uma tarefa muito longa. Isso significa que meu laptop foi deixado ligado nos últimos seis dias enquanto ele roda.

Ao fazer isso, periodicamente preciso usar meu laptop como laptop. Isso não deve ser um problema; a tarefa de longa execução é limitada por E/S, trabalhando em um disco rígido USB e não consome muita RAM (<200 MB) ou CPU (<4%).

O problema é que quando eu voltar ao meu laptop depois de algumas horas, ele ficará muito lento e pode levar 30 minutos para voltar ao normal. Isso é tão ruim que os monitores de falhas sinalizam seus respectivos aplicativos como congelados (especialmente as janelas do navegador) e as coisas começam a falhar incorretamente.

Olhando no monitor do sistema, dos 2,5 GB usados, cerca de metade é trocado. Confirmei que esse é o problema removendo o espaço de troca ( swapoff /dev/sda8). Se eu deixá-lo sem espaço de troca, ele volta à vida quase instantaneamente, mesmo após 24 horas. Com a troca, é praticamente um tijolo nos primeiros cinco minutos, restando apenas seis horas. Confirmei que o uso de memória nunca excede 3 GB , mesmo quando estou ausente.

Eu tentei reduzir o swappiness ( veja também: Wikipedia ) para valores de 10e 0, mas o problema ainda persiste. Parece que após um dia de inatividade, o kernel acredita que toda a GUI não é mais necessária e a limpa da RAM (troca-a para o disco). A tarefa de longa duração é ler através de uma vasta árvore de arquivos e ler todos os arquivos. Portanto, pode ser que o kernel esteja confuso ao pensar que o cache ajudaria. Mas em uma única varredura de um HD USB de 2 TB com ~ 1 bilhão de nomes de arquivos, uma RAM extra de GB não ajudará muito o desempenho. Este é um laptop barato com um disco rígido lento. Ele simplesmente não pode carregar dados de volta na RAM com rapidez suficiente.

Como posso dizer ao Linux para usar apenas o espaço de troca em uma emergência? Eu não quero correr sem swap. Se algo inesperado acontecer, e o sistema operacional de repente precisar de alguns GBs extras, não quero que as tarefas sejam eliminadas e prefiro começar a usar o swap. Mas no momento, se eu deixar a troca habilitada, meu laptop simplesmente não pode ser usado quando eu precisar.

A definição precisa de uma "emergência" pode ser motivo de debate. Mas para esclarecer o que quero dizer: uma emergência seria onde o sistema fica sem outra opção além de trocar ou matar processos.

O que é uma emergência? - Você realmente tem que perguntar?... Espero que você nunca se encontre em um prédio em chamas!

Não me é possível definir tudo o que possa constituir uma emergência nesta questão. Mas, por exemplo, uma emergência pode ser quando o kernel é tão pressionado pela memória que começa a matar processos com o OOM Killer . Uma emergência NÃO é quando o kernel pensa que pode melhorar o desempenho usando swap.

Edição final: aceitei uma resposta que faz exatamente o que pedi no nível do sistema operacional. Os futuros leitores também devem tomar nota das respostas que oferecem soluções em nível de aplicativo.

Estou tentando entender como os números de inode (como exibidos por ls -i) funcionam com partições ext4.

Estou tentando entender se eles são uma construção do kernel linux e mapeados para inodes no disco, ou se eles realmente são os mesmos números armazenados no disco.

Perguntas:

1. Os números de inode mudam quando um computador é reinicializado?
2. Quando duas partições são montadas, pode ls -iproduzir o mesmo número de inode para dois arquivos diferentes, desde que estejam em partições diferentes.
3. Os números de inode podem ser reciclados sem reinicializar ou remontar partições?

Por que estou perguntando...

Eu quero criar um índice secundário em um disco rígido USB com 1,5 TB de dados e cerca de 20 milhões de arquivos (nomes de arquivos). Os arquivos variam de 10s de bytes a 100s de GB. Muitos deles são vinculados várias vezes, portanto, um único arquivo (blob no disco) pode ter até 200 nomes de arquivo.

Minha tarefa é economizar espaço em disco detectando duplicatas e substituindo a duplicação por links ainda mais rígidos.

Agora, como um único exercício, acho que posso criar um banco de dados de cada arquivo no disco, é shasum, permissões etc... Uma vez construído, detectar duplicação deve ser trivial. Pouco preciso ter certeza de que estou usando a chave exclusiva correta. Os nomes dos arquivos são inadequados devido ao grande número de links físicos existentes. Minha esperança é que eu possa usar números de inode.

O que eu gostaria de entender é se o número do inode mudará ou não na próxima reinicialização da minha máquina. Ou se eles são ainda mais voláteis (eles mudarão enquanto estou construindo meu banco de dados?)

Toda a documentação que li falsifica a distinção entre números de inodes apresentados pelo kernel e inodes no disco. Se são ou não a mesma coisa, não está claro com base nos artigos que já li.

Estou tentando entender os relacionamentos de "sugestões" e "recomendações" entre os pacotes Debian. Eu sei que eles dão aos usuários mais opções sobre o que instalar e o que não instalar.

Mas estou ciente apenas de manualmarcadores autopara indicar o motivo de um pacote ser instalado. Isso não contém informações suficientes para rastrear as decisões do usuário sobre instalar ou não os pacotes sugeridos e recomendados. Não consigo ver na documentação qual comportamento o apt leva (o pacote X recomenda Y e sugere Z) :

apt-get dist-upgradeatualizar X para uma versão mais recente que não recomenda mais Y ou sugere Z.

apt-get dist-upgradeatualizando o X para uma versão mais recente que recomenda e sugere novos pacotes (ainda não instalados).

apt-get autoremoveremovendo o pacote X.

Eu tenho um pequeno número de discos rígidos removíveis. A qualquer momento, um deles será montado, /backupexceto durante a troca de unidades. Eu troco a unidade periodicamente. Ou seja, tenho 4 discos rígidos e os giro.

Atualmente eu monto/desmonto manualmente a unidade. Mas há momentos em que esta máquina é desligada e pior, às vezes ela é desligada sem o meu conhecimento. O script de backup diário falhará se uma unidade não estiver montada.

As unidades atualmente não compartilham um UUID ou rótulo. Não posso garantir que o disco estará sempre disponível em /dev/sdb1. Existe uma boa maneira de montar uma das várias unidades automaticamente de /etc/fstab quando eu simplesmente não sei qual unidade será inserida?

Observe que este é um sistema linux (debian) sem monitor ou teclado. No momento, as unidades são montadas/desmontadas manualmente por ssh depois de conectar/antes de desconectar.