dippynark's questions

Estou vendo os seguintes erros de leitura:

# btrfs device stats /mnt/data
[/dev/sda].write_io_errs    0
[/dev/sda].read_io_errs     0
[/dev/sda].flush_io_errs    0
[/dev/sda].corruption_errs  0
[/dev/sda].generation_errs  0
[/dev/sdd].write_io_errs    0
[/dev/sdd].read_io_errs     53
[/dev/sdd].flush_io_errs    0
[/dev/sdd].corruption_errs  0
[/dev/sdd].generation_errs  0
[/dev/sdc].write_io_errs    0
[/dev/sdc].read_io_errs     0
[/dev/sdc].flush_io_errs    0
[/dev/sdc].corruption_errs  0
[/dev/sdc].generation_errs  0

Quais poderiam ser as implicações disso? Como eles são apenas erros de leitura, isso provavelmente seria apenas uma mudança de bit na RAM que fez com que a soma de verificação não correspondesse, ou isso poderia implicar que os dados persistentes estão corrompidos?

Quais são todas as maneiras pelas quais os perfis do AppArmor podem ser combinados com os processos? Um parece ser baseado em caminho (por exemplo, o /sbin/dhclientperfil é aplicado quando /sbin/dhclienté executado), mas isso é devido a /sbin/dhclientaparecer no sbin.dhclientperfil ou por causa da maneira como sbin.dhclienté nomeado?

Além disso, para correspondência de perfil não baseada em caminho (por exemplo, para o docker-defaultperfil), como o AppArmor é informado a quais processos aplicar o perfil?

Estou tentando entender a diferença entre os diferentes tipos de interfaces (virtuais) (por exemplo, TUN/TAP, veth etc.) e estava estudando alguns desses tipos dentro do contexto de containers.

É possível enviar pacotes entre um contêiner (em seu próprio namespace de rede) para o namespace de rede do host usando apenas interfaces TUN/TAP ou é necessário um par de veth (uma extremidade em cada namespace) para fazer isso?

Do meu entendimento, as interfaces TUN/TAP só podem ser usadas para enviar/receber pacotes de/para o espaço do usuário de/para a pilha de rede correspondente ao espaço de nomes de rede dessa interface e não enviar pacotes entre espaços de nomes de rede. Isso está correto?

Ao ler esta postagem no blog do Kubernetes sobre o gerenciador de CPU da Intel, ele menciona que você pode evitar o tráfego entre soquetes tendo CPUs allocated on the socket near to the bus which connects to an external device.

O que significa tráfego entre soquetes e quais problemas ele pode causar? Esses são meus palpites:

• Uma CPU de um soquete precisa acessar um dispositivo conectado a um barramento que só é acessível a CPUs em outro soquete, portanto, as instruções para esse dispositivo devem ser gravadas na memória para serem executadas por uma CPU nesse outro soquete
• Uma CPU de um soquete precisa acessar um dispositivo conectado a um barramento que só é acessível para CPUs em outro soquete, então as instruções para esse dispositivo são enviadas diretamente para uma CPU neste outro soquete para serem encaminhadas ao dispositivo (não tenho certeza se isso é mesmo possível)

O controlador de recursos de memória para cgroups v1 permite definir limites no uso de memória em um cgroup específico usando o memory.limit_in_bytesarquivo. Qual é o comportamento do kernel do Linux quando esse limite é atingido?

Em particular:

• O OOM do kernel mata o processo e, em caso afirmativo, oom_scoreo processo é levado em consideração ou é o processo que pediu a memória que causou o limite ser atingido que é morto?
• Ou o pedido de memória seria simplesmente rejeitado, caso em que o processo só morreria se não lidasse com tal evento?

Ao ler https://lwn.net/Articles/391222/ e http://man7.org/linux/man-pages/man5/proc.5.html me deparei com os termos oom_scoree maldade. Ambos os números têm o mesmo significado básico; quanto mais altos forem, maior a probabilidade de a tarefa associada ser eliminada por OOM quando o host estiver sob pressão de memória.

Qual é a relação (se houver) entre os dois números?

EDIT: Meu palpite é oom_score= max(badness + oom_score_adj, 0), mas não encontrei nenhuma prova