Criando o sistema de arquivos de última geração do Windows: ReFS

Desejamos continuar o diálogo sobre armazenamento de dados falando sobre o sistema de arquivos de última geração introduzido no Windows 8. Hoje, o NTFS é o sistema de arquivos mais amplamente usado, avançado e repleto de recursos em uso. Mas, como o Windows 8 é uma reimaginação do Windows, os sucessos do passado não nos satisfazem mais. Portanto, com o Windows 8, estamos introduzindo um sistema de arquivos com uma engenharia totalmente nova. O ReFS (que significa Sistema de Arquivos Resiliente) foi criado com base no NTFS, portanto, ele mantém a compatibilidade crucial e, ao mesmo tempo, sua arquitetura e engenharia são voltadas para uma nova geração de cenários e tecnologias de armazenamento. No Windows 8, o ReFS será introduzido somente como parte do Windows Server 8, seguindo a mesma abordagem que sempre usamos em cada introdução de sistema de arquivos. É claro que, no nível de aplicativo, os dados armazenados do ReFS poderão ser acessados por meio de clientes, da mesma forma que ocorre com o NTFS. Não vamos nos esquecer de que o NTFS é de longe a tecnologia líder no setor para sistemas de arquivos em PCs.

Esta postagem detalhada sobre a arquitetura foi escrita por Surendra Verma, gerente de desenvolvimento da nossa equipe de sistema de arquivos e armazenamento, embora, assim como ocorre com todos os recursos, houve contribuição de várias pessoas. Incluímos a seção de possíveis perguntas frequentes nesta postagem novamente.
--Steven

Obs.: não deixe de nos seguir no @buildwindows8, onde fornecemos algumas atualizações da CES.  

---

Nesta postagem, falarei sobre um novo sistema de arquivos do Windows. Esse sistema de arquivos, chamado ReFS, foi criado do zero para atender a um grande conjunto de necessidades dos clientes, tanto atuais quanto futuras, para todas as formas de implantação diferentes do Windows.

As principais metas do ReFS são:

• Manter um alto grau de compatibilidade com um subconjunto de recursos do NTFS que são amplamente adotados, evitando outros que oferecem recursos limitados devido ao tamanho da memória e complexidade do sistema.
• Verificar e autocorrigir dados. Os dados podem se corromper devido a várias razões. Portanto, devem ser verificados e, quando possível, corrigidos automaticamente. Os metadados não devem ser gravados in loco para evitar a possibilidade de interrupção de gravações, sobre a qual falaremos em detalhes mais adiante.
• Otimizar para escala muito grande. Usa estruturas escalonáveis para tudo. Não supõe que algoritmos de verificação de disco, em especial, possam ser dimensionados ao tamanho do sistema de arquivos inteiro.
• Manter o sistema de arquivos sempre online. Considera que, no caso de corrupção, é vantajoso isolar a falha e permitir acesso ao restante do volume. Isso é feito ao mesmo tempo em que a máxima quantidade possível de dados é recuperada, tudo sem ficar offline.
• Fornecer uma arquitetura de resiliência ponta a ponta completa quando usado com o recurso Storage Spaces, que foi coprojetado e criado em conjunto com o ReFS.

Estes são os principais recursos do ReFS (observe que alguns deles são fornecidos em conjunto com o Storage Spaces):

• Integridade de metadados com somas de verificação
• Fluxos de integridade fornecendo integridade de dados do usuário opcional
• Modelo transacional de alocação na gravação para atualizações de disco robustas (também conhecido como gravação de cópia)
• Tamanhos de diretórios, arquivos e volumes grandes
• Virtualização e pooling de armazenamento, que facilitam o gerenciamento e a criação de sistemas de arquivos
• Distribuição de dados para desempenho (a largura de banda pode ser gerenciada) e redundância para tolerância a falhas
• Depuração de disco para proteção contra erros de disco latentes
• Resiliência a corrupções com "salvamento" para uma disponibilidade de volume máxima em todos os casos
• Pools de armazenamento compartilhados entre computadores para maior tolerância a falhas e balanceamento de carga

