[linux-lvm] Strange behaviour with initramfs and read-ahead settings

[linux-lvm] Strange behaviour with initramfs and read-ahead settings

[Michael Guntsche]

Hi list,

I am currently running the 2.6.32-rc8 kernel with lvm2 version 2.02.54-1
on debian unstable.
Since my root is on LVM as well I use an initramfs for booting. The
setup I have consists of 5 disks in a RAID-5 with one PV on top of it.
Now for my problem. The md device correctly sets the read-ahead to 4096.
If I understand correctly lvm should get this value and set the
read-ahead on the LVs accordingly. This is not working correctly for
all my LVs.
Apart from the FIRST LV on the disk all the others show

Read ahead sectors     auto
  - currently set to     256

Since this did not seem to work I changed the RA with lvchange -r 4096
and rebooted. Swap now showed 

Read ahead sectors     4096

while the other LVs still showed


Read ahead sectors     4096
  - currently set to     256

lvs -o lv_read_ahead after boot 

 Rahead 
 2.00m 
 2.00m 
 2.00m 
 2.00m 
 2.00m

blockdev --getra  showed 256 for each LV apart from the first one.

For testing purposes I took one LV (home) offline and back online again

lvchange -an;lvchange -ay

After that the readahead was set correctly to 4096. I am not sure what's
happening here. I would understand a problem with getting the values
automatically but right now they are saved in the metadata but are still
set to 256. 

I am glad for any help on this topic, in the mean-time I am using
blockdev --setra to work around this problem.

Kind regards,
Michael Guntsche

Re: [linux-lvm] Strange behaviour with initramfs and read-ahead settings

[Milan Broz]

On 11/28/2009 11:52 AM, Michael Guntsche wrote:
> I am currently running the 2.6.32-rc8 kernel with lvm2 version 2.02.54-1
> on debian unstable.
> Since my root is on LVM as well I use an initramfs for booting. The
> setup I have consists of 5 disks in a RAID-5 with one PV on top of it.
> Now for my problem. The md device correctly sets the read-ahead to 4096.
> If I understand correctly lvm should get this value and set the
> read-ahead on the LVs accordingly. This is not working correctly for
> all my LVs.

Hi,

the logic is simple here
- if readahead is set to auto, it should inherit value from underlying device
for all LVs on that PV
- if there is explicitly set value in metadata, it should always use that
(you can switch back to auto by specifying -r auto)

(striped volumes calculate readahead differently, but it is not the case here)

There was similar issue - caused by not updated lvm in initrd
(or with different lvm.conf there) - all volumes activated
in initramdisk had different readahead value set - please check this.

Also Check default value of readahed in lvm.conf in activation section.

(See also https://bugzilla.redhat.com/show_bug.cgi?id=473273 )

If you still see that some volume is activated wrongly, please send
debug output of lvchange -a y -vvvv <LV>, blockdev --getra <PV>

> For testing purposes I took one LV (home) offline and back online again
> 
> lvchange -an;lvchange -ay
> 
> After that the readahead was set correctly to 4096. I am not sure what's
> happening here. I would understand a problem with getting the values
> automatically but right now they are saved in the metadata but are still
> set to 256. 

Check which lvm activated it first - it seems that it uses old default or
old version of lvm.

Milan
--
mbroz@redhat.com

Re: [linux-lvm] Strange behaviour with initramfs and read-ahead settings

[Michael Guntsche]

On 2009.11.28 15:31:47 , Milan Broz wrote:
> the logic is simple here
> - if readahead is set to auto, it should inherit value from underlying device
> for all LVs on that PV
> - if there is explicitly set value in metadata, it should always use that
> (you can switch back to auto by specifying -r auto)

I updated the initramfs and all binaries and configs are the same. While
debugging it further I noticed something. Since this is a server I
connect via SSH. Immediately after reboot as soon as the ssh daemon
started the read-ahead was ok (checked via blockdev). A few seconds
later the numbers changed. Looking through my init scripts I saw that
the mdadm --monitor daemon was started as well. I temporarily disabled
it and checked after a reboot. The numbers did not change. I re-enabled
the daemon but the numbers did not change either. I tried to reproduce
the problems several times now but did not succeed. Of course this could
be a red herring and the problem will re-appear but as it is now it
seems LVM is doing the right thing and something else is changing the RA
on my setup here. I debug this further the next time the problem shows
up.

Please mind, in all this tests I only updated the initramfs only once
and the problem was still there so I am ruling out a miss-configuration.
It looks more likely that the number is changed under special
circumstances.

Kind regards,
Michael