"Cl�udio Sampaio (Patola)" wrote: > > Em Qui, 2001-11-15 �s 14:50, Lisias Toledo escreveu:
> Al�m do mais, /usr n�o � necessariamente read-only. Voc� pretende fazer > updates, nem que seja um update de seguran�a? Bem, vai ter que mexer no > /usr. Remount, u�... Vc remonta a /usr como rw, faz as updates, e depois a joga para ro de novo. Menos uma parti��o pra dar erro l�gico. > O esquema de parti��es �, na verdade, uma id�ia dos anos 70, muito > antiga. Hoje eu j� acho que n�o faz mais tanto sentido. Hummm... Tbm sou dos anos 70... Ser� ent�o por isto que o que eu digo n�o faz mais tanto sentido tamb�m??????? 8-P 8-P 8-P 8-P > Quando algo de > um disco r�gido � perdido, raramente voc� perde somente uma parti��o, o > disco todo vai pro saco. Ent�o colocar todo o computador com um �nico > filesystem root que seja todo o disco r�gido n�o � algo ruim, em minha > opini�o. Ali�s, � o que eu fa�o na minha m�quina caseira. Agora � s� opini�o (e experi�ncia). Eu uso e abuso das parti��es. Se n�o for por outro motivo, agiliza os backups. O problema de se jogar tudo numa parti��ozona s� � que vc joga todo mundo no mesmo barco : dados fixos passam a atrapalhar a vida dos transientes, e o FS tem mais trabalho para evitar fragmenta��o. Por isto n�o misturo os dados tempor�rios (/tmp e /usr/tmp) com os dados pessoais (/home). Que por sinal, n�o s�o misturados com o /usr (que praticamente nunca muda) nem com o root (diminui a possibilidade do sistema ficar "imboot�vel"). Quanto aos HDs, b�o... J� vi muito HD ter morte r�pida, mas j� vi muito ter morte lenta, com os setores estragando aos poucos. Por sinal, tenho um justamente com este problema. Criar v�rias parti��es com prop�sitos definidos ajuda na hora de recuperar os dados. Eu sinto isto na pele, vc n�o perde tempo recuperando bin�rios, por exemplo. > Se for pra usar o paradigma de volumes diferentes para cada filesystem, > que se use ent�o de vez o LVM para se ter flexibilidade com as > 'parti��es' (na verdade logical volumes), que voc� vai poder fazer > crescer e diminuir � revelia - e obviamente n�o faz muito sentido usar > LVM sem colocar journaled filesystems! � o que eu fa�o na minha m�quina > do trabalho. LVM � bacana, mas no meu caso eu ainda acho que um planejamento mais cuidadoso da instala��o tende a ser mais proveitoso. Eu ainda n�o vi um /usr precisar de mais de 1.2 giga. Logo, este � o tamanho padr�o das minhas /usr (que s�o r/o). Ok, temos as /opt e as /usr/local. Mas estas possuem a sua pr�pria parti��o (e s�o r/w - eu vivo instalando porcaria nelas). /opt � link simb�lico para /usr/local, diga-se de passagem. O /usr/src nem te digo que possui sua pr�pria parti��o tbm. Compilar programas (em especial o kernel) gera milhares de arquivos tempor�rios. Pra qu� complicar a vida do FileSystem? Joga este calhama�o de lixo bin�rio numa parti��o s�. Se a compila��o for um sucesso, eu vou apagar tudo mesmo. Por fim, quando a este novo paradigma sobre FS Banco de Dados, eles devem sofrer os mesmos gargalos que estudei quando paguei a cadeira de Banco de Dados... Quanto mais dados uma tabela possuir, mais mem�ria para controlar a aloca��o, mais processamento para evitar fragmenta��o, maior a necessidade de redund�ncia para evitar gargaloos de peformance (e mais trabalho para manter a consist�ncia) e maior a dor de cabe�a para evitar corrup��o dos dados. Pelo menos aparentemente, acredito que todo este overhead n�o valha a pena para algumas classes de dados. -- []s, Pink. Assinantes em 16/11/2001: 2376 Mensagens recebidas desde 07/01/1999: 141851 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