O ReFS também herda os recursos e a semântica do NTFS, o que inclui a criptografia BitLocker, listas de controle de acesso para segurança, diário de USN, notificações de alterações, links simbólicos, pontos de junção, pontos de montagem, pontos de nova análise, instantâneos de volume, identificações de arquivos e oplocks.

E, é claro, os dados armazenados no ReFS podem ser acessados por meio das mesmas APIs de acesso a arquivo em clientes que são usados em qualquer sistema operacional que possa acessar os volumes NTFS atuais.

Principais recursos e atributos de design

Os nossos atributos de design estão intimamente relacionados às nossas metas. Conforme analisamos esses atributos, lembre-se do histórico de produção de sistemas de arquivos usados por centenas de milhares de dispositivos, dos computadores com menor utilização de memória até os maiores data centers, do menor formato de armazenamento até o maior formato com vários eixos, do armazenamento de estado sólido às maiores unidades e sistemas de armazenamento disponíveis. Ao mesmo tempo, os sistemas de arquivos do Windows são acessados pela maior gama de aplicativos e software de sistema em qualquer lugar. O ReFS cria em cima desse aprendizado. Não começamos do zero, reimaginamos o sistema quando julgamos que isso fazia sentido e aproveitamos as partes certas do NTFS quando julgamos apropriado. O mais importante é que estamos oferecendo o sistema de forma pragmática, como deve ser quando se trata de um grande sistema de arquivos, algo que somente a Microsoft já fez nesse porte.

Compatibilidade e reutilização de código

A API do sistema de arquivos é a área em que a compatibilidade é mais crítica e, tecnicamente, mais desafiadora. Reescrever o código que implementa a semântica do sistema de arquivos impediria o nível correto de compatibilidade e os problemas apresentados seriam altamente dependentes do código de aplicativos, do tempo de chamada e do hardware. Portanto, na criação do ReFS, reutilizamos o código responsável pela implementação da semântica do sistema de arquivos do Windows. Esse código implementa a interface do sistema de arquivos (ler, gravar, abrir, fechar, notificar alteração etc.), mantém o estado do volume e o arquivo em memória, reforça a segurança e mantém o cache da memória e a sincronização dos dados de arquivos. Essa reutilização garante um alto grau de compatibilidade com os recursos do NTFS que estamos mantendo.

Sob essa parte reutilizada, a versão do NTFS da base do código usa um mecanismo com uma arquitetura recém-criada que implementa estruturas em disco, como o MFT (tabela mestra de arquivos) para representar arquivos e diretórios. O ReFS combina esse código reutilizado com um mecanismo novíssimo, onde se encontra uma parte significativa da inovação por trás do ReFS. Graficamente, ele é assim:

Estruturas em disco confiáveis e escalonáveis

As estruturas em disco e sua manipulação são tratadas pelo mecanismo de armazenamento em disco. Ele exibe uma interface de chave-valor genérica, aproveitada pela camada acima para implementar arquivos, diretórios etc. Para sua própria implementação, o mecanismo de armazenamento usa árvores B+ exclusivamente. Na verdade, utilizamos árvores B+ como a única estrutura em disco comum para representar todas as informações do disco. Pode haver árvores inseridas em outras árvores (uma raiz da árvore filha é armazenada na linha de uma árvore pai). As árvores no disco podem ser muito grandes e com vários níveis ou realmente compactas, com apenas algumas chaves e inseridas em outra estrutura. Isso garante total escalabilidade, sob todos os aspectos do sistema de arquivos. Uma única estrutura simplifica o sistema e reduz o código de forma significativa. A interface do novo mecanismo inclui a noção de "tabelas" que são conjuntos enumeráveis de pares chave-valor. A maioria das tabelas possui uma única ID (chamada de ID de objeto), pela qual podem ser identificadas. Uma tabela de objeto especial indexa todas essas tabelas no sistema.

Vejamos agora como as abstrações de sistemas de arquivos comuns são construídas com o uso de tabelas.

Estruturas de arquivos

