O Linux (exfat-fuse) não consegue ler a partir do disco exFAT externo de 4TB da GPT

1

Tenho um WD WD externo de 4 TB. Foi formatado como um disco exFAT em uma máquina com Windows 10. Não tenho problema em ler os arquivos da máquina original do Windows 10 e de um macbook pro 2017 (High Sierra).

Em qualquer máquina linux que eu use (Ubuntu 16.10 x64 + Slackware 14.2), o sistema nunca detecta o disco como legível ou montável. Confusamente, se eu apagar e formatar o disco na minha máquina Linux como exFAT, nem a máquina do Windows 10, nem o MacBook podem lê-lo, embora ambos os dispositivos Linux possam. Isso me leva a suspeitar que a implementação do fusível está incompleta ... embora, reconhecidamente, eu não saiba o suficiente para ter certeza.

[Como uma nota lateral, eu também apaguei + formatado como um exFAT do macbook pro, e a máquina Windows 10 ainda podia ler / escrever. Nenhuma máquina linux poderia.]

Aqui está o que eu investiguei até agora:

sudo lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
...
sdj      8:144  0   3.7T  0 disk 
├─sdj1   8:145  0   6.4G  0 part 
└─sdj2   8:146  0   7.3G  0 part 

Observe os tamanhos do sistema de arquivos de lixo que o lsblk detecta. O volume é formatado com apenas 1 partição exFAT, abrangendo todos os 4TB.

parted -l /dev/sdj

Error: /dev/sdj: unrecognised disk label
Model: WDC WD40 EZRZ-00GXCB0 (scsi)                                       
Disk /dev/sdj: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags: 
Parted é pelo menos honesto o suficiente para dizer que não tem idéia do que estamos lidando. Ele detectou o modelo certo, é um WD vermelho 4tb.

fdisk -l /dev/sdj

Disk /dev/sdj: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x3258a7ab

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdj1           1     76805     76805  37.5M ee GPT
/dev/sdj2       77056 976754431 976677376 465.7G  7 HPFS/NTFS/exFAT

A saída do fdisk é interessante porque está quase certa. Ele mapeia uma partição como os metadados da GPT. O outro, ele encontra corretamente o id (0x07 == dados da microsoft ), mas o tamanho está errado. A partição é 4 TB e não 465,7 GB.

Eu verifiquei que a partição realmente abrange 4 TB escrevendo 4 TB de conteúdo de teste do Windows e leia com êxito todo o conteúdo do MacBook Pro.

A tentativa de montar qualquer um dos dispositivos detectados não funciona:

sudo mount.exfat-fuse -d /dev/sdj1 /mnt/foobar

FUSE exfat 1.2.4
ERROR: exFAT file system is not found.

sudo mount.exfat-fuse -d /dev/sdj2 /mnt/foobar

FUSE exfat 1.2.4
ERROR: exFAT file system is not found.

Mesmo no modo de depuração, o fusível exfat não imprime nenhuma saída útil. Olhando para a fonte , ela falha muito cedo, logo após a leitura do superbloco.

Eu dei uma olhada nos primeiros 1MB de dados no dispositivo com um hexdump, e parece sensato, sem lixo óbvio. (Pastebin: link )

Quaisquer etapas adicionais de depuração que eu deveria tentar? Alguma idéia do que está acontecendo aqui?

Editar:

Usando gdisk , parece que a unidade possui um MBR + GPT híbrido. No entanto, o gdisk detecta o GPT como inválido:

sudo gdisk /dev/sdj
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: not present

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
    
por Afforess 10.12.2017 / 19:58

1 resposta

3

O problema parece ser que o disco foi particionado como se fosse um disco de tamanho de setor nativo 4k. O GPT começa em 4096 bytes. Como é uma unidade 512e, é suposto começar com 512 bytes no disco. Eu diria que, por qualquer motivo, o Windows está detectando incorretamente a unidade como 4kn.

    
por 10.12.2017 / 20:48