MacOS – Fusion drive suddenly not bootable: “Too few free segments”, made read-only

I've dealt with a lot of disk issues over the years admining lots of different OSs, but this one is new to me… help/ideas appreciated before I give up and restore!

Woke up this morning to my iMac (5K, 27", Late 2014, SSD + 3TB Fusion, OS X 10.11.3) having shut down overnight (no power issues elsewhere in the house, or on that outlet…). Rebooting a normal boot causes a shutdown before the graphical UI fires up. Safe boot does the same thing. During a verbose boot, I saw that the boot drive wasn't able to be mounted and the system gives up, going into a clean shutdown.

So, I booted into Recovery and ran Disk Utility. The Fusion drive was grayed out but running First Aid on it found no problems with the CoreStorage or actual HFS volume. It refused to mount by hand in a Terminal window (even with the readOnly option).

Next I booted into single-user mode where I was able to capture these unusual messages:

The key here seems to be the 3rd line Too few free segments, mark MLV as readonly. I assume this is from the CoreStorage structure but Googling find very few references to phrases like this. It crossed my mind that it could be referring to the SSD as well, but I'm honestly not too familiar with their storage details. After that, you can see the journal replay fails due to "privilege violation" (presumably the read-only status). On normal or safe boots, this pushes the system into a clean shutdown since it can't mount the root volume read-write with the permissions issue and a dirty journal (see more below).

Interestingly, in single-user boot the drive is mounted read-only at / just fine. I've skimmed through the directories and nothing looks odd. Running fsck_cs and fsck_hfs by hand report no errors at all. But the drive fails to mount read-write at any point. From single-user, I was also able to look at the system.log, but no real clues there either. The last bits in the log look like typical sleep cycle messages.

In any case, the HFS volume is only ~60-70% full, as confirmed in single-user mode. Curiously, DU shows the volume as full when booted into Recovery, but I'm not sure I trust that since it clearly isn't booting the volume there (e.g., there's no breakdown on the drive space into file types… it's all "Other").

Booting from an external drive didn't give results much different from Recovery—the drive can't be mounted, even read-only. Here's the output from fsck_cs:

   Executing fsck_cs (version 517.20.1)
** Checking volume
** disk0s2: Scan for Volume Headers
** disk1s2: Scan for Volume Headers
** disk1s5: Scan for Volume Headers
** disk0s2: Scan for Disk Labels
** disk1s2: Scan for Disk Labels
** disk1s5: Scan for Disk Labels
** Logical Volume Group 56BA393B-9EF3-4BE6-8CA0-240920F97724 spans 3 devices
** disk0s2+disk1s2+disk1s5: Scan for Metadata Volume
** Logical Volume Group has a 210 MB Metadata Volume with double redundancy
** Start scanning metadata for a valid checkpoint
** Load and verify Segment Headers
** Load and verify Checkpoint Payload
** Load and verify Transaction Segment
** Incorporate 0 newer non-checkpoint transactions
** Load and verify Virtual Address Table
** Load and verify Segment Usage Table
** Load and verify Metadata Superblock
** Load and verify Logical Volumes B-Trees
** Logical Volume Group contains 1 Logical Volume
** Load and verify DF9F3BA2-1863-4EEF-AA29-EEA46DE5151E
** Load and verify 13503CA3-FAC4-4CB1-ACF4-6930800B12E8
** Load and verify Freespace Summary
** Load and verify Block Accounting
** Load and verify Live Virtual Addresses
** Newest transaction commit checkpoint is valid
** Load and verify Segment Cleaning
** The volume 56BA393B-9EF3-4BE6-8CA0-240920F97724 appears to be OK

And here's what the Console reports as the system tries to mount the drive when fsck_cs finishes—these are nearly identical to the boot error messages:

com.apple.kextd[24]: LVG changed
kernel[0]: CoreStorage: fsck_cs has finished for group "56BA393B-9EF3-4BE6-8CA0-240920F97724" with status 0x00
com.apple.kextd[24]: LVG changed
kernel[0]: thr <ptr> Upgrading read-only MLV to at least read-only LV because LVG is sparse
kernel[0]: thr <ptr> Too few free segments, mark MLV as readonly
com.apple.kextd[24]: LVG changed
kernel[0]: hfs: early journal init: volume on disk2 is read-only and journal is dirty.  Can not mount volume.
kernel[0]: hfs_mountfs: hfs_early_journal_init failed, erroring out
kernel[0]: hfs_mount: hfs_mountfs returned error=22 for device disk2
diskarbitrationd[46]: unable to mount /dev/disk2 (status code 0x00000001).

This is pretty frustrating since the single-user boot (and DU) seems to indicate that the HFS volume is just fine. It's been running well for the last year or so. Nothing special was tweaked the day before this happened, either. If it matters, a BootCamp partition on the HDD still boots just fine. And I see no i/o errors in logs that are often preludes to disk failure.

At this point I am out of ideas other than destroying and re-creating the CS/Fusion volume with a TM backup, but I'm looking for other threads to follow before I waste a day doing that process.