[nSLUG] Advanced Format Disk (was: Best way to upgrade mirrored disks to larger capacity?)
George N. White III
gnwiii at gmail.com
Thu May 19 13:59:12 ADT 2011
On Thu, May 19, 2011 at 11:58 AM, D G Teed <donald.teed at gmail.com> wrote:
> On Thu, May 19, 2011 at 8:22 AM, George N. White III <gnwiii at gmail.com>
>> On Wed, May 18, 2011 at 11:35 PM, D G Teed <donald.teed at gmail.com> wrote:
>> > [...]
>> > Partitioning has come up as an issue I was not aware of before. They
>> > require
>> > partitions to be on certain boundaries with the Western Digital
>> > "Advanced
>> > Format"
>> > and the move to 4KB blocksize. Western Digital's info on it for Linux
>> > is
>> > rather lean.
>> > I found a nice page telling us how to do the math in fdisk and
>> > illustrating
>> > the performance difference in having the partitions sitting at the right
>> > boundaries.
>> > http://linuxconfig.org/linux-wd-ears-advanced-format
>> > Note how when using multiple partitions, the next start block must be 8
>> > greater
>> > than the previous end block. This becomes a gap of 64 with logical
>> > partitions,
>> > including a gap of 64 prior to the first partition in the extended
>> > partition.
>> > Is there something like this happening with Seagate or others?
>> Yes -- "Advance Format" is an industry-wide initiative.
>> <http://ubuntuforums.org/showthread.php?t=1619186> indicates that
>> Ubuntu 10.04 and
>> later should handle Advance Format disks, and has a link to a nice
>> DeveloperWorks article:
>> See <http://en.wikipedia.org/wiki/Advanced_Format>, which says:
>> "When using Advanced Format drives with legacy operating systems, it
>> is important to realign the disk drive using software provided by the
>> hard disk manufacturer. Disk realignment is necessary to avoid a
>> performance degrading condition known as cluster straddling where a
>> shifted partition causes filesystem clusters to span multiple physical
>> disk sectors. Since cluster to sector alignment is determined when
>> creating hard drive partitions, the realignment software is used
>> "after" partitioning the disk. This can help reduce the number of
>> unaligned writes generated by the computing ecosystem. "
>> In particular: <http://lwn.net/Articles/377897/> discusses the
>> implications for linux. Most of the problems appear to come when
>> Windows XP partitions are needed on a disk shared with linux.
> Linux has problems all on its own. fdisk found in Debian squeeze
> defaults to creating the first partition at sector 63, violating
> the divisible by 8 rule. I don't know what the installers from
> various distros do.
Sometimes 63 is really 64 -- see below.
The real problem is with filesystems that don't use 4KB blocks, as the
data clusters might not
"There is no 'proper' way to handle the new 4KB sector drives, because
1) there is no real standard for determining where to start a
partition so as to cause the data clusters within a partition to fall
on natural 4 KB disk boundaries (assuming that the clusters are at
least 4 KB in size themselves) - while NTFS and the ext(x) Linux file
systems start their cluster regions at a multiple of 4 KB from the
partition's start, FAT32 cluster regions begin at an offset from the
partition's start determined by the size of the partition (and hence
of its FATs) " --
Look for AF-Tech-r9-IDEMA.pdf or AF-tech.book in Google, p. 3:
If an Advanced Format drive has 4,096 byte physical sectors it reports
the following in IDENTIFY DEVICE data:
1. word 106: 6003h
2. word 209: 4001h (for adding one to each LBA) or 4000h (device adds
nothing to each LBA)
So if word 209 is 4001h then you want the partition to start at 63.
There is even a little picture in the
sdparm --page=ai -HHH /dev/sda | hdparm --Istdin
might show this information.
What is: alignment_offset?
$ cat /sys/block/sda/alignment_offset
A really interesting thread:
gives an example:
# ./hdparm -I /dev/sdb | grep Sector
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
"Quick answer from one of my contacts. Desktop drives will indeed ship
with an alignment of 1(*). The alignment is hardwired at time of
manufacture and can't be changed."
Other responses indicate the alignment is set when the drive is first used.
> Western Digital's site makes it sound like things are
> well under control in any modern Linux distro, but
> my experience with the defaults of gparted or fdisk
> shows this isn't what you get. You need to manually
> control and not accept defaults.
> The IBM article states gparted must be used with
> "Round to cylinders" option unchecked (not intuitive at all),
> and if using fdisk, the flags -H 224 -S 56 are required if you
> are not going to verify all the numbers manually in fdisk
> run without these options.
> I just tried fdisk with these funky options, creating
> an 8GB partition for sdb1 and got this result (fdisk -lu ):
> Device Boot Start End Blocks Id System
> /dev/sdb1 56 16783871 8391908 83 Linux
> The start sector defaulted to less than 64. I thought perhaps it
> would also choose an end sector divisible by 8.
The end sector shouldn't matter that much, as alignment is
determined from the beginning of the partition.
> gparted no longer has "Round to Cylinders", but now shows
> "Align to:" with options MiB, Cylinder and None. I selected MiB,
> provided the first partition with 2 MiB gap before it starts, and added
> a second partition of swap without telling gparted to leave a gap
> ( to see if it adds the 8 sectors as advised in the linuxconfig.org
> article). The results were not the best:
> fdisk -lu /dev/sdb
> Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
> 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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: 0x0001dd4d
> Device Boot Start End Blocks Id System
> /dev/sdb1 4096 16388095 8192000 83 Linux
> Partition 1 does not end on cylinder boundary.
> /dev/sdb2 16388096 22532095 3072000 82 Linux swap / Solaris
> Looks like I will be doing this manually as per the linuxconfig.org article,
> or something.
> fdisk has a -b option for blocksize. If I set that to 4096 and include
> the -H 224 -S 56 options, I get "Floating point exception" when
> making a new primary partition (after the first prompt for partition
> I don't see any articles suggesting the larger blocksize be set up
> within fdisk with -b. Would have thought this would match.
> There are a lot of articles out there saying different things. Some people
> -c on fdisk is all you need.
> Thankfully when we chuck a bunch of these into hardware RAID
> and use them they are using the whole disk and we don't have
> this step.
In the end what matters is that the 4k block sizes used by linux are
aligned with the 4k blocks used by the disk. I think linux tool authors
are trying to get it right, while vendors are only concerned with Windows
users. If you end up with horrible disk performance then you need to
consider an alignment problem.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the nSLUG