| 2007-07-31 18:42:34 |
James Troup |
bug |
|
|
added bug |
| 2007-07-31 18:43:02 |
James Troup |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2007-07-31 20:22:43 |
Kees Cook |
lvm2: status |
New |
Confirmed |
|
| 2007-07-31 20:22:43 |
Kees Cook |
lvm2: importance |
Undecided |
Medium |
|
| 2007-07-31 20:22:43 |
Kees Cook |
lvm2: statusexplanation |
|
|
|
| 2007-07-31 20:41:49 |
Kees Cook |
bug |
|
|
added attachment 'udev-hack.diff' (gross hack to make --setra stick) |
| 2007-07-31 21:06:14 |
James Troup |
description |
Binary package hint: lvm2
When you create an LV, the device ends up with a readahead of 256 bytes. A normal (non-LVM) device's readahead appears to default to 8192 bytes. This makes LVM FSs benchmark (and perform) very badly (our read rate dropped from 320M/s to 90M/s).
To make matters worse, LVM has an internal 'read ahead sectors' variable which is apparently unused, but still displayed by e.g. lvdisplay which just adds to the confusion.
This is apparently a known issue upstream, but not considered a priority:
http://linux.msede.com/lvm_mlist/archive/2004/06/0108.html |
Binary package hint: lvm2
When you create an LV, the device ends up with a readahead of 256 512-byte sectors. A normal (non-LVM) device's readahead appears to default to 8192 512-byte sectors. This makes LVM FSs benchmark (and perform) very badly (our read rate dropped from 320M/s to 90M/s).
To make matters worse, LVM has an internal 'read ahead sectors' variable which is apparently unused, but still displayed by e.g. lvdisplay which just adds to the confusion.
This is apparently a known issue upstream, but not considered a priority:
http://linux.msede.com/lvm_mlist/archive/2004/06/0108.html |
|
| 2007-12-14 17:13:59 |
James Troup |
description |
Binary package hint: lvm2
When you create an LV, the device ends up with a readahead of 256 512-byte sectors. A normal (non-LVM) device's readahead appears to default to 8192 512-byte sectors. This makes LVM FSs benchmark (and perform) very badly (our read rate dropped from 320M/s to 90M/s).
To make matters worse, LVM has an internal 'read ahead sectors' variable which is apparently unused, but still displayed by e.g. lvdisplay which just adds to the confusion.
This is apparently a known issue upstream, but not considered a priority:
http://linux.msede.com/lvm_mlist/archive/2004/06/0108.html |
Binary package hint: lvm2
When you create an LV, the device ends up with a readahead of 256 512-byte sectors. A normal (non-LVM) device's readahead appears to default to 8192 512-byte sectors. This makes LVM FSs benchmark (and perform) very badly (our read rate dropped from 320M/s to 90M/s).
To make matters worse, LVM has an internal 'read ahead sectors' variable which is apparently unused, but still displayed by e.g. lvdisplay which just adds to the confusion.
This is apparently a known issue upstream:
http://linux.msede.com/lvm_mlist/archive/2004/06/0108.html |
|
| 2007-12-14 17:13:59 |
James Troup |
title |
insane default readahead settings on device and unused readahead setting in LVM |
very sub-optimal default readahead settings on device and unused readahead setting in LVM |
|
| 2009-07-10 16:53:06 |
Stefano Maioli |
nominated for series |
|
Ubuntu Karmic |
|
| 2010-02-14 05:01:18 |
Jared Wiltshire |
removed subscriber Jared Wiltshire |
|
|
|
| 2010-05-13 18:27:09 |
Phillip Susi |
lvm2 (Ubuntu): status |
Confirmed |
Invalid |
|
| 2010-09-07 07:44:53 |
Nathan O'Sullivan |
bug |
|
|
added subscriber Nathan O'Sullivan |
