2014-09-08 15:45:31 +0000 2014-09-08 15:45:31 +0000
84
84

Desvantagens da partição de uma SSD?

Um tipo sábio que dá pelo nome de NickN mantém um longo post do fórum sobre as suas opiniões acerca da construção de um computador poderoso (direccionado para jogar o Flight Simulator X da Microsoft, uma peça de software muito exigente).

Ele resume pontos sobre unidades SSD algures, e conclui a lista como se segue:

NÃO PARTICIPE do SSD

Infelizmente, ele não se debruça sobre isto, mas pergunto-me porque é que ele diz isto. Quais são os inconvenientes da partição de um SSD? (Particionar neste contexto significa >= 2 partições)

Respostas (7)

126
126
126
2016-05-28 01:24:34 +0000

As SSDs não funcionam, repito, NÃO funcionam ao nível do sistema de ficheiros!

Não há correlação 1:1 entre a forma como o sistema de ficheiros vê as coisas e a forma como o SSD vê as coisas.

Sinta-se à vontade para particionar o SSD da forma que quiser (assumindo que cada partição está correctamente alinhada, e um sistema operativo moderno tratará de tudo isto por si); NÃO prejudicará nada, NÃO afectará negativamente os tempos de acesso ou qualquer outra coisa, e também não se preocupe em fazer uma tonelada de escritas ao SSD. Eles têm-nas para que possa escrever 50 GB de dados por dia, e durará 10 anos.

Respondendo à resposta de Robin Hood ,

Wear leveling não terá tanto espaço livre para jogar, porque as operações de escrita serão espalhadas por um espaço mais pequeno, pelo que “poderia”, mas não necessariamente desgastará essa parte da unidade mais rapidamente do que se toda a unidade fosse uma única partição, a não ser que esteja a executar um desgaste equivalente nas partições adicionais (por exemplo, uma dupla bota).

Isso é totalmente errado.  É impossível desgastar uma partição porque se lê/escreve apenas para essa partição. Isto NÃO é sequer remotamente como os SSDs funcionam.

Um SSD funciona a um nível de acesso muito inferior ao que o sistema de ficheiros vê; um SSD funciona com blocos e páginas.

Neste caso, o que realmente acontece é que, mesmo que esteja a escrever uma tonelada de dados numa partição específica, o sistema de ficheiros está limitado pela partição, MAS, o SSD não está. Quanto mais se escreve o SSD, mais blocos/páginas o SSD será trocado para fazer o nivelamento por desgaste. Não podia importar menos como o sistema de ficheiros vê as coisas!   Isto significa que, numa altura, os dados podem residir numa página específica na SSD, mas, noutra altura, podem ser e serão diferentes. A SSD manterá um registo de onde os dados são embaralhados, e o sistema de ficheiros não terá qualquer pista sobre onde os dados se encontram realmente na SSD.

Para tornar isto ainda mais fácil: digamos que se escreve um ficheiro na partição 1. O SO diz ao sistema de ficheiros sobre as necessidades de armazenamento, e o sistema de ficheiros atribui os “sectores”, e depois diz ao SSD que precisa X de espaço. O sistema de ficheiros vê o ficheiro em Logical Block Address (LBA) de 123 (por exemplo). O SSD faz notar que o LBA 123 está a utilizar o bloco/página #500 (por exemplo). Assim, cada vez que o SO precisar deste ficheiro específico, o SSD terá um ponteiro para a página exacta que está a utilizar. Agora, se continuarmos a escrever para o SSD, o nivelamento do desgaste faz efeito, e diz bloco/página #500, podemos optimizá-lo melhor no bloco/página #2300. Agora, quando o SO pedir esse mesmo ficheiro, e o sistema de ficheiros pedir novamente LBA 123, ESTE tempo, o SSD devolverá o bloco/página #2300, e NÃO a página #500.

Como os discos rígidos nand-flash S.S.D’s são acesso sequencial, por isso quaisquer dados que escreva/leia a partir das partições adicionais estarão mais longe do que “poderiam” estar se tivessem sido escritos numa única partição, porque as pessoas normalmente deixam espaço livre nas suas partições. Isto aumentará os tempos de acesso aos dados que são armazenados nas partições adicionais.

