Leo: Updated with link to the other page about the same issue

2021-12-30T02:04:57Z

Updated with link to the other page about the same issue

← Older revision		Revision as of 02:04, 30 December 2021
Line 9:		Line 9:

	The workaround I've sort of walked myself into is to use GPT. One small benefit with using GPT is that the partition table is written to both the start and the end of the disk. The additional copy at the end of the disk inadvertently acts as a sort of buffer and allows for partitions that span the full size of the disk to continue to mount at the expense of a corrupt second GPT partition table.		The workaround I've sort of walked myself into is to use GPT. One small benefit with using GPT is that the partition table is written to both the start and the end of the disk. The additional copy at the end of the disk inadvertently acts as a sort of buffer and allows for partitions that span the full size of the disk to continue to mount at the expense of a corrupt second GPT partition table.

			== See Also ==
			* [[Disk Issues]]

			{{Navbox Hardware}}
			[[Category:Hardware]]

Leo: Created page with "I have a few Seagate USB 3.0 SATA controllers which I obtained by shucking a few 8TB external hard drives. While attempting to use them as an automated backup solution with a..."

2020-12-02T04:59:37Z

Created page with "I have a few Seagate USB 3.0 SATA controllers which I obtained by shucking a few 8TB external hard drives. While attempting to use them as an automated backup solution with a..."

New page

I have a few Seagate USB 3.0 SATA controllers which I obtained by shucking a few 8TB external hard drives. While attempting to use them as an automated backup solution with a Raspberry Pi, I noticed that some drives which were partitioned on a real computer couldn't be mounted.

For some reason, hard drives connected to these Seagate USB SATA controllers appear a sector smaller. Partitions using the legacy MBR that run to the end of the disk 'lose' a sector of space which some filesystems don't like. Additionally, the partition will appear as corrupt and might not even show up with <code>lsblk</code> because the partition exceeds the size of the disk. When attempting to mount such a partition, the kernel spits out the following message:

{{Highlight
| code = [ 4147.344005] EXT4-fs (sdd1): bad geometry: block count 488378390 exceeds size of device (488378389 blocks)
| lang = text
}}

The workaround I've sort of walked myself into is to use GPT. One small benefit with using GPT is that the partition table is written to both the start and the end of the disk. The additional copy at the end of the disk inadvertently acts as a sort of buffer and allows for partitions that span the full size of the disk to continue to mount at the expense of a corrupt second GPT partition table.

USB External Hard Disks Appear Smaller - Revision history

Leo: Updated with link to the other page about the same issue

Leo: Created page with "I have a few Seagate USB 3.0 SATA controllers which I obtained by shucking a few 8TB external hard drives. While attempting to use them as an automated backup solution with a..."