Como mostrado no diagrama acima, os diretórios são representados em tabelas. Como implementamos tabelas usando árvores B+, os diretórios podem ser dimensionados de forma eficiente, se tornando muito grandes. Os arquivos são implementados como tabelas inseridas em uma linha do diretório pai, que também é uma tabela (representado como Metadados do arquivo no diagrama acima). As linhas na tabela Metadados do arquivo representam os vários atributos de arquivos. Os locais de extensão de dados de arquivos são representados por uma tabela de fluxo inserida, que é uma tabela de mapeamentos de compensação (e, opcionalmente, somas de verificação). Isso significa que os arquivos e diretórios podem ser muito grandes sem afetar o desempenho, superando as limitações encontradas no NTFS.

Como esperado, outras estruturas globais dentro do sistema de arquivos, como ACLs (Listas de controle de acesso), são representadas por tabelas com raiz na tabela de objetos.

Toda a alocação do espaço em disco é gerenciada por um alocador hierárquico, que representa o espaço livre em tabelas de intervalos de espaço livre. Para a escalabilidade, há três tabelas desse tipo: alocadores grandes, médios e pequenos. Elas diferem quanto à granularidade do espaço que gerenciam: por exemplo, um alocador médio gerencia partes médias do alocador grande. Isso faz com que os algoritmos de alocação de disco sejam muito bem dimensionados, e temos a vantagem de colocar metadados relacionados naturalmente, obtendo um melhor desempenho. As raízes desses alocadores, assim como a tabela de objetos podem ser acessadas de um local conhecido no disco. Algumas tabelas têm alocadores particulares, o que reduz a contenção e permite um melhor local para a alocação.

Com a exceção das tabelas de metadados do sistema global, as entradas na tabela de objetos se referem aos diretórios, pois os arquivos estão inseridos nesses diretórios.

Estratégia de atualização de disco robusta

Atualizar o disco de forma confiável e eficiente é um dos aspectos mais importantes e desafiadores do design de um sistema de arquivos. Passamos muito tempo avaliando as várias abordagens. Uma das abordagens que consideramos e rejeitamos foi implementar um sistema de arquivos estruturado em log. Essa abordagem não é adequada ao tipo de sistema de arquivos de finalidade geral exigido pelo Windows. O NTFS conta com um diário de transações para garantir a consistência no disco. Essa abordagem atualiza os metadados in loco no disco e usa um diário em paralelo para acompanhar as alterações que podem ser revertidas em erros e durante a recuperação após uma queda de energia. Um dos benefícios dessa abordagem é que ela mantém o layout de metadados no lugar, o que é vantajoso em termos de desempenho de leitura. As principais desvantagens de um sistema de diário é que as gravações podem ficar aleatórias e, mais importante, a atualização do disco pode corromper metadados gravados anteriormente em caso de falta de energia no momento da gravação, ou seja, a gravação é interrompida.

Para maximizar a confiabilidade e eliminar a interrupção de gravações, escolhemos uma abordagem de alocação na gravação que nunca atualiza os metadados in loco. Em vez disso, ela grava em outro local, de maneira rápida. Sob alguns aspectos, pegamos emprestada a antiga noção de “paginação de sombra”, que é usada para atualizar estruturas no disco de forma segura. As transações foram criadas com base nessa abordagem de alocação na gravação. Como a camada superior do ReFS é proveniente do NTFS, o novo modelo transacional aproveita perfeitamente a lógica da recuperação contra falhas já presente, que foi testada e estabilizada em muitas versões.

O ReFS aloca metadados de forma a permitir que as gravações sejam combinadas em partes relacionadas (por exemplo, alocação de fluxo, atributos de arquivos, nomes de arquivo e páginas de diretório) em E/Ss menores e maiores, o que é ótimo tanto para mídia de rotação, quanto para flash. Ao mesmo tempo, uma medida de contiguidade de leitura é mantida. O esquema de alocação hierárquico é muitíssimo aproveitado aqui.

Realizamos muitos testes em que se retira a energia do sistema enquanto ele se encontra sob estresse extremo e, assim que ele volta, todas as estruturas são examinadas quanto à correção. Esses testes são a medida definitiva do nosso sucesso. Alcançamos um nível sem precedentes de robustez nesse teste de sistemas de arquivos da Microsoft. Acreditamos que o sistema seja líder no setor e atenda às nossas principais metas de design.

