This little rant/buying hint could also be called: Western Digital and Advanced Format - why it sucks so much and why you should avoid buying that crap.

The Problem

WD has switched from 512-bytes blocks to a hard disk block size of 4kB (4096 bytes). This is all fine and well and in general a good idea nowadays, but there is one pitfall: if the partitions are not aligned to the block boundary (4096 bytes in that case), file systems might have to use expensive RMW (read-modify-write) cycles in order to write misaligned blocks. This is quite expensive and will impact hard drive performance massively (some threads speak of performance of 1 MB/s). Modern operating systems (such as Linux) also do not have any problem with drives with such block sizes. As can be read in this LKML thread, if you use a kernel >= 2.6.31 and util-linux >= 2.17, everything will work smoothly. The kernel will ask the hard disk about its geometry (called "topology information"), fdisk will use that topology information and align the partions correctly, problem solved before it ever occured. It should all work automagically. The hard drive has the option to report in which type of addressing it should be talked to logically (logical block size) and what the actual physical block size on disk is (physical block size). Those are two different values, a standard hard drive should have a logical blocksize of 512 bytes and a physical block size of (as mentioned twice) 4096 bytes. Previously, those were identical (both 512 bytes).

WD and their policy

In order to avoid complaining customers about "broken drives", WD has started a nice policy: they try to educate their customers on why the block size change was necessary and what steps they have to take in order to get them running smoothly. A great idea, actually. However, the WD drives are far dumber than their PR people. The technical approach of WD was that the drive still claims to be a vintage drive (i.e. 512 bytes logical and physical block size), although this is - in fact - not true.

Lying causing trouble

Since the WD drives (WDC WD15EARS 1.5TB) - instead of reporting the truth (512/4096) - choose to lie about their blocksize (512/512 bytes), the operating system has no way of knowing that it deals with a drive with large blocks. Therefore, every application you run (as fdisk or mkfs.reiserfs) has to be told to override the setting the kernel told it.

Solution the Windows way

So Windows people will have the same problem, right? Well, yes, they have. If you want to install Windows XP, there's a special jumper - I call it the GJC (Grand Jumper of Crapness). When you enable the GJC, the drive will lie to the installation program (probably because the crappy Windows installer can't cope with modern hardware, as it never has) and somehow magically align the partions, although the installer would misalign them. Wow, what great technical abomination you have created there, WD. I raise my hat to you technical wizards of pure awesomeness. Deep down in my heart I believe there is a group of technically quite competent people at WD who cry every time a little when they think of the GJC and the inept morons who created it.

WD: Excellence eversince!

I've been a long-time WD customer. Actually, I'm quite sure that my very first hard drive (that was a 20MB SCSI monster) was a WD. I've tried some other hard drive brands and was always bitterly disappointed. Ultimately, I've gone with WD eversince and put WD drives in whenever someone asked me to design a system. So, I thought, well - let's call their support and ask about the lying hard drive problem. Let's ask them if there's a "secret jumper" which makes the hard drive play nice (i.e. telling the truth) or if there's a firmware update or even some kind of bizarre configuration problem. Yeah, you'd think. I called there and described my problem, honestly stating that I've been using Linux. And I had a real bitch on the other end, that one's for sure. Linux, she stated, was not supported in any way and if I had and trouble with Linux they would not be able to support me. I responded that the problem was not, in fact, Linux (which is perfectly able to deal with real, modern hard drives), but their hard disk which was making it impossible for any operating system to know what block size the device had. She stated that I had said that I'd been using Linux, to which I agreed. And she stated that there'd been a problem, to which I agreed. Therefore, the bitch concluded, there was a problem with Linux with which she could not assist me with. Even when I responded that There was a total of 7 drives I would been sending back, she just did not give a crap. That's the way WD appears to work: as long as you like our products, nice! As soon as you have a problem with our drives: Go fuck yourself and die already! Well played, WD, well played.

How it could work with Linux

