Mover um arquivo entre duas unidades em um SSD - ele será copiado?

Ao mover um arquivo em uma unidade, o arquivo não é copiado e excluído. A tabela que se refere aos arquivos foi atualizada. E, tanto quanto eu sei, esse não é o caso em 2 unidades em um disco rígido. Mas os SSDs são diferentes, não há espaço físico dedicado a cada unidade. ( fonte )

Portanto, minha pergunta é o que acontece quando um arquivo é movido de uma unidade para outra no mesmo SSD, os bytes são copiados e o original excluído ou alguma tabela é atualizada, diminuindo menos o SSD?

Já existe uma pergunta duplicada aqui . Mas ambas as respostas afirmam:

cada partição terá sua própria área física da unidade para si mesma

e

Particionar um disco rígido na verdade designa regiões físicas para cada partição. [e em um comentário:] O SSD ainda é um disco rígido, apenas não possui um disco.

Tanto quanto sei, isso está errado. Veja aqui .

Então, alguém que sabe mais sobre SSDs, por favor, me diga se está correto em sua avaliação, apesar do erro?

Até onde eu sei, isso está errado

A descrição citada está meio correta, meio errada. Mas também está meio errado para os HDDs.

Particionar uma unidade designa regiões lógicas para cada partição. O sistema operacional não se importa com localizações físicas - apenas pede à unidade que "leia o bloco lógico # 31415926" e a própria unidade decide onde os dados estão localizados. Isso funciona da mesma maneira para a memória magnética e flash.

Na verdade, é o mesmo que com os HDDs dos últimos 20 a 25 anos: embora os primeiros sistemas operacionais usassem locais físicos de cilindros / cabeçote / setor, isso já faz muito tempo. Você não sabe exatamente onde está o prato LBA # 1234. Os HDDs remapeiam até mesmo setores físicos ruins automaticamente, para que o mesmo LBA possa ser lido repentinamente em uma área física completamente diferente - exatamente como nos SSDs.

Portanto, com HDDs e SSDs, o sistema operacional apenas possui uma variedade de LBAs (por exemplo, 0–999999) para leitura e gravação de dados. O objetivo do particionamento é alocar subintervalos nele - por exemplo, a partição A recebe 10–499999, a partição B recebe 500000–999999. Cada partição possui um sistema de arquivos independente, e os sistemas de arquivos dentro de cada partição não podem referenciar dados fora dela - eles não podem cruzar os limites da partição. (Por exemplo, a partição A não pode ter um arquivo cujos dados são mantidos no setor # 600000.)

Como resultado, todos os arquivos que se deslocam de um para o outro devem ser copiados na íntegra.

(Dito isso, em teoria, o sistema operacional pode solicitar ao próprio disco que duplique dados de uma área para outra (por exemplo, "copie o LBA # 1234 para # 567890"), sem precisar copiá-lo para a memória principal e depois voltar, e, é claro, isso ignoraria completamente os limites da partição. Isso poderia fazer uso da "camada de conversão de flash" do SSD, por exemplo. Mas, na prática, até onde eu sei, isso não é feito.)

O que acontece quando os dados são gravados em um disco de estado sólido é digno de vários artigos (bom resumo aqui ), porque é muito complicado e depende da tecnologia subjacente. A história resumida é que os SSDs em geral não podem gravar zero bits na memória. Em vez disso, eles precisam zerar (apagar) uma seção inteira da memória e, em seguida, podem armazenar dados depois disso, apenas escrevendo os que estão nela. Atualmente, eles escrevem blocos de 512 bytes, mas apagam uma página de 8 blocos, que é 4096. Isso e o fato de que cada ciclo de gravação / exclusão causa algum desgaste físico da memória e a memória acaba eventualmente se desgastando, torna os SSDs muito diferentes do que girar HDDs magnéticos.

Deixando isso de lado, as unidades SATA (e unidades AFAIK SAS) não implementam um comando nativo para copiar dados de um setor para outro. (Ou pelo menos nada nas especificações SATA ou SAS exige, portanto, o sistema operacional não pode contar com esse comando disponível.) Portanto, uma cópia de arquivo em uma partição envolverá a leitura dos dados de um setor de unidade na memória do host e a gravação de volta à unidade em um setor diferente.

Isso ocorre porque, no que diz respeito ao sistema operacional, uma unidade é um conjunto de setores lógicos numerados e tudo o que você pode fazer é ler de setores e gravar em setores. O sistema operacional não pode dizer à unidade para remapear setores.

Além disso, o sistema de arquivos (HFS +, NTFS, ext3 etc.) é um conjunto de estruturas de dados que impõem ordem a um conjunto de blocos lógicos. Essas estruturas de dados implementam "arquivos", "nomes de arquivos", "diretórios", "permissões" etc. Então, sim, quando você move um arquivo de um diretório para outro, ele não é copiado; somente os dados do sistema de arquivos que indicam em qual diretório o arquivo está são atualizados.

O conceito de uma partição é que é um conjunto de setores lógicos na unidade reivindicados por um único sistema de arquivos. O corolário disso é que um sistema de arquivos pode não acessar setores fora de sua partição. Em grande parte, esse é um recurso de segurança, mas também decorre do fato de que as estruturas de dados do sistema de arquivos são todas construídas para contabilizar todos os setores da unidade sob a propriedade do sistema de arquivos, e não é trivial adicionar ou remover setores a essas estruturas. É por isso que você precisa executar rotinas especiais para ajustar o tamanho de uma partição e também por que os sistemas de arquivos insistem em executar em um conjunto contíguo de setores.

Portanto, é impraticável e perigoso implementar uma cópia de arquivo apenas transferindo setores de um sistema de arquivos para outro. Em uma unidade magnética giratória, também seria um pesadelo de desempenho, porque, embora a unidade faça exceções para setores defeituosos, em geral ela organiza que os setores sejam localizados fisicamente de maneira a otimizar a velocidade de leitura e gravação de números numerados consecutivamente setores.

Além disso, 2 sistemas de arquivos podem não armazenar dados do mesmo modo no disco, o que significa que a troca de setores não funcionaria, mesmo que fosse prático. Mesmo que sejam exatamente os mesmos tipos de sistema de arquivos, digamos NTFS, um pode estar usando criptografia ou compactação e o outro não, ou ambos podem criptografar os dados, mas com chaves diferentes. Não é necessário que os dados no arquivo sejam exatamente o que está armazenado no disco, tudo o que precisa ser armazenado é uma transformação reversível dos dados, para que o sistema de arquivos possa obter os dados do arquivo fazendo algo com os dados no disco. Portanto, a menos que ambos os sistemas de arquivos estejam usando exatamente a mesma transformação, a simples troca de setores não alcançaria o objetivo de transferir os dados do arquivo.

Por todos esses motivos, é trabalho demais para pouco ganho para os gravadores de SO e gravadores de sistema de arquivos implementar um recurso que otimiza as movimentações entre partições para SSDs. Portanto, qualquer movimentação entre partições será uma leitura e uma gravação.

Dentro do SSD, é uma história um pouco diferente. Embora o sistema operacional não tenha informado à unidade que está copiando dados de um lugar para outro, as gravações em SSDs são tão caras (e complicadas) que os controladores de SSD fazem muito trabalho para minimizar as gravações. Alguns SSDs tentam detectar quando um setor que está sendo gravado no armazenamento corresponde a um setor já armazenado e marcam essa parte física da memória como agora mapeando para 2 setores lógicos diferentes, em vez de copiá-lo, fazendo no nível da unidade interna o que o OS não podia.

Mas não conte com isso.