Espaço deixado no Linux RAM / TMP, FS

Question

Recentemente eu passei a acreditar que várias ocorrências incomuns que aconteceram durante a execução de um Live CD do Parted Magic, são o resultado de ficar sem espaço no sistema de arquivos baseado em RAM, a saber:

• Conteúdo da pasta desaparecendo, apenas para reaparecer mais tarde
• Mount-gtk não mostrando unidade montada única / não permitindo desmontar (embora os comandos bash mount funcionem normalmente)
• Congelamento do Firefox, aparentemente congelando a GUI.
• Minha sessão do Firefox está se recuperando como se o navegador falhasse a cada fechamento limpo
• A perda dos últimos x minutos do histórico da sessão do Firefox
• Redirecionamento de som / área de trabalho não funciona de forma intermitente em rdesktop
• Conky falhando periodicamente

... Não apesar do aviso SpaceFM de nenhum espaço para armazenar dados de estado AND , alguns desses problemas desaparecem apenas após a remoção de alguns arquivos do sistema de arquivos.

Problema sendo, não sei como (pelo menos) ficar de olho no "espaço" restante do sistema de arquivos (Nota: Não há entrada para a partição / na saída de df , fdisk -l ou mount ), e muito menos (supondo que eu esteja certo de que o espaço do sistema de arquivos não está relacionado à memória do sistema, que eu estava monitorando com conky ) como aumentar o dimensionamento no momento da inicialização? / p>

Ajuda?

O PS achou mais apropriado marcar essa pergunta com parted-magic , ramfs (ou tmpfs ... Não sabe como identificar qual delas está em uso) e espaço em disco baixo como tags, mas infelizmente não aparece seja algum deles. Se a comunidade não quiser criar uma / todas, sinta-se à vontade para sugerir outras tags que outras pessoas considerem apropriadas.

    

Answer 1

Por padrão, um ramdisk tmpfs será configurado para usar um máximo de metade da RAM disponível no sistema (note que um kernel padrão, não-PAE, de 32 bits pode endereçar um máximo de 4 GB menos qualquer espaço de endereço usado por dispositivos como placas VGA).

Acabei de iniciar o Parted Magic 2013 08 01 em uma máquina virtual, com 4 GB de RAM. O rootfs tem um total de 2GB, com cerca de 444KB usados, então PM está usando os padrões para tmpfs. Se eu reiniciar a VM com apenas 1GB de RAM, o tmpfs de raiz tem apenas 504MB disponíveis - o kernel usa alguns, de modo que é pouco menos da metade do total de RAM.

Também é montado / tmp e / run como tmpfs do mesmo tamanho. Note que estes sistemas de arquivos não são espaço adicional, eles usam o mesmo conjunto de RAM que o rootfs e quaisquer programas em execução (isto é, um pouco menos de 1GB em um sistema com 1GB de RAM).

(BTW, df não seria executado até que eu excluísse o / etc / mtab e o substituísse por um link simbólico para / proc / mounts).

O importante é lembrar que o tmpfs e quaisquer programas em execução compartilham a mesma memória do sistema - portanto, se você preencher o tmpfs, ele reduzirá a quantidade de RAM disponível para a execução de programas, e se você executar programas que usam muitos RAM, isso reduzirá a quantidade de RAM disponível para tmpfs.

Você parece estar fazendo as duas coisas. Você está preenchendo o disco com seus arquivos de log, AND você está executando o firefox, X e rdesktop - e todos eles tendem a usar grandes quantidades de RAM. Sistemas Unix não reagem bem quando o rootfs fica cheio, e quando a RAM começa a ficar apertada, a tarefa de falta de memória (OOM) do kernel do Linux começa a matar aleatoriamente os processos para liberar alguma RAM.

Qualquer um desses fatores por si só causará problemas estranhos e imprevisíveis. Ambos juntos apenas tornam os problemas inevitáveis.

Como outros sugeriram, eu recomendo strongmente que você não use um Live CD (Parted Magic ou qualquer outro) dessa maneira. Eles não são projetados para isso, e o que você está fazendo é praticamente garantido para causar problemas. Em suma, Don't Do That, Then! .

Em vez disso, re-particione seu disco rígido e instale uma distro pequena nele, execute uma distro linux em uma VM, ou encontre uma distro que instale e execute um pendrive sem usar tmpfs para / root - isto é, usa o USB stick como seu sistema de arquivos raiz (isso seria muito mais lento do que rodar a partir de um tmpfs. E não, eu não conheço nenhum que funcione assim). ou use um disco rígido USB em vez de um disco flash USB.

BTW, Quanta memória RAM você tem em seu sistema e qual versão do Parted Magic você está rodando?

    

Answer 2

