Newsgroup: it.comp.os.linux.sys
Titolo: Massimo numero di files in una directory?

Ciao a tutti,
siccome dovrei riversare in una directory un certo numero di
microscopici files zippati (intorno ai 5000) mi è venuto il dubbio che
su un FileSystem Ext3 possa esserci qualche limitazione in questo
senso...
Ho cercato un po' in rete ma ho trovato solo il numero massimo di
elementi (in generale) e nulla che accennasse ad un limite di "capienza"
di una directory
Potete tranquillizzarmi?  : )
-- 
Mr. Fix @ work

 Potete tranquillizzarmi?  : )
mi pare 16k files, se non mi sbaglio.
Ma č inutilizzabile molto prima, meglio reiser per numeri alti di files.

>Potete tranquillizzarmi?  : )

Puoi dirmi se hai scritto k per M, oppure con ext2 e'
diverso? perche' guarda:
ls iniziare|wc -l
95975
(vabbe' che ho impostato gli inode a "news")
-- 
Saluti, Dalet

 Ma è inutilizzabile molto prima, meglio reiser per numeri alti di files.
The following filesystem features can be set  or  cleared  using
tune2fs:
 
      dir_index
	       Use hashed  b-trees  to  speed  up lookups in large
               directories.
 
(man tune2fs)	
 
-- 
Per rispondermi, togli il nome del poeta

 alti di files.
Ti sbagli.
Ti sbagli molto.
Ti sbagli su tutto.
Per ext3 il limite sul numero di file contenuti in una
directory e` legato alla dimensione massima di file ed 
e` diversi milioni di file per directory.
ext3 gestisce benisimo e molto efficientemente directory 
molto grandi.
Casomai reisefs e` piu efficiente di ext3 nella gestione 
di file piccoli.

 ad un limite di "capienza" di una directory
Potresti spiegarequale sarebbe la differenza tra "il limite 
di capienza di una directory" ed "il numero massimo di
elementi di una directory"?

 Potete tranquillizzarmi?  : )
si,
# ls -1tr /var/lib/amavis/virusmails/ | wc -l
93052
ora sono quasi 100k,ma prima di cancellarli erano quasi 250k.
vai tranquillo,ciao
--
Ranger!

 Ma è inutilizzabile molto prima, meglio reiser per numeri alti di files.
E' un amo per Cammarata, ammettilo. :P
-- 
Vide
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

 Ma è inutilizzabile molto prima, meglio reiser per numeri alti di files.
A volte in questo NG mi viene molto da ridere (tu non c'entri).
Per errore tempo fa - sul computer di casa - ho impostato un logrotate
in samba che "loopava" e continuava a creare file in continuazione e in
continuazione. Uso la combinazione EVMS + Reiser, su disco Sata.
Mi sono ritovato /var/log/samba con piu' o meno 300mila o 500mila
filettini.
Non e' successo niente..... solo che il logrotate si lamentava e andava
in crash :P
Ero entusiasta del funzionamento del FS e ho fatto un posto sul NG dal
titolo: "Reiser rocks"
Mi e' stato risposto che in fondo in fondo 300mila file non erano un
granche' (la risposta era buttata li' come se loro avessere milioni di
file su ciascuna directory)..... adesso leggo che tu scrivi 16mila e
che comunque e' ingestibile molto prima ......
-- 
Massimiliano

Mr. Fix ha scritto:

No.
Teoricamente ext3 supera questo limite di 5000.
In pratica ext3 - secondo me in particolare sui dischi ide (e forse
anche sata?) - si spappola come niente.
-- 
Massimiliano

 
secondo te e stop.
Se proprio vogliamo fare discorsi così ti dico che secondo me ext3 va bene 
su ata, sata e scsi perché a me va bene e non ha dato mai problemi
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
E' un cretino illuminato da lampi di imbecillita'.
		-- Ennio Flaiano

 anche sata?) - si spappola come niente.
Su quei dischi è invece il miglior file system, perchè non pretende un
hardware particolarmente performante.


 hardware particolarmente performante.
lo stesso slogan e' stato usato quando ci hanno fatto la presentazione
di ZFS: zfs wants poor hardware :P
boh, vabbe dai, a ognuno i suoi preferiti e i suoi odiati.
-- 
Massimiliano.

 wrote:

Non saprei spiegartelo perché non è quello che ho scritto io... : )
Io intendevo dire che ho trovato in rete il numero massimo di files
gestibili in totale (su tutto l'hd)  ma nulla che parlasse di un limite
nel numero di files contenuti in una sigola directory.
Mi è venuto questo cruccio perché (molti) anni fa, col Mac Os 8 e HFS
(vado moooolto a memoria : ) c'era una limitazione per cui il sistema
*visualizzava* solo i primi (mi pare) 2000 files presenti in una
directory. In pratica potevi metterceli ma il finder non te li
visualizzava.


 vai tranquillo,ciao
Wow!  : )
Grazie mille!


 boh, vabbe dai, a ognuno i suoi preferiti e i suoi odiati.
Certo, ma che "ext3 si spappola come niente" è nella tua testa.


 Os 8 e HFS ....
Altola`: altro sistema operativo, altri problemi, altri
programmi (ed a quanto dici era un bug di finder)

 programmi (ed a quanto dici era un bug di finder)
Si, si, era solo per far capire il motivo per cui mi è venuto il dubbio
che un limite potesse esistere, o potesse essere stato fissato per
garantire prestazioni o evitare problemi. Con i Mac ci lavoro da almeno
una quindicina di anni ma Linux è una passione recente (diciamo da Mac
OS X in poi... ; ), quindi non conosco a fondo pregi e difetti dei vari
FS ext, Reiser, ecc



No, questo non proprio. 
Avevo un file system ext3 che tra un reboot (regolare) e l'altro mi si e'
disintegrato senza nessuna spiegazione plausibile ... e non sono pochi i
messaggi di gente che ha lamentato problemi simili.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 messaggi di gente che ha lamentato problemi simili.
Rispetto al numero di utenti, praticamente nessuno. Reiser e XFS, tanto per
dirne due, hanno una affidabilità usualmente più bassa se non si basano su
un hardware di alte prestazioni (il contesto del discorso è: miglior
filesystem per dischi IDE).


 ...
Cioe` un inode ogni 8KiBi di dati.
Od in alternativa la dimensione media dei file e` 8KiBi;
puo` essere un problema se la dimensione media dei file e`
2KiBi. Per fortuna questo e` solo un consiglio, durante la
creazone del filesystem si puo` scegliere un blocco di 
1KiBi ed un numero maggiore di inode e non si lamenteranno
misteriosi crash che nessun altro utente sperimenta ed
ancor piu` misteriose prestazioni scadenti.

 messaggi di gente che ha lamentato problemi simili.
Se e` per questo ho letto di problemi simili con qualsiasi file system...
Personalmente la vedo cosi`: sei stato preso di mira dalla sfiga? Allora
non c'e` file system che tenga, _perderai_ i dati
Enrico

 Che non vuol dire che sia un problema di ext3.
vabbuo' va .... questa storia l'ho gia' sentita (proprio su questo NG,
proprio riguardo a questo problema).
Era colpa del disco vero? Dico bene? ... peccato che dopo 2 anni
quell'hardware e' ancora perfettamente funzionante... ti verra'
difficile iniziare con questo tipo di tormentone ;)
-- 
Massimiliano

MaxAdamo ha scritto:

Non è un problema di tormentone, è che non puoi dire a me è successo questo 
quindi ext3 è un cesso.
Io ti dico che sui miei server ho ext3 e non ho problemi: basta per dire che 
è perfetto e incorruttibile?
direi di no
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Vendiamo oro, incenso e mirra in cambio di tre nomi da cristiani e non
da pirla.  Firmato: Gaspare, Melchiorre, Baldassarre.
		-- Michele Serra

 direi di no
questa risposta e' piu' che accetabile............ ma non e' la
risposta che ottenni tempo addietro, mentre discutevo di questo
problema. Mi si voleva inculcare, a tutti costi, che il disco che
ancora oggi utilizzo, era sicuramente fottuto.
A prescindere dai meriti tecnici dei singoli - che sicuramente ci sono
- Il cervello collettivo di icol.* e' il cervello di un deficiente
sottosviluppato...... 
-- 
Massimiliano