1. Introdução

 2. Histórico

 3. Formatação

 4. Funcionamento

 5. Sistema de Dados

 6. Tecnologias

 7. RAID

 8. Fabricantes

 9. Extras

 10. Conclusão

 11. Bibliografia

SISTEMA DE DADOS

Existem vários sistemas de arquivo, e cada um divide a superfície do disco da sua maneira. Alguns exemplos de sistema de arquivo: EXT3, REISERFS, FAT, FAT32, NTFS, HPFS, CDFS, etc. Um sistema operacional pode reconhecer um, alguns ou todos estes sistemas.

WINDOWS

FAT16

Primeiro, o que quer dizer FAT? FAT significa File Allocation Table. (tabela de alocação de arquivos). Todas as localizações dos arquivos estão contidas em 2 tabelas: uma é a FAT corrente (ou working FAT) e a outra é a FAT de backup. A FAT indica em que cluster um arquivo começa, ou seja, onde está o primeiro byte de um arquivo. Um cluster é formado por um ou mais setores físicos, geralmente cada setor de 512 bytes de tamanho. Dependendo do tamanho do disco, o tamanho do cluster também é diferente. Quando um arquivo é maior que o tamanho de um cluster, ele tem que ser dividido em múltiplos pedaços/clusters. Algumas vezes é possível alocar estes múltiplos pedaços/cluster, ao lado uma das outras (seqüencialmente), de tal forma que quando for necessário ler o arquivo, a "cabeça de leitura" do disco, não precise se movimentar muito na superfície para ler o arquivo inteiro.  Porém, se os pedaços/clusters, forem gravados distantes uns dos outros no disco, a cabeça de leitura irá se movimentar ao longo das diversas trilhas na superfícies, o que resultará em um aumento do tempo de leitura do arquivo. Assim, tendo em mente estes 2 problemas (tamanho/desperdício do cluster, e fragmentação), junto com a características dos arquivos gravados no disco (se em sua maioria são pequenos ou grandes), poderemos ter diferente performance e aproveitamento do disco.
No Windows 3.x e 95, o sistema de arquivo utilizado é a FAT16 (mostrada na tabela a seguir), e como vemos este tipo de sistema de arquivo era particularmente sensível a desperdício de disco, além de não ser factível para discos maiores de 2GB/4GB.

FAT32

Para resolver o problema do fato de que o maior tamanho de partição que a FAT16 poderia gerenciar era de 2 GB, e também devido ao grande desperdício de disco causado pelos tamanhos de cluster utilizado na FAT16, a Microsoft lançou a FAT32.
A FAT32 foi lançada no Windows 95 OSR2 (também conhecido como B). Ela também está incluída no Windows 98, ME, 2000 e XP. Ela pode gerenciar partições de até 2 TB (tera-bytes). A outra vantagem, é que em partições menores, o espaço é usado mais eficientemente, devido à diminuição do tamanho dos clusters. Por exemplo: em uma partição de 2 GB que na FAT16 utilizava cluster de 32 KB agora utiliza clusters de apenas 4 KB, reduzindo o desperdício de espaço em disco.
Problemas da FAT32: praticamente o único problema da FAT32 é a "incompatibilidade" com sistemas antigos. O DOS, NT 4.0 e abaixo, OS/2 e Windows 95 (antes do OSR2), não conseguem ler discos neste padrão. Da mesma forma, utilitários (como por exemplo utilitário de disco), que acessavam diretamente o disco, e foram desenvolvidos para FAT16, também não funcionam. Como praticamente todos migraram para sistemas que suportam a FAT32 (Windows 98, ME, 2000, XP), e quase não se encontram mais sistemas utilizando DOS/NT/OS2, esta incompatibilidade acabou deixando de ser um problema na realidade atual.

NTFS

