¿Cómo lidiar con escenarios de "disco lleno"?

Question

La gran mayoría de las aplicaciones no maneja correctamente los escenarios de "disco lleno".

Ejemplo: un instalador no ve que el disco está lleno, ignora todos los errores y finalmente anuncia felizmente "instalación completa!", O un programa de correo electrónico no sabe que el mensaje que acaba de descargar no se pudo guardar, y le dice al servidor que elimine el original.

¿Qué técnicas existen para manejar esta situación con elegancia? ¿Los usas? ¿Los pruebas?

Answer 1

Como usuario, quiero software para:

1. Preserve mis datos.
2. Validar mi entorno lo antes posible, antes de Hago un trabajo real.
3. Si #2 es imposible, dime acerca de los requisitos especiales.
4. Limpiar después de sí mismo.

Como desarrollador, las técnicas para hacer esto incluyen:

1. Abortando única cuando no hay otra alternativa, y que permite al usuario la oportunidad de hacer una nueva elección si el anterior falla (ver Respuesta de AgentThirteen).
2. Comprobando los recursos necesarios (memoria, espacio en disco, periféricos) tan pronto como sea posible. Deténgase inmediatamente si la falla es segura; mostrar una advertencia si el éxito es incierto, lo que permite al usuario elegir si continuar.
3. Preasignación de recursos para garantizar que aún estén disponibles cuando sean necesarios.
4. Mostrando advertencias y errores en diálogos no modales para que el usuario pueda colocar la aplicación en segundo plano y utilizar otras herramientas para solucionar el problema.
5. Mantener una lista de "deshacer": el historial de acciones que se han llevado a cabo hasta el momento. Si la aplicación debe abortar, ofrezca la oportunidad de deshacer esas acciones.

Answer 2

Para ampliar esto aún más, ¿existen técnicas para manejar "disco lleno" en un servidor SQL? Nunca debería suceder, lo sé, pero puede (y me ha sucedido a mí).

Estoy familiarizado con las pruebas de disco completo en aplicaciones de PC independientes (habiendo crecido la programación en la era de disquete). Incluso en un sistema SCO Unix más antiguo que era muy estrecho en el espacio y se congelaría si se quedaba sin espacio. No estoy tan familiarizado con lo que significa en un sistema moderno.

Answer 3

Compruebo los errores cuando abro, escribo o cierro un archivo. Por otro lado, no hago nada en particular para manejar los errores de "disco lleno". En cambio, confío en el sistema operativo subyacente para informarme esos errores de la misma forma que informa cualquier otro tipo de error.

Answer 4

Trabajo con el software de adquisición de datos. Como puedo estimar el tamaño de un archivo antes de crearlo (basado en la cantidad de datos solicitados para adquirir), advierto incluso antes de crear el archivo en función de la cantidad de espacio disponible en disco si espero que me quede sin espacio. .

Answer 5

Tiene toda la razón. El software debe manejar con gracia este tipo de situación.

Siempre puede verificar una IOException para ver si el disco está lleno o si el usuario tiene derechos para escribir en esa ubicación.

SQL Server maneja esta situación pero no se recupera de ella. Cuando el disco está lleno ... deja de funcionar. :)

Answer 6

Es importante estructurar sus rutinas de persistencia para que estén dentro de un bloque que bucles, lo que solicita al usuario seleccionar una ubicación y luego intentar guardarla, hasta que los datos se guarden correctamente o el usuario decida cancelarlos. Me parece obvio, pero he visto muchas aplicaciones que hacen clic en una excepción cuando intentas persistir, que ni siquiera se maneja, y que empujan la ejecución hacia arriba fuera de tu rutina y pierden tus datos en la memoria.

Answer 7

Como suele ser el caso, mi posición sobre esta pregunta contradice el pensamiento convencional.

En general, ignoro el espacio fuera del disco de la misma manera que ignoro la falta de memoria. En parte porque es imposible predecir de manera confiable estas condiciones. En parte porque cuando hablamos del comportamiento del software en condiciones inesperadas (como un error que no sabe que tiene y que hace que se coma todo el disco o la memoria), es imposible razonar lo suficiente sobre la situación para codificarlo. Y PRUEBA. (Es seguro suponer que si tiene un código que no está probado, no funciona).

Sin embargo, hay condiciones específicas que indican un enfoque diferente:

• Si usted está sosteniendo importante, el estado del usuario y sin guardar (como un archivo de texto con algunas modificaciones), considere pre-guardar los datos en el fondo, para que un choque sea recuperable más tarde.

• Si está a punto de escribir en el disco en función de un comando de usuario interactivo (por ejemplo, Archivo-> Guardar), puede detectar un error y ofrecerles que lo intenten de nuevo.

En ambos casos, es importante que los errores se vean como errores. Los errores colapsados ​​deberían colapsar. Capturar excepciones inesperadas y continuar silenciosamente le roba oportunidades de diagnóstico mientras deja su software en un estado inseguro.

Answer 8

Acabamos de agregar compatibilidad con esto en nuestro producto. Al ejecutar en un dispositivo incrustado, comprobamos que el espacio en el disco sea inferior al 20% (10mb) cada hora, transmitimos advertencias al servidor de la oficina, registramos el problema y advertimos al usuario.

Una vez que esté en este estado, revisamos cada dos minutos el espacio sub 2mb y detenimos la aplicación con gracia (un sistema de guía) y nos negamos a ejecutar hasta que se resuelva el problema de espacio.

Como nuestro producto es un sistema central en el lugar de trabajo de nuestros clientes, esto capta la atención.

Answer 9

Si estoy escribiendo una aplicación, puedo hacer que se recupere de alguna manera de la falla de E/S, pero si estoy ejecutando la aplicación de otra persona, tengo que tomar un enfoque diferente, que es recuperar tanto espacio de disco como sea posible. This is the method I use. Puede haber grandes cantidades de espacio de disco recuperable en forma de 1) una pequeña cantidad de archivos grandes escondidos profundamente en directorios oscuros, o 2) una gran cantidad de archivos pequeños dispersos por el disco, nuevamente en ubicaciones no obvias. Este método los encuentra de cualquier manera.

Answer 10

Para realizar pruebas, cree particiones pequeñas que se queden sin espacio en diferentes puntos, tal vez como PC virtuales para que las pruebas estén bien contenidas y sean reproducibles.

Answer 11

Sí, probablemente sea una muy mala idea tratar de hacer algo "inteligente" sobre este tipo de problema. Básicamente, lo máximo que puede hacer es intentar minimizar la pérdida. Para aplicaciones interactivas con datos de usuario no guardados, intente evitar colisiones antes de que el usuario tenga la oportunidad de resolver el problema.