La rimozione dei file richiede troppo tempo

Versione corta : rm -rf mydircon mydir(ricorsivamente) contenente 2,5 milioni di file, richiede circa 12 ore su una macchina per lo più inattivo.

Ulteriori informazioni : La maggior parte dei file che vengono eliminati sono collegamenti diretti a file in altre directory (la directory che viene eliminata è in realtà il backup più vecchio fatto da rsnapshot; il rmcomando è effettivamente dato da rsnapshot). Quindi si tratta principalmente di eliminare le voci della directory - il contenuto del file stesso non è molto; è nell'ordine di alcune decine di GB.

Sono tutt'altro che sicuro che btrfssia il colpevole. Ricordo che anche il backup era molto lento prima di iniziare a utilizzare btrfs, ma non sono sicuro che la lentezza fosse nella cancellazione.

La macchina è un Intel Core i5 2,67 GHz con 4 GB di RAM. Ha due dischi SATA: uno ha il sistema operativo e alcune altre cose e il disco di backup è un 1 TB WDC WD1002FAEX-00Z3A0. La scheda madre è un Asus P7P55D.

Modifica : la macchina è un wheezy Debian con Linux 3.16.3-2~bpo70+1. Ecco come è montato il filesystem:

root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)

Modifica : l'utilizzo rsync -a --delete /some/empty/dir mydirrichiede circa 6 ore. Un miglioramento significativo rispetto rm -rf, ma penso ancora troppo. ( Spiegazione del perché rsyncè più veloce dirm : "[M] i filesystem ost memorizzano le loro strutture di directory in un formato btree, l'ordine [in] in cui si eliminano i file è ... importante. È necessario evitare di riequilibrare il btree quando si esegue il collegamento .... rsync -a --delete... elimina in ordine ")

Modifica : ho collegato un altro disco che aveva 2,2 milioni di file (ricorsivamente) in una directory, ma su XFS. Ecco alcuni risultati comparativi:

                  On the XFS disk      On the BTRFS disk
Cached reads[1]       10 GB/s               10 GB/s
Buffered reads[1]     80 MB/s              115 MB/s
Walk tree[2]         11 minutes            43 minutes
rm -rf mydir[3]       7 minutes            12 hours

[1] Con hdparm -T /dev/sdXe hdparm -t /dev/sdX.
[2] Tempo impiegato find mydir -print|wc -limmediatamente dopo l'avvio.
[3] Sul disco XFS, questo è stato subito dopo aver camminato con l'albero find. Sul disco BTRFS è la vecchia misura (e non penso che fosse con l'albero memorizzato nella cache).

Sembra essere un problema con btrfs.

linux btrfs

— Antonis Christofides
fonte

2,5 milioni di file in una singola directory? Non sono a conoscenza di un filesystem che lo gestisca bene.

— Michael Hampton,

@MichaelHampton: non è piatto, contiene directory nidificate. Ho aggiunto la parola "ricorsivamente" nella breve descrizione; Spero che questo lo chiarisca.

— Antonis Christofides,

Perché stai usando il trucco della directory copy-on-write su un filesystem copy-on-write?

— symcbean,

@symcbean: Vuoi dire che il trucco dell'hard link è ridondante btrfs? Questo è possibile, ovviamente, ma pensi che possa essere rilevante? In questo momento non ricordo perché ho deciso di provare btrfs.

— Antonis Christofides,

Ah, ora ricordo. Ho deciso di passare a btrfsperché volevo la compressione trasparente. Ora: rsnapshotutilizza collegamenti reali. Non ha alcuna opzione per non utilizzare i collegamenti reali. Quindi i collegamenti reali si sovrappongono alla funzionalità btrfsdi copia su scrittura, ma non posso fare molto al riguardo.

— Antonis Christofides,

Risposte:

Bene, questo è ancora un problema di Btrfs, è noto che l'eliminazione di molti file di piccole dimensioni richiede un tempo piuttosto lungo rispetto ad altri file system.

Se non ti piace, puoi aspettare fino a quando l'upstream non lo ha riparato o passare a un altro file system che lo fa meglio.

Il tuo errore principale però è usare un kernel antico (3.16, sì, era già antico quando hai postato) con btrfs. Btrfs è un file system che è ancora in forte sviluppo, quindi dovresti sempre rimanere con l'ultima e la più grande versione del kernel per entrare in contatto con i miglioramenti. Se la tua distribuzione non fa backport, puoi farlo da solo o sei fregato.

Btrfs ha ottenuto molti miglioramenti delle prestazioni nella versione 3.19 del kernel - questa è la versione minima che dovresti usare in produzione, la tua versione 3.16 del kernel fa schifo senza backport.

Ricorda anche che secondo Chris Mason considera ormai stabile Btrfs, ma non ancora pronto per la produzione.

— Marc Stürmer
fonte

Come definisci "noto"? Avevo cercato su Internet ampiamente e invano, e nessuno di coloro che hanno partecipato a questa discussione lo sapeva. Ma, comunque, ora sto solo alla larga btrfs. Troppo pubblicizzato mentre il suo sviluppo sembra durare per sempre.

— Antonis Christofides,

Bene, ad esempio ci sono persone di CoreOS. Hanno usato all'incirca Btrfs un anno come file system predefinito fino all'inizio del 2015, dove sono passati a Ext4 + Overlayfs. Ricorda però che questo era precedente alla versione 3.19 del kernel, che ha apportato molti miglioramenti a Btrfs. Dai anche un'occhiata a questa presentazione di ottobre 2015, che dà un'occhiata a ext4, xfs, zfs e btrfs sulle condizioni di carico di lavoro del database, vale a dire Postgres: de.slideshare.net/fuzzycz/… Un altro benchmark, anche se non così buono kernel: goo.gl/rR3kZ2

— Marc Stürmer il

E come ho detto, la versione del kernel del tuo box (3.16) è nota per essere afflitta da problemi di prestazioni, almeno usa 3.19 per cose serie su Btrfs secondo Chris Mason. Se vuoi usare seriamente Btrfs, usa sempre il kernel più recente e più grande - qualcosa che non funziona molto bene con Debian ... e il termine di ricerca "prestazioni dei metadati di btrfs".

— Marc Stürmer,

Sono un po 'in ritardo per questa festa, ma ecco un trucco per eliminare molto rapidamente alberi btrfs di grandi dimensioni:

Crea un sottovolume fittizio sullo stesso filesystem btrfs.
Sposta la directory di livello superiore che desideri rimuovere in detto sottovolume: questa operazione dovrebbe essere molto veloce se lo stai facendo sullo stesso filesystem btrfs, anche tra sottovolumi.
Distruggi il sottovolume.

Il kernel inizierà a recuperare lo spazio in background, quindi non avrai lo spazio disponibile abbastanza immediatamente, ma il processo dovrebbe essere molto più veloce di qualsiasi tipo di cancellazione della terra dell'utente.

— Nicolas Noble
fonte

È possibile rinominare la directory e quindi eliminare la directory rinominata in un processo in background. Questo non accelererà l'operazione di eliminazione. Tuttavia, ciò consentirebbe al programma di continuare con una directory vuota mentre l'operazione di eliminazione sta avvenendo sul lato.

Non sono sicuro che funzionerà nel tuo caso d'uso. Dipende se il programma non può continuare fino a quando il disco è inattivo (ovvero eseguirà alcune operazioni su disco pesante). Dipende se il programma riempirà il disco con molti dati.

— nathan
fonte