OS X a volte esegue una routine TRIM con unità che non sono supportate esplicitamente?
Quando un volume HFS Plus è smontato o espulso, forse?
Sfondo
Notato di recente in Console, mentre si esegue il partizionamento ripetuto / aggressivo di una semplice unità flash USB e si cancellano i suoi file system HFS Plus con journal multipli, messaggi come questo:
2013-12-29 21:56:18.000 kernel[0]: hfs_unmap_free_ext: ignoring trim vol=swivel @ off 4698607616 len 159744
In System Information, l'unità - Kingston DataTraveler 400 - non è trattata come un mezzo a stato solido e non esiste una linea di supporto TRIM: '.
Non faccio codice, ma mi sembra che ignorare il trim appaia in una parte del codice - la routine hfs_unmap_free_extent - che si applicherebbe dove TRIM è in qualche modo supportato.
Questo mi lascia chiedermi se - oltre alle presunte routine critiche su nanosecondi che possono essere eseguite mentre un file system è montato - una routine meno nota e relativamente grezza (meno critica) può essere eseguita in altri momenti .
correlati
Ottimizza macbook pro per drive SSD + HDD interni (2011), dove risposta accettata ha attirato l'attenzione su un commento di luglio 2011 di Hyram in risposta a un articolo digitaldj.net di Grant Pannell. All'interno di quel commento:
… 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. …
Tuttavia, un digitaldj di novembre 2011 .net article ha messo in dubbio alcune delle affermazioni di Hyram. In particolare:
… There is zero evidence that Apple has specific code to handle their specific SSD hardware for reading and writing. …
Tieni presente che questa domanda è non su Enabler TRIM di terze parti e simili. Si tratta di:
- cos'è integrante del sistema operativo
- e mi piacerebbe risposte autorevoli. Se possibile, basato sull'evidenza, anche se apprezzo che le porzioni a sorgente chiuso di OS X possano renderlo difficile.
Dal codice sorgente relativo a HFS per il 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);
}
Prima apparizione in open source Apple: link (Mac OS X 10.8.1)
Aspetto più recente: link
Inoltre, da quest'ultimo:
/*
* 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.
;________________________________________________________________________________
*/
... e così via.