Eu tenho uma nova unidade flash USB Silicon Power Marvel M70 de 64 GB com 45 MB de espaço não alocado antes dos 58,89 GB de espaço disponível. Não me importo em ter menos de 64 GB, pois sei que é devido à matemática baseada em 1024.
O que me preocupa é o tamanho de 45MB. Porquê tanto? 1 MB é típico para alinhamento.
Então, eu carreguei um hexeditor no Linux com este comando:
hexdump /dev/sdb -C | less
E encontro "sequências" de dados como o seguinte:
Tabela de partição invalida. Erro ao carregar o sistema operacional.
Remover discos ou outras mídias. Erro no disco. Pressione qualquer tecla para reiniciar. U.RRaA.
Este programa não pode ser executado no modo DOS.
CpaintDC. UserException. CResourceException.
Um aplicativo fez uma tentativa de carregar a biblioteca de tempo de execução C incorretamente. Entre em contato com a equipe de suporte do aplicativo para obter mais informações. Tente usar o código MSIL deste assembly durante o código nativo.
Isso está na área de 45 MB NÃO ATRIBUÍDOS ... Não deveriam ser zeros diretamente da fábrica? Além disso, uma unidade idêntica (veja abaixo) possui tamanhos completamente diferentes para a área não alocada e particionada; parece que os dados executáveis estão ou foram armazenados lá
Eu nunca encontrei isso antes. Tem mais alguém? Liguei para a empresa e eles não tinham uma explicação apenas para me dizer que, ao abrir um e conectá-lo ao computador, o computador também mostra 45 MB de espaço não alocado no início da unidade.
Isso indica que provavelmente é feito assim na fábrica e não apenas o meu tem essa configuração.
Estou preocupado com o que está armazenado lá; e é possivelmente executável, etc. especialmente com a visualização das seqüências de texto hexdump acima nos 45 MB de "espaço não alocado". Se é executável; Eu diria que talvez ele esteja acessível ao inicializar no drive.
Alguém viu isso antes? Alguma explicação que você possa pensar?
EDIT: Quando liguei para a empresa que a fabrica, eles também conectaram um tamanho de 128 GB da mesma linha de modelo e o espaço não alocado era de 31 MB. Não tenho certeza se isso tem alguma influência sobre o que pode estar acontecendo aqui, mas certamente não é "proporcional" ou, pelo menos, o mesmo.
EDIT: Tentei posteriormente outra unidade totalmente nova (mesmo modelo, número de lote, unidades de tamanho (64 GB). Conforme exibido por GParted:
Unidade # 1: 45,33 MiB não alocado e 58,89 GB FAT32
Unidade # 2: 46,38 MiB não alocado e 54,70 GB FAT32
Ambos devem ser unidades de 64 GB. Tamanho idêntico, etc. Isso é direto da fábrica. Eu nunca encontrei esse tipo de discrepância com outras unidades flash. Quero dizer, isso representa mais de 4 GB de espaço de armazenamento entre as duas unidades no tamanho total do setor.
As displayed by "fdisk -l" as requested (for the #2 drive only since I already cleared out the partition table of drive #1):
Disk /dev/sdc: 58.8 GB, 58787364864 bytes
90 heads, 26 sectors/track, 49067 cylinders, total 114819072 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x75cbf5af
Inicialização do dispositivo: / dev / sdb1
Início: 94976
Fim: 114819071
Blocos: 57362048
Id: c
Sistema: W95 FAT32 (LBA)
Além disso, isso não explica por que há 45 MB ou 46 MB de espaço não alocado antes da primeira partição, mas para 2 unidades idênticas de 64 GB quando eu executo um " dd if = / dev / sdb of = / flash_drive_dd.img bs = 1M " comando (que deve me dar uma indicação de toda a capacidade de armazenamento da unidade, certo?), recebo dois números completamente diferentes:
A unidade 1 exibe o tamanho do arquivo 63.283.658.752
A unidade 2 exibe 58.787.364.864 de tamanho de arquivo
Esses valores são para a unidade completa ... não apenas para uma partição de unidades de 64GB modelo supostamente idênticas.
Com relação ao setor possivelmente drasticamente diferente, relacionado, pode contar com dois dispositivos idênticos (talvez isso deva ser uma pergunta diferente?) O excesso de provisionamento está ocorrendo ---> À luz de perceber que duas unidades de 64 GB idênticas mostram tamanhos de setor disponíveis muito diferentes (um que não chega a lugar algum) quase perto de 64.000.000.000 MB) Isso significa que um está com excesso de aprovisionamento ou algo assim enquanto o outro não?
A maneira como descubro o que devo ver no meu sistema operacional é a seguinte: pego 64.000.000.000 de bytes e divido por 1024 ^ 3 e devo obter 59,6 GB relatados pelo sistema operacional (ou muito próximo).
Mesmo que exista algum "excesso de provisionamento" (existe algo como unidades flash USB como SSD), pelo menos, eu esperaria que sejam tamanhos consistentes e não muito diferentes entre duas unidades modelo idênticas.
Mas, recém-saído da caixa:
A unidade 1 possui apenas 63.283.658.752 setores para todo o dispositivo, que é 58,9G. Se eu fiz minhas contas corretamente; Faltam mais de 700 MB para esta unidade.
E
A unidade 2 possui apenas 58.787.364.864, que é 54,8G E, novamente, se eu fiz minhas contas corretamente, estou perdendo 5,2 GB para a segunda unidade.
Isso é desconcertante ... modelos idênticos com MUITO menos espaço (para toda a unidade) do que eu esperaria ... a segunda unidade tem muito menos tamanho que a outra.
Até era algum tipo de superprovisionamento; Eu acho que deveria ser consistente não?
Isso nem explica os 45 ou 46 MB de espaço não alocado no começo com dados aparentemente executáveis.
As coisas estão ficando cada vez mais estranhas, a menos que eu esteja perdendo algo fundamental nas unidades flash USB.
Desculpe, isso é um pouco longo ... Continuo descobrindo mais coisas e adicionando à medida que avança.
An application has made an attempt to load the C runtime library incorrectly
) fazem parte do MSVCRT . Aparentemente, a biblioteca de tempo de execução está estaticamente vinculada a qualquer executável que estivesse presente lá. Seqüências anteriores, como "Invalid partition table. Error loading operating system.
fazem parte do MBR / carregador de inicialização do Windows.
strings
pesquisa de toda a unidade não faz sentido; você terá que mostrar a tabela de partição para que possamos ver do que você está falando: ie fdisk -l
.