Duas novas informações vindas do time do Windows 8 Server são interessantes, uma pela consolidação e mudança na interface e outra por ser uma “novidade” que já era esperada desde o Longhorn (Windows 2008 RTM).
Interface Core
Essa mudança é significativa, apesar de não ser nova por já estar presente no Windows 2008 R2. Porem agora a interface Server Core será o padrão ao invés da interface completa em servidores Windows 8.
Com essa alteração vemos como está sendo bem aceito e fundamentado pelos clientes o uso de um SO Windows com menor consumo de memória (512 Kb no Core contra 1.5 GB com a interface gráfica).
Mas adicionalmente foi acrescentada a possibilidade de alterar entre o modo GUI e o Core, o que hoje não é possivel no Windows 2008 R2. Isso permitirá, inclusive é destacado no anúncio, que um administrador poderá instalar a interface gráfica para configurar o servidor e após terminar retornar para o modo Core, o que será muito bom para os que conhecem pouco de PowerShell.
Referencia http://blogs.technet.com/b/server-cloud/archive/2012/01/11/windows-server-8-server-applications-and-the-minimal-server-interface.aspx
Novo Sistema de Arquivos ReFS
Desde o Longhorn que se falava de um sistema de arquivos baseados em banco de dados e que foi testado e tinha o code name WinFS. Porem o modelo de banco de dados não é como o de arquivos por diversos motivos, mas principalmente na forma de armazenar dados que difere em muito documentos.
Já ouvi muitas vezes pessoas dizendo que o SharePoint guarda arquivos em banco de dados, porem são dados em formatos estruturados e não binários desestruturados como é o caso de um disco. Por exemplo, um doc/gif/jpeg/pdf tem inicio e fim na clusterização do arquivo com conteudo definido pela aplicação, enquanto em um sistema de arquivos como o NTFS guarda dados de criptografia para cada arquivo e dados desestruturados como é o caso do Shadow Copy (VSS).
O que o ReFS irá agregar de conceitos de banco de dados não é o formato BLOB ou CLOB de armazenamento, mas sim a estruturação do sistema de arquivos.
Isso é fácil de se entender quando pensamos que no NTFS original guardava-se os metadados do arquivo em uma “tabela” onde havia data de criação, nome e outros dados comuns, que seram vinculados as listas de permissões ACL/ACE com o “ID” do arquivo. Com o passar do tempo e as evoluções surgiram muitas outras tabelas como criptografia, compressão, BitLocker, Shadow Copy, etc. Com isso o NTFS acabou se dissipando em uma série de “tabelas” que tratam de determinado metadado. Imagine um disco onde o NTFS esteja com criptografia e VSS habilitado quantas diferentes informações estarão espalhadas entre as diversas tabelas especificas de cada recurso.
Já no ReFS será utilizado o conteudo de chave primária para um arquivo e apenas um ID e as tabelas serão unificadas com o conceito de “Key Value” comum em aplicações que utilizam matriz (array) como .NET e Java.
Abaixo é possivel ver um exemplo que o time de produto divulgou onde a tabela de alocação contem apenas o ID e a referencia dos blocos fisicos no disco, uma tabela contem os metadados basicos do arquivo e outra todos os “Key Values” juntos.
O conceito de “Key Value” é muito util pois podemos representar qualquer informação adicional sem a necessidade de criar tabelas em separado. Veja o exemplo abaixo, claro que teórico de como representar a melhora.
Note que no modelo NTFS temos uma “tabela” que representa apenas a criptografia e para cada agente de recuperação repete-se os dados. Multiplique isso por cada tipo de informação que um arquivo armazena no NTFS.
Em modelo baseado em estruturas de tabelas todas as informações estão em um unico lugar baseada no código do “Key” e o valor guarda os detalhes daquela informação, reduzindo o numero de tabelas para controle.
Isso irá reduzir a superficie de falhas por não serem x tabelas (ou blocos) para guardar e recuperar os dados, sendo mais simples ao SO juntar as informações e manter os backups (réplicas) atualizadas.
Nota: Não será possivel converter o sistema de arquivos, será necessário mover e reformatar.
Referencia http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx