web-dev-qa-db-pt.com

Movendo um arquivo entre os dois unidades em um SSD - será copiado?

Ao mover um arquivo dentro de uma unidade, o arquivo não é copiado e excluído. A tabela que se refere aos arquivos é apenas atualizada. E, tanto quanto eu sei, não é esse 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 )

Então, a 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, o que afasta o SSD menos?

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

e

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

Tanto quanto eu sei que está errado. Veja aqui .

Então, alguém que sabe mais sobre SSDs, por favor, me diga se eles estão corretos em sua avaliação, apesar de seu erro?

18
ispiro

Tanto quanto eu sei que está errado

A descrição citada é meio correta, meio errada. Mas também é meio errado para HDs também.

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

Na verdade, é o mesmo como nos HDDs dos últimos 20-25 anos: embora os primeiros sistemas operacionais usassem locais físicos de cilindros/cabeças/setores, isso já se foi há muito tempo. Você não sabe exatamente onde o Platter LBA # 1234 é mantido. Os HDDs até mesmo remapear setores físicos ruins automaticamente, de modo que o mesmo LBA pode ser lido repentinamente de uma área física completamente diferente - assim como ocorre com os SSDs.

Portanto, com os HDDs e os SSDs, o sistema operacional tem apenas um intervalo de LBAs (por exemplo, 0–999999) para ler e gravar 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 tem um sistema de arquivos independente, e 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 podeter um arquivo cujos dados são mantidos no setor # 600000.)

Como resultado, todos os arquivos que se movem de um para o outro precisam ser copiados integralmente.

(Dito isto, em teoria, o sistema operacional pode ser capaz de perguntaro próprio disco para duplicar dados de uma área para outra (por exemplo, "copiar LBA # 1234 para # 567890"), sem ter que copiá-lo para a memória principal e, em seguida, de volta, e é claro que isso iria ignorar completamente os limites das partições. 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 foi feito.

38
grawity

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. O conto é que os SSDs geralmente não podem escrever zero bits na memória. Em vez disso, eles precisam zerar (apagar) toda uma seção da memória, e então eles podem armazenar os dados depois disso apenas escrevendo os mesmos para ela. Normalmente, esses dias escrevem blocos de 512 bytes, mas apagam a page 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 se desgastando, tornando os SSDs muito diferentes dos HDDs magnéticos giratórios.

Deixando isso de lado, as unidades SATA (e as unidades AFAIK SAS) não implementam um comando nativo para copiar dados de um setor para outro. (Ou pelo menos nada na especificação SATA ou SAS exige, portanto, o SO não pode contar com tal comando disponível.) Portanto, uma cópia de arquivo em uma partição envolverá a leitura dos dados de um setor da unidade. na memória do host e, em seguida, gravá-lo de volta para a 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 ela pode fazer é ler os setores e gravar nos setores. O SO 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õe ordem em 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á atualizado são atualizados.

O conceito de uma partiçãoé que é um conjunto de setores lógicos na unidade reivindicada por um único sistema de arquivos. O corolário disso é que um sistema de arquivos não pode acessar setores fora de sua partição. Em grande parte, esse é um recurso de segurança, mas também deriva do fato de que as estruturas de dados do sistema de arquivos são construídas em torno de todos os setores do drive sob a propriedade do sistema de arquivos e não é trivial adicionar ou remover setores. para essas estruturas. É por isso que você tem que executar rotinas especiais para ajustar o tamanho de uma partição e também por que os sistemas de arquivos insistem em rodar 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 um drive magnético giratório, também seria um pesadelo de desempenho, porque embora a unidade faça exceções para setores defeituosos, em geral, ele organiza os setores fisicamente localizados de forma a otimizar a velocidade de leitura e gravação de números consecutivamente numerados. setores.

Além disso, dois sistemas de arquivos podem não armazenar os dados do arquivo da mesma forma no disco, o que significa que os setores de troca não funcionariam mesmo se fossem práticos. Mesmo que sejam exatamente os mesmos tipos de sistemas 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 é um requisito 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 o arquivo. os dados no disco. Portanto, a menos que ambos os sistemas de arquivos usem exatamente a mesma transformação, a simples troca de setores não atingiria o objetivo de transferir os dados do arquivo.

Por todas essas razões, é apenas muito trabalho para muito pouco ganho para os criadores de sistemas operacionais e criadores de sistemas de arquivos implementarem um recurso que otimiza as movimentações em partições para SSDs. Portanto, qualquer movimento de partição cruzada será uma leitura e uma gravação.

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

Mas não conte com isso.

9
Old Pro