Não, isto está novamente errado!  Robin Hood está a pensar nas coisas em termos do sistema de ficheiros, em vez de pensar como funciona exactamente um SSD. Mais uma vez, não há maneira de o sistema de ficheiros saber como o SSD armazena os dados. Não há aqui “mais longe”; isto é apenas aos olhos do sistema de ficheiros, NÃO a forma real como um SSD armazena informação. É possível que a SSD tenha os dados espalhados em diferentes chips NAND, e o utilizador não notará qualquer aumento nos tempos de acesso. Bolas, devido à natureza paralela do NAND, pode mesmo acabar por ser mais rápido do que antes, mas estamos aqui a falar de nanossegundos; pestaneje e perdeu-o.

Menos espaço total aumenta o provável capô de escrever ficheiros fragmentados, e embora o impacto do desempenho seja pequeno tenha em mente que é geralmente considerada uma má ideia desfragmentar uma S.S.D. de nano-flash porque vai desgastar o disco. Claro que, dependendo do sistema de ficheiros que estiver a utilizar, alguns resultam em quantidades extremamente baixas de fragmentação, porque são concebidos para escrever ficheiros como um todo sempre que possível, em vez de os despejar por todo o lado para criar velocidades de escrita mais rápidas.

Nope, desculpe; mais uma vez isto está errado. A visão do sistema de ficheiros e a visão da SSD sobre esses mesmos ficheiros não estão sequer remotamente fechados. O sistema de ficheiros pode ver o ficheiro como fragmentado no pior caso possível, MAS, a visão da SSD dos mesmos dados é quase sempre optimizada.

Assim, um programa de desfragmentação olharia para esses LBAs e diria, este ficheiro deve ser realmente fragmentado!  Mas, uma vez que não tem qualquer pista sobre os internos do SSD, está 100% errado. Essa é a razão pela qual um programa de desfragmentação não funcionará em SSDs, e sim, um programa de desfragmentação também causa escritas desnecessárias, como foi mencionado.

A série de artigos Codificação para SSDs é uma boa visão geral do que está a acontecer se quiser ser mais técnico sobre como funcionam as SSDs.

Para mais alguma leitura “leve” sobre como funcionam as FTL (Flash Translation Layer) realmente funciona, também sugiro que leia Critical Role of Firmware and Flash Translation Layers in Solid State Drive Design  (PDF) do site Flash Memory Summit .

Têm também muitos outros trabalhos disponíveis, como por exemplo:

& Outro trabalho sobre como isto funciona: Visão geral da memória flash & (PDF).  Ver a secção “Escrever Dados” (páginas 26-27).

Se o vídeo é mais a sua coisa, veja Um FTL de página eficiente para optimizar a tradução de endereços na memória flash e relacionados slides .

15
15
15
2016-05-30 14:53:57 +0000

Respostas muito longas aqui, quando a resposta é suficientemente simples e decorre directamente apenas do conhecimento geral das SSDs. Não é preciso mais do que ler o termo da Wikipédia de Solid-state drive para compreender a resposta, que é:

O conselho “NÃO PARTICIPE DE SSD” é um disparate.

& No passado (agora distante), os sistemas operativos não suportavam muito bem os SSD, e especialmente quando a partição não tinha o cuidado de alinhar as partições de acordo com o tamanho do bloco apagado.

Esta falta de alinhamento, quando um sector de disco lógico do SO foi dividido entre blocos SSD físicos, poderia exigir que o SSD piscasse dois sectores físicos quando o SO pretendia apenas actualizar um, retardando assim o acesso ao disco e aumentando Wear leveling .

Actualmente os SSDs estão a tornar-se muito maiores, e os sistemas operativos sabem tudo sobre eliminação de blocos e alinhamento, de modo que o problema já não existe. Talvez este conselho tenha tido em tempos o objectivo de evitar erros no alinhamento das divisórias, mas hoje em dia estes erros são praticamente impossíveis.

Na verdade, o argumento para particionar SSDs é hoje exactamente o mesmo que para os discos clássicos : Para melhor organizar e separar os dados.

Por exemplo, instalar o sistema operativo numa partição separada e mais pequena é útil para se ter uma imagem de salvaguarda da mesma como precaução ao fazer grandes actualizações ao sistema operativo.

4
4
4
2016-06-06 07:25:59 +0000

Não há inconvenientes na partição de um SSD, e pode de facto prolongar a sua vida, deixando algum espaço não particionado.

O nivelamento de desgaste é aplicado em todos os blocos do dispositivo (ref. HP white-paper, ligado abaixo)

