** Changed in: lvm2 (Ubuntu)
Status: Confirmed = Invalid
--
very sub-optimal default readahead settings on device and unused readahead
setting in LVM
https://bugs.launchpad.net/bugs/129488
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I suggest to mark this as fixed. I did a few simple tests with hdparm -t
/dev/xxx and while I am not convinced that this is necessarily the best, let on
alone the only relevant measure of performance, I found no limitation in Karmic
on a current 250 GB 7200 rpm laptop hard drive with the
Normal disks also have a default 128kb readahead, not 4 MB, which seems
to be quite sufficient. I don't see why you want the dm device layered
on top of the physical disks doing MORE readahead, let alone 4 MB worth.
If the setting given to lvchange is not respected though, that is a bug.
--
sudo blockdev --report
sudo blockdev --setra 16384 sd[abcd]
i've tried a few read-ahead amounts, and they all seem to show similar
performance.
E.g. a raid 1 rebuild jumped from ~46 to ~52 MiB/s after command.
--
very sub-optimal default readahead settings on device and unused readahead
(I meant when increasing ra from 256 to a large number)
--
very sub-optimal default readahead settings on device and unused readahead
setting in LVM
https://bugs.launchpad.net/bugs/129488
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'm not so sure it works in Ubuntu already. But it's been working fine in
Debian
Testing for a while now.
Jack Wasey schreef:
lvchange -r 8192 your-lv
seems to be safe and permanent, but does OS ignore this value (as
suggested by the original poster)?
--
very sub-optimal default
n.b. readahead is only half of the problem.
my 4 disk RAID10 array is 2/3 of the speed of my disk disk RAID0 array
for big sequential reads. this is complete madness, as there are twice
as many disks to read from in the RAID10 case. ANyway, not strictly
related to this bug, but the interaction
lvchange -r 8192 your-lv
seems to be safe and permanent, but does OS ignore this value (as
suggested by the original poster)?
--
very sub-optimal default readahead settings on device and unused readahead
setting in LVM
https://bugs.launchpad.net/bugs/129488
You received this bug notification
Seems to exist in Jaunty as well
--
very sub-optimal default readahead settings on device and unused readahead
setting in LVM
https://bugs.launchpad.net/bugs/129488
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
this bug still exists in intrepid and the fix mentioned helps.
--
very sub-optimal default readahead settings on device and unused readahead
setting in LVM
https://bugs.launchpad.net/bugs/129488
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This issue appears to still be present on a fresh install of Hardy
(Ubuntu 8.04) as well.
I'm in the process of setting up a new server, and I applied the gross
hack posted by Kees Cook. I have applied this to my desktop system a
while back, but was hoping that it would have been fixed by now.
** Summary changed:
- 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
** Description changed:
Binary package hint: lvm2
When you create an LV, the device ends up
12 matches
Mail list logo