Pas d'espace sur l'appareil lors de la suppression d'un fichier sous OpenSolaris

Lors de la tentative de montage d'un partage NFS (exporté à partir d'un serveur OpenIndiana ) sur une boîte client, le serveur OI s'est bloqué. J'ai eu l'écran noir de la mort, ce qui ressemblait à une décharge de journaux, puis le système a été retraité. Il n'est jamais revenu et j'obtiens le message d'erreur suivant après avoir arrêté le démarrage:

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

Je n'ai rien d'autre sur le disque de démarrage autre que le système d'exploitation, alors ... Je ne sais pas ce qui pourrait remplir le disque? Peut-être un fichier journal d'une sorte? Je n'arrive pas à supprimer quoi que ce soit. Cela me donne une erreur sans espace lorsque j'essaie de supprimer quoi que ce soit:

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

Je peux me connecter en "mode maintenance" mais pas à l'invite utilisateur standard.

La sortie de dfest:

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

La sortie de mountest:

/ 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 

La sortie de 'zfs list -t all' est:

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, c'est bizarre… pas assez d'espace pour supprimer un fichier!

Cela s'avère être un problème relativement courant avec ZFS, bien qu'il puisse potentiellement survenir sur n'importe quel système de fichiers qui possède des instantanés .

L'explication est que le fichier que vous essayez de supprimer existe toujours sur un instantané. Ainsi, lorsque vous le supprimez, le contenu reste existant (dans l'instantané uniquement); et le système doit également écrire les informations indiquant que l'instantané contient le fichier, mais pas l'état actuel. Il n'y a plus de place pour ces informations supplémentaires.

Une solution à court terme consiste à rechercher un fichier créé après le dernier instantané et à le supprimer. Une autre possibilité consiste à rechercher un fichier qui a été ajouté après le dernier instantané et à le tronquer à la taille qu'il avait au moment du dernier instantané. Si votre disque est saturé parce que quelque chose a pollué vos journaux, essayez de supprimer les fichiers journaux les plus volumineux.

Un correctif plus généralement applicable consiste à supprimer certains instantanés. Vous pouvez répertorier les instantanés avec zfs list -t snapshot. Il ne semble pas y avoir de moyen facile de prédire la quantité d'espace qui sera récupérée si vous détruisez un instantané particulier, car les données qu'il stocke peuvent s'avérer nécessaires à d'autres instantanés et donc continueront à vivre si vous détruisez cet instantané. Sauvegardez donc vos données sur un autre disque si nécessaire, identifiez un ou plusieurs instantanés dont vous n'avez plus besoin et exécutez zfs destroy name/of/snap@shot.

Il y a une discussion approfondie de ce problème dans ce fil de discussion OpenSolaris .

C'est un problème bien connu avec les systèmes de fichiers en copie sur écriture: pour supprimer un fichier, le système de fichiers doit d'abord allouer un bloc et corriger le nouvel état avant de pouvoir libérer la richesse d'espace contenu dans le fichier qui vient d'être supprimé.

(Ce n'est pas un problème de systèmes de fichiers avec des instantanés, car il existe d'autres façons de les implémenter que la copie sur écriture)

Moyens de sortir de la pression:

• libérer un instantané (s'il y en a un ...)
• agrandir la piscine (au cas où il y aurait encore de la réserve que vous pourriez lui affecter)
• détruisez un autre système de fichiers dans le pool, puis développez le système de fichiers serré
• tronquer le fichier, puis le supprimer (bien qu'une fois que j'ai été trop serré pour pouvoir le faire, voir le fil sur ZFS Discuss )
• dissociez le fichier. (comme ci-dessus)

Je suis tombé dans le même piège il y a quelques années et je n'avais aucun instantané que j'aurais pu publier pour me libérer. Voir le fil de discussion sur ZFS où ce problème a été discuté en profondeur.

4.Z3G (colonne rpool / root USED) est douteux.

Dans tous les cas, rpool / export / home / admin étant trop volumineux (3,85 Go) est probablement la cause première. Jetez un œil à son contenu et supprimez-y les fichiers inutiles. Étant donné que le système de fichiers administrateur ne contient aucun instantané, cela devrait immédiatement libérer de l'espace dans le pool.

Je l'avais et j'ai passé un moment à essayer de comprendre ce qui était nécessaire. Ma solution était de mettre à zéro l'espace des fichiers avant d'essayer de les supprimer.

Nous avons des processus qui se comportent mal et qui deviennent parfois fous et remplissent le disque avec des fichiers de base (se terminant par un nombre), j'ai donc produit un script qui contient quelque chose comme ça pour en garder une copie.

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

Lorsque j'ai exécuté mon script, il a produit une erreur:

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

et était fonctionnel pour effacer les fichiers.

Pour tester cela, j'ai rempli le disque avec:

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