Discussões técnicas de alto nível, isso eu adoro também, além de idéias legais, isso é legal, mas tem uns perhaps.
O que vocês acham de uma configuração de sistema com as seguintes especificações:
1. Os arquivos do Sistema Operacional (/ - root) ficariam armazenados num Solid State Drive (ex.: um Samsung PQI Turbo Industrial IFD Flash Disk SATA de 4 GB - US$ 499.00)
Seria interessante realmente, como em um live-CD, e não precisaria de aferição ou atestação de integridade se fosse um SSD ( Solid State Disk ) com bloqueio de escrita por chaveamento, assim teríamos um sistema inviolável á vírus e rootkits. Mesmo assim teríamos que desviar todos os procedimentos como em um live CD para que os logs fossem guardados em algum lugar. Os SSDs são mais rápidos, porém , sua vida útil é ainda rudimentar se comparado aos HDDs, e no Windows Vista eles são utilizados para acelerar e ao mesmo tempo evitar excessivos seeks de inicialização, o que faz com que os HDDs sejam menos passíveis de erros de seek e possíveis quebras por choque gravitacional nas cabeças. Ler SSDs é melhor do que os gravar, e sinceramente eu realmente prefiro que discos holográficos ou cubos laser sejam utilizados para esta tarefa e que sejam somente legíveis, assim teríamos risco zero se obtivermos o controle sobre essas gravações, não teríamos mais preocupações com segurança praticamente.
2. Quando da inicialização do sistema, os arquivos do sistema operacional seriam jogados para a memória RAM, como num LiveCD. A configuração da memória RAM tiraria proveito da arquitetura Dual Channel, onde poderiam até mesmo ser criados dois drivers virtuais (ramdisks) para operar na arquitetura dual channel como Raid 0 (o objetivo é sugar o máximo de desempenho possível). Com isso abrir os arquivos seria bem rápido, mas gravar não... Sendo que a edição se dá toda na memória RAM, esse seria um problema menor.
Técnicamente isso seria redundância, e além disso, o problema de limite de bandagem da memória poderia até ser aumentado para que diversos " Cache Flushes " fossem feitos por um ou mais processadores. Não adianta passar dois parafusos iguais pela mesma rosca, e a arquitetura dual channel já resolveria grande parte do problema. Ainda assim temos um limite imposto pelo FSB e Ponte Norte ( no caso de Intel com core duo de 1066 Mhz ) ou no caso do AMD com direct connect ( arquitetura de controladora de RAM incorporada ), isso significa que se um processador tem sua velocidade de cache interno de 22.000 Mbits por segundo, teríamos de ter memórias e controladores de memória que tivessem ou um alto FSB para cortar os wait states ou um chipset com cache e Quad Channel ( A intel já fez isso ), e frequências de operação de 1/4 ou 1/3. ( O máxinmo alcançado por GDDR4 é 900 Mhz Real ou 1800 GDDR4 por que são enviados dois sinais de clock por ciclo de frequencia ) . Só assim teríamos uma bandagem maior, e mesmo assim esse seria o limite, com ou sem raid de RAMdisks.
A única memoria capaz hoje de cortar os wait states são a XDR ( Fabricada pela Rambus ) , GDDR 4 ( caríssima ) ou Mcache ( a mesma dos processadores ), mesmo assim teríamos de rotear isso tudo, o que causaria gargalo e wait states novamente. Não há uma solução mais adequada para a questão das memórias, então mesmo que façamos os raids com os Ramdisks, bateríamos de frente com o limite do subsistema de memória, que é o limite de velocidade com raid ou não. A intel está tentando resolver este problema embutindo controladores de memória nas próprias memórias do tipo FB e serializando a comunicação.
3. Os arquivos /home ficariam armazenados num segundo drive SSD, para minimizar o gargalo quando fossem acessados ou modificados (afinal não adianta deixar os programas numa mídia ultra-rápida e os arquivos que seriam trabalhados com esses programas numa mídia ultra-lenta).
Isso seria um grande problema a menos que sua máquina fosse somente para testes, no dia a dia, nossa pasta /home está sempre ou com MP3, ou com vídeos ou com fotos. O que inviabilizaria SSD para o caso. O mais recomendado seria utilizar o que você disse primeiro para /root e /boot e usar HDs reais para guardar documentos, e desde que o Linux tem um sistema de cache excepcional, basta aumentar o cache de disco para certas tarefas como Mp3 para que isso fosse para direto e inteiro na memória, evitando a leitura do HDD de maneira assíncrona.
4. Os arquivos /var ficariam em discos-rígidos normais por razões de economia.
Esse seria o caso de um bom Ramdisk, principalmente no Ubuntu que tem uma pasta temp para um montão de coisas dentro da /var.
5. A quantidade de memória RAM necessária poderia ser entre 2x1GB (US$ 239.00) e 2x2GB (US$ 499.00), dependendo do quão enxuto seria o sistema desejado pelo usuário.
Do jeito que andamos ( os usuários avançados que não estão nem aí para a máquina e só querem que ela seja rápida e estável para trabalhar e não se preocupar com manutenção ... ) a segunda opção seria básica...
6. Quando as configurações do sistema ou o mesmo fosse atualizado, seria necessário que houvesse um script que permitisse a atualização dos seus arquivos no SSD, para que tais modificações não fossem perdidas no caso de uma reinicialização do sistema.
Command journaling with journaling of metadata + page binding , estou esperando isso faz tempo, apesar de tornar o sistema mais lento, as únicas empresas que ainda estão interessadas em desenvolver isso são a sun e a IBM, nunca mais perderíamos um bit sequer se esse sistema estivesse pronto.
7. Não faria sentido criar uma memória swap nessa configuração, a não ser no caso de se ter certeza de que ela viria a ser necessária, quando então ela poderia ser criada num drive SSD (degradando enormemente a performance do sistema) ou, com o devido investimento, na própria memória RAM (que teria que ser de um tamanho considerável).
Nesse caso com tudo sendo cacheado, os refluxos provocariam a liberação forçada de áreas de memória não paginadas, o sistema poderia ficar instável ou ter comportamentos estranhos como fechamento do konqueror quando da visualização de thumbnails de uma pasta grande de fotos, mas no linux ele avisa que não aguenta mais mesmo
e se recusa a abrir mais software fornecendo "calloc e malloc returns nill" e graças a Deus ainda dá para debugar. tente fazer no windows
ele fecha tudo e vc nem sabe o que foi que aconteceu
....
........
Tudo bem que não é exatamente um sistema barato, mas acho que é o mais rápido que se pode construir com as peças disponíveis comercialmente.
E o engraçado é que poderia ser mais barato do que alguns computadores topo de linha de marcas famosas.
Ideal para isso sem SWAP seria assim:
SSD para dar partida com /boot e /root( 8 ou 16GB ) com opção de bloqueio de escrita
/Home em HDD ( o tamanho que você quiser )
/Var precacheada e assíncrona com disco rígido por agendamento ( assím não perderíamos os Logs e eles seriam escritos em idle )
6 GB a 8GB de memória ECC registrada, sem nenhuma SWAP.
O sistema que você propõe chama-se entre os técnicos de Sky Rocket, normalmente se usa Sky Rocket para Cluster, o Dynebolic faz isso muito bem e ainda monta sua memória em NumaLink...
Mas vamos continuar, quem sabe alguma nova idéia não surge ? Por que não ?
Tópico: Ultradesempenho (suposições aqui) (Lida 2917 vezes)