Leonardo, quem gerencia a memória é o Sistema Operacional, e ele fará a troca de uma app que não está sendo usada naquele momento para que exista memória livre para executar as operações de outra aplicação. Creio que o assunto se desviou, pois estamos falando de servidores, alta disponibilidade e integridade de dados, e o assunto da thread é Swap em desktop. Também acho que empregar o termo "segurança da informação" para a situação que você coloca não é o mais adequado.
Mas independente disso, se uma aplicação mal construida e estiver mal comportada a ponto de impedir o gerenciamento de memória pelo SO, não será o uso de Swap que salvará alguma coisa. Hoje, com sistemas multicamada, dificilmente encontraremos aplicações para servidores que sejam construidas para usar Swap. Se tiver alguma, não vende. Em 30 de abril de 2013 09:14, Leonardo Carneiro <chesterma...@gmail.com> escreveu: > Oi China, tb não sou especialista em S.I. Sou apenas um entusiasta =) > > Nem pensei em recuperar informações do swap. Imagino que em um crash, no > boot o S.O. iria desconsiderar quaisquer informações que estivesse em swap e > iria sobrescrever sem se atentar a nada. > > Como disseram, se um servidor está usando swap, é fato que algo não está > funcionando tão bem quanto deveria estar. Mas o fato de estar usando swap > mostra que o sistema ainda está funcionando, e dá uma chance ao admin de > tentar intervir de uma maneira controlada. Sem o swap, a aplicação (e não o > S.O.), iria travar e o admin só iria poder intervir quando o problema já > tivesse acontecido. > > Entendo que o admin deva sempre provisionar memória suficiente para as > aplicações de um servidor, monitorando o uso de memória e que o swap nunca > deva ser usado, mas penso que o swap deva ser uma última linha de defesa: > caso ocorra alguma coisa extraordinária que faça a aplicação usar mais > memória do que o esperado, o swap vai estar lá para garantir que a aplicação > consiga ser computada. > > O que penso de swap como fator de S.I. é: o swap é uma última linha de > defesa para garantir que determinado programa consiga ser computado, em caso > de consumo extraordinário de memória. Caso o programa não consiga ser > computado, ou seja parcialmente computado, estão sendo feridas as > propriedades de integridade e disponibilidade. > > Reforço, quando digo sobre integridade e disponibilidade, não estou me > referindo sobre integridade de blocos, arquivos, filesystems, RAID ou > quaisquer questões técnicas nesse sentido, mas sim que a saída de um > determinado programa esteja íntegra e disponível para o usuário. > Exemplo: o relatório não pode não ser gerado, ou ser gerado pela metade. > > > 2013/4/30 China <china.lis...@gmail.com> >> >> Leonardo, não sou especialista em SI mas estudei o tema quando fiz uma >> pós. Você não está confundindo o papel da Swap com o papel de temp_db >> em SGBDs? Os dados que vão pra Swap não ficam gravados a ponto de >> serem recuperados em caso de crash, portanto Swap não pode ser >> considerada como fator de segurança da informação sob nenhum aspecto. >> Se você tem alguma literatura sobre isso, poderia nos indicar... >> >> Em 29 de abril de 2013 17:06, Leonardo Carneiro >> <chesterma...@gmail.com> escreveu: >> > >> > 2013/4/29 P. J. <pjotam...@gmail.com> >> > >> >> Em 29/04/13, Leonardo Carneiro<chesterma...@gmail.com> escreveu: >> >> >> >> > O fato é que ter o swap é uma questão de segurança de informação. >> >> >> >> Segurança da informação, não vi nda disso no livro de Stalling?! >> > >> > >> > Nunca nem vai ver. Segurança de informação (diferente de segurança de >> > redes) >> > é um tema muito mais conceitual e arquitetônico do que técnico. O tema >> > SI >> > transcende praticamente todas as áreas da computação e geralmente tem >> > livros >> > dedicados. os artigos da wikipedia mesmo, sobre SI são mto elucidativos >> > e >> > servem de trampolim pra algo mais profundo. >> >> >> >> -- >> @chinabhz > > -- @chinabhz -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKE1zwp-jweXSk-NOHCUvqLH1dnwV=cj07uv4kqykoxaobn...@mail.gmail.com
