filesystems - what - wiki ntfs




Quantos arquivos posso colocar em um diretório? (14)

Importa quantos arquivos eu mantenho em um único diretório? Em caso afirmativo, quantos arquivos em um diretório são muitos e quais são os impactos de ter muitos arquivos? (Isso está em um servidor Linux.)

Histórico: Eu tenho um site de álbum de fotos, e cada imagem enviada é renomeada para um ID de 8 dígitos (digamos, a58f375c.jpg). Isso é para evitar conflitos de nome de arquivo (se muitos arquivos "IMG0001.JPG" forem carregados, por exemplo). O nome do arquivo original e qualquer metadado útil é armazenado em um banco de dados. Agora, tenho cerca de 1500 arquivos no diretório de imagens. Isso faz com que a listagem dos arquivos no diretório (por meio do cliente FTP ou SSH) demore alguns segundos. Mas não vejo que tenha algum efeito além disso. Em particular, não parece haver nenhum impacto na rapidez com que um arquivo de imagem é exibido ao usuário.

Eu pensei em reduzir o número de imagens, fazendo 16 subdiretórios: 0-9 e af. Em seguida, movia as imagens para os subdiretórios com base no primeiro dígito hexadecimal do nome do arquivo. Mas não tenho certeza se há algum motivo para fazê-lo, exceto pela listagem ocasional do diretório por meio do FTP / SSH.


FAT32 :

  • Número máximo de arquivos: 268.173.300
  • Número máximo de arquivos por diretório: 2 16 - 1 (65.535)
  • Tamanho máximo do arquivo: 2 GiB - 1 sem LFS , 4 GiB - 1 com

NTFS :

  • Número máximo de arquivos: 2 32 - 1 (4.294.967.295)
  • Tamanho máximo do arquivo
    • Implementação: 2 44 - 2 6 bytes (16 TiB - 64 KiB)
    • Teórico: 2 64 - 2 6 bytes (16 EiB - 64 KiB)
  • Tamanho máximo do volume
    • Implementação: 2 clusters de 32 - 1 (256 TiB - 64 KiB)
    • Teórico: 2 64 - 1 clusters (1 YiB - 64 KiB)

ext2 :

  • Número máximo de arquivos: 10 18
  • Número máximo de arquivos por diretório: ~ 1,3 × 10 20 (problemas de desempenho após 10.000)
  • Tamanho máximo do arquivo
    • 16 GiB (tamanho do bloco de 1 KiB)
    • 256 GiB (tamanho do bloco de 2 KiB)
    • 2 TiB (tamanho do bloco de 4 KiB)
    • 2 TiB (tamanho do bloco de 8 KiB)
  • Tamanho máximo do volume
    • 4 TiB (tamanho do bloco de 1 KiB)
    • 8 TiB (tamanho do bloco de 2 KiB)
    • 16 TiB (tamanho do bloco de 4 KiB)
    • 32 TiB (tamanho do bloco de 8 KiB)

ext3 :

  • Número máximo de arquivos: min (volumeSize / 2 13 , numberOfBlocks)
  • Tamanho máximo do arquivo: igual ao ext2
  • Tamanho máximo do volume: igual ao ext2

ext4 :

  • Número máximo de arquivos: 2 32 - 1 (4.294.967.295)
  • Número máximo de arquivos por diretório: ilimitado
  • Tamanho máximo do arquivo: 2 44 - 1 bytes (16 TiB - 1)
  • Tamanho máximo do volume: 2 48 - 1 bytes (256 TiB - 1)

A questão se resume ao que você vai fazer com os arquivos.

No Windows, qualquer diretório com mais de 2k arquivos tende a abrir lentamente para mim no Explorer. Se forem todos arquivos de imagem, mais de 1k tendem a abrir muito lentamente na exibição de miniaturas.

Ao mesmo tempo, o limite imposto pelo sistema era de 32.767. É maior agora, mas mesmo assim são muitos arquivos para lidar de uma só vez na maioria das circunstâncias.


Depende um pouco do sistema de arquivos específico em uso no servidor Linux. Atualmente, o padrão é ext3 com dir_index, o que torna a pesquisa de diretórios grandes muito rápida.

Portanto, a velocidade não deve ser um problema, a não ser aquele que você já observou, que é que as listagens levarão mais tempo.

