O MBR (também conhecido como "tipo Disklabel: dos") não deve mencionar o tamanho do disco diretamente (nem o número de cilindros / setores / cabeçotes).
O limite do kernel também não deve ser gravado no dispositivo de bloco, com base em um MBR corrompido nesse dispositivo. Então, o kernel ou hardware estava confuso. Preocupante assim:).
Em suposição, no space left on device é gerado diretamente pelo kernel. Se o dispositivo retornar um erro ao kernel e reclamar sobre o acesso além do final (acontecendo porque o kernel achou que não estava além do fim), eu suspeito que o kernel retornaria um erro genérico de E / S. E eu ficaria surpreso se esse erro de dispositivo específico não fosse mostrado no log do kernel ( dmesg ).
O mais estranho é que, enquanto lsblk e fdisk usam abordagens ligeiramente diferentes, o AFAICT está lendo um valor que é armazenado em cache no kernel. Se eles consistentemente obterem valores diferentes, isso também soa como se fosse o buggy que age no kernel. É possível fdisk -l solicitar uma nova verificação antes de ler o valor. No entanto, parece que você executou lsblk depois de fdisk -l , então essa diferença não deveria importar.
Eu manteria uma suspeita ligeira deste sistema. ("Estou mantendo backups independentes de quaisquer dados valiosos, como seria uma boa prática?", Suspeito).