No nivelamento de desgaste estático, todos os blocos em todos os flash disponíveis no dispositivo participam nas operações de nivelamento de desgaste. Isto assegura que todos os blocos recebem a mesma quantidade de desgaste. O nivelamento por desgaste estático é mais frequentemente utilizado em SSDs de secretária e de portáteis.

A partir daí, podemos concluir que as partições não importam para o nivelamento de desgaste. Isto faz sentido porque, do ponto de vista do HDD & controlador, as divisórias não existem realmente. Existem apenas blocos e dados. Até a tabela de partições é escrita nos mesmos blocos (1º bloco da unidade para MBR). É o SO que depois lê a tabela, e decide a que blocos escrever os dados e a que blocos não escrever. O SO vê blocos utilizando LBA para dar um número único a cada bloco. No entanto, o controlador mapeia então o bloco lógico para um bloco físico real, tendo em consideração o esquema de nivelamento de desgaste.

O mesmo whitepaper dá uma boa sugestão para prolongar a vida do dispositivo:

A seguir, fornecer em excesso a sua unidade. Pode aumentar o tempo de vida útil apenas dividindo uma parte da capacidade total do dispositivo. Por exemplo, se tiver uma unidade de 256 GB - partilhe-a apenas até 240 GB. Isto irá prolongar grandemente a vida útil da unidade. Um nível de sobreprovisionamento de 20% (particionando apenas 200 GB) prolongaria ainda mais a vida útil da unidade. Uma boa regra geral é cada vez que duplicar o sobreprovisionamento da unidade adiciona 1x à resistência da unidade.

Isto também indica que mesmo espaço não particionado é utilizado para nivelamento por desgaste, provando assim ainda mais o ponto acima.

Fonte: White paper técnico - SSD Endurance http://h20195.www2.hp.com/v2/getpdf.aspx/4AA5-7601ENW.pdf )

1
1
1
2016-06-02 14:53:00 +0000

Os sectores dos discos têm sido 512 bytes durante muito tempo, e os discos mecânicos têm a propriedade de que a única coisa que afecta o tempo de leitura/escrita de um sector é o atraso na procura. Assim, o principal passo de optimização com discos rígidos mecânicos foi tentar ler/escrever blocos sequencialmente para minimizar as buscas.

Flash funciona de forma muito diferente dos discos rígidos mecânicos. Ao nível do flash em bruto, não há blocos, mas páginas e “apagar blocos” (para usar a terminologia do MTD Linux). Pode escrever para flash uma página de cada vez, e pode apagar flash um bloco de apagar de cada vez.

Um tamanho típico de página para flash é 2KBytes, e um tamanho típico para apagar blocos é 128KBytes.

Mas os SSDs SATA apresentam uma interface que funciona com tamanhos de sector de 512 bytes para o SO.

Se houver um mapeamento 1:1 entre páginas e sectores, pode ver como se depararia com problemas se a sua tabela de partições começasse numa página ímpar ou numa página no meio de um bloco de eliminação. Dado que os SOs preferem ir buscar dados a unidades em blocos de 4Kbyte, uma vez que isto se alinha com hardware de paginação x86, pode ver como um bloco de 4Kbyte deste tipo poderia atravessar um bloco de apagamento, o que significa que seria necessário actualizá-lo, depois reescrever 2 blocos em vez de 1, o que levaria a um desempenho inferior.

Contudo, o firmware SSD não mantém um mapeamento 1:1, faz uma tradução de Endereço de Bloco Físico (PBA) para Endereço de Bloco Lógico (LBA). O que significa que nunca se sabe para onde, digamos, o sector 5000 ou qualquer outro determinado sector está realmente a ser escrito no flash. Está a fazer muitas coisas nos bastidores por desenho para tentar escrever sempre em blocos pré apagados. Não se pode saber ao certo o que está a fazer sem uma desmontagem do firmware, mas a menos que o firmware seja completamente inútil, o firmware provavelmente contorna isto.

Já deve ter ouvido falar de discos rígidos de 4Kn. Estes são discos rígidos mecânicos que utilizam internamente um tamanho de sector de 4Kbytes, mas ainda assim apresentam uma interface de sector de 512 bytes para os sistemas operativos. Isto é necessário porque as lacunas entre sectores precisam de ficar mais pequenas no prato para caberem mais dados.

Isso significa que internamente lê e escreve sempre sectores de 4K, mas esconde-o do sistema operativo. Neste caso, se não escrever para sectores que caem num limite de 4KByte, incorrerá numa penalização de velocidade porque cada uma dessas leituras/escritas resultará na leitura e reescrita de dois sectores internos de 4KByte. Mas isto não se aplica aos SSDs.

