Bug 217088 - Poor performance of unaligned partitions, lots on reads on write
Summary: Poor performance of unaligned partitions, lots on reads on write
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-23 23:23 UTC by Henrik Nordstrom
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-12-10 00:15:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Henrik Nordstrom 2006-11-23 23:23:00 UTC
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):

kernel-2.6.18-1.2849.fc6

How reproducible:

always

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
3.

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-10 00:15:39 UTC
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.