Bug nell'implementazione della funzione ext4 dir_index che stai usando sul tuo filesystem di destinazione.
Soluzione:ricreare il file system senza dir_index. Oppure disabilitare la funzione utilizzando tune2fs (è necessaria una certa cautela, vedere il collegamento correlato Novell SuSE 10/11:Disabilita l'indicizzazione H-Tree su un filesystem ext3 che sebbene si riferisca a ext3 potrebbe richiedere un'attenzione simile.
(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)
- ext4:Misteriosi errori di "Spazio esaurito sul dispositivo"
ext4 ha una funzionalità chiamata dir_index abilitata per impostazione predefinita, che è abbastanza suscettibile alle collisioni di hash.
......
ext4 ha la possibilità di eseguire l'hashing dei nomi dei file dei suoi contenuti. Questo migliora le prestazioni, ma ha un "piccolo" problema:ext4 non cresce la sua tabella hash, quando inizia a riempirsi. Restituisce invece -ENOSPC o "nessuno spazio rimasto sul dispositivo".
Suggerimenti per scelte migliori di ext4 per l'archiviazione di grandi quantità di file di piccole dimensioni:
Se stai utilizzando il filesystem come archivio di oggetti, potresti voler utilizzare un filesystem specializzato in questo, possibilmente a scapito di altre caratteristiche. Una rapida ricerca su Google ha trovato Ceph , che sembra essere open source e può essere montato come filesystem POSIX, ma accessibile anche con altre API. Non so se vale la pena usarlo su un singolo host, senza sfruttare la replica.
Un altro sistema di archiviazione degli oggetti è Swift di OpenStack . I suoi documenti di progettazione dicono che memorizza ogni oggetto come file separato, con metadati in xattrs. Ecco un articolo a riguardo. La loro guida alla distribuzione afferma di aver scoperto che XFS ha offerto le migliori prestazioni per l'archiviazione di oggetti. Quindi, anche se il carico di lavoro non è ciò in cui XFS è il migliore, apparentemente era migliore dei concorrenti quando RackSpace stava testando le cose. Forse Swift favorisce XFS perché XFS ha un supporto buono/veloce per gli attributi estesi. Potrebbe essere che ext3/ext4 andrebbe bene su singoli dischi come backend dell'archivio oggetti se non fossero necessari metadati aggiuntivi (o se fossero conservati all'interno del file binario).
Swift esegue la replica/il bilanciamento del carico per te e suggerisce di fornirgli filesystem realizzati su dischi grezzi, non RAID . Sottolinea che il suo carico di lavoro è essenzialmente il caso peggiore per RAID5 (il che ha senso se stiamo parlando di un carico di lavoro con scritture di piccoli file. XFS in genere non li comprime completamente testa a coda, quindi non lo fai ottenere scritture full-stripe e RAID5 deve eseguire alcune letture per aggiornare la striscia di parità.I documenti Swift parlano anche dell'utilizzo di 100 partizioni per unità.Presumo che sia un termine Swift e non si tratta di creare 100 diversi filesystem XFS su ciascuno Disco SATA.
L'esecuzione di un XFS separato per ogni disco è in realtà un'enorme differenza . Invece di un gigantesco mappa free-inode, ogni disco avrà un XFS separato con liste libere separate. Inoltre, evita la penalità RAID5 per le piccole scritture.
Se hai già il tuo software creato per utilizzare un filesystem direttamente come archivio di oggetti, piuttosto che utilizzare qualcosa come Swift per gestire la replica / bilanciamento del carico, puoi almeno evitare di avere tutti i tuoi file in un'unica directory. (Non ho visto i documenti Swift dire come dispongono i loro file in più directory, ma sono certo che lo fanno.)
Con quasi tutti i filesystem normali, sarà utile utilizzare una struttura come
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
Probabilmente circa 10.000 voci sono ragionevoli, quindi prendere 4 caratteri ben distribuiti dei nomi dei tuoi oggetti e usarli come directory è una soluzione semplice. Non deve essere molto ben bilanciato. La directory dispari da 100k probabilmente non sarà un problema evidente, e nemmeno alcune directory vuote.
XFS non è l'ideale per grandi masse di piccoli file. Fa quello che può, ma è più ottimizzato per le scritture in streaming di file più grandi. Tuttavia, nel complesso è molto buono per un uso generale. Non ha ENOSPC sulle collisioni nella sua indicizzazione delle directory (AFAIK) e può gestire una directory con milioni di voci. (Ma è ancora meglio usare almeno un albero a un livello.)
Dave Chinner ha fatto alcuni commenti sulle prestazioni di XFS con un numero enorme di inode allocati, portando a un touch lento prestazione. La ricerca di un inode libero da allocare inizia a richiedere più tempo della CPU, poiché la bitmap dell'inode libero viene frammentata. Si noti che questo non è un problema di una grande directory rispetto a più directory, ma piuttosto un problema di molti inode utilizzati sull'intero filesystem. Dividere i file in più directory aiuta con alcuni problemi, come quello che ext4 si è bloccato nell'OP, ma non il problema dell'intero disco di tenere traccia dello spazio libero. Il filesystem separato per disco di Swift aiuta in questo, rispetto a XFS gigante su RAID5.
Non so se btrfs è bravo in questo, ma penso che potrebbe esserlo. Penso che Facebook assuma il suo sviluppatore principale per un motivo. :P Alcuni benchmark che ho visto, di cose come decomprimere un sorgente del kernel Linux, mostrano che btrfs funziona bene.
Conosco reiserfs è stato ottimizzato per questo caso, ma è a malapena, se non del tutto, mantenuto più. Non posso davvero raccomandare di andare con reiser4. Potrebbe essere interessante sperimentare, però. Ma è di gran lunga la scelta meno a prova di futuro. Ho anche visto segnalazioni di degrado delle prestazioni su reiserFS invecchiato e non esiste un buon strumento di deframmentazione. (Google filesystem millions of small files e guarda alcune delle risposte esistenti di scambio di stack.)
Probabilmente mi sto perdendo qualcosa, quindi raccomandazione finale:chiedi informazioni su serverfault! Se dovessi scegliere qualcosa in questo momento, direi di provare BTRFS, ma assicurati di avere dei backup. (specialmente se usi la ridondanza su più dischi integrata di BTRFS, invece di eseguirla su RAID. I vantaggi in termini di prestazioni potrebbero essere notevoli, poiché i file di piccole dimensioni sono una cattiva notizia per RAID5, a meno che non si tratti di un carico di lavoro prevalentemente in lettura.)
Per questo problema di seguito è quello che ho fatto per risolvere (potresti aver bisogno dell'accesso sudo per i passaggi seguenti):
-
Lo spazio utilizzato di Inodes era del 100% che può essere recuperato utilizzando il comando seguente
df -i /
Inode del filesystem IUsed IFree IUse% Mounted on
/dev/xvda1 524288 524288 o 100% /
- È necessario liberare iNoted, quindi è necessario trovare i file che hanno qui il numero di nodi i utilizzando il comando seguente:
Prova a scoprire se si tratta di un problema di inode con:
df -ih
Prova a trovare cartelle root con un numero elevato di inode:
for i in /*; do echo $i; find $i |wc -l; done
Prova a trovare cartelle specifiche:
for i in /src/*; do echo $i; find $i |wc -l; done
- ora abbiamo azzerato la cartella con un gran numero di file al suo interno. Esegui i seguenti comandi uno dopo l'altro per evitare qualsiasi errore (nel mio caso la cartella effettiva era /var/spool/clientmqueue):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +