[gentoo-dev] Re: udev <-> mdev

[Duncan]

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