¿Está bien simplemente tirar del enchufe?


18

Cada vez que apago mi pi, uso sudo poweroff, que (en mi opinión) es una forma segura de detener todos los procesos y apagar.

Aunque a veces cuando uso el Pi para proyectos integrados en los que no siempre estoy haciendo SSHing al Pi, a menudo parece que me lleva tiempo sacar mi teléfono o una computadora portátil y conectarme al Pi para apagarlo.

Algunas personas con las que he hablado han dicho que simplemente desconectan el cable de alimentación cuando quieren apagarse, y que nunca han notado ningún problema con esto.

Entonces, ¿qué puede salir mal con solo desconectar el Pi? ¿Debo comenzar simplemente desconectando?

Nota: en este caso no me preocupa demasiado la pérdida de datos. Guardo copias de seguridad periódicas y los únicos datos importantes en este Pi están en mi GitHub.


1
Aconsejaría que no desconecte el enchufe, ya que enchufar y desenchufar constantemente el cable de alimentación reducirá la vida útil del conector en el Pi. En segundo lugar, la tarjeta SD podría estar en el medio de realizar una operación cuando desconecta el enchufe; es probable que la corrompa. Y eso va a ser un inconveniente independientemente de qué tan bien haga una copia de seguridad de sus datos.
Darth Vader

2
@DarthVader ¿Qué quiere decir con "reducir la vida útil del conector"? No me desconectaría y enchufaría con más frecuencia, solo me desconectaría antes de un apagado. ¿Corromper la tarjeta SD es el único problema aparte de eso? ¿Formatear la tarjeta SD siempre hará que la tarjeta sea utilizable nuevamente?
James Vickery

1
Todavía creo que es mejor dejar el Pi enchufado y apagar la corriente en la pared. puede recuperar una tarjeta SD dañada formateando y reinstalando su sistema operativo de su elección, pero evitar la corrupción de la tarjeta SD en primer lugar es ciertamente recomendable. Otro problema es que partes del Pi podrían estar en el proceso de hacer algo y usted ha cortado el poder sin que se les dé la oportunidad de terminar lo que estaban haciendo.
Darth Vader

Respuestas:


23

No tengo el hábito de desconectar el pi en el sentido de evitar apagarlos correctamente, excepto cuando he perdido la conexión de red en un pi sin cabeza, en cuyo caso generalmente soy demasiado vago para enchufar un teclado, etc.

En general, siempre verifico para asegurarme de que la luz verde ACT no esté encendida en ese punto; para modelos recientes (¿o firmware?) esto estará apagado cuando no se acceda a la tarjeta SD. De eso es de lo que quieres asegurarte. A menos que esté escribiendo constantemente, esto debería ser lo suficientemente simple; siempre que haya una cantidad decente de espacio libre en la RAM libre (digamos 50-100 + MB, dependiendo del contexto), entonces las cosas que son propensas a ser reutilizadas con frecuencia pero que en realidad no están cargadas por un proceso en un momento dado estará almacenado en caché en la memoria libre y el SO lo volverá a cargar, no el medio físico real. Así es como funcionan todos los sistemas operativos contemporáneos de uso general.

Si el pi está haciendo uso de la tarjeta SD, esto es el riesgo mínimo : el sistema de archivos en la tarjeta no está sincronizado con el estado en memoria. Normalmente, esto probablemente no sea un gran problema; Para empezar, el diario del sistema de archivos utilizado de forma predeterminada en la mayoría de los pis podría ser una defensa contra él, al igual que el fsck que se debe aplicar automáticamente en el arranque si el sistema de archivos no se desmontó limpiamente. Explicaré por qué digo "podría" y no "es" en breve, porque en este contexto creo que a menudo podría no serlo .

Hasta donde sé, nunca terminé con la corrupción del sistema de archivos o la pérdida de datos al desconectar, lo que podría haber hecho cien o más veces a lo largo de los años. Sin embargo, de nuevo, no lo hago habitualmente. Si lo hace varias veces al día, puede encontrarse con el nivel de riesgo estadístico y hay una captura potencialmente desagradable.

Aquí está el problema:

Recientemente se me ocurrió que hay un problema con las tarjetas SD contra el cual los mecanismos del sistema operativo / sistema de archivos pueden ser impotentes, y lo que puede explicar por qué algunas personas parecen tener problemas persistentes con la corrupción de FS, particularmente aquellos que se tiran del cable independientemente del sistema estado - por ejemplo, recientemente alguien aquí afirmó estar ejecutando módulos de cómputo donde la corrupción dejó los sistemas no arrancables en ~ 1/40 tales cortes de energía.