Resiliência a corrupções de disco

Como mencionado anteriormente, uma das nossas metas de design era detectar e corrigir a corrupção. Isso não apenas garante a integridade dos dados, mas também aumenta a disponibilidade do sistema e o funcionamento online. Dessa forma, é feita a soma de verificação dos metadados do ReFS no nível de uma página de árvore B+ e essa soma é armazenada separadamente da página em si. Isso nos permite detectar todas as formas de corrupção de disco, incluindo gravações perdidas e incorretas e deterioração de bits (degradação de dados da mídia). Além disso, incluímos a opção de se fazer também a soma de verificação do conteúdo de um arquivo. Quando essa opção, chamada de "fluxos de integridade" é ativada, o ReFS sempre grava as alterações do arquivo em outro local que não seja o original. Essa técnica de alocação na gravação garante que os dados pré-existentes não sejam perdidos com a nova gravação. A atualização da soma de verificação é feita rapidamente com a gravação dos dados, de forma que, se faltar energia durante a gravação, teremos disponível uma versão do arquivo que poderá ser verificada de forma consistente quanto a corrupções que poderão ser detectadas de forma confiável.

Já blogamos sobre o Storage Spaces duas semanas atrás. Criamos o ReFS e o Storage Spaces para que um complementasse o outro, como dois componentes de um sistema de armazenamento completo. Estamos disponibilizando o Storage Spaces para o NTFS (e PCs cliente) porque isso será de grande utilidade; as camadas arquiteturais dão suporte a essa abordagem do lado do cliente enquanto adaptamos o ReFS para uso em clientes para que você possa usar o ReFS tanto em clientes quanto em servidores.

Além de aumentar o desempenho, o Storage Spaces protege dados contra falhas de disco parciais e totais, mantendo cópias em vários discos. Em caso de falhas de leitura, o Storage Spaces lê cópias alternativas e, em falhas de gravação (assim como quando há perda total de mídia em leitura/gravação), ele realoca dados de forma transparente. Muitas falhas não envolvem a falha de mídia, mas acontecem devido a corrupções de dados ou gravações perdidas e incorretas.

São exatamente essas falhas que o ReFS pode detectar usando somas de verificação. Quando o ReFS detecta uma falha dessas, ele se conecta por meio de interface com o Storage Spaces para ler todas as cópias de dados disponíveis e escolhe a correta, com base na validação das somas de verificação. Ele ordena que o Storage Spaces corrija as cópias ruins com base nas cópias boas. Tudo isso ocorre de forma transparente, do ponto de vista do aplicativo. Se o ReFS não estiver sendo executado com um espaço de armazenamento espelhado, ele não terá como reparar a corrupção automaticamente. Nesse caso, ele simplesmente registrará um evento indicando que a corrupção foi detectada e não fará a leitura, caso sejam dados de arquivos. Falarei mais sobre o impacto disso nos metadados mais adiante.

As somas de verificação (64 bits) estão sempre ativadas para os metadados do ReFS e, supondo que o volume esteja hospedado em um espaço de armazenamento espelhado, a correção automática também fica sempre ativada. Todos os fluxos de integridade (veja abaixo) ficam protegidos da mesma forma. Isso cria uma solução de alta integridade completa para o cliente, na qual um armazenamento relativamente não confiável pode se tornar altamente confiável.

Fluxos de integridade

Os fluxos de integridade protegem o arquivo contra todas as formas de corrupção de dados. Embora esse recurso seja valioso em muitos cenários, ele não é adequado em alguns casos. Por exemplo, alguns aplicativos preferem gerenciar seu armazenamento de arquivos cuidadosamente e confiar em um determinado layout de arquivo no disco. Como os fluxos de integridade realocam blocos sempre que o conteúdo de um arquivo é alterado, o layout do arquivo fica muito imprevisível para esses aplicativos. Os sistemas de banco de dados são excelentes exemplos disso. Esses aplicativos também normalmente mantêm suas próprias somas de verificação de conteúdo de arquivo e podem verificar e corrigir dados por meio da interação direta com as APIs do Storage Spaces.

