Do tmpfs e devtmpfs compartilham a mesma região de memória?

Question

O uso do meu disco do sistema é assim:

# df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   50G   39G   12G  77% /
devtmpfs               5.8G     0  5.8G   0% /dev
tmpfs                  5.8G  240K  5.8G   1% /dev/shm
tmpfs                  5.8G   50M  5.8G   1% /run
tmpfs                  5.8G     0  5.8G   0% /sys/fs/cgroup
/dev/mapper/rhel-home  1.3T  5.4G  1.3T   1% /home
/dev/sda2              497M  212M  285M  43% /boot
/dev/sda1              200M  9.5M  191M   5% /boot/efi
tmpfs                  1.2G   16K  1.2G   1% /run/user/1200
tmpfs                  1.2G   16K  1.2G   1% /run/user/1000
tmpfs                  1.2G     0  1.2G   0% /run/user/0

Eu tenho 2 de perguntas sobre devtmpfs e tmpfs :
(1)

devtmpfs               5.8G     0  5.8G   0% /dev
tmpfs                  5.8G  240K  5.8G   1% /dev/shm
tmpfs                  5.8G   50M  5.8G   1% /run
tmpfs                  5.8G     0  5.8G   0% /sys/fs/cgroup

Todos os espaços acima são 5.8G , eles compartilham o mesmo espaço de memória?

(2)

tmpfs                  1.2G   16K  1.2G   1% /run/user/1200
tmpfs                  1.2G   16K  1.2G   1% /run/user/1000
tmpfs                  1.2G     0  1.2G   0% /run/user/0

Cada usuário tem seu espaço de memória dedicado, não espaço compartilhado na partição /run/user ?

    

Answer 1

Para todas as montagens tmpfs, "Avail" é um limite artificial. O tamanho padrão para montagens tmpfs é metade da sua RAM. Pode ser ajustado no momento da montagem. ( man mount , vá até tmpfs ).

As montagens não compartilham o mesmo espaço, pois se você preenchesse a /dev/shm mount, /dev não mostraria mais "Used", e isso não necessariamente impediria você de gravar dados em /dev

(Alguém poderia inventar tmpfs montagens que compartilham espaço por bind-montagem de um único tmpfs. Mas não é assim que qualquer uma dessas montagens é configurada por padrão).

Eles compartilham o mesmo espaço, em que ambos são apoiados pela memória do sistema. Se você tentou preencher os dois /dev/shm e /dev , você estaria alocando espaço igual à sua RAM física. Supondo que você tenha espaço de troca, isso é totalmente possível. No entanto, geralmente não é uma boa ideia e terminaria mal.

Isso não se encaixa bem na idéia de ter várias montagens tmpfs acessíveis pelo usuário. Ou seja /dev/shm + /tmp em muitos sistemas. É indiscutivelmente que seria melhor se as duas grandes montagens compartilhassem o mesmo espaço. (O Posix SHM é literalmente uma interface para abrir arquivos em um tmpfs acessível pelo usuário).

/dev/ , /run , /sys/fs/cgroups são diretórios do sistema. Eles devem ser pequenos, não usados para dados consideráveis e, portanto, não causar problemas. Debian (8) parece ser um pouco melhor em estabelecer limites para eles; em um sistema de 500MB, vejo-os limitados a 10, 100, 250 MB e outros 5 para /run/lock , respectivamente.

/run tem cerca de 2MB usados nos meus sistemas. O systemd-journal é uma parte substancial dele e, por padrão, pode aumentar para 10% de "Avail". ( RuntimeMaxUse option), que não se encaixa no meu modelo.

Eu apostaria que é por isso que você tem 50MB lá. Permitindo o equivalente a 5% de RAM física para arquivos de log ... pessoalmente não é um grande problema em si, mas não é bonito e eu chamaria isso de erro / supervisão. Seria melhor se um limite fosse definido na mesma ordem daquela marca de 2MB.

No momento, sugere-se que o tamanho para /run seja definido manualmente para cada sistema, se você quiser evitar a morte em mil inchaços. Mesmo 2% (do meu exemplo Debian) parece presunçoso.

    

Answer 2

Cada instância de tmpfs é independente, portanto, é possível sobrecarregar a memória e, se você preencher toda a memória com arquivos grandes em tmpfs , o sistema eventualmente parará devido à falta de memória disponível e não será possível liberar nenhuma. (sem excluir tmpfs arquivos ou um montante).

tmpfs pode usar partições de swap para trocar dados, mas mesmo isso não ajuda se você estiver lendo / gravando esses arquivos ativamente, ponto no qual tem que ser trocado de volta.

Basicamente, os sistemas que possuem muitas instâncias de tmpfs montados, geralmente operam sob a suposição de que, embora tmpfs esteja lá, ele não será realmente preenchido até o limite.

Se você quiser tentar isso - de preferência em um Live CD com nada montado - então funciona assim:

mkdir a b c
mount -t tmpfs tmpfs a
mount -t tmpfs tmpfs b
mount -t tmpfs tmpfs c
truncate -s 1T a/a b/b c/c
shred -v -n 1 a/a b/b c/c

Isso cria três instâncias de tmpfs , por padrão, cada uma tem um limite de memória de 50%, portanto, é de 150% no total (sem contar swap, se você tiver swap, sinta-se à vontade para adicionar d e f ... ).

A saída de shred será algo assim:

shred: a/a: pass 1/1 (random)...
shred: a/a: error writing at offset 1049104384: No space left on device
shred: b/b: pass 1/1 (random)...
# system hangs indefinitely at this point, without swap it never reaches c/c #

    

Answer 3

(1) Todos os sistemas de arquivos baseados em tmpfs compartilham a memória virtual disponível no SO como back-end. devtmpfs usa o mesmo espaço, mas ao contrário do primeiro, não contém dados, portanto não deve crescer.

Os subdiretórios

(2) /run/users são criados pelo systemd como diretórios pessoais, transcendentes /tmp . Eles também compartilham o mesmo espaço de memória virtual com todos os outros sistemas de arquivos baseados em tmpfs . O fato de parecerem menores é devido a um limite estabelecido para impedir que um único usuário afete todos os outros usuários, preenchendo esse diretório.