Parted mostra a memória disponível em seu pequeno display "heads up" (aparentemente chamado conky ) no canto superior direito. Então você nem precisa descobrir como obter essa informação, ela já é exibida. (Como a memória disponível IS é o espaço livre em disco).

Ouvocêpodeestarficandosemblocosouinodes,vocêpodesercapazdeinferirestainformaçãoviastat:

#stat-f/File:"/"
   ID: 0        Namelen: 242    Type: aufs
Block Size: 4096     Fundamental block size: 4096
Blocks: Total: 129061   Free: 127337    Available: 127337
Inodes: Total: 129061   Free: 128101

    

Answer 3

Como eu e outros já dissemos nos comentários, você não deve usar o Parted Magic como uma distribuição normal, ele não foi projetado para isso e está fadado a ter problemas.

De qualquer forma, para verificar o espaço disponível, você pode executar df . Eu não quero comprar uma cópia do Parted Magic OS para testar isso, mas o seguinte é a saída de df em uma máquina virtual executando um Live CD do Ubuntu:

A maioria destas são coisas do estilo tmpfs (não são partições montadas reais de qualquer maneira) que existem na RAM. df ainda pode relatar com precisão o uso. Se você não vir uma entrada / em Parted magic, acho que eles estão usando algum tipo de nomenclatura esotérica. Outra sugestão de que você está usando a ferramenta errada para o trabalho.

    

Answer 4

Eu me deparo com esse problema há anos em distribuições live CD / DVD / USB como Debian, Ubuntu, Mint, talvez até mesmo o Fedora, se bem me lembro. A memória usada pelo overlayfs (o fstype atualmente usado para o Mint / Ubuntu) e tmpfs estão escondidos na memória em cache do free (e entradas inativas do / proc / meminfo), junto com caches de leitura de disco temporários, portanto não está claro quanta memória é realmente "livre".

Estou usando df para adicionar todo o espaço usado por overlayfs & tmpfs e subtraindo-o das informações livres + buffers + em cache de free . Eu vou ter o conky para destacar esse número ao lado dele é enganoso "free ram". Todos os tamanhos estão em K's.

Se a versão ao vivo da sua distribuição não suportar df , então não sei onde procurar informações no overlayfs / tmpfs. mount, / proc / mounts e / etc / mtab parecem apenas mostrar o máximo ou nenhum tamanho, não o tamanho atual como df .

Primeiro, para o espaço usado por overlayfs & tmpfs,

overlayfsused=$( df -t overlayfs --total |tail -n 1|tr -s [:space:]|cut -d " " -f 3 )
tmpfsused=$( df -t tmpfs --total|tail -n 1|tr -s [:space:]|cut -d " " -f 3 )
diskused=$(( overlayfsused + tmpfsused ))

FYI, df's -t mostra apenas que tipo de fs (poderia colocar ambos em um df), cauda apenas dá a última linha total, tr comprime espaço em branco para um único espaço por isso é mais fácil para cortar o campo direito para fora.

E para o RAM livre, você pode analisar a saída de free (provavelmente mais fácil) ou ler a partir de / proc / meminfo (eu já tentei digitado desta forma):

free=$(grep MemFree < /proc/meminfo |tr -s [:space:]|cut -d " " -f 2)
buffers=$(grep Buffers < /proc/meminfo |tr -s [:space:]|cut -d " " -f 2)
cached=$(grep "^Cached" < /proc/meminfo |tr -s [:space:]|cut -d " " -f 2)

Em seguida, coloque tudo junto, digamos, para uma boa saída de script que conky pode executar ou execi a cada minuto ou dois:

realfree=$(( free + buffers + cached - diskused ))
echo "$(( realfree / 1024 )) MiB"

Eu até consideraria um if-realfree < 100M, em seguida, exibir mensagem de aviso, arquivos del temp, alerta de som vermelho, etc ...

Quanto ao uso de uma distro ao vivo para uso diário, o objetivo do Ubuntu (e de muitas outras) versões ao vivo é experimentar uma distro para uso diário regular por algumas horas e ver se você gosta dela. E muitos bancos on-line e artigos de segurança recomendam especificamente o uso de uma distro ao vivo para serviços bancários on-line seguros e afins. O fato de as distribuições ao vivo não perceberem quando elas realmente ficam sem memória RAM é um erro da IMO. Consegui travar um Mint ao vivo apenas copiando arquivos grandes para $ HOME e / tmp, já que ambos usam RAM e ambos têm um tamanho máximo de 1/2 ram. FYI Atualmente o Mint tem possivelmente metade do ram usado por cada um dos / (overlayfs), / dev (devtmpfs - apenas 4k usados, então estou assumindo que é normalmente pequeno), / tmp, / run / shm