Spostamento di un file tra due unità su un SSD: verrà copiato?

Quando si sposta un file all'interno di un'unità, il file non viene copiato ed eliminato. La tabella che fa riferimento ai file è appena stata aggiornata. E per quanto ne so, questo non è il caso di 2 unità su un HDD. Ma gli SSD sono diversi, non c'è spazio fisico dedicato a ciascuna unità. ( fonte )

Quindi la mia domanda è: cosa succede quando un file viene spostato da un'unità all'altra sullo stesso SSD, i byte vengono copiati e l'originale viene cancellato o viene aggiornata una tabella, con conseguente riduzione dell'SSD?

C'è già una domanda duplicata qui . Ma entrambe le risposte affermano:

ogni partizione avrà la propria area fisica dell'unità su se stessa

e

Il partizionamento di un disco rigido in realtà designa regioni fisiche per ogni partizione. [e in un commento:] SSD è ancora un disco rigido, semplicemente non ha un disco.

Per quanto ne so, è sbagliato. Vedi qui .

Quindi qualcuno che sa di più sugli SSD per favore mi dirà se sono corretti nella loro valutazione nonostante il loro errore?

Per quanto ne so, è sbagliato

La descrizione citata è metà corretta, metà sbagliata. Ma è anche mezzo sbagliato anche per gli HDD.

Il partizionamento di un'unità indica le aree logiche per ogni partizione. Il sistema operativo non si preoccupa affatto delle posizioni fisiche: chiede solo all'unità di "leggere il blocco logico # 31415926" e l'unità stessa decide dove si trovano i dati. Funziona allo stesso modo per la memoria magnetica e flash.

In realtà è lo stesso dei dischi rigidi degli ultimi 20–25 anni: anche se i primi sistemi operativi utilizzavano posizioni di cilindri / testine / settori fisici, ormai è passato molto tempo. Non sai con precisione su quale piatto è tenuto LBA # 1234. Gli HDD rimodellano anche automaticamente i settori fisici danneggiati, quindi lo stesso LBA può essere improvvisamente letto da un'area fisica completamente diversa, proprio come con gli SSD.

Quindi, sia con HDD che con SSD, il sistema operativo ha solo una gamma di LBA (ad es. 0–999999) da cui leggere e scrivere dati. Lo scopo del partizionamento è quello di allocare sotto-intervalli - ad es. La partizione A ottiene 10–499999, la partizione B ottiene 500000–999999. Ogni partizione ha un filesystem indipendente e i filesystem all'interno di ciascuna partizione non possono fare riferimento ai dati al di fuori di essa - non possono oltrepassare i confini della partizione. (Ad esempio, la partizione A non può avere un file i cui dati sono conservati nel settore # 600000.)

Di conseguenza, tutti i file che si spostano dall'uno all'altro devono essere copiati per intero.

