Many Western Digital external USB drives over 2 TB (including at least some My Book, My Book Essential, Elements, and Easystore drives) can be configured for either 512 byte logical sectors or 4096 byte logical sectors using the WD Quick Formatter tool. When configured for 4096 byte logical sectors, the USB-to-SATA bridge in the enclosure does a translation between 512 byte logical sectors at the SATA interface to the internal drive and 4096 byte logical sectors at the USB interface to the host computer.
With 512 byte logical sectors, an MBR partition table could only use up to 2 TB of a drive. That's because MBR table entries are 32 bits with a max of 2^32 or 4,294,967,296 sectors. 2^32 sectors x 512 bytes/sector is 2 TB. With 4096 byte logical sectors, an MBR partition cable can use up to 16 TB of a drive. (2^32 sectors x 4096 bytes/sector is 16 TB) Windows XP only supports MBR partition tables, and so 4096 byte logical sectors are the only way to use all of the space on a drive over 2 TB in Windows XP. The newer GPT partition table format supported in Windows Vista and later does not have the 32-bit limitation, and can support disks larger than 2 TB regardless of the sector size.
The WD Quick Formatter tool (version 2.0.0.65 available for download as of this writing) can enable or disable the sector size translation. This version of the tool does not work correctly under Windows XP, so I recommend running the tool in Windows 7 or later. When run in Windows 7, or in later version of Windows but with Windows 7 compatibility mode, the tool will present two configuration options on the "Format your WD external drive" screen:
- XP Compatible: This option configures the drive for 4096 byte logical sectors, and creates an MBR partition table.
- Most Compatible (Vista or later required): This option configures the drive for 512 byte logical sectors, and creates a GPT partition table.
Both options also create a single partition filling the entire drive, and quick format it in NTFS.
If you run the tool in Windows 8 or later without putting it in Windows 7 compatibility mode, the tool will not present a compatibility option on the formatting screen and it will format in the "most compatible" mode (512 byte logical sectors).
WD Quick Formatter 2.0.0.65 doesn't work correctly in Windows XP: it successfully configures 4096 byte logical sectors, but fails to format correctly. Another tool can subsequently be used to partition and format the drive.
WD Quick Formatter 1.2.0.10 works correctly in Windows XP, but is not available for download from Western Digital anymore.
When the target drive is configured for the same logical sector size as the source, you can copy to it using dd and the copy will work without any need to alter the partition table.
I can confirm that these Western Digital external USB drives can be configured for XP compatibility:
Easystore 14 TB (WDBCKA0140HBK)
Easystore 12 TB (WDBCKA0120HBK)
Easystore 8 TB (WDBCKA0080HBK)
My Book Essential 1140, 3 TB (WDBACW0030HBK)
Elements 1021, 3 TB (WDBAAU0030HBK)
The 512-byte emulation is intended for compatibility with older systems. However, writes involving only part of a physical 4K sector can cause reduced performance because the sector needs to be read and modified before it can actually be written.
When a legacy operating system tries to write to an Advanced Format disk, performance issues can arise because the logical sectors written may not match up with the physical sectors.
- When only part of a 4K physical sector is read, the data is simply read off the physical sector and there is no reduction in performance. However, when the system tries to write to part of a physical sector (e.g. an emulated 512-byte sector rather than the whole physical sector), the hard drive needs to read the whole physical sector, modify the changed portion in the hard drive's internal memory, and write it back to the platters. This is called read-modify-write (RMW), an operation which requires an extra rotation of the disk and therefore reduces performance. Seagate explains this as follows:
[...] the hard drive must first read the entire 4K sector containing the targeted location of the host write request, merge the existing data with the new data and then rewrite the entire 4K sector:
In this instance, the hard drive must perform extra mechanical steps in the form of reading a 4K sector, modifying the contents and then writing the data. This process is called a read-modify-write cycle, which is undesirable because it has a negative impact on hard drive performance.
Disk partitions that are not aligned to a 4K boundary can cause degraded performance as well.
Traditionally, the first partition on a hard disk starts at sector 63. Windows XP and older operating systems partitioned disks in this manner. Newer versions of Windows will create partitions on a 1 MB boundary, ensuring proper alignment to the physical sectors. This is called Alignment 0.
Because LBA 63 is not a multiple of 8 (eight 512-byte legacy sectors fit into a 4K sector), an Advanced Format disk which is formatted in the old manner will have clusters (the smallest unit of filesystem data allocation, typically 4K in size) that are not aligned to the physical sectors on a 4K disk, a condition called Alignment 1. As a result, an I/O operation that otherwise involves 4K of data now spans two sectors leading to a read-modify-write operation that reduces performance.
While information about physical sector size is unnecessary if the OS always writes data on a 4K boundary, this information may still be needed by applications which perform low-level I/O.
- When a drive reports that its physical sector size is 4K, the OS or application can tell that it is an Advanced Format drive and therefore must avoid performing I/O operations that do not span full physical sectors. A drive that reports 512-byte native sectors does not impose this restriction. While newer operating systems will usually try to read or write data in 4K units whenever possible (making this information irrelevant), applications which perform low-level I/O may need to know the physical sector size so that they can adjust accordingly and avoid misaligned or partial-sector writes that cause slow RMW cycles.
Your SSD provides the ability to change the reported physical sector size because it is necessary for compatibility with certain storage arrays.
Datacenters often have storage arrays consisting of legacy 512n drives. 4K drives, even those that emulate 512-byte sectors, may not be compatible with such arrays, so this feature is necessary to ensure compatibility. See this forum thread:
We can't just stick a 4K drive in an array formatted with 512b disks. Many arrays (most notably ZFS based storage, which is increasingly popular as software defined storage makes waves) will not accept a replacement drive with a different physical sector format.
Note that better performance will be attained on modern systems if the drive is configured to use 4K sectors.
Best Answer
It's a little late, but I had a similar problem after the USB port of my IOMEGA hard disk case broke off. I switched to another USB-2-SATA case just to discover, that I could not mount the EXT4 partition. For some reason the IOMEGA case reported the logical sector size to be 4096, but my new case said it was only 512 bytes. This screws up the MS-DOS partitioning table.
It was driving me nuts, because with the help of
testdisk
I was able to access the partition, when changing the sector size, but I found no way to change the sector size system-wide. It turns out, that's not necessary, because EXT4 does not care for sector size, you just have to find the beginning of the partition you'd like to access.Quick fix: Use a loopback device to shift to the correct position of the partition.
Permanent fix: Rewrite partition table, accordingly.
In my case the affected drive was
/dev/sdb
.My quick fix was relatively easy, since I had only one partition beginning at sector 63.
Now we have to calculate the partition's position, when sector size still was 4096 bytes:
And use that with
losetup
:Your partition should now be mounted at
/mnt
.For the longterm fix I used
sfdisk
to dump the partition layout:Fixing the partition table by multiplying with the beginning sector with 8 where appropriate -- here I realized my partition table was kinda screwed from the beginning.
I edited the partition table dump with
nano sdb.partitions.sfdisk.text
:to:
and later on extended the partition to use all available space (which I determined by other means):
Last step is to write back the partition table with: