¿OS X a veces ejecutar un RECORTE de rutina con unidades que no están explícitamente apoyado?

Cuando un HFS Plus de volumen se desmonta o expulsado, tal vez?

De fondo

Señaló recientemente en la Consola, mientras que con frecuencia/de manera agresiva la partición de un simple unidad flash USB y borrar sus múltiples diario HFS Plus sistemas de archivos, mensajes como este:

2013-12-29 21:56:18.000 kernel[0]: hfs_unmap_free_ext: ignoring trim vol=swivel @ off 4698607616 len 159744 

En el Sistema de Información, la unidad de un Kingston DataTraveler 400 – no es tratado como un estado sólido a medio, y no hay 'Soporte TRIM:' la línea.

Yo no hago el código, pero a mí me parece que ignorar recorte aparece en una parte del código – hfs_unmap_free_extent rutina – que se aplican donde RECORTAR es en cierto modo compatible.

Esto me deja preguntándome si – además de los supuestos de nanosegundos crítica de rutina(s) que se puede ejecutar mientras que un sistema de archivos es montado – menos conocidas y relativamente crudo (menos importante) de rutina se pueden ejecutar en otros momentos.

Relacionados con la

Optimizar el macbook pro para SSD interno+unidades de disco duro (2011), donde la aceptaron responder llamó la atención a que en julio de 2011 comentario por Hyram en respuesta a una digitaldj.net artículo de la Concesión Pannell. Dentro de ese comentario:

... Apple bloquea el soporte TRIM para una muy buena razón - su código funciona de forma fiable con el SSD que han elegido usar, y no otros, porque ellos se han programado en nanosegundos-sincronización crítica de bucles que coincide perfectamente con el acceso a los tiempos de los controladores utilizados en Apple Ssd. ...

Sin embargo, en el mes de noviembre de 2011 digitaldj.net artículo puesto en duda algunos de Hyram declaraciones. En particular:

... No existe ninguna evidencia de que Apple tiene un código específico para manejar sus específicas SSD de hardware para la lectura y la escritura. ...

Por favor, tenga en cuenta que esta pregunta es no sobre terceros TRIM Enabler y similares. Se trata de:

• lo que es parte integral del sistema operativo

– y me gustaría respuestas autorizadas. Basada en la evidencia, si es posible, aunque soy consciente de que la fuente cerrada porciones de OS X puede tomar esta difícil.

De HFS relacionados con el código fuente 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 la Manzana de código abierto: http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/hfs/hfscommon/Misc/VolumeAllocation.c (Mac OS X 10.8.1)

La mayoría de reciente aparición: http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/hfs/hfscommon/Misc/VolumeAllocation.c

También, desde el ú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.