NTFS significa NT File System (sistema de arquivos do NT, onde NT originalmente significava New Tecnhology). Suportado pelo Windows NT, 2000 e XP, ele é um sistema de arquivo superior se comparado ao FAT16 e ao FAT32, e foi desenvolvido principalmente para SERVIDORES. As principais vantagens do NTFS estão na área de segurança (muito importante para servidores), compatibilidade POSIX*, e alta capacidade de tolerância a falhas (também muito importante para servidores). Ele também é muito eficiente na área de tamanhos de cluster, e na realidade você pode formatar uma partição com o tamanho de cluster que você desejar (muito útil quando por exemplo você tem em uma máquina características bem específicas de tipos/tamanhos de arquivos predominantes). Suporta partições de até 16 exabytes, o que no momento excede em muito qualquer previsão de crescimento de volumes de dados, porém, isto só na teoria. A capacidade correntemente suportada pelo cluster é de 2 TB (igual ao FAT32), porém a tecnologia está pronta para suportes a maiores tamanhos, e espera-se que com o barateamente do custo de armazenagem/HDs, as novas versões rapidamente irão implementar a capacidade prevista no seu desenvolvimento. Os dados sobre os arquivos são armazenados no MFT (Master File Table) que inclui informações sobre localizações dos clusters do arquivo, atributos de segurança, nome de arquivos, etc. Além disto mantém um log de transações, que pode ser utilizado para recuperação. Operações de arquivos que ainda não foram realizadas também são gravadas no log, de tal forma que se o sistema cair, o sistema de arquivos pode ser rapidamente atualizado.

GNU/LINUX

O GNU/Linux suporta diversos formatos de sistemas de arquivos através de uma camada modular introduzida no kernel denominada VFS (Virtual File System).
Dentre os sistemas de arquivos suportados pelo GNU/Linux estão os sistemas EXT3 e ReiserFS, que apresentam excelentes tempos de resposta em suas tarefas e possuem recursos avançados de recuperação de dados em casos de desastres e falhas. Dentre os sistemas de arquivos suportados pelo GNU/Linux estão os sistemas EXT3 e ReiserFS, que apresentam excelentes tempos de resposta em suas tarefas e possuem recursos avançados de recuperação de dados em casos de desastres e falhas.


EXT3

O sistema de arquivos EXT3 é uma evolução do sistema de arquivos EXT2, que foi originalmente desenvolvido por Stephen Tweedie, Rémy Card e Theodore Ts'o e outros para a Red Hat.

O EXT3 possui uma vantagem significativa sobre todos os outros sistemas atuais, que é a sua total compatibilidade com o sistema de arquivos EXT2. O EXT3 é praticamente um EXT2 acrescido das propriedades de "journal". Conseqüentemente, pode empregar todas as aplicações existentes desenvolvidas para manipular o sistema de arquivos EXT2, bem como permitir uma migração para EXT3 sem grande esforço.

O EXT2 tem sido o sistema de arquivos mais popular para o GNU/Linux até o momento. Essa ampla base de usuários faz parecer que o EXT2 é o sistema de arquivos padrão do GNU/Linux. Tal afirmação não é de todo correta, já que o GNU/Linux reconhece os sistemas de arquivos através de uma funcionalidade incorporada ao kernel denominada VFS (Virtual File System). Não existe realmente um sistema de arquivos considerado padrão e sim o mais adotado pelos usuários.

Deste modo, o GNU/Linux pode reconhecer mais de vinte sistemas de arquivos em diferentes níveis de funcionalidade. Entre eles estão alguns que são proprietários e outros que são populares em diversas plataformas. Parte dessas características ainda é experimenta,l não estando totalmente funcionais.

Os dados do arquivo são armazenados em unidades chamadas 'blocos'. Estes blocos podem ser numerados seqüencialmente. Um arquivo também tem um inode. Como os blocos, os inodes são numerados seqüencialmente, embora tenham uma seqüência diferente. Uma entrada de diretório consiste do nome do arquivo e um número de inode. O inode também armazena o local dos blocos de dados:

• Os números dos blocos dos primeiros 12 blocos de dados estão armazenados diretamente no inode. Estes às vezes são chamados de blocos diretos.
• O inode contém o número do bloco de um bloco indireto. Um bloco indireto contém os números de blocos de 256 blocos de dados adicionais.
• O inode contém o número do bloco de um bloco duplamente indireto. Um bloco duplamente indireto contém os números de blocos de 256 blocos indiretos adicionais.
• O inode contém o número do bloco de um bloco três vezes indireto. Um bloco três vezes indireto contém os números de blocos de 256 blocos duplamente indiretos adicionais.

• Células de armazenamento inode;
• Superblocos distribuídos;
• Mapa de blocos no sistema de arquivos;
• Resumo de emprego de blocos;
• Conjunto de blocos de dados.

Cada partição de sistema de arquivos é dividida em grupos de blocos. Estruturas como tabelas de inode são alocadas entre os grupos de blocos para que os blocos que são acessados juntos possam ser armazenados próximos uns dos outros no disco. Esse agrupamento aumenta a velocidade de acesso ao arquivo e reduz o tempo de procura por blocos do mesmo arquivo. Inodes são entradas de tabelas de comprimento fixo, cada uma das quais armazenam informações sobre um arquivo existente no sistema de arquivos.

