Alguns pontos interessantes:
* Existem dois tipos de memórias Flash:
NOR:
** acessíveis como memória RAM, permitem XiP (Execute in Place)
** mais caras
** tempo de leitura rápido, tempo de escrita muito alto
NAND:
** acessíveis serialmente (como um HD)
** trabalha internamente com páginas de 4KB
** mais baratas, tempo de escrita melhor que a NOR
* Primeiros SSDs eram sofríveis. O SSD usado nos primeiros EeePC por exemplo tinham taxa de gravação de apenas 48KB/s (muito baixo)
* Um SSD de segunda geração pode atingir taxas de 250MB/s e 80MB/s (leitura e escrita sequencial respectivamente).
* Após algum tempo de uso, os SSDs apresentam uma perda de desempenho, semelhante apenas em aparência a uma perda de desempenho causada por fragmentação em um HD tradicional, mas com uma causa totalmente diferente (http://www.guiadohardware.net/tutoriais/entendendo-ssd/ssd-novo-velho.html). Em SSDs mais atuais os fabricantes implementaram alguns mecanismos para minimizar o problema.
* A estimativa de vida útil de um SSD não é tão alta quanto boa parte do pessoal é levado a pensar (a velha lenda de que simplesmente por não ter partes móveis a durabilidade seja maior). Na prática as estimativas de vida útil dos SSDs atuais giram em torno de 5 a 10 anos.
* Nos próximos anos há uma tendência para aumentos de capacidades, mas os preços não devem ter uma queda muito significativa. Devido também ao fator custo, SSDs não são vantajosos para armazenamento de grandes volumes de dados, sendo mais vantajoso combinar o uso de SSD para o sistema operacional e HDs para a massa de dados.
* Por diversas questões técnicas, a tecnologia de memória Flash usada nos SSDs não escalará a longo prazo.
* A principal candidata a sucessora da memória Flash é a PCM (Phase-Change Memory), uma tecnologia que estava em estudo na decada de 60/70. Com a evolução da memória RAM e mídias magnéticas essa tecnologia foi deixada de lado, mas está sendo retomada agora pela ameaça de estagnação da memória Flash.

E coincidentemente ontém a noite li um artigo sobre o impacto das taxas de transferência e IOPs mais altos dos SSDs e pontos que precisam melhorar no kernel Linux para conseguir tratar melhor esse tipo de dispositivo de blocos. Segue o link: http://lwn.net/Articles/408428/

IOzone
IOzone é uma ferramenta de benchmark de filesystem. Este benchmark gera e
mede uma variedade de operações com arquivos. É uma ferramenta útil para
uma análise abrangente de performance de diversas condições de uso de
dispositivos de armazenamento de dados.
A seguir temos uma descrição de cada tipo de operação sobre a qual são
executados os testes com o IOzone.

Write
Este teste mede a performance de escrita de um novo arquivo. Quando um
novo arquivo é escrito, não apenas os dados necessitam ser gravados, mas
também informações adicionais sobre onde e como os dados estão
armazenados na mídia. Estas informações adicionais (overhead) são chamadas
de “metadados”, e consistem de informações do diretório, espaço alocado, e
qualquer outra informação necessária ao arquivo que não faz parte dos dados
do arquivo. É normal a performance da escrita inicial ser menor do que a
performance de uma re-escrita, devido ao tratamento dessa informação
adicional (metadados, overhead).

Re-write
Este teste mede a performance de escrita de um arquivo já existente. Nestes
casos o trabalho requerido é menor, pois já existem os metadados do arquivo.
É normal portanto que a performance de re-write seja melhor do que a
performance de escrever um novo arquivo.

Read
Este teste mede a performance de leitura de um arquivo já existente.

Re-read
Este teste mede a performance de leitura de um arquivo que foi lido
recentemente. É normal que esta performance seja melhor que a primeira
leitura, pois o sistema operacional geralmente mantém um cache dos arquivos
e dados lidos recentemente, e este cache pode ser usado para novas
chamadas de leitura (evitando uma re-leitura do disco), aumentando a
performance.

Random Read
Este teste mede a performance de leitura de um arquivo com acessos feitos a
partir de localizações randômicas do arquivo. A performance do sistema sob
este tipo de atividade pode ser influenciada por vários fatores como: tamanho
do cache do sistema operacional, número de discos, latência, entre outras.

Random Write
Este teste mede a performance de escrita de um arquivo com acessos feitos a
localizações randômicas do arquivo. Novamente, a performance do sistema sob
este tipo de atividade pode ser influenciada por vários fatores como: tamanho
do cache do sistema operacional, número de discos, latência, entre outras.

Backwards Read
Este teste mede a performance de leitura de um arquivo de trás para frente.
Pode parecer uma maneira estranha de ler um arquivo, mas existem
aplicativos que fazem isso. Enquanto a maioria dos sistemas operacionais
possuem otimizações para permitir a leitura seqüêncial de um arquivo mais
rapidamente, existem poucos sistemas operacionais que possuam alguma
melhoria para leituras de arquivos de trás para frente.

Record Rewrite
Este teste mede a performance de escrita e re-escrita de um bloco de dados
em particular de um arquivo. Com isso podemos ter comportamentos
interessantes. Se o tamanho do bloco for pequeno o suficiente para caber na
área de cache da CPU então teremos uma performance altíssima. Se o
tamanho for maior que o cache de dados da CPU mas couber no TLB, então
teremos um nível diferente de performance. Se o tamanho do bloco for maior
que o cache de dados da CPU e do TLB mas ainda couber no cache do sistema
operacional então teremos outro nível de performance, e se o tamanho do
bloco for maior que o cache do sistema operacional teremos mais outro nível
diferente de performance.

Strided Read
Este teste mede a performance de leitura de um arquivo com acesso em
passos. Um exemplo possível para explicar melhor este teste: ler com offset
zero 4Kbytes, saltar 200Kbytes, e então ler 4Kbytes, saltar 200Kbytes, e assim
por diante. Uma aplicação típica com esse comportamento é quando temos
estruturas de dados em arquivos e processos de leituras de registros dessas
estruturas. A grande maioria dos sistemas operacionais não detecta este
comportamento nem implementa nenhuma técnica de melhoria de
performance para esse tipo de acesso.

Fwrite
Este teste mede a performance de escrita de um arquivo utilizando a função
fwrite(). Esta é uma rotina de biblioteca que realiza uma operação de escrita
bufferizada, com o buffer no espaço de endereçamento de usuário. Se uma
aplicação está para escrever em transferências de tamanhos pequenos, então
as funcionalidades de buffer e blocked I/O de fwrite() podem melhorar a
performance da aplicação pela redução do número real de system calls
utilizadas e aumentando o tamanho da transferência quando as chamadas ao
sistema operacional são feitas. Como este teste é feito com a escrita de um
arquivo novo, então a carga de escrita dos metadados está inclusa na medição.

Frewrite
Este teste é semelhante ao teste de Fwrite, porém escrevendo em um arquivo
já existente. Com isso não temos a carga adicional de escrita dos metadados,
causando uma melhor performance.

Fread
Este teste mede a performance de leitura de um arquivo usando a função de
biblioteca fread(). Esta é uma rotina de biblioteca que realiza uma operação de
leitura bufferizada e blocked. com o buffer no espaço de endereçamento do
usuário. Se um aplicação está para escrever em transferências de tamanhos
pequenos, então as funcionalidades de buffer e blocked I/O de fread() podem
melhorar a performance da aplicação pela redução do número real de system
calls utilizadas e aumentando o tamanho da transferência quando as chamadas
ao sistema operacional são feitas.

Freread
Este teste é semelhante ao teste de Fread, porém relendo dados do arquivo
que já foram lidos anteriormente. Como esses dados costumam ficar no cache
do sistema operacional, um aumento de performance é obtido.

Hoje (14/7/2011) eu precisei fazer um update desse tipo em um servidor SuperMicro, e inicialmente tentei uma dica passada pelo suporte da própria SuperMicro:

http://www.softpedia.com/get/System/Boot-Manager-Disk/BootFlashDOS.shtml

Testei com esse programa, usando uma máquina com Windows XP.
Porém, ao testar o boot via pendrive, não funcionou.

Pesquisei no google, e encontrei esse link:
http://www.adrenaline.com.br/forum/area-windows/181133-criando-um-pendrive-bootavel-do-ms.html

Através dele, baixei dois arquivos:
http://www.techpowerup.com/articles/34/images/SP27213.exe
http://www.techpowerup.com/articles/34/images/USBImage.zip

E o procedimento funcionou com sucesso.

• menu Permissions, Server Groups
• aba Server Groups, Groups Guest
• painel direito, Virtual Server, Information
• duplo clique nos 3 itens com seta verde, para deixar como o screenshot abaixo:

http://tabs.ultimate-guitar.com/m/misc_soundtrack/airwolf_theme_tab.htm

O método é o taps[2][3].

Exemplos:

• To tap all email and send a copy to admin@example.com add a line like:
  .*:admin@example.com
• To tap a whole domain and send a copy to admin@example.com add a line like:
  .*@domain.com:admin@example.com
• To tap an individual email address and send a copy to archive@example.com add a line like:
  user@domain.com:archive@example.com

Testado com CentOS 5.3 + qmail-toaster (versão atual[4]).

Referências:
[1] http://wiki.qmailtoaster.com/index.php/Control_Files_by_Name
[2] http://wiki.qmailtoaster.com/index.php/Taps
[3] http://www.inter7.com/index.php?page=qmailtap
[4] http://qmailtoaster.com/

Configuração que eu uso:

]$ cat userContent.css
@-moz-document url(http://mail.google.com/),
        url-prefix(http://mail.google.com/),
        domain(google.com)
{
        .gs .ii, textarea.dV {
                font-family: MonoSpace !important;
                font-size: 9pt !important;
        }
}

Usando o arts, cheguei a uma solução intermediária, conseguia pelo menos ouvir o som do TeamSpeak (TS) durante o jogo, iniciando-o via artsdsp, porém o microfone não funcionava.

A gambiarra que resolveu por enquanto foi o aoss, que permite aplicações legadas usarem OSS através do ALSA.
Fiz assim:

• Instalação do pacote (Fedora):

yum install aoss

• Modifiquei o script original do TS para usar o aoss:

[user@host dir] cat /opt/TeamSpeak2RC2/TeamSpeakalsa
#!/bin/bash
export LD_LIBRARY_PATH=/opt/TeamSpeak2RC2:$LD_LIBRARY_PATH
aoss /opt/TeamSpeak2RC2/TeamSpeak.bin $*

• Inicio o TS pelo comando:

/opt/TeamSpeak2RC2/TeamSpeakalsa

• Nas configurações do TS, coloquei para usar “push to talk”, e mapeei a tecla de ativação para o CAPS LOCK. Sem fazer isso, e deixando ele pra ativar a transmissão de voz pelo nível de som do microfone, não funcionou direito: não importam as regulagens de volume tanto do sistema quanto do TS, fica sempre ativado. Anteriormente tinha tentado mapear a tecla de ativação para o End (que fica entre o teclado normal e o teclado numérico), mas não funcionava durante o jogo.