C'è qualche altro motivo per "nessuno spazio lasciato sul dispositivo"?


12

Sto usando Dirvish su un sistema server Ubuntu per il backup di un hd su un'unità USB 3.0 esterna. Fino a pochi giorni fa, tutto funzionava bene, ma ora ogni backup fallisce senza "spazio sul dispositivo (28)" e "file system pieno". Sfortunatamente non è così semplice: sul dispositivo ci sono> 500 GB gratuiti.

Dettagli:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

il registro appare praticamente come al solito fino a quando non colpisce:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

Ma, come detto sopra, c'è molto spazio sul dispositivo:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

e inoltre ci sono molti inode rimasti:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

Il dispositivo è montato come rw:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

Il processo è in esecuzione come root.

Stavo per dire che non ho cambiato nulla, ma non è del tutto vero: ho acceso acl per l'unità di cui sto eseguendo il backup:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

Potrebbe essere questo il problema? Se si, come? root ha ancora pieno accesso ai file.

MODIFICARE:

Ho appena controllato le directory temporanee:

  • / tmp contiene solo una cartella .webmin vuota
  • / var / tmp è vuoto

il file system in cui risiedono queste directory ha molto spazio libero e inode:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

Le directory sono piuttosto grandi, ma non> 2 GB. Quello in cui il backup fallisce non è nemmeno uno dei più grandi, contiene 7530 file.

Edit3:

Un'informazione che non ho ritenuto pertinente nel pubblicare questa domanda:

Il giorno prima che i backup iniziassero a fallire avevo attivato acls sui file system di cui era stato eseguito il backup. Suppongo ora che questo abbia spinto Dirvish (o rsync) a pensare che tutti i file fossero cambiati, quindi l'elenco dei file da copiare piuttosto che hard link era molto grande. Questo potrebbe significare che alcuni buffer erano troppo piccoli.

Oggi un backup completo su un disco vuoto ha funzionato perfettamente. Proverò un backup incrementale dopo. Questo mostrerà se l'attivazione di acls è stata la causa del problema.


Risposte:


4

Il mio sospetto (vedi EDIT3) apparentemente aveva ragione: aggiungere il supporto acl al file system ha fatto pensare a rsync / dirvish che tutti i file fossero cambiati. Quindi, invece di fare un backup incrementale e creare semplicemente collegamenti reali ai file già esistenti, ha provato a creare un backup completo che ovviamente non è riuscito perché il disco rigido non aveva abbastanza spazio per quello.

Quindi il messaggio di errore era effettivamente corretto.

Dopo aver riavviato con un disco di backup vuoto, i backup incrementali hanno funzionato come prima.


4

Guardare il 2% degli inode rimasti mi ha fatto pensare alle riserve di root che il filesystem EXT impone. Potresti voler dare un'occhiata a questi:

  1. " Spazio riservato per root su un filesystem - perché? "
  2. " Dimensioni ragionevoli per" blocchi riservati del filesystem "per dischi non OS? "

Vorrei provare a .tar.gz alcuni dei backup più vecchi sperando che ridurrebbe il numero di inode in uso.


2
La penultima colonna di dfoutput è la percentuale di Inodi utilizzati, quindi viene utilizzato il 2% degli Inodi e il 98% viene lasciato.
Deve il

3

Vedo che dummzeuch trova una soluzione al suo problema, ma in realtà c'è un altro caso in cui ho scoperto che il disco può avere abbastanza inode / spazio libero e che mostra ancora "nessuno spazio lasciato sul dispositivo" durante il tentativo di trasferire determinate directory.

Ciò è causato da collisioni di hash su dispositivi a blocchi formattati con il file system ext4 in cui l'indicizzazione della directory è abilitata anche in particolare dove una singola directory contiene più di 100k file e il nome dei file viene generato dallo stesso algoritmo (file cache, nomi file md5sum ecc. .)

La soluzione è provare con un altro algoritmo di indicizzazione di directory:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

o per disabilitare completamente l'indicizzazione della directory per quel dispositivo a blocchi (potrebbe danneggiare le prestazioni)

tune2fs -O ^dir_index /dev/blockdev_name

Un'altra soluzione è vedere cosa sta riempiendo la directory con tali file e riparare il software.

La possibile soluzione è dividere il contenuto della cartella con un volume enorme di file in più sottocartelle separate.

La descrizione completa del problema è presentata da Axel Wagner qui

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

Saluti.


1

Esiste un limite di dimensioni di 2 GB sulla directory stessa, ovvero se hai così tanti file che la dimensione della directory è> 2 GB (NON la dimensione dei file nella directory), avrai un problema. Detto questo, con solo 2.8M di inode utilizzati, questo non dovrebbe essere un problema. Di solito accade intorno a 15 milioni di inode.

Quindi questo potrebbe non essere di grande aiuto, ma prova ext4 sul tuo dispositivo di backup?


Le directory non sono così grandi. Modifiche ai semi.
Dummzeuch,

1
Le tue modifiche non mostrano le dimensioni effettive delle directory. Prova questo: find /mnt/backupsys/shd -type d -exec ls -ld {} \;per vedere le dimensioni effettive delle directory.
Jenny D,

1

Aumenta il limite di watcher di Inotify in sysctl:

fs.inotify.max_user_watches = 100000 

E riavvia o esegui anche la sysctl -wversione.

Di solito lo farà. Qualcosa ha troppi file aperti nel kernel e l'errore è totalmente fuorviante. Dropbox ne è un classico esempio.


Avresti potuto avere ragione. Sfortunatamente avevo già riavviato il computer a causa di un aggiornamento del kernel prima di leggere il tuo suggerimento. Successivamente ho avviato il backup ed è ancora in esecuzione felicemente. Vedrò se finisce e anche cosa succede con il prossimo in programma.
dummzeuch,

Questo risolto un problema che stavo vedendo: ho Dropbox e qualsiasi altra cosa guidata da inotify fallirebbe con il messaggio "Nessuno spazio lasciato sul dispositivo".
Steve

0

Ti suggerirei di verificare un paio di altre cose:

  1. Controlla se la tua directory temporanea non si sta riempiendo. A volte viene utilizzato per l'archiviazione intermedia e si riempie facilmente.
  2. Controlla se esiste un processo che contiene ancora un descrittore di un file eliminato. Le probabilità sono meno probabili dal momento che df riporta dimensioni adeguate ma non farà male.

Controllato / tmp e / var / tmp. Vedi le modifiche.
Dummzeuch,

Guarda anche la quota (limiti utente). Non so perché stai usando rsync per un backup locale, comunque. : ~ /
Dennis,

0

Ho appena trovato questo argomento durante la ricerca di una soluzione al mio problema.

In effetti, esiste almeno un altro motivo per ENOSPC. E l'ho trovato anche con rsync, mentre copiavo da un file system ZFS a uno EXT4:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

In questo caso:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr spiega:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

Nel mio caso, significa che devo riformattare l'intero file system. :-(

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.