Is it possible that having only 16MB of /tmp available could cause trouble for some software?
Sim, se algum software quiser gravar em /tmp e ele ou outro software já tiver preenchido a partição. Geralmente isso indicaria uma configuração deficiente do sistema, uma limitação legítima dos recursos disponíveis ou um mau comportamento por parte de algum outro software - em qualquer caso, é muito improvável que o software que está procurando escrever tente encontrar uma solução em si. e vai lançar um erro.
Alguns softwares assumem que podem gravar arquivos grandes em /tmp , o que, para ser justo, é uma suposição justa. Esta questão seria abrangida pela "má configuração" guarda-chuva de erros.
A primeira pergunta que você deve se fazer é: "Quais benefícios existem para mim no uso de RAM para /tmp ?" O benefício mais óbvio potencial é que acessar a RAM é muito mais rápido do que acessar um disco. No entanto, é improvável que esse benefício potencial aparentemente óbvio seja tão benéfico na realidade, porque:
-
O sistema armazena em cache os arquivos acessados com freqüência na RAM de qualquer maneira. Reduzindo a quantidade de RAM disponível para esse cache para que você possa colocar
/tmp, é um pouco estúpido, já que significa que os arquivos usados raramente em/tmpterão suplantado os arquivos usados com frequência no cache. -
As aplicações já estão livres para armazenar coisas na RAM, o que geralmente é mais fácil do que armazená-las em um arquivo, então se elas colocam algo em um arquivo tmp, é muito improvável que seja algo que se beneficiaria de ser na RAM. Se você olhar o que realmente está no seu
/tmp, provavelmente são principalmente soquetes e fifos ou pequenos bits de dados do IPC. Acessá-los através de um sistema de arquivos baseado em RAM é meio que conceitualmente mais ordenado, mas duvido que faça alguma diferença real.
Sendo esse o caso, por que /tmp seria implementado na RAM?
-
Ele simplifica a implementação de uma propriedade preferencial de
/tmp, ou seja, que é apagada no encerramento. -
Pode reduzir um pouco o desgaste do hardware. Isso é muito mais significativo em contextos que têm apenas flash vitalício limitado e limitado para armazenamento ou nenhum armazenamento gravável (por exemplo, sistemas incorporados).
-
Presumir que
/tmpnão está sendo abusado, usar RAM explora a capacidade de memória geralmente enorme do hardware moderno - isto é, esse material pode estar na RAM, presumindo que seja o tipo de coisa que deveria ser .
16 MB poderia ser suficiente, mas ainda não é muito assim se algum processo der errado - e /tmp deve ser gravável por qualquer pessoa. No entanto, se algum processo der errado escrevendo coisas para /tmp , será melhor se ele eventualmente preencher um disco rígido ou acenar com mais rapidez porque esgotou uma partição RAM?
Se você tem confiança no software que você está usando, o último faz mais sentido, então você poderia ir para a partição RAM. Você deve examinar um pouco seu uso real de /tmp primeiro, caso algo incomum esteja acontecendo (por exemplo, du -h /tmp ). Você poderia criar um "limite normal" e verificar isso com um cron job para alertar alguém e / ou fazer alguma limpeza de emergência quando for excedido.
Infelizmente, alguns aplicativos podem ocasionalmente despejar coisas em /tmp que não são removidas se falharem repentinamente, e em um servidor - que não é desligado com frequência - que pode ser deixado lá indefinidamente. Isso pode acontecer muito inocentemente, por exemplo, quando alguém faz login e faz uso de algo, a conexão é arbitrariamente fechada ou abandonada.
Portanto, a% não-RAM/tmp é mais segura. O abuso pode passar despercebido por mais tempo, mas apenas porque não é tão significativo quanto seria com a RAM. Além disso, se algo realmente causar um problema, haverá uma arma fumegante no disco indicando a origem do problema.