Para esses casos em que um determinado layout de arquivo é necessário, oferecemos mecanismos e APIs para controlar essa configuração em vários níveis de granularidade.

No nível mais básico, a integridade é atributo de um arquivo (FILE_ATTRIBUTE_INTEGRITY_STREAM). Também é atributo de um diretório. Quando presente em um diretório, ela é herdada por todos os arquivos e diretórios criados dentro do diretório. Para a sua conveniência, você pode usar o comando "formatar" para especificar isso para o diretório raiz de um volume na hora da formatação. Definir isso na raiz garante a propagação por padrão para todos os arquivos e diretórios do volume. Por exemplo:

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

Por padrão, quando o comutador /i não é especificado, o comportamento escolhido pelo sistema depende se o volume reside em um espaço espelhado ou não. Em um espaço espelhado, a integridade fica habilitada porque esperamos que os benefícios sejam muito superiores aos custos. Os aplicativos podem substituir isso de forma programática para arquivos individuais.

Combatendo a "deterioração de bits"

Como descrevemos antes, a combinação do ReFS com o Storage Spaces oferece um alto grau de resiliência de dados em casos de corrupções de disco e falhas no armazenamento. Uma forma de perda de dados que é mais difícil de ser detectada e tratada ocorre devido à "deterioração de bits", em que partes do disco desenvolvem corrupções ao longo do tempo sem que sejam detectadas por não serem lidas com frequência. No momento em que são lidas e detectadas, as cópias alternativas também já podem ter sido corrompidas ou perdidas devido a outras falhas.

A fim de lidar com a "deterioração de bits", adicionamos uma tarefa do sistema que periodicamente depura todos os metadados e dados do Fluxo de integridade em um volume do ReFS que resida em um espaço de armazenamento espelhado. A depuração envolve a leitura de todas as cópias redundantes e a validação de sua correção com o uso das somas de verificação do ReFS. Se houver divergência nas somas de verificação, as cópias ruins serão corrigidas com o uso das boas.

O atributo de arquivo FILE_ATTRIBUTE_NO_SCRUB_DATA indica que o depurador deve ignorar o arquivo. Esse atributo é útil para os aplicativos que mantém suas próprias informações de integridade, quando o desenvolvedor de aplicativos deseja exercer um controle mais estrito sobre quando e como esses arquivos devem ser depurados.

A ferramenta de linha de comando Integrity.exe é uma ótima maneira de gerenciar as políticas de depuração e integridade.

Quando tudo der errado... disponibilidade de volume continuada

Esperamos que muitos clientes usem o ReFS em conjunto com o Storage Spaces espelhado para que as corrupções sejam corrigidas de forma automática e transparente. Mas há casos raros em que um volume em um espaço espelhado pode ser corrompido – por exemplo, uma falha na memória do sistema pode corromper dados, que, por sua vez, podem corromper todas as cópias redundantes do disco. Além disso, alguns clientes podem optar por não usar um espaço de armazenamento espelhado no ReFS.

Nesses casos em que o volume é corrompido, o ReFS realiza um "salvamento", por meio de um recurso que remove os dados corrompidos do namespace em um volume dinâmico. A intenção por trás desse recurso é impedir que uma corrupção não reparada afete a disponibilidade dos dados bons. Se, por exemplo, um único arquivo em um diretório for corrompido e não puder ser reparado automaticamente, o ReFS removerá esse arquivo do namespace do sistema de arquivo, salvando, ao mesmo tempo o restante do volume. Essa operação normalmente pode ser realizada em um segundo.

Normalmente, o sistema de arquivos não pode abrir ou excluir um arquivo corrompido, impossibilitando um administrador de responder. Mas, como o ReFS ainda poderá salvar os dados corrompidos, o administrador poderá recuperar esse arquivo de um backup ou fazer com que o aplicativo o recrie sem precisar deixar o sistema de arquivos offline. Com essa inovação fundamental, não precisamos executar uma ferramenta cara de correção e verificação de discos offline e podemos implantar volumes de dados muito grandes sem o risco de o sistema ficar offline por muito tempo devido à corrupção.

