IMac – Why is Target Disk Mode so slow

Issue solved; no physical errors. These are what I did:

First I analyzed where the error occurred :

...
** Checking catalog file.
Invalid index key
(4, 20220)
Invalid node structure
(4, 38065)
The volume SSD could not be verified completely.
...

fsck stops while scanning catalog files. Let's try reading fsck_hfs user manual by executing man fsck_hfs for clues.

...
-R flags Rebuilds the requested btree.  The following flags are supported:
     a       Attribute btree
     c       Catalog btree
     e       Extents overflow btree
...

Let's try rebuilding catalog btree then. fsck_hfs -Rc /dev/rdisk0s2

Results: fsck does not stop at catalog file check anymore, and the Invalid index key error disappeared, revealing more errors ( clues! ).

** Checking extents overflow file.
Incorrect block count for file Cache.db-wal
(It should be 114 instead of 119)
** Checking catalog file.
Missing thread record (id = 30291961)
Incorrect number of thread records
Incorrect number of thread records
** Checking multi-linked files
** Checking catalog hierarchy.
Invalid directory item count
(It should be 221 instead of 244)
Invalid volume file count
(It should be 1318081 instead of 1318117)
** Checking extended attributes file.
Invalid node structure
The volume SSD could not be verified completely.

fsck now stops when checking extended attributes file. Let's try rebuilding the attributes btree with fsck -Ra /dev/rdisk0s2.

Result(s): All errors, except Invalid node structure disappeared after the first repair attempt. It shows several invalid nodes, then attempts the second repair, and rechecks. It still shows some invalid nodes, but even less then before.

However the fsck stops with a message saying that it stops making repair attempts after 3 check failures. I ran fsck -Ra /dev/rdisk0s2 again. It attempts to repair again, then rechecks. No invalid node structure error shows up!

It now makes Invalid volume free blocks count, Invalid volume file count, and Invalid volume directory count errors, but it doesn't stop yet!

After yet another attempt of repair, fsck finished without any errors.

Shut down. Boot normally without entering single user mode. And it works! Problem solved by running fsck several times, rebuilding catalog btree, and attribute btree several times.

I have the same problem, which I'm pretty sure is due to a combination of the way write operations work on flash memory and the way core storage (or any whole-volume) encryption works.

First, write behavior: unlike volatile memory (the stuff used in the memory of your computer) or hard disks, where any bit can be written to 0 or 1 at any time, flash memory has two main states: written and erased. Within "written" are 0 and 1. When you need to write to flash memory you must write an entire block that is currently in the erased state. File system software in the OS may know what blocks are free, but the controller and storage on a flash device don't. A special way for the OS to tell an SSD to make blocks available has been devised for "bus-connected" SSDs: it's called TRIM. USB protocol stacks don't, to my knowledge, support TRIM. So, basically, flash memory continues to fill up until there are no actual erased blocks, at which point the file system has to erase and rewrite blocks by reading them, merging in the new data, erasing, and writing them back out. That's why you see small-file write performance degrade on SSDs over time.

The special circumstances of encrypted volumes is interesting: depending on the way the encryption works, it may actually encrypt an entire volume, filling all the blocks with what appears to be random data even if the blocks are actually unused and would contain zeroes. So when you turn on FileVault (or otherwise enable core storage encryption), it basically consumes the entire volume, leaving no space for write operations. The file system has to constantly read, erase and rewrite blocks so that it can rewrite them with any encrypted data you want to put on it.

Now I will say right here that this is speculation based on a reasonable understanding of how things work, but there are people who actually know the details, who may correct or improve my explanation and I hope that they will do so.