[systemd-devel] [PATCH] readahead: add option to create pack in directory other than root

[Chaiken, Alison]

Commit message:
>> Add support for creating a readahead pack in a runtime-specified
>> directory.  Users may want the feature if they their rootfs is
>> read-only at boot or if they maintain more than one pack file.  The
>> new pack-file location is specified by a --pack-location command-line
>> switch.  Default behavior is retained if the switch is absent.

Lennart asks:
>Hmm, how could this work? I mean, if that writable dir is writable, it
>probably means that it is not on the same disk as the root dir. But that
>also means that it is mounted later, which means readahead-replay
>couldn't access it, since readahead-reply runs as one of the first
>things at all?

Some systems have multiple non-volatile storage devices.     If the rootfs is read-only, another non-volatile filesystem (or even a VFS) can receive the pack.    After boot, the pack can be moved over to the rootfs when it is remounted read-write.   It's true that creating the pack outside the rootfs will delay the start of collection, but if several large files are read a few seconds into boot, the performance degradation associated with the delay may be minimal.   We in fact have this situation and have tested this solution on v205 with success.

>I am actually all for moving the file, though. But can't we find a more
>automatic solution for this, that doesn't
>require manual configuration. Maybe a scheme like this could work:
>a) readahead-reply would look for both /.readahead and
> /var/lib/systemd/readahead. If both files exist, it picks the newer
>one, if only one exists it picks that one.
>b) readahead-collect would check if /var/lib/systemd is on the same
>mount point as /. If so, it would store the file in
> /var/lib/systemd/readahead. Otherwise it would store the file in
>  /.readahead, as before.
>This would move the file for most folks, while still allowing a split off
>/var -- but I figure this wouldn't solve your specific problem?

In our case, /var/lib/ is part of / partition that is unwritable, but /var/opt is not.   How about a tristate option, where we implement the solution you suggest above, but also allow runtime specification to override the other two choices?

-- Alison