Um ajuste limpo na pilha de armazenamento do Windows

Sabíamos que precisávamos criar um sistema com a máxima flexibilidade e compatibilidade. Criamos o ReFS para conectar a pilha de armazenamento exatamente como fazemos com qualquer outro sistema de arquivos, para maximizar a compatibilidade com as outras camadas ao seu redor. Por exemplo, ele pode aproveitar perfeitamente a criptografia BitLocker, as Listas de controle de acesso para segurança, diário de USN, notificações de alterações, links simbólicos, pontos de junção, pontos de montagem, pontos de nova análise, instantâneos de volume, identificações de arquivos e oplocks. Esperamos que a maioria dos filtros do sistema de arquivos funcione perfeitamente com o ReFS com pouca ou nenhuma modificação. Os nossos testes confirmaram isso; por exemplo, pudemos validar a funcionalidade da solução antivírus Forefront.

Alguns filtros que dependem do formato físico do NTFS precisarão de mais modificações. Executamos um programa de compatibilidade extensivo em que testamos os nossos sistemas de arquivos com antivírus de terceiros, backup e outros softwares do tipo. Estamos fazendo o mesmo com o ReFS e trabalharemos com os nossos principais parceiros para solucionar toda incompatibilidade que descobrirmos. Já fizemos isso antes e não é exclusividade do ReFS.

Um aspecto da flexibilidade que vale a pena ressaltar é que, embora o ReFS e o Storage Spaces funcionem bem juntos, eles foram criados para serem executados independentemente um do outro. Isso oferece maior flexibilidade de implantação para os dois componentes, sem que um limite o outro desnecessariamente. Ou seja, há alternativas de confiabilidade e desempenho que podem ser escolhidas quando se opta por uma solução de armazenamento completa, incluindo a implantação do ReFS com armazenamento subjacente dos nossos parceiros.

Com o Storage Spaces, um pool de armazenamento pode ser compartilhado por vários computadores e os discos virtuais podem transitar perfeitamente entre eles, fornecendo resiliência adicional contra falhas. Devido à arquitetura que criamos para o sistema, o ReFS pode aproveitar isso perfeitamente.

Uso

Testamos o ReFS com um vasto conjunto de dezenas de milhares de testes sofisticados desenvolvidos durante duas décadas para o NTFS. Esses testes simulam e ultrapassam os requisitos das implantações que esperamos em termos de estresse do sistema, falhas devido a falta de energia, escalabilidade e desempenho. Portanto, o ReFS está pronto para ter sua implantação testada em um ambiente gerenciado. Sendo a primeira versão de um grande sistema de arquivos, recomendamos um pouco de cuidado. Não classificamos o ReFS no Windows 8 como um recurso “beta”. Sua versão estará pronta para a produção quando o Windows 8 sair da fase beta, mas é necessário ter em mente que nada é mais importante do que a confiabilidade de dados. Portanto, diferentemente de qualquer outro aspecto do sistema, esse exige uma abordagem conservadora à implantação inicial, e o teste é obrigatório.

Com isso em mente, implementaremos o ReFS em etapas, de acordo com a evolução do recurso: primeiro como um sistema de armazenamento para o Windows Server, depois, como armazenamento para os cliente e, por fim, como um volume de inicialização. Foi essa abordagem que sempre usamos antes com novos sistemas de arquivos.

Inicialmente, o foco do nosso teste principal é executar o ReFS como um servidor de arquivos. Esperamos que os clientes se beneficiem de seu uso como um servidor de arquivos, especialmente em um espaço de armazenamento espelhado. Também planejamos trabalhar com os nossos parceiros de armazenamento para integrá-lo com suas soluções de armazenamento.

Conclusão

O ReFS e o Storage Spaces juntos formam a base do armazenamento no Windows para a próxima década, no mínimo. Acreditamos que isso seja um enorme avanço no estado da arte do armazenamento. Juntos, o Storage Spaces e o ReFS foram projetados com reserva dinâmica para permitir ainda mais inovações, e esperamos ver o ReFS como o próximo sistema de arquivos a ser implantado de forma maciça.

