¿OS X a veces ejecuta una rutina TRIM con unidades que no son explícitamente compatibles?
Cuando un volumen HFS Plus se desmonta o se expulsa, ¿quizás?
Fondo
Notado recientemente en la Consola, mientras particiona repetida / agresivamente una simple unidad flash USB y borra sus múltiples sistemas de archivos HFS Plus registrados en diario, como este:
2013-12-29 21:56:18.000 kernel[0]: hfs_unmap_free_ext: ignoring trim vol=swivel @ off 4698607616 len 159744
En Información del sistema, la unidad, una Kingston DataTraveler 400, no se trata como un medio de estado sólido, y no hay una línea de "Soporte TRIM:".
No hago el código, pero me parece que ignorar el recorte aparece en una parte del código, la rutina hfs_unmap_free_extent , que se aplicaría cuando se admita TRIM de alguna manera.
Esto me hace preguntarme si, además de las supuestas rutinas críticas de nanosegundos que pueden ejecutarse mientras se monta un sistema de archivos, una rutina menos conocida y relativamente burda (menos crítica) puede ejecutarse en otros momentos .
Relacionado
Optimizar macbook pro para unidades de disco duro internas SSD + (2011), donde respuesta aceptada llamó la atención sobre un comentario de julio de 2011 de Hyram en respuesta a un artículo de digitaldj.net de Grant Pannell. Dentro de ese comentario:
... Apple bloqueó el soporte TRIM por una muy buena razón: su código funciona de manera confiable con los SSD que eligieron usar y no con otros, porque han programado ciclos de temporización de nanosegundos críticos que coinciden perfectamente con los tiempos de acceso del Controladores utilizados en los SSD de Apple. ...
Sin embargo, un digitaldj de noviembre de 2011 El artículo .net arroja dudas sobre algunas de las declaraciones de Hyram. En particular:
... No hay evidencia de que Apple tenga un código específico para manejar su hardware SSD específico para leer y escribir. ...
Tenga en cuenta que esta pregunta no es sobre el tercero TRIM Enabler y similares. Se trata de:
- ¿qué es integral al sistema operativo
- y me gustaría respuestas autorizadas. Basado en evidencia, si es posible, aunque aprecio que las partes de código cerrado de OS X pueden hacer esto difícil.
Desde el código fuente relacionado con HFS para el 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);
}
Primera aparición en código abierto de Apple: enlace (Mac OS X 10.8.1)
Aspecto más reciente: enlace
También, desde este último:
/*
* 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.
;________________________________________________________________________________
*/
... y así sucesivamente.