En términos abstractos, sin tener en cuenta la naturaleza de las tarjetas SD , eso no debería suceder incluso si el sistema está ocupado, porque lo que es más probable que termine dañado son las cosas no críticas que se están escribiendo, no cualquier software del sistema que esté efectivamente solo lectura y solo se altera durante las actualizaciones.

Podría suceder si se manipulan bits, por lo que la metainformación del sistema de archivos que almacena dónde se encuentran varios bits está dañada. Una vez más, sin embargo, Journalling y fsck deberían ser capaces de lidiar con esto, lo que requiere que el kernel arranque, pero el kernel en el pi está en una partición de arranque separada que también podría desmontarse durante el uso (excepto cuando se actualiza) porque nada de esto se usa después de que el sistema se haya iniciado. Lo que significa que la información sobre la partición debe ser, efectivamente, incorruptible, incluso cuando se deja montada.

Pero...

Las tarjetas SD son una caja negra para el sistema operativo. No hay forma de salir de eso. Si bien existen controladores específicos para los controladores de tarjetas SD que forman parte del hardware de la computadora (en la pi, esto es parte del SoC), no existe un controlador para diferentes marcas y modelos específicos de tarjetas.

Y, sin embargo, todos tienen microcontroladores dentro de ellos que pueden funcionar de maneras muy diferentes. 1. Esto es lo que hace que la tarjeta sea una caja negra; interactúa con el sistema operativo a través de un protocolo SD estandarizado, y ese es el último punto de control que tiene el sistema operativo.

Una de las cosas que hacen las tarjetas SD y otros medios de estado sólido que es diferente de los discos giratorios tradicionales es usar direccionamiento virtual opaco; no almacenan información físicamente en las secuencias que percibe el sistema operativo. Esto es principalmente algo bueno, o de lo contrario podríamos necesitar controladores diferentes para diferentes marcas de tarjetas, etc., y permite que las tarjetas implementen (opacamente) la nivelación del desgaste , lo que prolonga significativamente su vida útil.

Otra cosa en la que confían es en "bloques de borrado" relativamente grandes; Cuando los datos en un bloque necesitan ser cambiados, todo el bloque es borrado y reescrito. Los sistemas de archivos también hacen este tipo de cosas de manera habitual, pero tenga en cuenta que se trata de un nivel de software del sistema, y ​​los problemas que resultan de esto son exactamente los tipos de problemas que se fsckenfrentan y tratan.

El quid del problema más insalvable es que los sistemas de archivos de escala hacen eso generalmente es mucho más pequeño que las tarjetas SD de escala. Si no fuera así, terminaría desperdiciando una gran cantidad de espacio de almacenamiento, porque un bloque del sistema de archivos solo puede contener datos de un archivo. Si el bloque es de 2 MB y solo hay unos pocos KB de datos, el resto se desperdicia. Por lo tanto, los bloques del sistema de archivos tienden a oscilar entre 1/2 KiB y 4 KiB.

Es bastante obvio que las tarjetas SD no hacen eso y, de hecho, no pueden hacerlo, porque el controlador en una tarjeta SD no tiene conocimiento de los límites tales como "archivo", "sistema de archivos" o incluso "partición del dispositivo". Solo trata con los fragmentos de datos que el sistema operativo desea, a través de una capa opaca desde el interior de una caja negra donde cualquier cosa podría estar sucediendo a nivel físico.

Una de las razones por las que es obvio (aparte de las tarjetas de premisas "no podía hacer eso en primer lugar") es que esos bloques son con frecuencia bastante grandes, sin embargo, las tarjetas parecen hacer un trabajo decente al utilizar todo el espacio. Un bloque de borrado puede tener varios megabytes de tamaño. Además, los detalles son propietarios. Si bien puede haber mecanismos por los cuales el sistema operativo puede solicitar el tamaño de bloque de borrado de la tarjeta, la tarjeta no tiene que proporcionar esto, puede mentir al respecto, y sería absurdo si el sistema operativo intentara aprovecharlo.

De esto se desprende que desde:

  1. El controlador de la tarjeta SD no tiene idea de qué datos "legítimamente" pertenecen, en el sentido de sistemas de archivos coherentes y pariticiones, y

  2. La tarjeta SD es una caja negra en la que el sistema operativo realmente no puede ver,

Entonces, lo que está en un bloque de borrado de 1 MB dado, donde una tarjeta contiene varias particiones usando 4 KiB o bloques de sistema de archivos más pequeños, será arbitrario una vez que la tarjeta se haya usado lo suficiente (y posiblemente incluso si no se ha usado mucho en todos). Esto probablemente sea cierto incluso si intenta forzar al sistema operativo a usar tamaños de bloque más grandes / correspondientes; terminarán desalineados.

Entonces:

Si se corta la alimentación mientras la tarjeta SD está en medio de la alteración de un bloque, eso podría provocar la pérdida de un volumen bastante grande de datos arbitrarios que podrían ser cualquier cosa de la tarjeta. Podría ser información marcada como "solo lectura". Podría ser información de una partición que ni siquiera está montada y, obviamente, de la partición de arranque en su mayoría no utilizada.

Si eso sucede y la tarjeta no tiene algún tipo de sistema de protección propio (que algunos pueden tener, pero estoy seguro de que la mayoría no), entonces podría estar viendo una situación FUBAR. Journalling no protegerá contra la corrupción aleatoria del tamaño de MB que ni siquiera reconoce los límites de partición. O fsck.

O, dado que el hardware de la tarjeta es generalmente propietario, podría cualquier otra cosa, excepto el software producido por el fabricante de la tarjeta, suponiendo que sea plausible. Nunca he oído hablar de eso. Esto haría que las tarjetas sean más complicadas, más caras y más complicadas de usar. Cuál no es el objetivo.

Dicho de otra manera, las tarjetas SD no están destinadas a ser utilizadas de manera confiable de esta manera . Son baratos y muy prácticos, pero ese es el resultado de una compensación en el protocolo: en general, no hay garantía de integridad de datos para nada en la tarjeta si matas arbitrariamente el poder.

¿Qué puede salir mal con solo desconectar el Pi? ¿Debo comenzar simplemente desconectando? Nota: en este caso no me preocupa demasiado la pérdida de datos.

No dañará físicamente el pi, no, solo tenga cuidado con que la "pérdida de datos" podría extenderse a la "tarjeta inútil" que necesita ser reformateada por completo. Sin embargo, diría que la posibilidad de que si lo está haciendo con la luz ACT verde apagada sea muy baja.


  1. Esto puede ser significativo cuando se considera por qué algunas marcas / modelos de tarjeta específicos son claramente peores que otras para algunas personas. Desafortunadamente, si bien dos tarjetas que están etiquetadas de manera idéntica pueden ser idénticas en términos de características establecidas (tamaño, velocidad, etc.), los fabricantes no están obligados a hacerlas realmente 100% idénticas en términos de partes constituyentes.

1

Depende en gran medida del esquema de trabajo de su sistema operativo:

  • Si está utilizando un esquema estándar, cuando está utilizando su tarjeta SD en modo r / w para datos reales (intercambiar particiones no cuenta aquí), entonces es un problema como en el caso habitual de "enchufar una PC" : está en todo Google, por lo que tendrá toneladas de información sobre el caso. Es exactamente lo mismo: los mismos problemas, los mismos riesgos y el mismo impacto.
  • Si solo está leyendo datos de su tarjeta SD, es decir, monte cada partición que contenga datos de su tarjeta SD con la roopción, entonces definitivamente no es un problema simplemente desconectar: ​​está terminando el trabajo de sus servicios, están a punto para hacer una copia de seguridad de los datos en un almacenamiento externo grabable (como NAS o NFS / SMB / CIFS, por ejemplo), y después de que se cierren los servicios, sí, simplemente desconecte: no necesita su (s) disco (s) RAM / tmpfs ) más, y no dañarás nada

1
Tu primer punto es incorrecto; la tarjeta SD presenta complicaciones que hacen que no sea "exactamente el mismo" problema que con, por ejemplo, discos giratorios donde el registro diario y la verificación deben ser salvaguardas efectivas la mayor parte del tiempo, o medios SSD más caros que pueden tener hardware adicional y ajustarse a un estándar más estricto, frente a los medios SD. Qv mi respuesta cuando hablo sobre "En términos abstractos, sin tener en cuenta la naturaleza de las tarjetas SD ..."
goldilocks

1
@goldilocks, por supuesto, en los ajustes profundos de la mecánica de los medios de almacenamiento es diferente. Estoy hablando aquí de manera más general, es decir, "¿por qué es malo desconectar si no está asegurando el hecho de que todos sus datos se guardan de forma segura y segura".
Alexey Vesnin

@goldilocks Gracias a ambos por sus excelentes respuestas. Ambos han hecho excelentes puntos, aunque he decidido aceptar la respuesta de Ricitos de Oro, ya que proporciona mucha información relevante mientras sigo respondiendo la pregunta; Sin embargo, he votado a favor ambas respuestas.
James Vickery

1

Como @goldilocks ha respondido, hay poco riesgo, pero la mayoría de nosotros no lo hacemos.

Es muy simple agregar un interruptor de apagado seguro, que uso en mi Pi sin cabeza. Consulte ¿Cómo apagar con seguridad la Raspberry Pi? esto casi no usa recursos, aparte de un poco de RAM y un simple botón pulsador.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.