De qualquer modo, esta é a única situação em que consigo pensar porque é sugerido não dividir os SSDs. Mas não se aplica.

-1
-1
-1
2015-10-14 07:21:57 +0000

O que estas respostas ignoram são optimizações de SSD do Windows. Não sei se isto significa que o particionamento se torna melhor, mas para um drive C particionado como o drive do Windows, pode:

  1. volta de indexação
  2. não precisa de manter o registo da hora do último acesso
  3. não precisa de armazenar os velhos 8 caracteres dos-nomes
  4. contornar o lixo do Windows
-2
-2
-2
2014-09-08 22:10:25 +0000

Decidi que alguma informação de fundo poderia ser útil para tornar esta resposta clara, mas como podem ver, fui um pouco ao TOC, por isso talvez queiram saltar para o fim e depois voltar, se necessário. Embora eu saiba um pouco, não sou especialista em S.S.D.s, por isso, se alguém vir um erro EDIT :).

Informação de fundo:

** O que é um S.S.D.?:**

Um S.S.D. ou drive de estado sólido é um dispositivo de armazenamento sem partes móveis. O termo S.S.D. destina-se frequentemente a referir-se especificamente a unidades de estado sólido baseadas em nano-flash destinadas a actuar como uma alternativa de disco rígido, mas na realidade são apenas uma forma de S.S.D., e nem sequer a mais popular. O tipo de S.S.D. mais popular é o S.S.D. à base de nano-flash, como os bastões de memória (unidades flash), e os cartões de memória, embora raramente sejam referidos como S.S.D.. Os S.S.D.s também podem ser baseados em ram, mas a maioria dos ram-drives são software gerados em oposição ao hardware físico.

Por que razão as S.S.D.s Nand-flash pretendem agir como uma alternativa ao disco rígido?:

Para executar um sistema operativo, e para o seu software, é necessário um meio de armazenamento rápido. É aqui que o ram entra em jogo, mas historicamente o ram era caro e os cpu’s não conseguiam lidar com grandes quantidades. Quando executa um sistema operativo, ou programa as partes de dados actualmente requeridas são copiadas para o seu ram, porque o seu dispositivo de armazenamento não é suficientemente rápido. É criado um estrangulamento, porque tem de esperar que os dados sejam copiados do dispositivo de armazenamento lento para o carneiro. Embora nem todos os S.S.D.s nand-flash tenham melhor desempenho do que os discos rígidos mais tradicionais, os que ajudam a reduzir o gargalo, dando tempos de acesso mais rápidos, velocidades de leitura e de escrita.

O que é Nand-flash?:

O armazenamento Flash é um meio de armazenamento que utiliza electricidade em vez de magnetismo para armazenar dados. Nand-flash é um armazenamento flash que utiliza um gateway NAND. Ao contrário de A nor-flash que é acesso aleatório, o nand-flash é acedido sequencialmente.

** Como é que Nand-flash S.S.D.s armazena dados?:**

O armazenamento Nand-flash é composto por blocos, esses blocos são divididos em células, as células contêm páginas. Ao contrário de um disco rígido que utiliza magnetismo para armazenar dados, os suportes flash utilizam electricidade, devido a estes dados não podem ser escritos em excesso; os dados devem ser apagados a fim de reutilizar o espaço. O dispositivo não pode apagar páginas individuais; o apagamento deve ocorrer a um nível de bloco. Uma vez que os dados não podem ser escritos num bloco que já esteja a ser utilizado (mesmo que nem todas as páginas do mesmo sejam), o bloco inteiro deve ser apagado primeiro, e depois o bloco agora em branco pode ter dados escritos nas suas páginas. O problema é que perderia quaisquer dados já nessas páginas, incluindo dados que não quer descartar! Para evitar que estes dados existentes sejam retidos deve ser copiado para outro lugar antes de se proceder ao apagamento do bloco. Este procedimento de cópia não é executado pelo sistema operativo do computador, é executado a nível de dispositivo por uma funcionalidade conhecida como recolha de lixo.

