Kevin Krammer posted on Sun, 17 Apr 2011 19:16:10 +0200 as excerpted:
> On Sunday, 2011-04-17, Duncan wrote:
>
>> Plus, because unlike md/raid, lvm must be configured at every run from
>> userspace, either lvm can't be run on root itself, rather limiting its
>> flexibility which is much of its point, or if it is to be run on root,
>> it requires an initr*, adding yet MORE complexity to an otherwise
>> reasonably simple initr*-less boot.
>
> What do you mean with "must be configured at every run"?
>
> I never have any interaction with LVM tools unless I want to
> add/remove/resize LVM volumes.
What I mean is that the config is found in userspace on the disk, and must
be read and auto-configured by the userspace helper at every boot to tell
lvm what devices to operate on, what devices to create out of them, and
what their physical and logical limits are. This job MUST be done by
userspace, as the data (static or not) cannot be either handed to the
kernel on the kernel command line (from grub/lilo/whatever or on the
compile-time specified kernel command line).
This contrasts with traditional disk layouts and with md/raid, for
instance, which is smart enough to scan and configure itself without any
outside config, in many cases, or can read its config directly from the
kernel command line.
As a consequence, were the original rootfs to be managed by lvm, there'd
be the proverbial chicken-and-egg problem, as the kernel could not load
the rootfs without knowing about the lvm it's on, and could not load the
lvm configuration and userspace binary to give it that info, since it's on
the rootfs.
Now binary distributions tend to handle this in the same way they do the
kernel modules necessary to load the rootfs itself -- they put it all on
the "hack" of a solution called an initr* (initrd, the separate-image init-
ramdisk, early on, now sometimes initramfs, with this early user-space
stub-filesystem appended to the kernel file itself).
But using an initr* is normally an option (quite a complex one, to the
point it's really a hack, tho a practically necessary one at times!) for
those who build a custom kernel, with at least all the drivers necessary
to load the real-root on their hardware, directly built into the kernel
itself. And because the ability to load modules at all, means a cracker
could load who knows /what/ sort of code directly into kernel mode itself,
particularly those running public servers exposed to cracking attempts
should be STRONGLY considering built-ins for ALL kernel code, at which
point they can disable the module loader code (and all the complexity that
comes with it) entirely, thus avoiding that security issue entirely.
So where it's an option, there's a number of quite strong reasons NOT to
run an initr*. (1) Given that code /will/ contain bugs, complexity is the
enemy of reliability. (2) Complexity also decreases the sysadmin's
ability to understand what's going on, thus MARKEDLY increasing the
chances of "fat-fingering" something -- and this factor gets MANY TIMES
WORSE when a sysadmin is operating under the pressures of recovery mode,
when stress is at max, information and time are often limited, and the
normal usermode tools may be unavailable or themselves limited. (3)
Module loading (as from an initr*) is a non-trivial security issue,
particularly for those running public servers.
In this thread I've been stressing point two the most, as it was one of
the biggest deciding factors, here. I do not want and chose to simply not
have, since it wasn't necessary, the piled on pressure of trying to deal
with either an initr* or lvm, in the event that I'm ever faced with a
recovery scenario. It's that sort of decisions that can make a very real
difference between successful recovery, and failure, either due to simply
not understanding the situation, or due to fat-fingering due to working
with tools one isn't used to under the most difficult and stressful
scenario most admins will ever deal with, that of trying to recover a
failed system, often under extreme time pressure (perhaps millions of
dollars of sales a day go thru that system, don't ask me why the bosses
won't authorize redundant backups systems!). Now I'm a hobbyist, but I
spend enough time on my system and value what's on it enough that I don't
want to foolishly be putting myself in situations that make a bad recovery
situation even worse!
Now people who simply trust the tools to do what's right probably don't
even notice the issue on many binary distributions as lvm and its config
are simply built-into the initr* along with the modules necessary to boot
the real root. But at least to me, that's the sort of person I'd expect
not to have actually tested his recovery scenario as well, or perhaps to
have hardly even thought about it, simply trusting the distribution and
their tools.
Unfortunately, when push comes to shove and it's time to actually /use/
those recovery tools, such people are often at a loss, and may not even
have the ability to do it at all (bad backups come to mind here, or as
Gene mentioned the problem he's actually having earlier, probably good
backups, but backed-up with a custom-built tool that's lost now as well,
making recovery far more difficult than it should have been!)
But some people like to have a decent enough understanding of not only the
tools, but the principles and layers involved, so they can have a
reasonable confidence of actually doing that recovery successfully, even
under the stressful conditions we're talking about. And they test them,
too, and know exactly how to for instance rebuild that raid after pulling
a disk from a running system, and what alternative commandline options to
feed the kernel to boot from the backup-root-partition on an entirely
separate md-raid, should not only the working root be unbootable (bad
update of a critical package, but the working root's filesystem and/or
raid get scrambled beyond recovery (as, perhaps, by the live-git kernels
they might test!).
These are situations I've both tested and in some cases actually dealt
with, "This is not a drill!"
> The latter is why I primarly use it, i.e. in order to distribute the
> rather limited space of my SSD to the respective partitions on demand.
>
> Occasionally adding and later removing additionally encrypted volumes
> when working on something you need to safely dispose of when finished.
Now that scenario actually does make a decent amount of sense. Consider,
for much of the system data (the generally encrypted bit), and any
temporary volumes, encrypted or not, that can go on other than the rootfs,
so LVM managing it does make some sense. But of course you either can't
put root on it, or you must use an initr* if you do (which you may well do
anyway, but which I didn't want to do).
FWIW, here, I'd probably throw hardware at the problem. I took the 120
gig conventional disk option on my netbook, but it'd be IIRC 8 or 16 gig
SSD otherwise, and has two memory card slots and of course several usb
slots (plus the ability to wire one internally if desired), for SSD
storage upgrade if one wishes. All those are cheap enough, at least in
comparison to the netbook itself, that I expect I'd be using them for the
temporary use you outlined, keeping the space on the SSD for other uses.
But as it's available and convenient for you to use, why not, right? =:^)
--
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
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
