[Triumf-linux-managers] WD20EARS Advanced Format Drive

[Konstantin Olchanski]

There appears to be a problem with the latest "Advanced format drives" and
SL-5.4 Linux. These disks use 4kbyte blocks internally and most
web sites mumble about minor performance loss because standard Linux
does not align the filesystems on these 4k boundaries, etc.

This was not my experience. After installing SL-5.4 on 2 mirrored (RAID1)
2TB WD20EARS disks, I had an unusable computer.

There was only one sign of trouble - the installation (PXE boot
install using the TRIUMF kickstart) took a very long time (many
hours instead of 1 hour at most on this state of the art
Intel Core i7 computer).

After installation, when I try to login and use the computer,
I observed strange 1-2-3 second "freezes". Those I traced to 1-2 second
delays in disk "write" operations. I confirmed that it was not
computer (used a different model 0.5TB disk, no delays, no freezes),
and I confirmed that it is not just my 2 disks (using an identical
2TB WD20EARS purchased separately - same "write" delays).

Google searches, red hat bugzilla & etc do not report such behaviour -
there are references to excessive head load/unload cycling, but my disks
do not seem to have *that* problem (confirmed using smartctl). At most,
people complain about some reduced read/write performance. Not strange
freezes making computer unusable.

But there was a lot of discussion about partition alignement & etc - e.g. see
http://www.linuxconfig.org/linux-wd-ears-advanced-format

So I tried some suggestions. To cut the story short,
the action proposed by most web sites - forcing disk formatting
to be "fdisk -H 224 -S 56" does work. The strange "write" delays
are gone, the strange OS freezes are gone, RAID1 rebuilds run
at the cool 100 Mbytes/sec.

Unfortunately the SL linux installer does not know to do
this "fdisk -H 224 -S 56" adjustement during the OS installation,
and after the OS is installed, it is too late to fix the disk layout
(unless one has mirrored disks and relishes playing with mdadm to bounce
the OS between the disks as one adjusts their layout one by one disk).

This issue will have to be raised with Red Hat and SL, but until they
have a solution, perhaps we should issue a notice that "advanced format"
disks are not recommended for general use as Linux system disks.

(Use by expert users should be okey - they can pre-partition the disks
using knoppix & co before running the SL installer; use for data or RAID
disks should be okey as partition layout can be corrected before mkfs & etc).

For reference, here is my partition tables - observe the non-standard "heads"
and "sectors/track".

[root at ladd13 ~]# fdisk -l

Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
224 heads, 56 sectors/track, 311465 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        6540    41018852   fd  Linux raid autodetect
/dev/sda2            6541       11835    33210240   fd  Linux raid autodetect
/dev/sda3           11836      311465  1879279360   83  Linux

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
224 heads, 56 sectors/track, 311465 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        6540    41018852   fd  Linux raid autodetect
/dev/sdb2            6541       11835    33210240   fd  Linux raid autodetect
/dev/sdb3           11836      311465  1879279360   83  Linux

Disk /dev/md0: 41.9 GB, 41940549632 bytes
2 heads, 4 sectors/track, 10239392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md1: 33.5 GB, 33550827520 bytes
2 heads, 4 sectors/track, 8191120 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md1 doesn't contain a valid partition table
[root at ladd13 ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md0              39674076   7009640  30616560  19% /
tmpfs                  4082564         0   4082564   0% /dev/shm
[root at ladd13 ~]# 

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada