Rich Freeman posted on Sun, 15 Jul 2012 08:30:31 -0400 as excerpted: > Looking at the docs it seems like you'd need a hook for the cmdline > stage that sets rootok (assuming it gets that far without a root, or if > you set it to something like root=TMPFS). Then you'd install a hook to > mount to mount the tmpfs, and then use the fstab-sys module to mount > everything else. You'd need to create mountpoints for everything of > course, and not just the boot-critical stuff, since otherwise openrc > won't be able to finish mounting mounting everything.
The last bit I had already anticipated, as I'm doing something similar with my tmpfs-based /tmp and /var/tmp (symlinked to /tmp). Nothing mounted on top, but I'm creating subdirs inside it, setting permissions, etc. A critical difference is that this is on a full rootfs so I don't have to worry about not having the necessary tools available yet, but I do have the general ideas down. And I'm doing some bind-mounts as well, which require a remount to let all the options take effect, and of course there's mount ordering to worry about, etc. So I have the general idea, but doing it from an initr* with limited tools available will be interesting. As for the tmpfs rootfs itself, I have the vague idea that I'd "simply" (note the scare-quotes) use what's normally the initial root that's essentially thrown away, only I'd not throw it away, I'd just mount everything on top, keep using it, and /somehow/ ensure that anything running from it directly terminates one way or another, so that I don't have old processes stuck around using the mounted-over points. >> The big problem with btrfs subvolumes from my perspective is that >> they're still all on a single primary filesystem, and if that >> filesystem develops problems... all your eggs/data are in one big >> basket, good luck if the bottom drops out of it! > > Maybe, but does it really buy you much if you only lose /lib, and not > /usr? I guess it is less data to restore from backup, but... Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, tho the traditional /usr/src/, /usr/local, and /usr/portage are either pointed elsewhere with the appropriate vars or mountpoints/symlinks to elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, since /lib64, /usr and /etc would obviously be mounted from elsewhere, but they could still be either symlinked or bind-mounted to the appropriate location on the single (read-only) system-filesystem. FWIW I remember being truly fascinated with the power of symlinks when I first switched from MS. Now I consider them normal, but the power and flexibility of bind-mounts still amazes me, especially since, as with symlinks, it's possible to bind-mount individual files, but unlike symlinks (more like hard-links but cross-filesystem), it's possible to have some of the bind-mounts read-write (or dev, exec, etc) while others are read-only (or nodev, noexec...). > The beauty of btrfs subvolumes is that it lets you manage all your > storage as a single pool, even more flexibly than LVM. Sure, chopping > it up does reduce the impact of failure a bit, but I'd hate to have to > maintain such a system. Filesystem failure should be a very rare > occurance for any decent filesystem (of course, this is why I won't be > using btrfs in production for a while). Very rare, yes. Hardware issues happen tho. I remember the a/c failing at one point, thus causing ambient temps (Phoenix summer) to reach 50C or so, and who knows how much in the computer. Head-crash time. But after cooling off, the unmounted-at-the-time filesystems were damaged very little, while a couple of the mounted filesystems surely had physical grooves in the platter. Had that been all one filesystem, the damage would have been far less confined. That's one example. Another one, happened back when I was beta testing IE4 on MS, was due to a system software error on their part. IE started bypassing the filesystem and writing to the cache index directly, but it wasn't set system attribute, so the defragger moved the file and put something else in that physical disk location. I had my temp-inet-files on tmp, which was its own partition and didn't have significant issues, but some of the other betatesters lost valuable data, overwritten by IE, which was still bypassing the filesystem and writing directly to what it thought was its cache index file. So it's not always filesystem failure, itself. But I tried btrfs for a bit just to get an idea what it was all about, and agree totally with you there. I'm off of it entirely now, and won't be touching it again until I'd guess early next year at the earliest. The thing simply isn't ready for the expectations I have of my filesystems, and anybody using it now without backups is simply playing Russian Roulette with their data. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
