We’re rewarding the question askers & reputations are being recalculated! Read more.
2 added 406 characters in body
source | link

MBR (aka "Disklabel type: dos") should not mention the disk size directly (nor the number of legacy cylinders/sectors/heads).

https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout

Nor should the kernel limit writes to the block device, based on a corrupt MBR on that device. Either So either the kernel or hardware was confused. Worryingly so :).

At a guess, no space left on device is generated directly by the kernel. If the device return an error to the kernel and complained about access beyond the end (happening because the kernel thought it wasn't beyond the end), I suspect the kernel would return a generic IO error instead. And I'd be surprised if this specific device error wasn't shown in the kernel log (dmesg).

The strange thing is that while lsblk and fdisk use slightly different approaches, AFAICT both are reading a value which is cached in the kernel. If they consistently get different values, itthis also sounds like it's the kernel is acting buggy. It's possible fdisk -l requests a rescan before reading the value. However it sounds like you ran lsblk after fdisk -l, so that difference shouldn't matter.

I would retain a slight suspicion of this system. ("Am I maintaining independent backups of any valuable data, as would be good practice?" suspicious).

MBR (aka "Disklabel type: dos") should not mention the disk size directly (nor the number of legacy cylinders/sectors/heads).

https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout

Nor should the kernel limit writes to the block device, based on a corrupt MBR on that device. Either the kernel or hardware was confused. Worryingly so :).

The strange thing is that while lsblk and fdisk use slightly different approaches, AFAICT both are reading a value which is cached in the kernel. If they consistently get different values, it sounds like the kernel is acting buggy. It's possible fdisk -l requests a rescan before reading the value. However it sounds like you ran lsblk after fdisk -l, so that difference shouldn't matter.

I would retain a slight suspicion of this system. ("Am I maintaining independent backups of any valuable data, as would be good practice?" suspicious).

MBR (aka "Disklabel type: dos") should not mention the disk size directly (nor the number of legacy cylinders/sectors/heads).

https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout

Nor should the kernel limit writes to the block device, based on a corrupt MBR on that device. So either the kernel or hardware was confused. Worryingly so :).

At a guess, no space left on device is generated directly by the kernel. If the device return an error to the kernel and complained about access beyond the end (happening because the kernel thought it wasn't beyond the end), I suspect the kernel would return a generic IO error instead. And I'd be surprised if this specific device error wasn't shown in the kernel log (dmesg).

The strange thing is that while lsblk and fdisk use slightly different approaches, AFAICT both are reading a value which is cached in the kernel. If they consistently get different values, this also sounds like it's the kernel acting buggy. It's possible fdisk -l requests a rescan before reading the value. However it sounds like you ran lsblk after fdisk -l, so that difference shouldn't matter.

I would retain a slight suspicion of this system. ("Am I maintaining independent backups of any valuable data, as would be good practice?" suspicious).

1
source | link

MBR (aka "Disklabel type: dos") should not mention the disk size directly (nor the number of legacy cylinders/sectors/heads).

https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout

Nor should the kernel limit writes to the block device, based on a corrupt MBR on that device. Either the kernel or hardware was confused. Worryingly so :).

The strange thing is that while lsblk and fdisk use slightly different approaches, AFAICT both are reading a value which is cached in the kernel. If they consistently get different values, it sounds like the kernel is acting buggy. It's possible fdisk -l requests a rescan before reading the value. However it sounds like you ran lsblk after fdisk -l, so that difference shouldn't matter.

I would retain a slight suspicion of this system. ("Am I maintaining independent backups of any valuable data, as would be good practice?" suspicious).