Mientras hacía una copia de seguridad de algunos datos (un directorio de inicio de 200 GB) con rsync, recibí un error I/0 para un archivo en particular, después de lo cualsincronizaciónContinuó "normalmente" con su copia de seguridad. El archivo fuente del problema mostraba un tamaño de archivo de 72 bytes.
cancelé sincronizacióny ejecuté el mismo comando nuevamente. Esta vez ese mismo archivo demostró estar transfiriendo datos.muchos datos...y más datos, y más... Verifiqué el tamaño del archivo de destino y ¡era de hasta 13 GB! así que usé Ctrl-c para cancelarsincronización.
Al verificar nuevamente el tamaño del archivo fuente, en Nautilus, mostró un tamaño de 60.0 PB(¡Peta Bytes!) en una unidad de 500 GB.
Ahora, el punto principal de todo esto: ¿eliminar este archivo podría causar pérdida de datos en otros archivos, ya que el sistema de archivos puede percibir que es mucho más grande de lo que realmente es... El sistema de archivos es ext4...
Podría saltearlo con unsincronizaciónexcepción, pero estoy particularmente interesado en lo que podría suceder si se elimina.
ACTUALIZACIÓN: Tanto el destino como la fuente sonext4
Con respecto a las sugerencias de que sea un archivo disperso: si es un archivo disperso, ¿por qué mostraría diferentes tamaños de un minuto a otro? El archivo ciertamente(?) no estaba en uso en ese momento. Es un ~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.solarchivo, del cual haymuchosmás tales.Solarchivos en ese directorio ... además mostró un error de I/0 en la primera pasada.
Además, según man rsync, la opción sugerida -Ses manejar archivos dispersos.eficientemente, noadecuadamente, por lo que eso me sugiere que, aunque no -Slo estaba usando, debería copiar un archivo disperso con precisión en cualquier caso: lo cual no fue así, e incluso si es un archivo disperso, ser 60.0 Peta Bytes parece seguramente (?) ser un error en el sistema de archivos, en alguna parte... y esa es mi principal preocupación: si hay un problema técnico en el sistema de archivos, ¿eliminar ese archivo podría tener repercusiones en otros archivos?
Más específicamente: como escribió 13 GB de datos, ¡y subiendo! cuando lo cancelé, ¿podría eliminar también 13 GB - 60 PB de datos cuando lo borre?
Respuesta1
Parece que el sistema de archivos de origen está dañado, generalmente debido a un error del kernel o a una RAM defectuosa (es más probable que un disco dañado genere archivos ilegibles que datos corruptos). En este punto, todas las apuestas están canceladas. Sin embargo, si la corrupción estaba muy localizada, solo el inodo de un archivo está dañado y los demás archivos no están dañados, por lo que puede eliminar el archivo de forma segura. Tenga en cuenta que no hay forma de probar esta suposición.
Mi recomendación es:
- Realice una prueba de RAM o conecte el disco a otra máquina.
- Asegúrese de haber hecho una copia de seguridad de todos sus datos.
- Verifique el estado del disco con SMART, si es posible.
- Correr
fsck. - Si el disco aún está en buen estado, continúa usándolo.
Respuesta2
Es unarchivo escaso. Debería considerar utilizar -S, para que el archivo se maneje lo más correctamente posible.
Respuesta3
Esto es muy probablemente unarchivo escaso. (si no es así, empieza a correrahora!) No es asíde hechoOcupa todo este espacio, tiene agujeros. Quizás un gran agujero.
Elimínelo del rsynclado de destino, luego agregue la -Sopción (escaso) para rsyncasegurarse de que reconozca y trate archivos dispersos.
El tipo de sistema de archivos de destino debeadmite archivos dispersostambién. (versión corta: ext[234]sí, NTFS sí, FAT no)