On Wed, Apr 26, 2017 at 04:08:21PM +0200, Lennart Poettering wrote: > On Tue, 25.04.17 13:13, jr (darwinsker...@gmail.com) wrote: > > > hello, > > > > in a fully-volatile boot scenario /usr from a physical disk gets mounted on > > top of an instance of a tmpfs. my first question is why is that necessary? > > (the tmpfs part i mean) > > I am not sure I grok what you are trying to say? tmpfs is how on Linux > you can easily have a volatile file system, as it lives entirely in > memory and never hits the disk (admittedly modulo swapping). >
but once you mount over that tmpfs from disk the overlaying fs will hide the underlying tmpfs, no? baring the fs-caching done in kernel (readahead?), for anything that needs to be loaded into memory for executing or otherwise disk has to be touched for, well reading, at least once, no? this is the part i'm trying to understand, if the overlaying fs is mounted from physical disk, does mounting over tmpfs causes kernel to cache that fs entirely into memory? this looks a lot like initramfs where it is an instance of tmpfs but that also gets *shadowed* once "real_root" is switched to, no? > > my second question is, would it be possible to do the same but rather > > than mounting the /usr *populate* the said tmpfs with OS tree from said > > physical disk, preferably in a blocked or fs cached setup (db-cache or > > bcachefs). i realise that this can be done easily in initrd or even > > initramfs can hold the /usr but the problem there is when we boot > > "developmen" and not "production" in which case we want updates to be > > written to disk. > > I am not grokking this question either, but keeping the whole OS in > memory of course means you need a lot of memory. Moreover depending on > disk speeds it means your boot will be quite slow, as you copy stuff over > every single time before you can boot. If you copy things around like > that during boot the best thing would be to do it in the initrd, as > otherwise you are running the system already, that you are about to > prepare for running, and dropping open references the the old files is > hard (though not entirely impossible, after all there is "systemctl > daemon-reexec" and things). no, no, i'm thinking systemd as rdinit rather than init; i.e. initramfs is the real_root. one way of doing it is to pack the /usr into a initramfs archive and either build it into kernel or pass it via bootload (never worked for me)? then you boot the system into ram, enjoy blazing fast responsiveness of it but there comes along some update that one would like to apply and it turns out be really great that update. but how do you make it stick then? in fact if /var is not volatile and your package manager keeps it's records there (in my case portage does) on the next boot system is confused because it thinks that updates are going to be there. this has a number of solutions; bcachefs or dm-cache or even --overlay. --overlay is cool since it stages the upgrade; caching solutions are for performance though. i just don't know if the hooks are there (kernel and/or systmd) too boot the system this way? i.e. populate the initramfs from current or next or the one-after gold-master which resides on disk; start working on initramfs; associate this initramfs with original or another block-device or subvol of an fs on the disk and let our chosen caching system take care of mirroring our working tree with said *backup*. next reboot we should have the option of roll-back or continuing with our work and so on. please, please let me know if i'm still making no-sense :) English is not my strong suit and on top of that i'm horrible at explaining something. jrun _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel