Ima smisla - obavezno, obavezno podeli (po nekakvom sistemu) fajlove u poddirektorijume. Npr, ls nad jednim direktorijumom sa tolikim brojem fajlova bi ti gotovo sigurno vratio "argument list too long" (iz iskustva znam )..

Takav veliki folder sa tolikim brojem fajlova bi sigurno bio usko grlo..

Izdeli sto vise. Mozes cak i na svake 3 cifre. Tako ces imati uvek do 1000 fajlova (direktorijuma), sto nece biti problem.

da, definitivno.. i mada bi ti dva nivoa verovatno završila posao (po hiljadu fajlova/direktorijuma u jednom nivou), možda je bolje da ideš sa tri nivoa.

i druga preporuka, ako je taj 20tocifreni ID/broj ima nekog smisla (tj ne dodeljuje se totalno random, nego sa nekim smislom), može ti se desiti da imaš dosta sličica koje počinju istim ciframa, tako da ti razdvajanje po početnim ciframa neće mnogo pomoći.

onda se može koristiti obrnut princip, da razdvajaš po poslednjih par cifara.. znači, ako ti se sličica zove 1234567890.jpg predlažem da je sačuvaš kao ./90/78/1234567890.jpg (pametno je da fajl sačuva svoje originalno ime da ne bi morao da ga spajaš svaki put)..

U svakom slucaju moraces da proveris broj index nodova koje imas za taj fajlsistem, inace moze da ti se desi da neces imati gde da snimas fajlove iako ima prostora na disku...

Gde postoji takva informacija?
Ili ako neko zna za ntfs, ext2 i ex3.

Ako bi se u istom direktorijumu nalazila velika kolicina fajlova (fotografija) i ako bi im se prilazilo direktno programski po imenu (imena fajlova su u bazi) da li bi postojala bilo kakva razlika ako bi fajlovi bili razvrstani po direktorijumima?

zahvaljujem

Potvrdiću da je navedeni način efikasan. Koristim razdvajanje po prvih par cifara (12/34/1234567890.jpg) na 1.5M datoteka i radi odlično.

uposlite google, ja sam tražio nešto za reiser pa naleteh na:

Specifications for ReiserFS: (in according to NIST standard)
3.5 3.6
max number of files 232 - 3 => 4 Gi - 3 232 - 3 => 4 Gi - 3

max number files a dir can have 518701895,
but in practice this value is limited by hash function. r5 hash allows about 1 200 000 file

names without collisions 232 - 4 => 4 Gi - 4
but in practice this value is limited by hash function. r5 hash allows about 1 200 000 file names without collisions

max file size 231 - 1 => 2 Gi - 1 260 - bytes => 1 Ei,
but page cache limits this to 8 Ti
on architectures with 32 bit int

max number links to a file 216 => 64 Ki 232 => 4 Gi

max filesystem size 232 (4K) blocks => 16 Ti 232 (4K) blocks => 16 Ti


ostalo na: http://www.namesys.com/faq.html

Mozes pogledati kako trenutno stoji stanje na sistemu sa: df -i

Gustina (tj. broj) inodova se regulise prilikom pravljenja fajlsistema. Sto znaci da ako ih treba vise, onda se mora reformatirati fs na kojem ce stajati fajlovi.

trenutno stanje kod mene je:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 8699904 205782 8494122 3% /
dakle 3 miliona fajlova plus svi ti direktoriji na dva nivoa sa max 1000^2 sto je jos jedan milion znaci dalke moze stati da iskoristim nekih 45%

ReiserFS je i nastao sa namjerom da opslužuje masivne serverske instalacije na pouzdaniji način nego što je to bilo do njegovog pojavljivanja. Od tada je i on značajno unaprijeđen a više detalja o tome ima i na
http://www.namesys.com/

Jedno malo skretanje sa teme, ako vec imas 3Mil slicica, sto ih ne
puknes u neku bazu?

--
Sve najlepse,
Best regards,
Slobodan mailto:[email protected]