Bug 217088 - Poor performance of unaligned partitions, lots on reads on write
Poor performance of unaligned partitions, lots on reads on write
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-11-23 18:23 EST by Henrik Nordstrom
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-09 19:15:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Henrik Nordstrom 2006-11-23 18:23:00 EST
Description of problem:

Slow performance on partitions not starting at sector 1, such as is normally the
case for the first partition. For some reason all blocks seem to be read before
they are overwritten.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create a partition not starting on cylinder boundary. This is the default for
hte first partition on an harddrive (part of the first cylinder is used by the MBR)
2. dd if=/dev/zero of=/dev/sda1

Actual results:

Takes much longer than expected, and vmstat shows a lot of read activity. dd
reports a write performance of about 7 MB/s.

Expected results:

should complete fairly quickly, and no read activity in vmstate.

Additional info:

The exact same setup, but with partition starting exacly on cylinder boundaries
gives the expected result.

It does not matter where on the harddrive the partition is. Only that it does
not start on cylinder boundary.
Comment 1 Henrik Nordstrom 2006-12-09 19:15:39 EST
Found what it is. For some reason the block size for those devices gets set to
1KB instead of the expected 512bytes. As result a dd with default block size to
the device is real slow as every second write (first half of the 1KB blocks)
needs to read in the block to be modified..

Note You need to log in before you can comment on or make changes to this bug.