Existe um limite para o número total de arquivos em um diretório. Eu pareço lembrar isso definitivamente trabalhando até 32.000 arquivos.


Eu estou trabalhando em um problema semelhante agora. Nós temos uma estrutura hierárquica de diretórios e usamos ids de imagens como nomes de arquivos. Por exemplo, uma imagem com id=1234567 é colocada em

..../45/67/1234567_<...>.jpg

usando os últimos 4 dígitos para determinar para onde o arquivo vai.

Com alguns milhares de imagens, você poderia usar uma hierarquia de um nível. Nosso administrador de sistemas sugeriu não mais do que milhares de arquivos em qualquer diretório (ext3) para eficiência / backup / qualquer outra razão que ele tivesse em mente.


Eu prefiro o mesmo que @armandino . Para isso eu uso essa pequena função no PHP para converter IDs em um caminho de arquivo que resulta em 1000 arquivos por diretório:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

ou você poderia usar a segunda versão se você quiser usar o alfanumérico:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

resultados:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Como você pode ver para o $int -version, cada pasta contém até 1000 arquivos e até 99 diretórios contendo 1000 arquivos e 99 diretórios ...

Mas não se esqueça que para muitos diretórios pode reduzir o seu processo de backup. Sinta-se livre para testar 1000 a 10000 arquivos por diretório, mas não adicione muito mais, pois você terá tempos de acesso muito longos se quiser ler o arquivo de diretório por arquivo (clientes ftp, funções de leitura de arquivos, etc.).

Finalmente, você deve pensar em como reduzir a quantidade de arquivos no total. Dependendo do seu alvo, você pode usar sprites CSS para combinar várias imagens minúsculas como avatares, ícones, smilies, etc. ou se você usar muitos pequenos arquivos que não são de mídia, considere combiná-los, por exemplo, no formato JSON. No meu caso eu tinha milhares de mini caches e finalmente decidi combiná-las em pacotes de 10.


Eu respeito isso não totalmente responder a sua pergunta sobre quantos é demais, mas uma idéia para resolver o problema a longo prazo é que, além de armazenar os metadados do arquivo original, também armazenar em qual pasta no disco é armazenado - normalize esse pedaço de metadados. Uma vez que uma pasta cresce além de algum limite que você está confortável com o desempenho, estética ou qualquer outra razão, basta criar uma segunda pasta e começar a soltar arquivos lá ...


Eu tenho um diretório com 88.914 arquivos nele. Como você mesmo, isso é usado para armazenar miniaturas e em um servidor Linux.

Os arquivos listados via FTP ou uma função php são lentos sim, mas há também um impacto na exibição do arquivo. Por exemplo, www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg tem um tempo de espera de 200-400 ms. Como uma comparação em outro site eu tenho com cerca de 100 arquivos em um diretório a imagem é exibida após apenas ~ 40ms de espera.

Eu dei essa resposta porque a maioria das pessoas acabou de escrever como as funções de pesquisa de diretório irão funcionar, o que você não estará usando em uma pasta thumb - apenas exibindo arquivos estaticamente, mas estará interessado em mostrar como os arquivos podem realmente ser usados .


Isso realmente depende do sistema de arquivos usado e também de alguns sinalizadores.

Por exemplo, ext3 pode ter muitos milhares de arquivos; mas depois de alguns milhares, costumava ser muito lento. Principalmente ao listar um diretório, mas também ao abrir um único arquivo. Alguns anos atrás, ele ganhou a opção 'htree', que reduziu drasticamente o tempo necessário para obter um inode dado um nome de arquivo.

Pessoalmente, eu uso subdiretórios para manter a maioria dos níveis abaixo de mil ou mais itens. No seu caso, eu criaria 256 diretórios, com os dois últimos dígitos hexadecimais do ID. Use o último e não os primeiros dígitos, para obter a carga balanceada.


Não é uma resposta, mas apenas algumas sugestões.

Selecione um FS (sistema de arquivos) mais adequado. Desde um ponto de vista histórico, todos os seus problemas foram sábios o suficiente, para ser uma vez central para FSs evoluindo ao longo de décadas. Quero dizer mais FS moderno melhor apoiar seus problemas. Primeiro, faça uma tabela de decisão de comparação com base no seu propósito final na lista de FSs .

