Nessuno spazio sul dispositivo durante la rimozione di un file in OpenSolaris

Durante il tentativo di montare una condivisione NFS (esportata da un server OpenIndiana ) su una casella client, il server OI si è bloccato. Ho ottenuto la schermata nera della morte, quella che sembrava una discarica, poi il sistema è stato ripristinato. Non è mai tornato indietro e ottengo il seguente messaggio di errore dopo aver interrotto l'avvio:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

Non ho nient'altro sull'unità di avvio diverso dal sistema operativo quindi ... Non sono sicuro di cosa potrebbe riempire l'unità? Forse un file di registro di qualche tipo? Non riesco a cancellare nulla a prescindere. Mi dà un errore senza spazio quando provo ad eliminare qualcosa:

$ rm filename
cannot remove 'filename' : No space left on device 

Posso accedere alla "Modalità di manutenzione" ma non al prompt utente standard.

L'output di dfè:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

L'output di mountè:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

L'output di 'zfs list -t all' è:

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Ok, è strano ... non c'è abbastanza spazio per rimuovere un file!

Questo risulta essere un problema relativamente comune con ZFS, anche se potrebbe potenzialmente insorgere su qualsiasi filesystem che abbia istantanee .

La spiegazione è che il file che si sta tentando di eliminare esiste ancora in un'istantanea. Quindi, quando lo elimini, il contenuto rimane esistente (solo nell'istantanea); e il sistema deve inoltre scrivere le informazioni secondo cui lo snapshot ha il file ma lo stato attuale no. Non c'è più spazio per quel po 'di informazioni in più.

Una soluzione a breve termine è trovare un file creato dopo l'ultima istantanea ed eliminarlo. Un'altra possibilità è quella di trovare un file che è stato aggiunto dopo l'ultima istantanea e troncarlo alla dimensione che aveva al momento dell'ultima istantanea. Se il disco si è riempito perché qualcosa sta inviando spam ai log, prova a tagliare i file di log più grandi.

Una correzione più generalmente applicabile è quella di rimuovere alcune istantanee. Puoi elencare le istantanee con zfs list -t snapshot. Non sembra esserci un modo semplice per prevedere quanto spazio verrà recuperato se si distrugge una particolare istantanea, perché i dati che archivia potrebbero rivelarsi necessari per altre istantanee e quindi sopravvivere se si distrugge quella istantanea. Quindi, se necessario, esegui il backup dei dati su un altro disco, identifica uno o più snapshot non più necessari ed esegui zfs destroy name/of/snap@shot.

C'è una discussione estesa di questo problema in questo thread del forum OpenSolaris .

Questo è un problema ben noto con i filesystem copy-on-write: per eliminare un file, il filesystem deve prima allocare un blocco e correggere il nuovo stato prima di essere in grado di liberare la ricchezza di spazio contenuta nel file appena eliminato.

(È non è un problema di file system con istantanee, in quanto vi sono altri modi di attuazione di questi non solo copy-on-write)

Modi fuori dalla compressione:

• rilasciare uno snapshot (nel caso ce ne sia uno ...)
• fai crescere il pool (nel caso in cui rimanga qualcosa di ricambio che puoi assegnargli)
• distruggere un altro filesystem nel pool, quindi aumentare il filesystem stretto
• troncare il file, quindi rimuoverlo (anche se una volta che sono stato in una stretta troppo stretta per essere in grado di farlo, vedere il thread su ZFS Discussione )
• scollegare il file. (come sopra)

Ho incontrato la stessa trappola qualche anno fa e non avevo istantanee che avrei potuto rilasciare per liberarmi. Vedi il thread su ZFS Discutere dove questo problema è stato discusso in modo approfondito.

4.Z3G (colonna USATO rpool / root) è dubbia.

In ogni caso, rpool / export / home / admin essendo troppo grande (3,85 GB) è probabilmente la causa principale. Dai un'occhiata al suo contenuto e rimuovi i file non necessari lì. Poiché il file system admin non ha istantanee, questo dovrebbe liberare immediatamente un po 'di spazio nel pool.

L'ho avuto e ho trascorso un po 'a cercare di capire cosa fosse necessario. La mia soluzione era di azzerare lo spazio dei file prima di provare a eliminarli.

Abbiamo alcuni processi che si comportano in modo anomalo che impazziscono di tanto in tanto e riempiono il disco di file core (terminando con un numero), quindi ho prodotto uno script che contiene qualcosa del genere per conservarne una copia.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

Quando ho eseguito il mio script, ha prodotto un errore:

mv: cannot rename core.200000 to core: No space left on device

ed era funzionale a cancellare i file.

Per provare questo ho riempito il disco con:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done