Errore "No space left on device" nonostante disponga di molto spazio, su btrfs


17

Quasi ovunque ricevo errori nei registri di cui mi lamento No space left on device

Registri di Gitlab:

==> /var/log/gitlab/nginx/current <==
2016-11-29_20:26:51.61394 2016/11/29 20:26:51 [emerg] 4871#0: open() "/var/opt/gitlab/nginx/nginx.pid" failed (28: No space left on device)

Registri e-mail Dovecot:

Nov 29 20:28:32 aws-management dovecot: imap(email@www.sitename.com): Error: open(/home/vmail/emailuser/Maildir/dovecot-uidlist.lock) failed: No space left on device

Uscita di df -Th

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     ext4      7.8G  3.9G  3.8G  51% /
devtmpfs       devtmpfs  1.9G   28K  1.9G   1% /dev
tmpfs          tmpfs     1.9G   12K  1.9G   1% /dev/shm
/dev/xvdh      btrfs      20G   13G  7.9G  61% /mnt/durable
/dev/xvdh      btrfs      20G   13G  7.9G  61% /home
/dev/xvdh      btrfs      20G   13G  7.9G  61% /opt/gitlab
/dev/xvdh      btrfs      20G   13G  7.9G  61% /var/opt/gitlab
/dev/xvdh      btrfs      20G   13G  7.9G  61% /var/cache/salt

Sembra che ci sia anche un sacco di spazio inode. Uscita didf -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 105031 419257   21% /
devtmpfs       475308    439 474869    1% /dev
tmpfs          480258      4 480254    1% /dev/shm
/dev/xvdh           0      0      0     - /mnt/durable
/dev/xvdh           0      0      0     - /home
/dev/xvdh           0      0      0     - /opt/gitlab
/dev/xvdh           0      0      0     - /var/opt/gitlab
/dev/xvdh           0      0      0     - /var/cache/salt

Uscita di btrfs fi show

Label: none  uuid: 6546c241-e57e-4a3f-bf43-fa933a3b29f9
        Total devices 4 FS bytes used 11.86GiB
        devid    1 size 10.00GiB used 10.00GiB path /dev/xvdh
        devid    2 size 10.00GiB used 9.98GiB path /dev/xvdi
        devid    3 size 10.00GiB used 9.98GiB path /dev/xvdj
        devid    4 size 10.00GiB used 9.98GiB path /dev/xvdk

Uscita di btrfs fi df /mnt/durable

Data, RAID10: total=17.95GiB, used=10.12GiB
Data, single: total=8.00MiB, used=0.00
System, RAID10: total=16.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID10: total=2.00GiB, used=1.74GiB
Metadata, single: total=8.00MiB, used=0.00
unknown, single: total=272.00MiB, used=8.39MiB

Quale potrebbe essere la causa di questo? Sto usando una base Linux AMI ec2 versione kernal 4.4.5-15.26.amzn1.x86_64

Aggiornare

L'esecuzione del comando suggerito di seguito btrfs fi balance start -dusage=5 /mnt/durablemi ha restituito un errore del seguente:

ERROR: error during balancing '/mnt/durable' - No space left on device There may be more info in syslog - try dmesg | tail

Dopo aver eliminato manualmente un mucchio di file più grandi per un totale di ~ 1 GB, ho riavviato la macchina e riprovato, assicurandomi di utilizzare sudo e il comando eseguito. Ho quindi riavviato la mia macchina ancora una volta per buona misura e sembra aver risolto il problema


Avete qualche tipo di configurazione delle quote?
Zoredache,

Gli strumenti generici non sono in grado di comprendere correttamente BTRFS, sono necessari strumenti specifici BTRFS. Per favore, aggiungi l'output di "btrfs fi show" e "btrfs fi df / mnt / lasting"
Peter Green,

@PeterGreen ha aggiunto l'output di btrfs ... sembra che tu abbia trovato il colpevole.
Austin,

Puoi anche aggiungere l'output del secondo comando che ho suggerito.
Peter Green,

2
La versione del kernel è piuttosto importante qui, poiché btrfs ha avuto un certo numero di problemi con lo spazio libero in passato, e nel caso in cui questa sia un'altra istanza i futuri lettori potrebbero trarre vantaggio da tali informazioni.
PlasmaHH,

Risposte:


19

Benvenuti nel mondo di BTRFS. Ha alcune caratteristiche allettanti ma anche alcuni problemi esasperanti.

Prima di tutto, alcune informazioni sulla tua configurazione, sembra che tu abbia quattro unità in un volume "raid 10" di BTRFS (quindi tutti i dati vengono memorizzati due volte su dischi diversi). Questo volume BTRFS viene quindi suddiviso in sottovolumi su diversi punti di montaggio. I sottovolumi condividono un pool di spazio su disco ma hanno numeri di inode separati e possono essere montati in luoghi diversi.

BTRFS alloca spazio in "blocchi", un blocco viene allocato a una classe specifica di dati o metadati. Ciò che può accadere (e sembra che sia accaduto nel tuo caso) è che tutto lo spazio libero viene allocato in blocchi di dati senza lasciare spazio ai metadati

Sembra anche che (per motivi che non capisco del tutto) che i BTRF "esauriscano" lo spazio dei metadati prima che l'indicatore della percentuale di spazio dei metadati utilizzato raggiunga il 100%.

Questo sembra essere quello che è successo nel tuo caso, c'è molto spazio libero per i dati ma non c'è spazio libero che non è stato assegnato a blocchi e spazio libero insufficiente nei blocchi di metadati esistenti.

