Formatting 1.5TB Western Digital EARS Drives

Command Line Formatting of a WD EARS 1.5TB Hard Drive

The Situation

The Western Digital 1.5 TB Drives are known to report the wrong size and many programs like fdisk create partitions on the wrong boundary, or without physical sector alignment.

I realized this after horrible performance during a mkfs.ext4 -cc, a read write bad blocks test which took over 24 hours.

Test if your a victim

When you type

sudo fdisk -l

Do any of your partitions have a START value of 63 or some odd number?

Kill the ALL THE THINGS on the drive

IMPORTANT! It is important to understand which drive you want to work with. "sudo fdisk -l" lists all drives and partitions. Be very careful to choose the correct one. Delete all data from the drive. And Verify with "df" that your correct drive is actually 0% full.This tutorial uses /dev/sdd. This values is chosen as most computers don't have 4 physical hard drives and will most likely error out. You will need to adjust /dev/sdd to represent your actual value.

List the partitions

sudo fdisk -l

Execute Fdisk with compatibility and units parameters, turning it into old mode to compensate for WD lying drives.

Choose Option: 2048
This Sets your First Sector to be 2048 bits. 2048 is the correct alignment, If it suggest 63 then may I suggest more research.

Choose Option: , Just Press Enter
This finalizes the partition creation, as you just selected the maximum partition size.

Choose Option: p
This prints your partitions within your partition table.
Notice the Start column having 2048. It is imperative that all other partitions on this hard drive are also aligned to a 2048 boundary. If for example one did not choose the maximum size during the creation of partition #1, there will be waisted space if one did not choose an ending value which is not within the set of 2048*n-1, for positive whole values of n. Some more explanations and calculations are required; But in the end the really important value to concern yourself is the Start value for a partition must be a multiple of 2048. Seriously, Do you want a 500GB Partition, well did you know that that 500GB is really 500*1024^3=536870912000 bits. The equation for Start value of the Second Partition should be like $DiskSizeInGB * 1024 * 1024 * 1024 / 512 = 1048576000, the Start Value.

Test the write speed, benchmark

Run dd with a byte size of 1MB, for a total of 128MB of data coming from the /dev/zero zero generator to the hard drive /dev/sdd1 using file synchronization before termination (commits writes). Write speeds in my test case indicate 59.8 MB/s

sudo dd bs=1M count=128 if=/dev/zero of=/dev/sdd1 oflag=dsync

Format the ext4 filesystem with read write bad blocks test. At the time of this writing.n The following command...

sudo mkfs.ext4 -L WDEARS -cc /dev/sdd1

... uses block sizes of 4096 by default. But in the case that it does not. You should format using

sudo mkfs.ext4 -b 4096 -L WDEARS -cc /dev/sdd1

or perhaps a windows compatible format.

sudo mkfs.ntfs -b 4096

Summary

Initially a read write bad blocks test indicated that my hard drive was performing horrible. Although it made it though the read write bad block test with zero errors, it had consumed too much time to be reasonable.

After this procedure the hard drive performs an order of magnitude better. Compatibility and Unit Parameters were given to fdisk to override the kernel values. Manually Alignment along 2048 boundaries allow for faster writes and verifies.

The Following link provided reference material, and useful editorial comments. It summarizes a days worth of research on online forums. EARS Information

This drive, like most of WD Caviar ones with equal or more than 1 TB, is known for having serious problem with EXT4 - intensive use, specially with more than one partition leaves then to generate false badblocks in a matter of minutes. EXT4 is not recommended, prefer to use a more robust filesystem, like XFS. EXT3 is known to have worse performance than XFS; and EXT2 have the problem to need to fsck after every reboot. BTRS is slow, and ReiserFS will be probably dead in near future.