Nos discos rígidos é utilizada uma placa magnética para armazenar os dados. Tal como nos discos de vinil, a placa tem pistas, e estas pistas são divididas em secções chamadas sectores. Um sector pode conter uma certa quantidade de dados (tipicamente 512 bytes, mas alguns mais recentes são 4KB). Quando se aplica um sistema de ficheiros, os sectores são agrupados em clusters (com base num tamanho especificado, chamado tamanho de alocação ou tamanho de cluster), e depois os ficheiros são escritos através de clusters. É também possível dividir um sector para fazer clusters menores do que o seu tamanho de sector. O espaço não utilizado num agrupamento depois de um ficheiro ser escrito através de um agrupamento (ou vários) não é utilizável, o ficheiro seguinte começa num novo agrupamento. Para evitar muito espaço inutilizável, as pessoas usam tipicamente tamanhos de clusters mais pequenos, mas isto pode diminuir o desempenho ao escrever ficheiros grandes. Os S.S.D.s Nand-flash não têm uma placa magnética, utilizam electricidade que passa através de blocos de memória. Um bloco é feito de células contendo páginas. As páginas têm capacidade X (normalmente 4 KB), e assim o número de páginas determinará a capacidade de um bloco (normalmente 512 KB). Nas SSD’s uma página equivale a um sector num disco rígido, porque ambas representam a menor divisão de armazenamento.

O que é nivelamento de desgaste?:

Nand-flash os blocos de armazenamento podem ser escritos, e apagados um número limitado de vezes (referido como o seu ciclo de vida). Para evitar que a unidade sofra de redução de capacidade (blocos mortos), faz sentido desgastar os blocos o mais uniformemente possível. O ciclo de vida limitado é também a principal razão pela qual muitas pessoas sugerem não ter um ficheiro de página ou partição de troca no seu sistema operativo se estiver a utilizar um S.S.D. baseado em Nand-flash (embora as rápidas velocidades de transferência de dados do dispositivo para o ram são também um factor importante nessa sugestão).

O que é o Over Provisioning?:

O Over Provisioning define a diferença entre quanto espaço livre existe, em comparação com o que parece existir. Os dispositivos de armazenamento baseados em Nand-flash afirmam ser mais pequenos do que eles são, de modo a garantir a existência de blocos vazios para a eliminação do lixo a utilizar. Existe um segundo tipo de sobreprovisionamento chamado “dinâmico sobreprovisionamento” que se refere simplesmente ao espaço livre conhecido dentro do espaço livre mostrado. Há dois tipos de sobreabastecimento dinâmico: nível do sistema operacional, e nível do controlador de accionamento. Ao nível do sistema operativo, o Trim pode ser utilizado para libertar blocos que podem depois ser escritos de imediato. Ao nível do controlador pode ser utilizado espaço não atribuído na unidade (não particionado, nenhum sistema de ficheiros). Ter mais blocos livres ajuda a manter a unidade a funcionar com o seu melhor desempenho, porque pode escrever imediatamente. Também aumenta a provável capota de ter blocos que estão localizados sequencialmente, o que reduz os tempos de acesso porque os S.S.D.s Nand-flash usam acesso sequencial para ler e escrever dados.

O que é Write Amplification?:

Porque os meios Nand-flash requerem que um bloco seja apagado antes de poder ser escrito, qualquer dado dentro do bloco que não esteja a ser apagado deve ser copiado para um novo bloco por eliminação de lixo. Estas escritas adicionais são chamadas amplificação de escrita.

O que é Trim…:

Os sistemas operativos são construídos tendo em mente os discos rígidos tradicionais. Lembre-se de que um disco rígido tradicional pode sobregravar dados directamente. Quando se elimina um ficheiro, o sistema operativo marca-o como apagado (está bem para sobreescrever), mas os dados continuam lá até que ocorra uma operação de gravação. Nos S.S.D.s baseados em Nand-flash isto é um problema, porque os dados devem ser apagados primeiro. O apagamento ocorre a um nível de bloco, pelo que pode haver dados adicionais que não estejam a ser apagados. A eliminação do lixo copia quaisquer dados que não estejam prontos para eliminação para blocos vazios, e depois os blocos em questão podem ser apagados. Tudo isto leva tempo, e causa escritas desnecessárias (amplificação da escrita)! Para contornar isto, foi feita uma funcionalidade chamada Trim. Trim dá ao sistema operativo o poder de dizer ao S.S.D. para apagar blocos com páginas que contenham dados que o sistema operativo tenha marcado como apagados durante períodos de tempo em que não está a pedir uma operação de escrita lá. A recolha de lixo faz a coisa, e como resultado, os blocos são libertados para que a escrita possa, assim se espera, ocorrer aos blocos que não precisam de ser apagados primeiro, o que torna o processo mais rápido, e ajuda a reduzir a amplificação da escrita a um mínimo. Isto não é feito com base num ficheiro; Trim utiliza o endereçamento lógico dos blocos. O L.B.A. especifica quais os sectores (páginas) a apagar, e o apagamento ocorre a nível de bloco.

