Ello, I'm sort of new to the lists...is it best to install from livecd?

Mike McCarty Mike.McCarty at sbcglobal.net
Thu Sep 4 17:29:41 UTC 2008


Tim wrote:
> Chris Tyler:
>> OTOH, I can't see why you'd avoid LVM these days in most
>> configurations.  It's very stable, adds only very tiny overhead,
> 
> Does it have repair tools yet?  Back when I first considered it,
> recovering lost files, etc., from it seemed like it would be much more

[...]

> That and the pain of trying to plug a second drive in from another
> system to grab files off it, and them both having the same volume/group
> names, really put me off it.  It suffers the same problem of volume
> labelling - stupid defaults, all installations get identically
> identified.

This is a common problem with much software development. The
developers think about new features which make "normal" use
"better" by some criteria. However, they forget to take into
account that sometimes one needs "not normal" use. This even
happens with seemingly seasoned developers. I recall once
when a project lead designed a firmware update protocol for
a telecomm switch which, if it lost remote comm during the
update would leave the remote device in a state where someone
would have to go out to the site (some were in the Phillipines)
remove the board from the switch, and physically desolder the
FLASH chips from the board and replace them. We were doing a
walkthrough and I saw the glaring hole. I had gently to ask
questions and finally we got down to "yes, but what happens
if the satellite link goes down right at this point", when
she finally saw the problem.

Thinking in terms of "how to recover" is a learned skill.

That's one of the reasons I don't run LVM. Another reason
is that, every single line of code on your machine is a place
for a defect to hide out. If you don't actually need the
code, then it shouldn't be there.

http://en.wikipedia.org/wiki/Software_testing

Has an interesting take on this issue. I disagree with some
of the statements. For example, the purpose of test is to
verify proper operation, not find defects. Defect finding is
more efficiently done by code reading. However, one really
good statement is

Many software defects are really Defects in Requirements.

No one thinks of putting "data recovery" into the requirements, so it
doesn't get put in. So, there's a hole.

As anyone who actually administers a machine knows, problems
do occur, and recovery is necessary. Sometimes recovery is
necessary due to bonehead actions by root.

Of course, best is when full backups of all data exist, so
that recovery, if it fails, is not catastrophic in effect.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!




More information about the fedora-list mailing list