[systemd-devel] [PATCH] readahead: Add savedir option

Kok, Auke-jan H auke-jan.h.kok at intel.com
Thu Feb 14 12:53:00 PST 2013

On Thu, Feb 14, 2013 at 6:50 AM, Kyungmin Park <kmpark at infradead.org> wrote:
> Hi,
> On Thu, Feb 14, 2013 at 10:04 PM, Tom Gundersen <teg at jklm.no> wrote:
>> On Thu, Feb 14, 2013 at 9:47 AM, Seunghun Pi <sh.pi at samsung.com> wrote:
>>> In case of root file system mounted in read-only mode,
>>> the collected data cannot be stored.
>>> Then add code to specify directory path of collected data as RW position.
>>> With --savedir=PATH option, collected data can be stored in the path.
>> Hm, I don't se how this could work like this. What is making sure that
>> this other filesystem is mounted before you try to access it?
>> You probably want to use a .path unit as mentioned in [0].
> In our case, /var is mounted as tmpfs. IOW, it can't contain
> persistent .readahead for next booting.

It still means you're putting the pack on a second filesystem, so you
still need a path unit to delay startup of the replay and collect
threads to assure the pack is available before it is processed by

>> Also, if the case can be made for this being good enough, then maybe
>> we always want to put the readahead file there rather than having it
>> configurable?
> The main reason for this patch is that it can't save $root/.readahead
> at RO partition. Are there other way?

I don't think we want to change the location by default, it can have a
severe performance impact at boot time if we store the pack file on a
filesystem that is slow to mount.

As is, the patch isn't shocking per se, but it sure isn't going to
work for folks unless they also modify the unit files for the replay
and collector services.

And that points out the gap in the documentation that this patch
leaves - in order for this to be useful to folks, it should point in
e.g. a manual page that certain modifications are needed to the
service files.

Ultimately, that's a lot of work to support something as obscure as a
read-only rootfs. I'm not sure we even want to support that, as that's
a battle nobody should fight.


More information about the systemd-devel mailing list