La correzione è eseguire un "riequilibrio". Ciò sposterà i dati in modo che alcuni blocchi possano essere restituiti al pool libero "globale" dove possono essere riallocati come blocchi di metadati

btrfs fi balance start -dusage=5 /mnt/durable

Il numero dopo -dusagestabilisce quanto sia aggressivo il ribilanciamento, ovvero quanto vicino devono essere vuoti i blocchi per essere riscritti. Se la bilancia dice che ha riscritto 0 blocchi, riprovare con un valore superiore di -dusage.

Se il saldo non riesce, proverei a riavviare e / o liberare spazio rimuovendo i file.


9
il riequilibrio è la nuova deframmentazione.
Nathan Osman,

1
Andare in ERROR: error during balancing '/mnt/durable' - No space left on devicepareggio dopo aver eliminato quasi 1 GB dall'unità
Austin,

Hai provato a riavviare (il riavvio dopo la pulizia ha funzionato per me quando ho avuto un problema simile).
Peter Green,

@PeterGreen Aggiunti i contenuti del dmesg | tailmio post dopo aver ricevuto un nuovo errore dopo il riavvio.
Austin,

4

Dato che stai eseguendo btrfs con una configurazione RAID, prova a eseguire un'operazione di bilanciamento.

btrfs balance start /var/opt/gitlab

Se viene visualizzato un errore relativo allo spazio insufficiente, riprovare con questa sintassi:

btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab 

Ripetere questa operazione per ciascun filesystem btrfs in cui vengono visualizzati errori sullo spazio. Se il tuo problema di spazio è dovuto alla mancata distribuzione dei metadati sui dischi con mirroring, questo potrebbe liberare spazio per te.


Ho ricevuto un errore relativo allo spazio. Quando provo l'altra sintassi mi mostra quello che sembra un avvertimento: va Refusing to explicitly operate on system chunks. Pass --force if you really want to do that.bene farlo?
Austin,

provalo senza l' -susage=0opzione.
Virtex,

2

Sul mio sistema, ho aggiunto il seguente lavoro in cron.monthly.

Il clear_cacherimontaggio è dovuto ad alcuni problemi di corruzione che btrfs stava riscontrando con le mappe gratuite. (Penso che alla fine abbiano trovato il problema, ma il problema è così fastidioso, sono disposto a pagare per ricostruire le mappe una volta al mese.)

Accelero le usageopzioni per liberare gradualmente spazio per bilanci sempre più grandi.

#!/bin/sh

for mountpoint in `mount -t btrfs | awk '{print $3}' | sort -u`
do
    echo --------------------------
    echo Balancing $mountpoint :
    echo --------------------------
    echo remount with clear_cache...
    mount -oremount,clear_cache $mountpoint
    echo Before:
    /usr/sbin/btrfs fi show $mountpoint
    /usr/sbin/btrfs fi df $mountpoint
    for size in 0 1 5 10 20 30 40 50 60 70 80 90
    do
        time /usr/sbin/btrfs balance start -v -musage=$size $mountpoint 2>&1
        time /usr/sbin/btrfs balance start -v -dusage=$size $mountpoint 2>&1
    done
    echo After:
    /usr/sbin/btrfs fi show $mountpoint
    /usr/sbin/btrfs fi df $mountpoint
done

Se si arriva al punto in cui non è possibile riequilibrare perché lo spazio è insufficiente, si consiglia di aggiungere temporaneamente un altro dispositivo a blocchi (o dispositivo di loopback su un altro disco) di qualche tipo al volume per la durata del riequilibrio, quindi rimuoverlo.


Grazie mille @rrauenza! La tua sceneggiatura mi ha davvero salvato la giornata. Nel mio caso il comando di bilanciamento è riuscito a spostare pezzi a partire da 60 anni.
Michal Fapso

1

Questo non è un grosso problema con btrfs, ma è qualcosa che è stato fatto a questo sistema. Questo sembra il risultato di un ribilanciamento incompleto da una politica di allocazione "singola" a una politica di allocazione "raid 10", come evidenziato dalla grande quantità di singoli blocchi allocati. Probabilmente è iniziato come singolo e quindi una conversione è stata interrotta. Un pool con un'allocazione così incoerente è destinato ad avere ... beh, problemi di allocazione.

Considera che hai consumato il 61% del tuo pool. Il criterio di allocazione è RAID10, quindi ciò dovrebbe comportare un consumo massimo del 50% del pool prima di raggiungere il pieno, poiché tutto è replicato 2. Ecco perché la conversione da singolo a RAID 10 non è riuscita (e continua a farlo). Posso solo immaginare, ma probabilmente è stato assegnato a nel mezzo di un riequilibrio. Non c'è spazio sul tuo dispositivo per riequilibrare un RAID 10 con i dischi che hai. L'unico motivo per cui sei arrivato al 61% è perché i tuoi dischi sono allocati incoerenza, alcuni in modo lineare con allocazione singola e la maggior parte in RAID 10.

Potresti riequilibrare una singola politica di allocazione se volessi guadagnare spazio senza cambiare granché. È inoltre possibile aggiungere più dischi o aumentare le dimensioni dei dischi. O potresti, come hai fatto in questo caso, eliminare solo un mucchio di file in modo che il tuo pool possa effettivamente bilanciarsi con RAID 10 (dato che sarebbe consumato meno del 50% nel complesso). Assicurati di riequilibrare dopo aver eliminato i file, o avrai comunque questa politica di allocazione janky.

In particolare, applicare RAID 10 durante il riequilibrio dopo aver eliminato quei file per assicurarsi di sbarazzarsi di quei singoli blocchi allocati, in questo modo:

btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.