(Detto questo, in teoria il sistema operativo potrebbe essere in grado di chiedere al disco stesso di duplicare i dati da un'area all'altra (ad es. "Copia LBA # 1234 a # 567890"), senza dover copiarli nella memoria principale e poi indietro, e ovviamente questo aggirerebbe completamente i confini della partizione. Questo potrebbe fare uso del "livello di traduzione flash" dell'SSD, per esempio. Ma in pratica, per quanto ne so, questo non è fatto.)

Cosa succede quando i dati vengono scritti su un disco a stato solido è degno di numerosi articoli (un buon riassunto qui ), perché è molto complicato e dipende dalla tecnologia sottostante. La storia breve è che gli SSD in generale non possono scrivere zero bit in memoria. Invece, devono azzerare (cancellare) un'intera sezione di memoria, e quindi possono archiviare i dati dopo semplicemente scrivendo quelli su di essa. In genere in questi giorni scrivono blocchi di 512 byte, ma cancellano una pagina di 8 blocchi che è 4096. Questo, e il fatto che ogni ciclo di scrittura / cancellazione causi un po 'di usura fisica della memoria e la memoria alla fine si esaurisca, rendono gli SSD molto diversi rispetto alla rotazione di HDD magnetici.

A parte questo, le unità SATA (e le unità AFAIK SAS) non implementano un comando nativo per copiare i dati da un settore all'altro. (O almeno nulla nelle specifiche SATA o SAS lo richiede, quindi il sistema operativo non può contare sul fatto che tale comando sia disponibile.) Quindi una copia di file su una partizione implica la lettura dei dati da un settore di unità nella memoria host e quindi la scrittura ritorna all'azionamento in un altro settore.

Questo perché, per quanto riguarda il sistema operativo, un'unità è un insieme di settori logici numerati e tutto ciò che può fare è leggere da settori e scrivere in settori. Il sistema operativo non può dire all'unità di rimappare i settori.

Inoltre, il file system (HFS +, NTFS, ext3, ecc.) È un insieme di strutture di dati che impongono l'ordine su un insieme di blocchi logici. Tali strutture di dati implementano "file", "nomi file", "directory", "autorizzazioni", ecc. Quindi, sì, quando si sposta un file da una directory all'altra, non viene copiato; vengono aggiornati solo i dati del file system che indicano in quale directory si trova il file.

Il concetto di una partizione è che si tratta di un insieme di settori logici sull'unità rivendicati da un singolo file system. Il corollario di ciò è che un file system non può accedere a settori esterni alla sua partizione. In gran parte questa è una caratteristica di sicurezza, ma deriva anche dal fatto che le strutture di dati del file system sono tutte costruite attorno alla contabilizzazione di ogni settore dell'unità sotto la proprietà del file system, ed è banale aggiungere o rimuovere settori a quelle strutture. Questo è il motivo per cui è necessario eseguire routine speciali per regolare le dimensioni di una partizione e anche perché i file system insistono per l'esecuzione su un insieme contiguo di settori.

Pertanto, non è pratico e pericoloso implementare una copia di file in quanto trasferisce semplicemente settori da un file system a un altro. Su un disco magnetico rotante, sarebbe anche un incubo di prestazioni, perché sebbene l'unità farà eccezioni per i settori danneggiati, in generale organizza che i settori siano posizionati fisicamente in modo tale da ottimizzare la velocità di lettura e scrittura di numeri progressivamente numerati settori.

Inoltre, 2 file system potrebbero non archiviare i dati dei file allo stesso modo sul disco, il che significa che i settori di scambio non funzionerebbero anche se fossero pratici. Anche se sono esattamente gli stessi tipi di file system, diciamo NTFS, uno potrebbe usare la crittografia o la compressione e l'altro no, oppure entrambi potrebbero crittografare i dati, ma con chiavi diverse. Non è necessario che i dati nel file siano esattamente ciò che è archiviato sul disco, tutto ciò che deve essere archiviato è una trasformazione reversibile dei dati, in modo che il file system possa ottenere i dati del file facendo qualcosa con i dati sul disco. Quindi, a meno che entrambi i file system non utilizzino esattamente la stessa trasformazione, semplicemente lo scambio di settori non raggiungerebbe l'obiettivo di trasferire i dati del file.

Per tutti questi motivi, è troppo lavoro per un guadagno troppo poco per gli scrittori del sistema operativo e gli autori del file system per implementare una funzione che ottimizza le mosse tra le partizioni per gli SSD. Quindi ogni mossa tra partizioni sarà una lettura e una scrittura.

All'interno dell'SSD, è una storia leggermente diversa. Sebbene il sistema operativo non abbia comunicato all'unità che sta copiando i dati da una posizione all'altra, le scritture su SSD sono così costose (e complicate) che i controller SSD fanno molto lavoro per ridurre al minimo le scritture. Alcuni SSD arrivano al punto di provare a rilevare quando un settore in fase di scrittura nello spazio di archiviazione corrisponde a un settore già archiviato e contrassegnano quel pezzo di memoria fisica come attualmente mappato su 2 diversi settori logici anziché copiarlo, facendo a livello di unità interna ciò che il Il sistema operativo non potrebbe.

Ma non ci contare.