Führt OS X manchmal eine TRIM-Routine mit Laufwerken aus, die nicht explizit unterstützt werden?

Wann wird ein HFS Plus-Volume möglicherweise abgemeldet oder ausgeworfen?

Hintergrund

In letzter Zeit in Console zur Kenntnis genommen, während ein einfaches USB-Flash-Laufwerk wiederholt / aggressiv partitioniert und seine mehreren aufgezeichneten HFS Plus-Dateisysteme gelöscht werden, werden folgende Meldungen angezeigt:

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

In den Systeminformationen wird das Laufwerk - ein Kingston DataTraveler 400 - nicht als Solid-State-Medium behandelt, und es gibt keine TRIM-Support-Zeile.

Ich mache keinen Code, aber es scheint mir so Trim ignorieren erscheint in einem Teil des Codes - der hfs_unmap_free_extent Routine - das würde zutreffen, wenn TRIM in irgendeiner Weise unterstützt wird.

Ich frage mich daher, ob - zusätzlich zu vermeintlich nanosekundenkritischen Routinen, die möglicherweise ausgeführt werden, während ein Dateisystem eingehängt ist - Eine weniger bekannte und relativ grobe (weniger kritische) Routine kann zu anderen Zeiten ausgeführt werden .

verbunden

Optimieren Sie das macbook pro für interne SSD + HDD-Laufwerke (2011), wo die akzeptierte Antwort lenkte die Aufmerksamkeit auf ein Kommentar von Hyram vom Juli 2011 als Antwort auf einen Artikel von Grant Pannell auf digitaldj.net. Innerhalb dieses Kommentars:

… Apple hat die TRIM-Unterstützung aus einem sehr guten Grund gesperrt - ihr Code funktioniert zuverlässig mit den von ihnen ausgewählten SSDs und mit keinem anderen, da sie nanosekundenkritische Zeitschleifen programmiert haben, die perfekt mit den Zugriffszeiten der in verwendeten Controller übereinstimmen Apples SSDs. …

Jedoch, Ein Artikel von digitaldj.net vom November 2011 bezweifle einige von Hyrams Aussagen. Im Speziellen:

… Es gibt keinen Hinweis darauf, dass Apple einen bestimmten Code für die Verarbeitung der SSD-Hardware zum Lesen und Schreiben hat. …

Bitte beachten Sie, diese Frage ist nicht über Dritte TRIM Enabler und dergleichen. Es geht um:

• was ist integraler Bestandteil des Betriebssystems

- und ich hätte gerne verbindliche Antworten. Wenn möglich nachweisbasiert, obwohl ich zu schätzen weiß, dass die geschlossenen Quellen von OS X dies möglicherweise erschweren.

Aus HFS-bezogenem Quellcode für den 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);
}

Erster Auftritt 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)

Letzter Auftritt: http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/hfs/hfscommon/Misc/VolumeAllocation.c

Auch aus letzterem:

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

… und so weiter.

Also, kraft:

Bei dieser Frage geht es nicht um TRIM Enabler von Drittanbietern und dergleichen

Dies kann nicht die "richtige Antwort" sein, wie es scheint. Aber selbst wenn es nicht darum geht, worum es geht, ist es das, ähm, "korrekte Antwort" ist eine Art von? Also werde ich es trotzdem versuchen ...

Die kurze Antwort auf die Titelfrage: kurz nein.

Es gibt nur eine Implementierung ... pro unterstütztem Controller .

hfs_unmap_free_ext bezieht sich nicht auf die hfs_unmap_free extent Funktion .

Es bezieht sich auf die kext was macht das " hfs_unmap_free ing. "

Der Fehler,

hfs_unmap_free_ext: ignoring trim kann aus einem oder beiden der folgenden Gründe auftreten:

• Das Laufwerk verwendet einen unterstützten Controller, wurde jedoch nicht "gesegnet" mit einer Apple-Seriennummer und Firmware. In diesem Fall wird dieser Schutz ausgebessert Die Kernel-Erweiterung - was Trim Enabler macht - wird TRIM seit der Hardware aktivieren hat einen Treiber, der es unterstützt.

  (Auch ich selbst würde das Patchen des Kernels als fast die Definition von etwas betrachten Integration in das Betriebssystem.)

• Es wird ignoriert, obwohl das Gerät dies ankündigt es unterstützt TRIM, Es gibt keinen TRIM-Treiber im Kernel für diesen Controller, da Apple niemals einen ausgeliefert hat Laufwerk basierend auf diesem Controller in erster Linie. Es werden also nur allgemeine ATA-Befehle verwendet.

(Dies ist wahrscheinlich bei Ihrem Laufwerk der Fall, da das Bit "Nicht als SSD erkannt" verwendet wird.)

Während:

Sie haben nanosekundenkritische Timing-Schleifen programmiert, die perfekt zu den Zugriffszeiten der Controller passen, die in den SSDs von Apple verwendet werden

ist eine wahre Aussage, das ist definitiv nicht, warum Apple Laufwerke sperrt. Sie tun dies, damit Sie keinen Support innerhalb der Garantie für ein Laufwerk eines Drittanbieters erhalten.

Apple stellt keine Laufwerke her. Aber wenn Sie nachlesen, wie Tim Cook (während COO) vor ein paar Jahren den asiatischen NAND-Flash-Markt erobert hat - mehr oder weniger, warum er heute CEO ist - werden Sie verstehen, warum Flash-Hersteller Apple erlauben, solche Dinge zu diktieren.

Abgesehen davon bin ich mir nicht sicher, ob Sie noch viel mehr als das finden werden, was "maßgeblich" ist, fürchte ich. Wie Sie sagten, ist das meiste von diesem Zeug eine geschlossene Quelle, obwohl Sie überall Spuren finden können, mit denen beinhaltet mögen dieses . Beachten Sie auch, dass TRIM eher eine Konzept- / Implementierungssache als ein Standard ist (zumindest mit irgendetwas vor SATA 3.1).

Ich kann Ihnen auch mit Zuversicht sagen, dass SSDs mit TRIM-fähigem Apple-Logo nur über GSX (oder den grauen Markt) erhältlich sind. Und dieser Trim Enabler funktioniert ganz gut. Ich habe (die neueren Versionen) in vielen Produktionsumgebungen installiert.

Ein paar Links:
http://www.anandtech.com/show/5453/trim-enabler-20-for-os-x-lion-released http://en.wikipedia.org/wiki/Trim_(computing)