Os inodes são criados no momento da formatação lógica do dispositivo. Desta forma é possível redimensionar o número de inodes de acordo com a capacidade do dispositivo e o tipo e tamanho de arquivos que serão nele armazenados. Isso evita a falta de inodes que poderia provocar uma parada de sistema. Para determinar o tamanho do inode no momento da formatação é usado o comando mke2fs com opção -i bytes-por-inodes.

Observe que este ajuste é feito na criação da partição, não sendo possível redimensionar o número de inodes após a formatação inicial. A forma de disponibilizar inodes em um dispositivo é removendo arquivos que ocupam muitas entradas nas tabelas de blocos ou movendo-os para outros dispositivos.

Um superbloco é um registro que descreve as características do sistema de arquivos. Ele contém informações sobre:

• Comprimento de um bloco de disco;
• Tamanho e localização das tabelas de inodes;
• Mapa de blocos de disco e informações sobre utilização;
• Tamanho dos grupos de blocos;
• e outros parâmetros importantes para o sistema de arquivos.

Várias cópias do superbloco são gravadas em áreas diferentes do disco, (no início de cada grupo de bloco) prevenindo desse modo perdas de informações essenciais para o sistema de arquivos.

O GNU/Linux mantém para cada sistema de arquivos montado uma cópia do superbloco em memória RAM. A chamada de sistema "sync" despeja os dados sobre os superblocos que estão armazenados em memória cache para seus locais em disco, sincronizando as informações sobre o sistema de arquivos. Essa sincronização torna o sistema de arquivos consistente em um tempo extremamente pequeno. Esse salvamento ou sincronização ocorre em intervalos constantes de trinta segundos para sistemas EXT2 e a cada 5 segundos para EXT3, reduzindo, ainda mais, as falhas em servidores com intensas atividades de gravação de arquivos.

São descarregados tanto inodes modificados quanto blocos de dados armazenados em cache. O comando "update" executado no boot aciona o daemon bdflush, que executa uma sincronização nesse intervalo de tempo.

Um mapa de blocos do disco é uma tabela de blocos livres que o disco contém. No momento da gravação de arquivos novos esse mapa é verificado de modo que uma disposição eficiente seja utilizada. Os resumos de empregos de blocos registram informações básicas sobre os blocos que já se encontram em uso.

Até esse ponto os sistemas EXT3 e EXT2 são totalmente iguais.

Essa estrutura que se utiliza de dados e metadados é bastante eficiente em termos de velocidade de tempo de acesso e permite armazenar um grande número de arquivos em tamanhos diversos. Contudo, o problema nessa abordagem é a baixa tolerância às falhas apresentada pelo EXT2.

Na ocorrência de falta de energia elétrica, por exemplo, podem surgir inconsistências entre os dados e os metadados. Nesse caso, uma região do disco poderia estar ocupada com dados sem que os metadados relacionados estivessem devidamente registrados apontando esse fato. Deste modo, uma perda de dados irá ocorrer no sistema de arquivos com a sobreposição dos dados por outros.

No caso de falhas ou interrupções bruscas do sistema elétrico, por exemplo, um utilitário chamado fsck (filesystem consistency check) é utilizado para restaurar a consistência do sistema de arquivos. Esse utilitário é confiável e apresenta um trabalho de recuperação bastante eficiente na verificação de erros e da consistência do sistema.

Os danos mais comuns averiguados pelo fsck em sua verificação são:

• Inodes não referenciados;
• Contagem de links exagerada;
• Blocos de dados não utilizados e não registrados nos mapas de blocos;
• Blocos de dados listados como livres e que são usados num arquivo;
• Informações de resumo incompletas no superbloco.

Esses cinco problemas são corrigidos de maneira segura e automática. O utilitário também é capaz de analisar erros e solicitar a intervenção do operador como nos casos de:

• Blocos reivindicados por mais de um arquivo;
• Blocos reivindicados fora do intervalo do sistema de arquivos;
• Contagem de links muito pequenos;
• Blocos não contabilizados;
• Diretórios que se referem aos inodes não alocados;
• Variados erros de formato.

Corrigir um sistema de arquivos manualmente é uma tarefa complexa que exige do administrador conhecimentos sobre a estrutura e o funcionamento interno do sistema de arquivos. Alterações introduzidas nessa tentativa de recuperação que sejam indevidas podem danificar permanentemente o acesso aos dados.

