O que limita internamente essas coisas?
Resposta longa
Os limites do ZFS são baseados em números inteiros de tamanho fixo, porque essa é a maneira mais rápida de fazer aritmética em um computador.
A alternativa é chamada aritmética de precisão arbitrária , mas é inerentemente lenta . É por isso que a aritmética de precisão arbitrária é uma biblioteca complementar na maioria das linguagens de programação, não a maneira padrão de fazer aritmética. Há exceções, mas estes são geralmente orientadas matemática DSLs como bcou Wolfram idioma .
Se você deseja aritmética rápida, use palavras de tamanho fixo, ponto final.
A velocidade atingida pela aritmética de precisão arbitrária já é ruim o suficiente na RAM de um computador, mas quando um sistema de arquivos não sabe quantas leituras ele precisa fazer para carregar todos os números necessários na RAM, isso seria muito caro. Um sistema de arquivos baseado em números inteiros de tamanho arbitrário teria que reunir cada número de vários blocos, exigindo muitas E / S extras de várias ocorrências de disco em relação a um sistema de arquivos que sabe de antemão qual o tamanho de seus blocos de metadados.
Agora vamos discutir a importação prática de cada um desses limites:
Máx. tamanho do volume
2 128 bytes já são efetivamente infinitos. Em vez disso, podemos escrever esse número em aproximadamente 10 38 bytes, o que significa que, para atingir esse limite, você precisa ter um único pool ZFS do tamanho da Terra, onde cada um de seus 10 50 átomos é usado para armazenar dados e cada byte é armazenado por um elemento não superior a 10 12 átomos.
10 12 átomos parecem muito, mas são apenas cerca de 47 picogramas de silício .
A densidade de dados em gramas é de 2,5 × 10 -13 g / byte para armazenamento microSD, conforme está escrito: o maior cartão SD disponível é de 1 TB e pesa cerca de 0,25 g. about Um cartão microSD não é puro silicone, mas você não pode ignorar a embalagem, porque também precisaremos disso em nosso computador terrestre; assumiremos que a baixa densidade do plástico e a maior densidade dos pinos de metal atingem a mesma densidade do silício. Também precisamos de algumas informações aqui para explicar as interconexões entre chips, etc.
Um pico- nada é de 10 -12 , de modo a 47 pg e 2,5 x 10 -13 números g / B acima são cerca de uma ordem de grandeza de intervalo. Isso significa que, para uma primeira aproximação, para construir um único pool ZFS de tamanho máximo a partir dos maiores cartões microSD disponíveis no momento, talvez você precise usar o valor de átomos de um planeta do tamanho da Terra inteiro e, em seguida, somente se você começar com algo próximo à mistura certa de silício, carbono, ouro, etc., de modo que você não fique com tanta escória que exploda a estimativa.
Se você acha injusto que eu esteja usando armazenamento flash aqui, em vez de algo mais denso, como fita ou disco, considere as taxas de dados envolvidas, bem como o fato de que nem tentamos considerar redundância ou substituição de dispositivo. Temos que assumir que esse pool ZFS do tamanho da Terra será composto de vdevs que nunca precisam ser substituídos e que eles podem transferir dados com rapidez suficiente para que você possa preenchê-lo em um tempo razoável. Somente o armazenamento em estado sólido faz sentido aqui.
A aproximação acima é bastante grosseira e as densidades de armazenamento continuam aumentando, mas mantenha as coisas em perspectiva: no futuro, para realizar esse truque de construir pools ZFS de tamanho máximo, ainda precisaremos usar o total de crosta para recursos centrais de pequenos planetas .
Máx. tamanho do arquivo
Então, agora temos um sistema de arquivos do tamanho de um planeta . O que podemos dizer sobre o tamanho dos arquivos armazenados nele?
Vamos dar a cada pessoa no planeta sua própria fatia do mesmo tamanho:
10 38 10 10 10 ≈ 10 28 ÷ 10 19 ≈ 10 9
Esse é o tamanho do pool dividido pela população da Terra² dividido pelo tamanho máximo do arquivo, em números redondos.
Em outras palavras, cada pessoa pode armazenar cerca de um bilhão de arquivos de tamanho máximo em sua pequena fatia pessoal de nossa matriz de armazenamento ZFS do tamanho da Terra.
(Se você está incomodando que nossa matriz de armazenamento ainda seja do tamanho de um planeta aqui neste exemplo, lembre-se de que tinha que ser tão grande para atingir o primeiro limite acima, por isso é justo continuar usando-a neste exemplo aqui.)
Esse tamanho máximo de arquivo por arquivo é 16 EiB no ZFS, que é 16 vezes maior que o tamanho máximo do volume ext4 , considerado hoje ridiculamente grande por si só.
Imagine alguém usando sua fatia do Planet ZFS (anteriormente conhecido como Earth) para armazenar backups de imagens de disco ext4 de tamanho máximo. Além disso, esse cliente demente (sempre existe um) decidiu tar, 16 por arquivo, apenas para atingir o limite máximo de tamanho de arquivo do ZFS. Feito isso, esse cliente ainda terá espaço para fazer isso novamente cerca de um bilhão de vezes.
Se você vai se preocupar com esse limite, esse é o tipo de problema que você precisa imaginar para resolver. E isso sem sequer entrar na largura de banda de dados necessária para transferir o arquivo para o serviço de backup online uma vez .
Vamos deixar claro também o quão improvável é esse computador terrestre. Primeiro, você teria que descobrir como construí-lo sem permitir que ele se desmoronasse sob a força da gravidade e se fundisse no centro. Então você teria que descobrir como fabricá-lo usando todos os átomos da Terra sem restos de escória.
Agora, desde que você transformou a superfície do computador da Terra em um cenário infernal, todas as pessoas que tentassem usá-lo teriam que morar em outro lugar, um lugar onde você ouviria frequentemente pessoas amaldiçoando a velocidade da atrasos leves que adicionam latência a todas as transações entre o computador da Terra e onde quer que eles morem agora. Se você acha que seu tempo de ping na Internet de ~ 10 ms é um problema hoje, imagine colocar 2,6 segundos-luz entre o teclado e o computador se movermos a população da Terra para a lua para que possamos fabricar esse computador da Terra.
As limitações de volume e tamanho de arquivo do ZFS são grandes em ficção científica.
Máx. número de arquivos por diretório
2 48 são aproximadamente 10 14 arquivos por diretório, o que só será um problema para aplicativos que tentam tratar o ZFS como um sistema de arquivos simples .
Imagine um pesquisador da Internet que esteja armazenando arquivos sobre cada endereço IP na Internet. Digamos que há exatamente 2 32 IPs sendo rastreados após subtrair os espaços livres no antigo espaço IPv4 e depois adicionar os hosts agora usando endereços IPv6 para tornar a aritmética agradável. Que problema esse pesquisador está tentando resolver, o que exige que ele construa um sistema de arquivamento que possa armazenar mais de 2 16 - 65536! - arquivos por IP?
Digamos que esse pesquisador também esteja armazenando arquivos por porta TCP, de modo que, com apenas um arquivo por combinação IP: porta, consumimos nosso multiplicador 2 16 .
A correção é simples: armazene os arquivos por IP em um subdiretório nomeado após o IP e os arquivos por porta em um subdiretório do diretório que contém os arquivos por IP. Agora, nosso pesquisador pode armazenar 10 14 arquivos por combinação IP: porta, suficiente para um sistema global de monitoramento da Internet a longo prazo.
O limite de tamanho de diretório do ZFS não é o que eu chamaria de "ficção científica grande", como sabemos de aplicativos reais hoje em dia que podem atingir esse limite, mas o poder da hierarquia significa que você pode adicionar outra camada de diretório se enfrentar o limite.
Provavelmente, esse limite é definido como baixo para evitar que as estruturas de dados necessárias para localizar arquivos em um determinado diretório sejam muito grandes para caber na RAM. Ele incentiva você a organizar seus dados hierarquicamente para evitar esse problema em primeiro lugar.
Máx. comprimento do nome do arquivo
Embora esse limite pareça rigoroso, na verdade faz sentido.
Esse limite não se origina no ZFS. Eu acredito que remonta ao FFS em 4.2BSD . Não consigo encontrar a citação, mas quando esse limite era jovem, alguém apontou que isso é espaço suficiente para "uma breve carta para a avó".
Então, isso levanta a questão: por que você precisa nomear seus arquivos de forma mais descritiva que isso? Qualquer necessidade verdadeira maior que isso provavelmente exige hierarquia, altura em que você multiplica o limite pelo número de níveis na hierarquia, mais um. Ou seja, se o arquivo estiver enterrado em três níveis na hierarquia, o limite no nome do caminho completo será 4 × 255 = 1020 caracteres.
Em última análise, esse limite é um limite humano, não um limite tecnológico. Os nomes de arquivo são para uso humano, e os humanos realmente não precisam de mais de 255 caracteres para descrever com utilidade o conteúdo de um arquivo. Um limite mais alto simplesmente não seria útil. A limitação é antiga (1983) porque os humanos não adquiriram a capacidade de lidar com nomes de arquivos mais longos desde então.
Se você está perguntando de onde vem o valor "255", é uma limitação baseada no tamanho de um byte de 8 bits. 2 8 é 256, e o valor N-1 usado aqui provavelmente significa que eles estão usando um terminador nulo para marcar o final da cadeia de nomes de arquivos em um campo de 256 bytes nos metadados por arquivo.
Resposta curta
Na prática, quais limites?
Notas de rodapé:
Eu medi isso usando uma escala especificada com uma precisão de 0,01g.
7,55 bilhões , até o momento em que este artigo foi escrito. Acima, estamos arredondando para 10 10 , que deveríamos atingir em meados do século .
PATH_MAXum sistema POSIX é 256. Isso pode ser composto de componentes com no máximoNAME_MAXcaracteres cada (esse valor é pelo menos 14).