MacBook Pro, finales de 2013, SSD de 1 TB (nueva, recientemente reemplazada por Apple), APFS (sin diario, no distingue entre mayúsculas y minúsculas), High Sierra 10.13.2, Time Machine a HDD de red.
no space left on device
.rm
de , obtuveno space left on device
cat /dev/null > somefile
de , obtuveno space left on device
Arrancó en modo de recuperación con Shift-Command-R (descarga el sistema de Internet) y ejecutó Primeros Auxilios nuevamente. Esta vez con un éxito limitado:
** Checking volume.
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the object map.
** Checking the APFS volume superblock.
** Checking the object map.
error: invalid dstream.size (10730881024), is greater than dstream.alloced_size (71151616)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0x16309a1): invalid xfields
** Checking the fsroot tree.
fsroot tree is invalid.
** The volume /dev/rdisk2s1 could not be verified completely.
Entonces, aparentemente, el árbol fsroot no es válido. Busqué, pero no pude encontrar ningún consejo útil sobre cómo solucionar esto (excepto, por supuesto, reformatear y restaurar desde la copia de seguridad, que me gustaría evitar).
En el sistema hay una máquina virtual Windows Parallels con un disco duro virtual de 100 GB (sí, un archivo grande), que se usó recientemente (por lo que se necesitaba una copia de seguridad). La última vez que usé la computadora, aproximadamente 20 GB todavía estaban libres en el SSD de macOS. Durante aproximadamente un día, las copias de seguridad de Time Machine no se completaron, pero no se mostró ningún mensaje de error. Cuando ocurrió el problema, dejé la máquina encendida durante la noche para completar una copia de seguridad incremental de Time Machine. La conexión aquí es que Time Machine aparentemente está usando instantáneas APFS. Sospecho que esta es la causa raíz de por qué sucedió este lío.
Gracias.
Cuando se ejecuta fsck_apfs
con el indicador de depuración -d
, la salida contiene un poco más de información:
** Checking volume.
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the object map.
** Checking the APFS volume superblock.
** Checking the object map.
error: invalid dstream.size (10730881024), is greater than dstream.alloced_size (71151616)
error: xf : INO_EXT_TYPE_DSTREAM : invalid dstream
error: inode_val: object (oid 0x16309a1): invalid xfields
obj-id: 23267745 type: Inode
private-id: 23267745 parent-id: 12896552 cr/mtime: 1515089959653928186/1515090145416398252
def-prot-class: 0
uid/gid/mode: 0/0/0x8180 bsd_flags: 0x0 internal_flags: 0x8280 name: NO-NAME
** Checking the fsroot tree.
fsroot tree is invalid.
** The volume /dev/disk2 could not be verified completely.
Acabo de encontrarme con un problema similar. Probablemente habría descubierto que el problema estaba en uno de los archivos de Parallels VM, al menos ese fue el culpable en mi caso. Su fsck_apfs -d /disk/<disk>
cheque devuelto:
obj-id: 23267745 type: Inode
Si hubiera abierto la terminal, podría haber obtenido la ruta al archivo (o archivos) usando ese inodo usando el siguiente comando:
find / -inum 23267745
A partir de ahí, habría sabido qué archivos necesitaban restaurarse en lugar de realizar una restauración completa.
En mi caso, el archivo de VM solo estaba disponible en la instantánea, ya que excluyo mis VM de TimeMachine. Restauré solo ese archivo de una instantánea anterior y avancé más a través de fsck_apfs: atravesó el disco para verificar las instantáneas y luego bombardeó el mismo archivo en la segunda instantánea. Afortunadamente, las instantáneas solo se conservan durante un máximo de 24 horas, por lo que debería desaparecer después de ese punto.
Sin embargo, su millaje puede variar, ya que podría ser tan "simple" como un archivo o solo la punta del iceberg.
mike testamentos
Hendrik
gctwnl