No hay espacio en el dispositivo al eliminar un archivo en OpenSolaris

Al intentar montar un recurso compartido NFS (exportado desde un servidor OpenIndiana ) en un cuadro de cliente, el servidor OI se bloqueó. Obtuve la pantalla negra de la muerte, que parecía un volcado de registro, luego el sistema se reinició. Nunca volvió a aparecer y recibo el siguiente mensaje de error después de detener el arranque:

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

No tengo nada más en la unidad de arranque que no sea el sistema operativo, así que ... No estoy seguro de qué podría estar llenando la unidad. Tal vez un archivo de registro de algún tipo? Parece que no puedo eliminar nada independientemente. Me da un error sin espacio cuando intento eliminar algo:

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

Puedo iniciar sesión en "Modo de mantenimiento" pero no en el aviso de usuario estándar.

La salida de dfes:

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 salida de mountes:

/ 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 salida de 'zfs list -t all' es:

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, esa es extraña ... ¡no hay suficiente espacio para eliminar un archivo!

Esto resulta ser un problema relativamente común con ZFS, aunque podría surgir en cualquier sistema de archivos que tenga instantáneas .

La explicación es que el archivo que está intentando eliminar todavía existe en una instantánea. Entonces, cuando lo elimine, el contenido seguirá existiendo (solo en la instantánea); y el sistema debe escribir adicionalmente la información de que la instantánea tiene el archivo pero el estado actual no. No queda espacio para esa pequeña información extra.

Una solución a corto plazo es encontrar un archivo creado después de la última instantánea y eliminarlo. Otra posibilidad es encontrar un archivo al que se haya agregado después de la última instantánea y truncarlo al tamaño que tenía en el momento de la última instantánea. Si su disco se llenó porque algo ha estado enviando spam a sus registros, intente recortar los archivos de registro más grandes.

Una solución más general aplicable es eliminar algunas instantáneas. Puede enumerar instantáneas con zfs list -t snapshot. No parece haber una manera fácil de predecir cuánto espacio se recuperará si destruye una instantánea en particular, porque los datos que almacena pueden ser necesarios para otras instantáneas y, por lo tanto, seguirán vigentes si destruye esa instantánea. Por lo tanto, haga una copia de seguridad de sus datos en otro disco si es necesario, identifique una o más instantáneas que ya no necesita y ejecútelas zfs destroy name/of/snap@shot.

Hay una discusión extendida sobre este tema en este hilo de foros de OpenSolaris .

Ese es un problema bien conocido con los sistemas de archivos de copia en escritura: para eliminar un archivo, el sistema de archivos primero debe asignar un bloque y corregir el nuevo estado antes de que pueda liberar la gran cantidad de espacio contenido dentro del archivo que se acaba de eliminar.

(Es no un problema de los sistemas de ficheros con instantáneas, ya que hay otras maneras de implementar estos que acaba de copy-on-write)

Salidas del apretón:

• liberar una instantánea (en caso de que haya una ...)
• crecer el grupo (en caso de que quede algún recambio que pueda asignarle)
• destruir otro sistema de archivos en el grupo, luego crecer el sistema de archivos apretado
• truncar el archivo, luego eliminarlo (aunque una vez que he estado apretado demasiado para poder hacer eso, vea el hilo en ZFS Discuss )
• desvincular el archivo. (lo mismo que arriba)

Me encontré con la misma trampa hace unos años, y no tenía ninguna instantánea que pudiera haber lanzado para liberarme. Vea el hilo en ZFS Discuta dónde se discutió este problema en profundidad.

4.Z3G (columna USADA rpool / root) es dudosa.

En cualquier caso, rpool / export / home / admin siendo demasiado grande (3.85 GB) es probablemente la causa raíz. Eche un vistazo a su contenido y elimine los archivos innecesarios allí. Como el sistema de archivos de administración no tiene instantáneas, esto debería liberar inmediatamente algo de espacio en el grupo.

Tuve eso y pasé un tiempo tratando de descubrir lo que se necesitaba. Mi solución fue poner a cero el espacio de los archivos antes de intentar eliminarlos.

Tenemos algunos procesos que se comportan mal y que se vuelven locos ocasionalmente y llenan el disco con archivos principales (que terminan en un número), así que produje un script que contiene algo como esto para mantener 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

Cuando ejecuté mi script, produjo un error:

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

y fue funcional borrando los archivos.

Para probar esto llené el disco con:

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