Newsgroup: it.comp.os.linux.sys
Titolo: numero di file troppo elevato da far schiantale ls

come da oggetto.... su di un mailserver, in una specifica directory, ho 
un numero di file così elevato da far schiantare ls
 
rimane appeso e non risponde nemmeno con CTRL+C.
 
non si riesce a killare il processo (vedere per credere):
 
pub1:/ # ps -xa | grep ls
22265 pts/0    D+     0:00 ls -A -N --color=tty -T 0 -l
28878 pts/1    D+     0:00 ls -A -N --color=tty -T 0
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # kill 22265
pub1:/ # ps -xa | grep ls
22265 pts/0    D+     0:00 ls -A -N --color=tty -T 0 -l
28878 pts/1    D+     0:00 ls -A -N --color=tty -T 0
 
 
find manco per l'anticamera
 
se riavvio, anche con un fsck pianificato, non cambia nulla.
 
gli inode stanno bene e ce ne sono a volontà:
/dev/mapper/system-homelvm    10346496 1415020 8931476   14% /home
 
 
 
...chiamo l'esorcista? :)
 
 

 se riavvio, anche con un fsck pianificato, non cambia nulla.
 
pardon, giusto una precisazione: se riavvio ls ovviamente smette (e ci 
mancherebbe), ma se ridņ il comando rimane schiantato da capo. :)
 
inoltre scusate per l'oggetto sgrammaticato :P

> se riavvio, anche con un fsck pianificato, non cambia nulla.
 
Secondo me hai problemi sul disco che sta per schiattare.


sgrat.. sgrat..
 
in ogni caso sarebbe strano, c'è un raid hardware serveraid ibm com due 
dischi in mirror sotto, in genere quel tipo di raid si accorge di 
problemi strani e mette facilmente offline il disco guasto.
 
 
 
dimenticavo, il fs è ext3. così, per la cronaca :)
 
 


Ext3 non è molto performante ma problemi di questo tipo non mi risultano.
Se stessi parlando di NFS o di OCFS allora potrei capire ma in locale no, 
non è ragionevole.
 
Prova a dargli un ls (liscio, senza altri parametri) per vedere se tiri 
fuori qualcosa di più.
 
Ti capisco comunque: io ci lotto ogni giorno con gente che fa i sistemi 
senza pensare che prima o poi questi tipi di botti succedono...

 senza pensare che prima o poi questi tipi di botti succedono...
 
guarda, alla fine è una casella di posta che riceve in alias moltissime 
email, la persona è andata in maternità, nessuno ha avvertito e per un 
anno nessuno ha svuotato nulla.
 
ora... ok, ma chi pensava che si inchiodava? :)

 ora... ok, ma chi pensava che si inchiodava? :)
 
Per quale motivo devi fare un ls? Se è per avere la lista dei files puoi
provare con un find... magari funziona.
 
find . -type f > /tmp/listafiles.txt
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left


 
ls fa pure un ordinamento
mentre find no quindi dovrebbe essere piu veloce
 
ma quanti sono questi files ?
 
find . -type f | wc -l
 

 28878 pts/1    D+     0:00 ls -A -N --color=tty -T 0
 
Beh, kill -9 22265
 
Nicola.
 
-- 
chi va pian va san e va lontan

 find . -type f | wc -l
 
 
ehm... avevo scritto nel primo post: find non funziona uguale :)


e rm:
 
bash: /bin/rm: Lista degli argomenti troppo lunga
 
 
certo che ce ne vuole eh!!

 certo che ce ne vuole eh!!
 
[SOLVED]
 
fatto!
sostanzialmente sono tutti file chiamati 13equalchecosa.
 
ho creato uno scriptino che fa sostanzialmente:
 
rm 1301*
rm 1302*
rm 1303*
...
rm 1399*
 
 
etc etc...
 
piano piano e suddividendo i file a piccoli gruppi da 2-300, rm va a 
buon fine.
 
dovrei finire nel 2021, ma almeno risolvo! :)

> dovrei finire nel 2021, ma almeno risolvo! :)
 
Quantitativamente quanti file erano ?
 
Giulia

 [...]
 
 
Ciao  Manlio


penso non meno di 500.000. ma ï¿œ una stima fatta a naso.


fantastico, salvo subito nei preferiti!
tnks

 find . -type f | wc -l
 
ls liscio non richiede stat al file.
find di solito lo richiede, aumentando i tempi.
 
Provalo, ad esempio, su OCFS2 e dimmi se non noti differenze.


Si, ma qua non vedo una soluzione buona (IMHO).
Ho solo capito che la readdir (e quindi getdents) ha il limite di 32k, ma è 
nella libc e non ci si può mettere le mani.
Ovviamente non ho provato alcuna delle proposte fatte in quel thread. 
Sarebbe interessante se chi ha aperto la discussione ci può far vedere se le 
soluzioni funzionano e soprattutto in quanto tempo :)


 soluzioni funzionano e soprattutto in quanto tempo :)
 
 
 
fortunatamente il problema è rientrato sul server in produzione, però su 
un server di test vorrei provare a metter su un loop stanotte e generare 
qualche milione di file per poi domani trovare una soluzione più 
ragionata in caso di problemi futuri.
 
sempre che il disco non mi lasci prima, ovviamente :)

 Ho solo capito che la readdir (e quindi getdents) ha il limite di 32k
 
Ma no, scusa, se ben intendo il bello è proprio che getdents NON ha 
questo limite.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://www.worldcommunitygrid.org/index.jsp
 
http://www.rnaworld.de/rnaworld/
 
http://home.edges-grid.eu/home/
 
 
http://www.gpugrid.net/
 

 questo limite.
 
 
Ah si, hai ragione è la dirp->fd passata a getdents ad avere il limite di 
32k.
Il mio inglese fa ca...e :P


 Il mio inglese fa ca...e :P
 
Mi sembra che anche lui si chieda perche il limite a 32K.....
 
Giulia
 


però provo a fare un ragionamento:
se il limite è 32K,
ed è vero che stiamo parlando di 32.768, ed un file aveva una lunghezza 
media di 14 caratteri, possibile che lui si blocchi ad appena 2300 file 
circa? non mi torna qualcosa oppure ho fatto un calcolo erroneo..

 circa? non mi torna qualcosa oppure ho fatto un calcolo erroneo..
 
Non devi contare solo quei 14 caratteri. Il problema è che vien fatta 
un'operazione di I/O ogni pochi file (spannometricamente direi un 
migliaio, a far tanto). Un disco meccanico ti consente da poche decine a 
poche centinaia di iops al secondo, e così...
 
Per vedere la dimensione del "file directory", spostati dentro tale 
directory e dai:
 
$ ls -dhl .
 
Poi dividi la dimensione per 32K, e ottieni il numero di iops necessarie.


 poche centinaia di iops al secondo, e così...
 
Ormai qualunque disco  e file system fanno abbondate read-head,
penso sia piu' un problema di syscall .....
 
Giulia