Does OS X sometimes run a TRIM routine with drives that are not explicitly supported?
When an HFS Plus volume is unmounted or ejected, maybe?
Background
Noted recently in Console, whilst repeatedly/aggressively partitioning a simple USB flash drive and erasing its multiple journaled HFS Plus file systems, messages such as this:
2013-12-29 21:56:18.000 kernel[0]: hfs_unmap_free_ext: ignoring trim vol=swivel @ off 4698607616 len 159744
In System Information, the drive – a Kingston DataTraveler 400 – is not treated as a solid state medium, and there's no 'TRIM Support:' line.
I don't do code, but it seems to me that ignoring trim appears in a part of the code – the hfs_unmap_free_extent routine – that would apply where TRIM is in some way supported.
This leaves me wondering whether – in addition to supposed nanosecond-critical routine(s) that may run whilst a file system is mounted – a lesser-known and relatively crude (less critical) routine can run at other times.
Related
Optimize macbook pro for internal SSD+HDD drives (2011), where the accepted answer drew attention to a July 2011 comment by Hyram in response to an digitaldj.net article by Grant Pannell. Within that comment:
… Apple locked TRIM support for a very good reason — their code works reliably with the SSD’s they’ve chosen to use and no others, because they have programmed in nanosecond-critical timing loops that match perfectly with the access timings of the controllers used in Apple’s SSDs. …
However, a November 2011 digitaldj.net article cast doubt on some of Hyram's statements. In particular:
… There is zero evidence that Apple has specific code to handle their specific SSD hardware for reading and writing. …
Please note, this question is not about third party TRIM Enabler and the like. It's about:
- what's integral to the operating system
– and I'd like authoritative answers. Evidence-based if possible, although I appreciate that the closed source portions of OS X may make this difficult.
From HFS-related source code for the kernel
/*
;________________________________________________________________________________
;
; Routine: hfs_unmap_free_extent
;
; Function: Make note of a range of allocation blocks that should be
; unmapped (trimmed). That is, the given range of blocks no
; longer have useful content, and the device can unmap the
; previous contents. For example, a solid state disk may reuse
; the underlying storage for other blocks.
;
; This routine is only supported for journaled volumes. The extent
; being freed is passed to the journal code, and the extent will
; be unmapped after the current transaction is written to disk.
;
; Input Arguments:
; hfsmp - The volume containing the allocation blocks.
; startingBlock - The first allocation block of the extent being freed.
; numBlocks - The number of allocation blocks of the extent being freed.
;________________________________________________________________________________
*/
static void hfs_unmap_free_extent(struct hfsmount *hfsmp, u_int32_t startingBlock, u_int32_t numBlocks)
{
u_int64_t offset;
u_int64_t length;
u_int64_t device_sz;
int err = 0;
if (hfs_kdebug_allocation & HFSDBG_UNMAP_ENABLED)
KERNEL_DEBUG_CONSTANT(HFSDBG_UNMAP_FREE | DBG_FUNC_START, startingBlock, numBlocks, 0, 0, 0);
if (ALLOC_DEBUG) {
if (hfs_isallocated(hfsmp, startingBlock, numBlocks)) {
panic("hfs: %p: (%u,%u) unmapping allocated blocks", hfsmp, startingBlock, numBlocks);
}
}
if (hfsmp->jnl != NULL) {
device_sz = hfsmp->hfs_logical_bytes;
offset = (u_int64_t) startingBlock * hfsmp->blockSize + (u_int64_t) hfsmp->hfsPlusIOPosOffset;
length = (u_int64_t) numBlocks * hfsmp->blockSize;
/* Validate that the trim is in a valid range of bytes */
if ((offset >= device_sz) || ((offset + length) > device_sz)) {
printf("hfs_unmap_free_ext: ignoring trim vol=%s @ off %lld len %lld \n", hfsmp->vcbVN, offset, length);
err = EINVAL;
}
if (err == 0) {
err = journal_trim_add_extent(hfsmp->jnl, offset, length);
if (err) {
printf("hfs_unmap_free_extent: error %d from journal_trim_add_extent for vol=%s", err, hfsmp->vcbVN);
}
}
}
if (hfs_kdebug_allocation & HFSDBG_UNMAP_ENABLED)
KERNEL_DEBUG_CONSTANT(HFSDBG_UNMAP_FREE | DBG_FUNC_END, err, 0, 0, 0, 0);
}
First appearance in Apple open source: http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/hfs/hfscommon/Misc/VolumeAllocation.c (Mac OS X 10.8.1)
Most recent appearance: http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/hfs/hfscommon/Misc/VolumeAllocation.c
Also, from the latter:
/*
* Validation Routine to verify that the TRIM list maintained by the journal
* is in good shape relative to what we think the bitmap should have. We should
* never encounter allocated blocks in the TRIM list, so if we ever encounter them,
* we panic.
*/
…
/*
;________________________________________________________________________________
;
; Routine: hfs_track_unmap_blocks
;
; Function: Make note of a range of allocation blocks that should be
; unmapped (trimmed). That is, the given range of blocks no
; longer have useful content, and the device can unmap the
; previous contents. For example, a solid state disk may reuse
; the underlying storage for other blocks.
;
; This routine is only supported for journaled volumes.
;
; *****NOTE*****:
; This function should *NOT* be used when the volume is fully
; mounted. This function is intended to support a bitmap iteration
; at mount time to fully inform the SSD driver of the state of all blocks
; at mount time, and assumes that there is no allocation/deallocation
; interference during its iteration.,
;
; Input Arguments:
; hfsmp - The volume containing the allocation blocks.
; offset - The first allocation block of the extent being freed.
; numBlocks - The number of allocation blocks of the extent being freed.
; list - The list of currently tracked trim ranges.
;________________________________________________________________________________
*/
… and so on.
