OS X exécute-t-il parfois une routine TRIM avec des disques qui ne sont pas explicitement pris en charge ?

Lorsqu'un volume HFS Plus est démonté ou éjecté, peut-être ?

Contexte

Récemment, lors du partitionnement répété/agressif d'une simple clé USB et de l'effacement de ses multiples systèmes de fichiers HFS Plus journalisés, des messages tels que celui-ci ont été observés dans la Console :

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

Dans les informations système, le disque - un Kingston DataTraveler 400 - n'est pas traité comme un support à semi-conducteurs, et il n'y a pas de ligne "Prise en charge TRIM :".

Je ne fais pas de code, mais il me semble que ignorer l'habillage apparaît dans une partie du code - le hfs_unmap_free_extent routine - cela s'appliquerait là où le TRIM est pris en charge d'une manière ou d'une autre.

Je me demande donc si, en plus des routines supposées critiques à la nanoseconde qui peuvent être exécutées pendant qu'un système de fichiers est monté, il n'est pas possible d'avoir un système de fichiers qui ne soit pas monté. une routine moins connue et relativement rudimentaire (moins critique) peut être exécutée à d'autres moments .

En rapport

Optimiser le macbook pro pour les disques internes SSD+HDD (2011), où le réponse acceptée a attiré l'attention sur un commentaire de Hyram en juillet 2011 en réponse à un article de Grant Pannell paru sur digitaldj.net. Dans ce commentaire :

Apple a verrouillé la prise en charge du TRIM pour une très bonne raison - leur code fonctionne de manière fiable avec les disques SSD qu'ils ont choisi d'utiliser et aucun autre, parce qu'ils ont programmé des boucles de synchronisation critiques à la nanoseconde qui correspondent parfaitement aux temps d'accès des contrôleurs utilisés dans les disques SSD d'Apple.

Cependant, un article de digitaldj.net de novembre 2011 mettent en doute certaines des déclarations de Hyram. En particulier :

Il n'y a aucune preuve qu'Apple dispose d'un code spécifique pour gérer leur matériel SSD spécifique pour la lecture et l'écriture.

Veuillez noter que cette question est no à propos du tiers Enabler TRIM et autres. Il s'agit de :

• ce qui est partie intégrante du système d'exploitation

- et j'aimerais obtenir des réponses fiables. Des réponses fondées sur des preuves si possible, bien que je comprenne que les parties à code source fermé d'OS X puissent rendre cela difficile.

A partir du code source du noyau lié à HFS

/* 
 ;________________________________________________________________________________ 
 ; 
 ; 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);
}

Première apparition dans l'open source d'Apple : http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/hfs/hfscommon/Misc/VolumeAllocation.c (Mac OS X 10.8.1)

Dernière apparition : http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/hfs/hfscommon/Misc/VolumeAllocation.c

De même, dans ce dernier cas :

/* 
 * 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. 
 ;________________________________________________________________________________ 
 */ 

et ainsi de suite.