Edgard Lemos wrote:
>
> Em Monday 27 August 2001 22:10, Lisias Toledo escreveu:
>
> > Como testar as mem�rias ou verificar se o HD est� em condi��es de
> > funcionamento...
>
> Voc� n�o leu o artigo que eu postei, n�o �?
Li sim... >8-)
> http://www.gensw.com/pages/news/quikboot.htm
>
> Vou quebrar seu galho: a mem�ria � verificada por amostragem.
Ou seja, n�o � testada. O tipo mais comum de falha em mem�ria � quando um bit
� alterado arbitrariamente quando seu vizinho � setado. Mesmo um teste
seq�encial superficial � insuficiente, mas j� � bem mais que este tal teste de
amostragem...
L�gico, se os PC ainda inclu�ssem o bit de paridade nos pentes de mem�ria como
nos antigos XTs e ATs, esta abordagem n�o seria perigosa...
> Minha placa-m�e ASUS P5S-B faz isso. Ela conta 128MB em menos de 1
> segundo.
Ela apenas faz isto. Conta a mem�ria.
> "They accomplished this quick boot time by disabling standard Embedded
> BIOS configurable features. The adaptation included disabling memory
> count-up, banners, and various POST status messages; using the "quick"
> memory test, which scans only the first word of each 1KB unit of memory
> during the memory test; and disabling floppy and hard disk seeks during
> POST."
Desabilitar o seek do floppy eu j� fa�o � anos. Desabilitar o seek do HD n�o �
signigicativo, minha placa PC-CHIPS leva menos de 1/2 de segundo para dar o
seek nos 3 HDs que tenho aqui. O que demora � o spinup do harddisk, que se n�o
for feito durante o POST, ter� que ser feito quando o drive for acessado pela
primeira vez, e vai demorar do mesmo jeito - com a agravante de que talvez o
loader do sistema operacional n�o esteja preparado para esperar o 1/2 segundo
do spinup e conclua que o hardisk n�o exista ou esteja pifado.
Desabilitar o POST messages significa que vc n�o sabe se alguma coisa t�
desconectada ou pifada at� que ela seja necess�ria, provavelmente durante o
boot do sistema operacional ou, pior, duranta a montagem dos volumes. Neste
�ltimo caso, provavelmente o pr�ximo boot completo vai incluir um fsck
completo em todos os volumes... Bad move...
Isto pra n�o falar dos avisos do SMART... Receber uma msg do kernel avisando
que o HD est� pra pifar depois de todos os servi�os estarem no ar e recebendo
pedidos n�o me parece muito esperto... 8-)
Mas esta �ltima � especula��o, estou assumindo que as mensagens SMART est�o
entre as msgs POST desabilitadas, e esta informa��o n�o est� em nenhum lugar
do texto (embora tbm n�o exista nada que me impe�a de especular sobre isto).
> > Gastar 5 segundos num cold boot para ter certeza que seus dados n�o
> > ir�o pro vinagre ap�s o boot n�o me parece m� id�ia. Que se economize
> > tempo no warm boot...
>
> Um monte de gente falou isso no Slashdot.
>
> Peguei uma outra discuss�o em que um cara falou que o AIX demora **15**
> minutos para iniciar a quente.
Pow... A� tbm j� � exagero, n�o?
> Mas acho que boots mais r�pidos s�o uma tend�ncia j� que s�o
> essenciais em aplica��es de alta disponibilidade em que 1 minuto fora
> do ar j� d� muito preju�zo.
Nada substitui uma boa arquiterura de rede bem planejada. Nas aplica��es em
que 1 minuto fora do ar � preju�zo inaceit�vel, profissionais competentes
adicionam um servidor redundante. Mesmo que ele seja mais barato e de
performance inferior, ele ag�enta o tranco enquanto o principal gasta seus 5
ou 10 segundos validando seu hardware essencial.
> "This Embedded BIOS quick-boot operation allows the device to restart
> and resume operations well within three seconds -- the maximum amount
> of downtime allowed per year for a device that must support "seven
> nines" or 99.99999 percent uptime."
Trocar seguran�a por performance � algo aceit�vel para o usu�rio dom�stico.
Para o corporativo, creio que n�o...
Al�m do mais, agilizar o boot para aumentar a disponibilidade anual s� �
significativo em sistemas inst�veis que precisem de reboot o tempo todo
(leia-se Microsoft...heheheheh). Sistemas Linux podem ficar tranquilamente sem
rebootar durante meses (algu�m aqui mesmo nesta lista mencionou um uptime de
104 dias!!!). Mesmo que se considere o Linux ainda muito imaturo para certas
aplica��es, existem os BSDs da vida. Outro dia, brinquei de shell num FreeBSD
nos states com um uptime de 500 dias.
Neste contexto, n�o vejo vantagem, pelo contr�rio, em se abreviar os testes de
power up. Pra que gastar dinheiro (e ainda perder confiabilidade) para ganhar
um punhado de segundos num processo que ocorre uma ou duas vezes por ano (ou
pior, a cada 2 anos...)?
--
[]s,
([EMAIL PROTECTED])
Quote of week: The day Micro$oft makes something that doesn't suck is the day
they start selling vacuum cleaners.
Assinantes em 28/08/2001: 2273
Mensagens recebidas desde 07/01/1999: 129921
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
