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!
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
