Existe algum problema em ter pastas enormes?

3

Meu site requer 10.000 segundos e 1-2 segundos de clipes de mp3, salvos como arquivos individuais. Cada um tem cerca de 12Kb de tamanho.

Existe algum problema em armazená-los em uma única pasta enorme como word_1.mp3, word_2.mp3 etc ...? Existem outras abordagens?

Muito obrigado, Patrick

EDITAR

Desculpe por não ser mais claro. Os arquivos serão enviados para a pasta via FTP, mas uma função javascript (SoundManager2) seleciona os arquivos mp3 para reprodução. Haverá problemas de velocidade com o rastreamento da pasta para o arquivo correto?

    
por Patrick Beardmore 22.12.2009 / 17:07

5 respostas

2

Você pode classificar e agrupar seu mp3 em temas? Se assim for, então eu iria colocá-los em pastas separadas, tudo a partir de um nome de pasta raiz mp3, clipes, ou o que for adequado ao seu uso.

Talvez seja só eu, mas ter milhares em uma pasta pode ser difícil de gerenciar, e alguns FS podem não gostar disso.

    
por 22.12.2009 / 17:14
2

Por experiência pessoal, alguns sistemas de arquivos ficam paralisados com 1k + arquivos em uma pasta. Lembro-me de NTFS sendo um desses cerca de 3-3,5 anos atrás no win2003 / XP.

O Reiser fs deve ser projetado para esse tipo de coisa, outros sistemas de arquivos UNIX também podem se sair bem. Para sustentar isso, direi que no mundo do UNIX tudo é um arquivo, e os daemons de correio pesado contam com isso e muitas vezes enchem pastas com milhares de e-mails (qmail).

    
por 22.12.2009 / 17:11
2

Existem algumas razões pelas quais sugiro que você as organize um pouco mais.

Em primeiro lugar - e isso pode não ser um problema para você - se você acessar a pasta via FTP, será uma pasta muito lenta para navegar. Ao organizar os arquivos em várias pastas, cada pasta será mais fácil de navegar.

Em segundo lugar, eu tive um problema no Windows onde havia muitos arquivos em uma pasta e tudo parou - que era com 2.000 arquivos - desculpas, já que não consigo lembrar os detalhes exatos que cercam esse problema. / p>     

por 22.12.2009 / 17:13
1

um bom conselho sobre pastas grandes em volumes NTFS:

Here's some advice from someone with an environment where we have folders containing tens of millions of files.

  1. A folder stores the index information (links to child files & child folder) in an index file. This file will get very large when you have a lot of children. Note that it doesn't distinguish between a child that's a folder and a child that's a file. The only difference really is the content of that child is either the child's folder index or the child's file data. Note: I am simplifying this somewhat but this gets the point across.
  2. The index file will get fragmented. When it gets too fragmented, you will be unable to add files to that folder. This is because there is a limit on the # of fragments that's allowed. It's by design. I've confirmed it with Microsoft in a support incident call. So although the theorical limit is several billions, good luck when you start hitting tens of million of files.
  3. It's not all bad however. You can use the tool: contig.exe to defragment this index. It will not reduce the size of the index (which can reach up to several Gigs for tens of million of files) but you can reduce the # of fragments. Note: The Disk Defragment tool will NOT defrag the folder's index. It will defrag file data. Only the contig.exe tool will defrag the index. FYI: You can also use that to defrag an individual file's data.
  4. If you DO defrag, don't wait until you hit the max # of fragment limit. I have a folder where I cannot defrag because I've waited until it's too late. My next test is to try to move some files out of that folder into another folder to see if I could defrag it then. If this fails, then what I would have to do is 1) create a new folder. 2) move a batch of files to the new folder. 3) defrag the new folder. repeat #2 & #3 until this is done and then 4) remove the old folder and rename the new folder to match the old.

To answer your question more directly: If you're looking at 100K entries, no worries. Go knock yourself out. If you're looking at tens of millions of entries, then either:

a) Make plans to sub-divide them into sub-folders (e.g., lets say you have 100M files. It's better to store them in 1000 folders so that you only have 100,000 files per folder than to store them into 1 big folder. This will create 1000 folder indices instead of a single big one that's more likely to hit the max # of fragments limit or

b) Make plans to run contig.exe on a regular basis to keep your big folder's index defragmented.

Fonte

Contig é gratuito.

se você não está confortável com a linha de comando, você pode usar Desfragmentador de energia , uma GUI escrita para o Contig.

    
por 22.12.2009 / 18:25
0

10000+ arquivos não são muito.

Todos os sistemas de arquivos que não usaram uma lista vinculada para o armazenamento do dentry devem estar bem, por exemplo mesmo ext3 com a opção dir_index. Os inodes e dentries de 10000+ arquivos são facilmente armazenados em cache na RAM.

    
por 26.12.2009 / 11:21