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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