A resposta à sua pergunta “Desvantagens de particionar uma SSD?”:

** S.S.D.s baseados em Ram:**

Não há absolutamente nenhuma desvantagem porque são acesso aleatório!

Nand-flash Based S.S.D.s:

As únicas desvantagens que me vêm à mente seriam:

  1. o nivelamento do desgaste não terá tanto espaço livre para jogar, porque as operações de escrita serão espalhadas por um espaço menor, pelo que “poderia”, mas não necessariamente desgastará essa parte da unidade mais rapidamente do que se toda a unidade fosse uma única partição, a menos que esteja a executar um desgaste equivalente nas partições adicionais (por exemplo: uma dupla bota).

  2. Tal como os discos rígidos, os S.S.D. nand-flash são acesso sequencial, assim quaisquer dados que escreva/leia a partir das partições adicionais estarão mais longe do que “poderiam” estar se fossem escritos numa única partição, porque as pessoas normalmente deixam espaço livre nas suas partições. Isto aumentará os tempos de acesso aos dados que são armazenados nas partições adicionais.

  3. Menos espaço total aumenta o provável capô de escrever ficheiros fragmentados, e embora o impacto do desempenho seja pequeno tenha em mente que é geralmente considerada uma má ideia desfragmentar uma S.S.D. de nano-flash porque esta irá desgastar a unidade. Claro que, dependendo do sistema de ficheiros que estiver a utilizar, alguns resultam em quantidades extremamente baixas de fragmentação, porque são concebidos para escrever ficheiros como um todo sempre que possível, em vez de os despejar por todo o lado para criar velocidades de escrita mais rápidas.

Eu diria que não há problema em ter múltiplas partições, mas o nivelamento do desgaste pode ser uma preocupação se tiver algumas partições com muita actividade de escrita, e outras com muito pouca. Se não particionar espaço não planeia utilizar, e em vez disso deixá-lo para uma dinâmica sobre o aprovisionamento, poderá receber um aumento de desempenho porque será mais fácil libertar blocos e escrever dados sequenciais. No entanto, não há garauntee de que será necessário espaço de sobreprovisionamento, o que nos leva de volta ao ponto #1 sobre nivelamento de desgaste.

Algumas outras pessoas neste tópico levantaram a discussão de como a partição afectará as contribuições de Trim para a dinâmica de sobre provisionamento. Ao meu entender, a TRIM é utilizada para apontar sectores (páginas) que têm dados assinalados para eliminação, e assim a eliminação do lixo pode apagar livremente esses blocos. Este espaço livre actua como dinâmico sobre o aprovisionamento dentro DAQUELA partição, porque esses sectores fazem parte de aglomerados sendo utilizadas pelo sistema de ficheiros dessa partição; outras partições têm os seus próprios sistemas de ficheiros. No entanto, posso estar totalmente enganado quanto a isto, uma vez que a ideia de sobreprovisionamento é um pouco obscura para mim, uma vez que os dados serão escritos em locais que nem sequer têm sistemas de ficheiros ou aparecem na capacidade das unidades. Isto faz-me pensar se talvez o espaço de aprovisionamento excessivo seja utilizado numa base temporária antes de uma operação final de escrita optomizada em blocos dentro de um sistema de ficheiros? Claro que as contribuições de Trim para o provisionamento dinâmico em excesso dentro do sistema de ficheiros não seriam temporárias, uma vez que poderiam ser escritas directamente, uma vez que já se encontram em espaço utilizável. Essa é pelo menos a minha teoria. Talvez a minha compreensão dos filesytems esteja errada? Tenho sido incapaz de encontrar quaisquer recursos que entrem em detalhes sobre isto.

-14
-14
-14
2014-09-08 16:14:00 +0000

Não, isto faz sentido.

A velocidade de um SSD liga directamente à quantidade de espaço utilizável na partição em uso. Se partiu a unidade em pequenas secções, a eficiência do SSD será atingida devido à falta de espaço livre.

Portanto, não há desvantagens em particionar um SSD, mas há desvantagens em não ter espaço livre na unidade.

Consulte este SuperUser post .