"Claudio Polegato Junior" <[EMAIL PROTECTED]> writes: > Isso s�o estimativas de alguns sites, os quais dizem que se seu sistema de > arquivos estiver confinado a uma "pequena" parti��o, em alguns anos (ou at� > em um > ano, dependendo o caso), o processo que detalhei procede.
Isso � extremamente dependente do sistema de arquivos usado. S�rio mesmo. Mas, parti��es min�sculas -- onde o tamanho dos arquivo pode ter um percentual significativo da parti��o -- t�m mais problemas que parti��es maiores, com certeza. Um exemplo de parti��o problem�tica � um /boot de 25 MB. Cada vers�o de kernel atual instalada ocupa uns 300 KB de initrd, mais uns 1,5 MB de "vmlinuz", mais 1 MB de System.map... S�o quase 3 MB -- mais de 10% da parti��o -- por instala��o / remo��o de kernel. Eu tenho uma situa��o destas aqui :-) Em 5 anos de updates di�rios, passando por praticamente todas as vers�es de kernel de desenvolvimento desde o CL 6, a parti��o est� com 14% de fragmenta��o. Veja que � um caso extremo e uma parti��o min�scula. Perceba, tamb�m, que � coincidente com a remo��o de uma vers�o de kernel (3 MB s�o ~ 12% de 25 MB). Creio que na pr�xima vers�o que instalar, este espa�o vai ser realocado e a fragmenta��o diminu�da. > Por�m, mergulhando em terabytes, presup�es que use-se lvm e/ou raid para > tanto e Infelizmente o LVM no Linux est� limitado a 255 GB. Uma pena... > quanto mais espa�o for necess�rio n�o ser� por desfragmenta��o que vir� a > solu��o, principalmente devido aos pontos que levantou. Nem mesmo no caso dos 14% citados acima este espa�o vem dela. Sistemas como ReiserFS com tamanhos de bloco vari�veis reduzem muito este tipo de problema. Nesses anos todos de Linux, o exemplo que dei acima � a maior fragmenta��o que j� vi -- antes dele a maior era de 5% -- e a causa � bem "adivinh�vel" neste caso :-) O gerenciamento que temos � muito mais eficiente. Por outro lado, em termos de desempenho, faz uma enorme diferen�a ter as entradas de diret�rios pr�ximas ao centro do disco -- come�o do disco -- e ter as parti��es mais usadas por ali. Isso tem explica��es mec�nicas para trazer vantagens, al�m de ter explica��es do projeto dos sistemas de arquivos e de onde guardam informa��es :-) Quanto mais pr�ximos, menor o tempo de busca das informa��es e se as informa��es mais acessadas est�o todas pr�ximas, tem-se um ganho que pode ser significativo numa carga elevada. :-) -- Godoy. <[EMAIL PROTECTED]> --------------------------------------------------------------------------- Esta lista � patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br Regras de utiliza��o da lista: http://linux-br.conectiva.com.br FAQ: http://www.zago.eti.br/menu.html