Caso fsck localize um arquivo cujo diretório "pai" não pode ser encontrado, esse arquivo será salvo no diretório lost+found no nível mais alto do sistema de arquivos. Uma vez que os nomes dos arquivos são registrados somente em seus diretórios "pais", não é possível referenciar-se a esses arquivos por seus nomes. Os arquivos salvos nessa pasta terão como nomes seus números de inode.

A introdução do "journal" em sistemas EXT3 modifica essa abordagem de recuperação de sistemas de arquivos e reduz o tempo de parada do sistema para valores muito baixos, introduzindo uma confiabilidade muito superior ao servidor. Na instalação do sistema de arquivos, uma área é reservada para a alocação do "journal" ou "log".

As operações efetuadas nos arquivos são registradas nessa área de log do mesmo modo que o controle de transações em bancos de dados. As operações são primeiramente gravadas no journal. Quando a atualização do registro de ações (log) é completada, um registro de complemento (commit record) é gravado sinalizando o final da entrada. Então, as mudanças são efetivamente gravadas em disco no sistema de arquivos normal.

Uma falha nesse ponto permite, através da consulta ao journal, a reconstrução das operações ainda não concluídas e a rápida recuperação do sistema. Após a gravação em disco no sistema de arquivos, um marcador confirma a operação e descarta o log, já que a operação foi corretamente confirmada.

O EXT3 passou a ser suportado pelo kernel do Linux a partir da versão 2.4. Conseqüentemente, todas as distribuições Linux lançadas com esse kernel ou superior têm suporte padrão para EXT3.

No EXT3, o código de Journaling usa uma camada chamada "Journaling Block Device" (módulo JBD). A JBD foi criada com o propósito de implantar o suporte ao Journal em qualquer tipo de dispositivo com base em blocos de dados. Por exemplo, o código EXT3 informa e "pede autorização" à JBD para efetuar as mudanças antes de modificar/adicionar qualquer dado no disco. Sendo assim, é o JBD que verdadeiramente "gerencia" o Journal. Portanto, ele é uma dependência de módulo para o correto funcionamento do EXT3 juntamente com o módulo mbcache, que introduz uma camada cache para os metablocos melhorando o desempenho do sistema.

O JBD funciona como uma entidade independente permitindo que não só o EXT3 a use, mas, também, outros sistemas de arquivos. A JBD utiliza um método diferente de outros Journalings para recuperação de informações. Ao invés de armazenar as informações em bytes que depois devem ser gravados, a JBD grava os próprios blocos modificados do sistema de arquivos. Assim, o EXT3 também armazena "réplicas" completas dos blocos modificados em memória para rastrear as operações que ficaram pendentes. A desvantagem desta forma de trabalho é que o Journal acaba sendo maior.

No entanto, o EXT3 não precisa lidar com a complexidade dos Journalings que trabalham gravando bytes. Ele suporta três diferentes modos de trabalho do Journaling:

• Journaling (Registro de ações): grava todas as mudanças em sistema de arquivos e usa um arquivo de registros de ações maior. Isso pode retardar a recuperação durante a reinicialização. É o mais lento dos três modos, sendo o que possui maior capacidade de evitar perdas de dados. Uma forma de aperfeiçoar a velocidade dessa opção é gravar os registros em bancos de dados externos.
• Ordered (Ordenado): grava somente mudanças em arquivos metadados (arquivos que possuem informações sobre outros arquivos), mas registra as atualizações no arquivo de dados antes de fazer as mudanças associadas ao sistema de arquivos. Este Journaling é o padrão nos sistemas de arquivos EXT3 sendo a melhor opção para a maioria dos sistemas.
• Writeback: também só grava mudanças para o sistema de arquivo em metadados, mas utiliza o processo de escrita do sistema de arquivos em uso para gravação. É o mais rápido Journaling EXT3, porém é o menos confiável e mais suscetível à corrupção de arquivos após uma queda do sistema. Esse modo é equivalente à instalação de um sistema com EXT2 nativo.

O modo Ordered é o padrão no EXT3, mas é possível especificar qual o modo que se deseja usar através da modificação no arquivo /etc/fstab do parâmetro data="mode", onde "mode" pode ser igual a ordered, writeback ou journal. Por exemplo, uma entrada no /etc/fstab, usando o modo journal como padrão:

Devido à compatibilidade entre o sistema EXT2 e seu sucessor EXT3, é possível realizar uma migração apenas incluindo a área destinada ao registro das ações. O utilitário que faz essa configuração é o tune2fs com opção -j.