If you really want the drive to run, you sure can make it. You just have to be careful as hell when partitioning (i.e. align all partitions manually) and you also have to be careful when creating a file system. And since WDC really took care to make it as hard as possible (having their HDDs telling the truth would've been too hard for them, I guess), you will enjoy the fun of CHS (cylinders, heads, sectors) once again! Yay!

CHS revisited

Hard disks today use LBA addressing. CHS is the ancient addressing system that was in use before LBA. Still, there are conversion rules for LBA to CHS addresses and back. Those are:

lba := (c, h, s) -> ((c * HPC + h) * SPT) + s - 1;
chs := lba -> (
    trunc(lba / (SPT * HPC)),
	trunc(lba / SPT) mod HPC, 
	(lba mod SPT) + 1
);

From that calculation you can see that a cylinder is exactly HPC * SPT logical blocks in size. HPC and SPT are the "Heads per Sector" and the "Sectors per Track", two values which are also written down in the partition table and which used to correspond to acutal physical hard drive parameters (they stopped corresponding to actual parameters years ago). A logical block is usually 512 bytes (that's the logical block size mentioned above). So in order to have cylinders aligned at 4096 bytes boundaries, the "HPC * SPT * 512" value has to be divisible by 4096, or simlified: "HPC * SPT" must be divisible by 8. The default, however, is a HPC of 255 and a SPT of 63, which yields 13515 logical blocks per cylinder or 6919680 bytes per cylinder (which is not divisible by 4096 bytes).

Therefore, one should think that choosing HPC and SPT correctly when partitioning the drive results in all being well. And one could guess that 252 HPC and 62 SPT should work smoothly (this will give you 15624 LB sized cylinders which are 7999488 bytes per cylinder, 7999488 = 1953 * 4096). There is one last pitfall, however: When you create the first partition at cylinder 1, the first partition will be created at CHS (0, 0, 1) as this is the first CHS-address (use the above formula and you will see that CHS{0, 0, 1} = LBA{0}). You have two options: Either you let the first partition start at cylinder 2 or make SPT alone be divisible by 8. See the following table for clarification:

Cylinder 252/62 252/56 255/56
1 0x7c00 (MISALIGN) 0x7000 0x7000
2 0x7a1000 0x6e4000 0x6f9000
3 0xf42000 0xdc8000 0xdf2000

CHS sucks, isn't there something else?

As I mentioned, CHS is deprecated and not in use anymore, it's just used for calculation purposes nowadays. You'll see that you start up fdisk:

joequad [~]: fdisk -H 255 -S 56 /dev/sdb
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').
[...]

Okay, let's try that:

joequad [~]: fdisk -cu /dev/sdb

In this mode, you will notice that the addressing is directly in sectors (i.e. in logical blocks). The minimal value for recent versions of fdisk is 2048, which is already divisible by 8. You also have to take care that the last sector yields mod 7 divided by 8 (as fdisk displays the sectors inclusive, not exclusive). Therefore, this would work fine:

joequad [~]: fdisk -cu /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x7284c740.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (2048-2930277167, default 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-2930277167, default 2930277167): 2847

Command (m for help): p

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x7284c740

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048        2847         400   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
joequad [~]:

Here, we have created a partition from LBA 2048 to LBA 2847 (all inclusive). 2048 MOD 8 = 0, which is good. 2847 MOD 8 = 7, which is also good. You will notice the total partition size is divisible by 4096:

joequad [~]: cat /dev/sdb1 | wc -c
409600

Final Pitfalls

In all likelyhood you will not want to write directly to disk (in which case you'd write your software to use 4kB blocks, obviously), but you want a file system on top of that. Here again you must pay attention to the block sizes. Since those cannot be determined automatically using WDs crappy hard disks (THANKS AGAIN, MORONS!), you need to specify it each and every time. If you forget it, you need to recreate your file system or suffer enormous performance losses. If you know what to do, it's actually pretty simple:

joequad [~]: mkfs.ext4 -b 4096 /dev/sdb1
or
joequad [~]: mkfs.reiserfs -b 4096 /dev/sdb1
or (hahaha)
joequad [~]: mkfs.ntfs -s 4096 /dev/sdb1

Conclusion

You can get it, if you really want. But you must try, try and try, try and try, you'll succeed at last. Oh and you must know what the fuck you're doing in order not to screw up things majorly. Sums it up nicely, really. I will return my WD drives, however, since I was so totally pissed about the bitchy "support" that I got from Mrs. Linuxguru. I am quite disappointed, frankly, about the way WD goes about this. If they really wanted their 4k drives to be used (and they should, it's a much better technology than what we're using right now) they should have the courtesy of implementing drives correctly. Building drives with crappy legacy systems like Windows XP in mind is just weak. Too weak for a company like WD, IMHO.