Eu acho que é hora de mudar seus paradigmas. Então, pessoalmente, sugiro usar um FS com sistema distribuído , o que significa nenhum limite em relação ao tamanho, número de arquivos e etc. Caso contrário, você será mais cedo ou mais tarde desafiado por novos problemas imprevistos.

Eu não tenho certeza de trabalhar, mas se você não mencionar alguma experimentação, experimente o AUFS em seu sistema de arquivos atual. Eu acho que tem recursos para imitar várias pastas como uma única pasta virtual.

Para superar os limites de hardware, você pode usar o RAID-0.


Não há uma figura única que seja "demais", desde que não exceda os limites do sistema operacional. No entanto, quanto mais arquivos em um diretório, independentemente do sistema operacional, quanto mais tempo for necessário para acessar qualquer arquivo individual, e na maioria dos sistemas operacionais, o desempenho não é linear, por isso, para encontrar um arquivo de 10.000 leva mais de 10 vezes mais então para encontrar um arquivo em 1.000.

Problemas secundários associados a ter muitos arquivos em um diretório incluem falhas de expansão de curingas. Para reduzir os riscos, você pode considerar a possibilidade de ordenar seus diretórios por data de envio, ou algum outro pedaço útil de metadados.


O maior problema que enfrentei foi em um sistema de 32 bits. Depois de passar um certo número, ferramentas como 'ls' param de funcionar.

Tentar fazer qualquer coisa com esse diretório depois de passar por essa barreira se torna um grande problema.


O que a maioria das respostas acima não mostra é que não existe uma resposta "tamanho único" à pergunta original.

No ambiente de hoje, temos um grande conglomerado de hardware e software diferentes - alguns são de 32 bits, alguns são de 64 bits, outros são de ponta e outros são testados e verdadeiros - confiáveis ​​e nunca mudando. Além disso, há uma variedade de hardware antigo e mais novo, sistemas operacionais mais antigos e mais recentes, fornecedores diferentes (Windows, Unixes, Apple etc.) e uma infinidade de utilitários e servidores que acompanham. Como o hardware melhorou e o software foi convertido para compatibilidade de 64 bits, houve necessariamente um atraso considerável em fazer com que todas as partes desse mundo tão grande e complexo funcionassem bem com o ritmo acelerado das mudanças.

IMHO não há uma maneira de corrigir um problema. A solução é pesquisar as possibilidades e, em seguida, por tentativa e erro, encontrar o que funciona melhor para suas necessidades específicas. Cada usuário deve determinar o que funciona para seu sistema, em vez de usar uma abordagem de cookie.

Eu, por exemplo, tenho um servidor de mídia com alguns arquivos muito grandes. O resultado é apenas cerca de 400 arquivos preenchendo uma unidade de 3 TB. Apenas 1% dos inodes são usados, mas 95% do espaço total é usado. Outra pessoa, com muitos arquivos menores, pode ficar sem inodes antes de chegar perto de preencher o espaço. (Em sistemas de arquivos ext4, como regra geral, 1 inode é usado para cada arquivo / diretório.) Embora, teoricamente, o número total de arquivos contidos em um diretório seja quase infinito, a praticidade determina que o uso geral determine unidades realísticas, não apenas recursos do sistema de arquivos.

Espero que todas as diferentes respostas acima tenham promovido o pensamento e a resolução de problemas, em vez de apresentar uma barreira insuperável ao progresso.


Se o tempo envolvido na implementação de um esquema de particionamento de diretório for mínimo, eu sou a favor dele. A primeira vez que você tem que depurar um problema que envolve a manipulação de um diretório de arquivos 10000 através do console, você vai entender.

Como exemplo, o F-Spot armazena arquivos de fotos como YYYY \ MM \ DD \ filename.ext, o que significa que o maior diretório com que tive que lidar enquanto manipulava manualmente minha coleção de fotos ~ 20000 é de cerca de 800 arquivos. Isso também torna os arquivos mais facilmente navegáveis ​​de um aplicativo de terceiros. Nunca assuma que seu software é a única coisa que estará acessando os arquivos do seu software.


Tenha em mente que no Linux, se você tiver um diretório com muitos arquivos, o shell pode não ser capaz de expandir curingas. Eu tenho esse problema com um álbum de fotos hospedado no Linux. Ele armazena todas as imagens redimensionadas em um único diretório. Enquanto o sistema de arquivos pode manipular muitos arquivos, o shell não pode. Exemplo:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

ou

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long