Por mais que seja segura a migração, é imprescindível efetuar cópia de segurança antes do procedimento e garantir que nenhum usuário obtenha acesso ao sistema nesse momento para evitar perdas dos dados. Por exemplo, para migrar uma partição EXT2 em /dev/hda3 para EXT3 usa-se:

# tune2fs -j /dev/hda3

Após a conclusão do comando é necessário alterar o tipo de partição no /etc/fstab para que esta seja corretamente montada. É possível montar uma partição EXT3 como EXT2, porém, isso não é recomendável, pois pode causar danos inesperados aos dados.


REISERFS

Um modo de se organizar os dados é no formato de árvores. Quando organizamos a informação em um computador, a classificamos tipicamente em pilhas (chamadas de nós ou nodes), e há um nome (ponteiro) para cada pilha. Esse ponteiro é usado para encontrar a pilha. Alguns dos nós podem conter ponteiros através dos quais podemos localizar outros ponteiros para outros nós.

Uma árvore é uma estrutura organizada que tem algumas propriedades úteis para essa finalidade conforme Figura 3.

Assim define-se uma árvore como:

1. Um conjunto de nós organizados em um nó raiz (Root node), e zero ou mais conjuntos adicionais de nós chamados sub-árvores.

2. Cada sub-árvore é uma árvore.

3. Nenhum nó na árvore aponta ao nó raiz, e há exatamente um ponteiro de nó na árvore que aponta para cada nó da árvore que não seja o nó raiz.

4. O nó raiz tem um ponteiro para cada uma das sub-árvores, isto é, um ponteiro para o nó raiz da sub-árvore.

As árvores balanceadas ("balanced tree") (B*) usadas pelo ReiserFS para organizar o sistema de arquivos são uma versão melhorada de árvores B+, onde não existe uma árvore diferente para cada diretório e sim, cada qual possui uma sub-árvore da principal.

O ReiserFS é um sistema de arquivos com suporte a "journaling" concebido por Hans Reiser e mantido pela empresa The Naming System Venture . São seus patrocinadores as empresas SuSE e Linspire. O ReiserFS já é o sistema de arquivos padrão nas distribuições GNU/Linux da SuSE, Gentoo e Linspire.

O ReiserFS é uma camada semântica com métodos e funções que são referenciados para executar tarefas no sistema de arquivos fazendo o uso de plug-ins que evocam chamadas de sistema para esses métodos e funções.

Esse método de acesso trata toda a partição como se fosse uma única tabela de banco de dados contendo diretórios, arquivos e metadados dentro de uma mesma árvore. A implantação dessa característica exigiu que técnicas mais complexas de indexação fossem implementadas no ReiserFS, tornando mais eficientes seus tempos de resposta comparados aos de outros sistemas. ReiserFS usa uma árvore finita (o número de nós é limitado).

Outro termo importante para a definição de árvores é o termo Edge. Diferentemente de um ponteiro que é unidirecional, o Edge é bidirecional, ou seja, pode ser seguido de um nó a outro e desse para seu antecessor. Então se pode dizer que Edge não é ponteiro.

Atribuímos a tudo que está armazenado na árvore uma chave. A pesquisa de localização se dá por meio das chaves. O uso das chaves nos dá uma flexibilidade adicional para classificação da informação, se essas chaves forem pequenas elas nos dão um modo compacto de especificar como encontrar as informações. Isto também limita o tipo de informação que podemos usar como uma chave.

Este limite restringe sua utilidade, e assim tem-se uma camada de armazenamento, que encontra dados por chaves, e uma camada semântica, que tem um sistema de nomes rico.
A busca por chaves, então, agiliza a pesquisa em árvores, mas limita o tipo de chaves que podemos trabalhar.O ReiserFS possui suporte a arquivos maiores que 2GB.

ReiserFS usa árvores balanceadas para tornar o processo de busca de arquivos, informações sobre segurança e outros metadados mais eficientes. Para arquivos muito pequenos, seus dados podem ser armazenados próximos aos metadados, então, ambos podem ser recuperados com um pequeno movimento do mecanismo da "cabeça" de leitura do disco. Essa propriedade vai contribuir para um melhor desempenho caso uma aplicação necessite abrir muitos arquivos pequenos rapidamente.

Outra grande vantagem do ReiserFS é a alocação dinâmica de inodes, já que esse sistema de arquivos não os aloca em espaços fixos ou blocos e sim, aloca o tamanho exato que o arquivo precisa. Em sistemas baseados em inodes fixos, como o EXT3, o espaço no disco é alocado em blocos que variam de 512 a 4096 bytes ou até maior, caso o arquivo exceda um múltiplo exato do tamanho do bloco.

A leitura e escrita de arquivos grandes são limitadas pela velocidade do dispositivo de armazenamento e pelo canal de entrada e saída da controladora de discos. Já o acesso a arquivos pequenos, como scripts do Shell, é limitado pela eficiência do projeto do sistema de arquivos. A razão disso é que a abertura de um arquivo requer a leitura dos metadados sobre ele que estão armazenados no inode do diretório em uma área distinta dos dados. Após localizar a entrada referente ao arquivo no diretório é que o sistema realiza a leitura dos setores que contêm os dados.

Além disso, o sistema precisa examinar os metadados relativos à segurança para verificar se o usuário tem permissão de acesso ao arquivo, isso significa leituras adicionais. O sistema pode gastar mais tempo decidindo entre permitir o acesso e localizar as entradas de dados do que se as buscasse dentro do próprio arquivo. Entre o EXT3 e o ReiserFS, a principal diferença é que o EXT3 tenta guardar informações tanto sobre o metadados, ou seja, as informações sobre o espaço ocupado pelos arquivos e suas permissões quanto sobre os dados em si, enquanto o ReiserFS guarda apenas informações sobre os metadados.

Para completar, o ReiserFS é rápido. Seu ganho de velocidade em relação a outros sistemas de arquivos varia de acordo com cada operação em disco. Em quase todas as operações ele é mais rápido, e em algumas não. Não é incomum alguém utilizar o ReiserFS com milhares de arquivos no mesmo diretório, uma tarefa para a qual o ReiserFS é especialmente adaptado.

Seu uso de funções hash e árvores balanceadas, ao invés de seqüências infindáveis de inodes tornam a procura de um arquivo em uma dezena ou em uma grande quantidade uma operação bem rápida.

No caso de um desligamento incorreto do sistema, o ReiserFS é capaz de recuperar a consistência do sistema de arquivos em frações de segundo e a possibilidade de perda de pastas ou partições é nula. Em compensação, os arquivos que eventualmente estiverem sendo gravados no exato momento em que acabou a energia ficarão com seus dados alterados. Você continuará tendo acesso aos arquivos normalmente, mas o conteúdo estará truncado ou incompleto.

Já o EXT3 tenta sempre preservar não só o metadados, mas também os dados dos arquivos em si. Isto se revela ao mesmo tempo uma força e uma fraqueza. A vantagem é que existe uma possibilidade maior de recuperar os arquivos que estiverem sendo gravados no exato momento em que acabar a energia. Por outro lado o journal guarda mais informações e é acessado mais freqüentemente, o que causa degradação no desempenho (é justamente por isso que o ReiserFS costuma se sair melhor nos benchmarks) e ao mesmo tempo faz com que exista a possibilidade do próprio journal se corromper durante o desligamento.

Apesar de ser muito difícil a corrupção do sistema ReiserFS, também pode acontecer. Porém o gerenciamento de setores defeituosos do sistema de arquivos ReiserFS é simples de ser realizado já que as ferramentas para essa operação estão disponíveis. Pode-se usar o comando badblocks para fazer um exame de superfície e mostrar uma lista com os setores defeituosos. Para usar em conjunto com o ReiserFS, é necessário especificar o tamanho dos blocos (em bytes). Se você não usou nenhuma opção especial ao formatar a partição, os blocos terão 4096 bytes. O comando para verificar a partição /dev/hda1, por exemplo, fica:
# badblocks -b 4096 /dev/hda1

O ReiserFS é capaz de marcar, via software, setores defeituosos que for encontrando. Isso é feito automaticamente, assim como no NTFS do Windows XP. Só é preciso marcar setores defeituosos manualmente em sistemas de arquivos antigos, como o FAT32 e o EXT2.

Para ver se existem setores defeituosos na partição, marcados via software, execute o comando:
# debugreiserfs /dev/hda1

Caso exista algum erro no sistema de arquivos, causados por desligamentos incorretos, por exemplo, você pode corrigir com o comando:
# reiserfsck /dev/hda1

O ReiserFS é um sistema de arquivos relativamente novo, mas que conta com o patrocínio de grandes empresas. Apesar de ainda estar em desenvolvimento, seu uso em servidores de produção já é uma realidade. Dadas as características do sistema tem se mostrado como uma solução a mais para os usuários do sistema GNU/Linux.