[systemd-devel] readahead-replay seems to not be doing anything.

Kok, Auke-jan H auke-jan.h.kok at intel.com
Mon Feb 11 10:52:30 PST 2013


On Mon, Feb 11, 2013 at 2:34 AM, Gary van der Merwe <garyvdm at gmail.com> wrote:
> Hi all.
>
> This is my first post to this list, so I just want to say I thank you
> too all those
> who wrote systemd.
>
> systemd-readahead-replay does not seem to be doing what it should.
>
> Bootchart with readahead-[replay|collect] enabled:
>   http://www.garyvdm.co.za/bootchart-20130211-1328.svg
>
> Output of `/usr/lib/systemd/systemd-readahead analyze /.readahead` :
>   http://www.garyvdm.co.za/systemd-readahead-analyze
>
> There is no output in `journalctl -u systemd-readahead-replay.service`
>
> Bootchart with readahead-[replay|collect] disabled:
>   http://www.garyvdm.co.za/bootchart-20130211-1409.svg
>
> Note that both my root & home partitions are btrfs with
> options=defaults,noatime,compress=lzo.
>
> If you compare the bootcharts, you see that there is very little io reads when
> systemd-readahead-replay starts. (Do systemd-readahead-replay reads not show in
> bootcharts by design?)

the replay thread should be relatively short-lived, and theoretically
should run for about (readaheadvolume / hdd_speed) in time.

> Am I correct in thinking that systemd-readahead-replay is not doing what it
> should?

absolutely. Or at least, something is preventing it from working properly.

> How can I debug why it is not working?

unfortunately, it's hard to debug this. I've attached strace -tt to
-replay and get an idea of the timestamps of each fadvise() calls.

Also, I see you're using btrfs. I've noticed bad btrfs performance
with readahead and this reminds me that read_ahead_kb was horribly
mistuned for btrfs - I think we included some fixes for it but I don't
know whatever happened to those tunes.

compression may also be an extra factor.

what kind of drive does that system have?

Cheers,

Auke


More information about the systemd-devel mailing list