-- Surendra

Perguntas frequentes:

P) Por que o nome ReFS?

ReFS significa Sistema de Arquivos Resiliente. Embora ele tenha sido criado para ser melhor em muitas dimensões, a resiliência se destaca como um de seus recursos mais importantes.

P) Quais são os limites de capacidade do ReFS?

A tabela abaixo mostra os limites de capacidade do formato em disco. Outras questões podem determinar alguns limites práticos, como a configuração do sistema (por exemplo, a quantidade de memória), limites definidos por vários componentes do sistema, além do tempo que se leva para popular conjuntos de dados, horários de backup etc.

Atributo	Limite baseado no formato em disco
Tamanho máximo de um arquivo	2^64-1 bytes
Tamanho máximo de um único volume	O formato dá suporte a 2^78 bytes com tamanho de cluster de 16 KB (2^64 * 16 * 2^10). O endereçamento de pilha do Windows permite 2^64 bytes
Número máximo de arquivos em um diretório	2^64
Número máximo de diretórios em um volume	2^64
Comprimento máximo do nome do arquivo	Caracteres unicode de 32 K
Comprimento máximo do caminho	32 K
Tamanho máximo de um pool de armazenamento	4 PB
Número máximo de pools de armazenamento em um sistema	Sem limite
Número máximo de espaços em um pool de armazenamento	Sem limite

P) Posso converter dados entre o NTFS e o ReFS?

No Windows 8, não há como converter dados in loco. Os dados podem ser copiados. Optamos por isso intencionalmente devido ao tamanho de conjuntos de dados que vemos hoje em dia e por sabermos que a conversão in loco seria impraticável, além da provável alteração na abordagem projetada antes e após a conversão.

P) Posso inicializar do ReFS no Windows Server 8?

Não, não há implementação nem suporte para isso.

P) O ReFS pode ser usado em mídia ou unidades removíveis?

Não, não há implementação nem suporte para isso.

P) Quais semânticas ou recursos do NTFS deixarão de ter suporte no ReFS?

Optamos por não dar suporte a estes recursos do NTFS no ReFS: fluxos nomeados, IDs de objeto, nomes curtos, compactação, criptografia no nível do arquivo (EFS), transações de dados do usuário, itens esparsos, links físicos, atributos estendidos e cotas.

P) E quanto aos espaços de paridade e o ReFS?

Há suporte ao ReFS nas opções de resiliência a falhas oferecidas pelo Storage Spaces. No Windows Server 8, a correção automática de dados somente é implementada para espaços espelhados.

P) Há suporte a clustering?

Há suporte a clustering de failover, pelo qual pode haver failover de volumes individuais em vários computadores. Além disso, há suporte a pools de armazenamento compartilhados em um cluster.

P) E quanto ao RAID? Como uso os recursos do ReFS de distribuição, espelhamento ou outros formatos de RAID? O ReFS oferece o desempenho de leitura necessário para vídeo, por exemplo?

O ReFS aproveita os recursos de redundância de dados do Storage Spaces, que incluem paridade e espelhos distribuídos. Espera-se que o desempenho de leitura do ReFS seja semelhante ao do NTFS, pois há compartilhamento de muitos códigos relevantes entre eles. Ele será ótimo na transmissão de dados.

P) Como o ReFS não tem eliminação de duplicação, cache de segundo nível entre a DRAM e o armazenamento, e instantâneos graváveis?

O ReFS em si não oferece eliminação de duplicação. Como a arquitetura do sistema de arquivos é clássica e conectável, outros produtos de eliminação de duplicação poderão se conectar ao ReFS da mesma forma que fazem com o NTFS.

O ReFS não implementa explicitamente um cache de segundo nível, mas os clientes podem usar soluções de terceiros para isso.

O ReFS e o VSS funcionam juntos para oferecer instantâneos de forma consistente com o NTFS em ambientes do Windows. Por enquanto, eles não dão suporte a instantâneos graváveis ou instantâneos com mais de 64 TB.