On Sun, Feb 07, 2010 at 08:27:46AM -0800, Mark Knecht wrote:
> <QUOTE>
> 4KB physical sectors: KNOW WHAT YOU'RE DOING!
>
> Pros: Quiet, cool-running, big cache
>
> Cons: The 4KB physical sectors are a problem waiting to happen. If you
> misalign your partitions, disk performance can suffer. I ran
> benchmarks in Linux using a number of filesystems, and I found that
> with most filesystems, read performance and write performance with
> large files didn't suffer with misaligned partitions, but writes of
> many small files (unpacking a Linux kernel archive) could take several
> times as long with misaligned partitions as with aligned partitions.
> WD's advice about who needs to be concerned is overly simplistic,
> IMHO, and it's flat-out wrong for Linux, although it's probably
> accurate for 90% of buyers (those who run Windows or Mac OS and use
> their standard partitioning tools). If you're not part of that 90%,
> though, and if you don't fully understand this new technology and how
> to handle it, buy a drive with conventional 512-byte sectors!
> </QUOTE>
>
> Now, I don't mind getting a bit dirty learning to use this
> correctly but I'm wondering what that means in a practical sense.
> Reading the mke2fs man page the word 'sector' doesn't come up. It's my
> understanding the Linux 'blocks' are groups of sectors. True? If the
> disk must use 4K sectors then what - the smallest block has to be 4K
> and I'm using 1 sector per block? It seems that ext3 doesn't support
> anything larger than 4K?
The problem is not when you are making the filesystem with mke2fs, but
when you partitioned the disk using fdisk. I'm sure I am making some
small mistakes in the explanation below, but it goes something like
this:
a) The harddrive with 4K sectors allows the head to efficiently
read/write 4K sized blocks at a time.
b) However, to be compatible in hardware, the harddrive allows 512B
sized blocks to be addressed. In reality, this means that you can
individually address the 8 512B-sized chunks of the 4K sized blocks,
but each will count as a separate operation. To illustrate: say the
hardware has some sector X of size 4K. It has 8 addressable slots
inside X1 ... X8 each of size 512B. If your OS clusters read/writes on
the 512B level, it will send 8 commands to read the info in those 8
blocks separately. If your OS clusters in 4K, it will send one
command. So in the stupid analysis I give here, it will take 8 times
as long for the 512B addressing to read the same data, since it will
take 8 passes, and each time inefficiently reading only 1/8 of the
data required. Now in reality, drives are smarter than that: if all 8
of those are sent in sequence, sometimes the drives will cluster them
together in one read.
c) A problem occurs, however, when your OS deals with 4K clusters but
when you make the partition, the partition is offset! Imagine the
physical read sectors of your disk looking like
AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD
but when you make your partitions, somehow you partitioned it
....YYYYYYYYZZZZZZZZWWWWWWWW....
This is possible because the drive allows addressing by 512K chunks.
So for some reason one of your partitions starts halfway inside a
physical sector. What is the problem with this? Now suppose your OS
sends data to be written to the ZZZZZZZZ block. If it were completely
aligned, the drive will just go kink-move the head to the block, and
overwrite it with this information. But since half of the block is
over the BBBB phsical sector, and half over CCCC, what the disk now
needs to do is to
pass 1) read BBBBBBBB
pass 2) modify the second half of BBBB to match the first half of ZZZZ
pass 3) write BBBBBBBB
pass 4) read CCCCCCCC
pass 5) modify the first half of CCCC to match the second half of ZZZZ
pass 6) write CCCCCCCC
Or what is known as a read-modify-write operation. Thus the disk
becomes a lot less efficient.
----------
Now, I don't know if this is the actual problem is causing your
performance problems. But this may be it. When you use fdisk, it
defaults to aligning the partition to cylinder boundaries, and use the
default (from ancient times) value of 63 x (512B sized) sectors per
track. Since 63 is not evenly divisible by 8, you see that quite
likely some of your partitions are not aligned to the physical sector
boundaries.
If you use cfdisk, you can try to change the geometry with the command
g. Or you can use the command u to change the units used in the
partitioning to either sectors or megabytes, and make sure your
partition sizes are a multiple of 8 in the former, or an integer in
the latter.
Again, take what I wrote with a grain of salt: this information came
from the research I did a little while back after reading the slashdot
article on this 4K switch. So being my own understanding, it may not
completely be correct.
HTH,
W
--
Willie W. Wong ww...@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire
et vice versa ~~~ I. Newton
