1i5t5.duncan at cox
Jul 15, 2012, 11:25 AM
Post #32 of 45
(239 views)
Permalink
|
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
|
