<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Thanks again for those answers which I'm sure will
also interest other people.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>If I understand correctly, I can use software RAID
with no disadvantages over hardware RAID as for reliability in cases of power
failures (as long as we use journalised filesystem), is that correct
?</FONT></DIV>
<DIV><FONT face=Arial size=2>I'm not in fear about he CPU increase for software
RAID, that isn't a problem to me.</FONT></DIV>
<DIV><FONT face=Arial size=2>What else do you think I would loose by using
software RAID instead of hardware raid ?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Also, sorry to insist about power failures, but
here is the reason: my provider allows me to have remote reboot on my server,
which is very helpful when the system hangs suddenly as I have no physical
access. Curently I must do a hardware reboot 1-2 times per year and the system
starts and runs again correctly. These remote reboots are power failure types
and are more and more frenquently offered to customers. It avoids us to ask the
technician to reboot the machine.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Your professionnal experience is very instructive.
All you said about the flush problem is thrilling. Do you mean then that having
battery bakup RAID will not help much regarding reliability in cases of power
failures ? Then many people have been tricked ?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Last: is there a mean of knowing what datas have
been lost when a power failure happened ? Can we see that in terms of sectors,
clusters or in terms of files which are corrupted ? Can we see a list of those
?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thank you a lot, Terrence !</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Daniel</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=tmartin@physics.ucsd.edu
href="mailto:tmartin@physics.ucsd.edu">Terrence Martin</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=dan1@edenpics.com
href="mailto:dan1@edenpics.com">dan1</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, November 05, 2004 2:01
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Centos] Promise raid cards
- software raid</DIV>
<DIV><FONT face=Arial size=2></FONT><BR></DIV>dan1 wrote:<BR><BR>> Hello,
Terrence.<BR>> <BR>> Thank you for your complete answers. That's
very interesting.<BR>> <BR>><BR>> > I am not sure what you
mean about the file system crashing?<BR>> <BR>> I meant that it
becomes unrecoverable, or that some datas are missing.<BR>>
<BR><BR>These are two seperate problems with two seperate
solutions.<BR><BR>You can have loss of data without the file system having any
problems. <BR>That is data is missing, perfectly working file system. In fact
<BR>journaled file systems pick preserving the file system over missing data
<BR>every time.<BR><BR>Eg.<BR><BR>You have a database and are writing a query
to the database that inerts <BR>1000 records. If you do not insert all 1000
records then you cannot use <BR>any of them. That is record 1000 depends on
all the previous 999. On <BR>record 678 the power fails. When the system
comes back what happened to <BR>the first 678 inserts? You assume they
complete but since you need all <BR>1000 for the data to be valid you
basically have to delete the ones you <BR>did insert and start again, if you
can.<BR><BR>Deleting means that you first have to know what records to
delete.<BR><BR>Depending on the complexity of the inserts (they could touch
dozens of <BR>tables and interrelationships) you could have a lot of work
ahead of you <BR>to manually find what is a record that is part of that
incomplete set <BR>and what records are not.<BR><BR>This is where a journal
comes in. A journal records when data is <BR>written. Basically you record
what you write after you finish writing a <BR>record so that worst case you
can replay that journal of changes to back <BR>out of what happened. This is
what a journaled file system does. It <BR>allows you to more easily back out
of the incomplete data problem <BR>quickly. This is opposed to the old method
of file system consistency <BR>checking which was like a manual search of the
entire database. If you <BR>only have to go over the changes, rather than
searching the whole <BR>database it is faster. Also the long manual
check is complicated and <BR>prone to error. For speed and accuracy a journal
is better.<BR><BR>However journaled file systems do not save the data. In fact
journaled <BR>file systems will throw away data if it is incomplete. Say in
the above <BR>example for some reason that you could use the first 678
records, or <BR>that there was no other way to recover the 1000 records again
so 678 was <BR>better than nothing. Well a journal does not care. It simply
looks to <BR>see if the whole transactions completed of 1000 records. If it
didn't it <BR>deletes everything up to the failure. Even if 999 of the 1000
records <BR>was written it will still delete the 999. The assumption being
that it <BR>is better to have a consistent file system and protect the good
data <BR>than have partially written data, that while valuable is
inconsistent.<BR><BR>If you want to ensure that even partial data is preserved
you have to do <BR>other things to protect it. A battery protect RAID
card is one very <BR>very narrow approach that solves one specific type of
failure state. <BR>Where data is written to the RAID card but not to disk
yet.<BR><BR>Lets go back to our above example<BR><BR>You have a power failure
on record 678. The raid card has memory to <BR>store 5 records. At the time of
the power failure it has only sent the <BR>first 673 records to the disks for
writting. The other 5 are in the <BR>controller cache. If you have a battery
on that memory you will save <BR>those 5 records. However does it matter?
Afterall 678 or 673 they are <BR>still not 1000. Also the disks themselves may
store in their cache 2 <BR>records. So the disk has only written records up to
670 with records 671 <BR>and 672 still waiting in volatile RAM with no battery
backup attached <BR>directly to the disk (write back cache on all PATA
drives).<BR><BR>The power fails and the system comes back online. The RAID
card writes <BR>records 673-678 to the disks and they write them.
Unfortunately records <BR>671 and 672 are lost because they were in volatile
disk cache on the <BR>disk itself.<BR><BR>So you have records 0-670,637-678.
You in fact have a hole in what you <BR>have on disk, and who cares anyway
because the journaled file system is <BR>going to delete all those records
when it goes to work to ensure <BR>integrity over data
preservation.<BR><BR>Basically RAID batteries buy you something, but not much,
and they buy <BR>you even less when they are attached to ATA drives that have
write back <BR>cache that essentially makes the RAID cache moot.<BR><BR>>
> I do not recommend ext3 for anything over about 120GB.<BR>>
<BR>> OK, that's interesting.<BR>> <BR><BR><BR>I work with compute
cluster and with file systems that are in the <BR>terabytes of size. Basically
nothing else has come close to XFS in <BR>practice. The guys that admin
the really big stuff that we collaborate <BR>with will not touch anything but
XFS and they have petabytes of storage. <BR>If you can go with XFS. Even RHEL4
should finally have XFS standard <BR>since fedora core 2 and later has it as
an option, even for the root disk.<BR><BR>> > My biggest question is why
at this point are you even bothering with<BR>> PATA drives? Compared to
SATA drives they are unreliable and poor<BR>> performing for about the same
cost.<BR>> This is what I get from my ISP (I think). However it doesn't
change a <BR>> lot my conception and thoughts about raid. The flush problem
remains <BR>> the same.<BR>> Also I am more familiar to PATA.<BR><BR>The
flush problem as I hope I have demonstrated is not at all addressed <BR>by
battery backups on RAID card ram. Battery based backup of RAID memory <BR>is a
good gimmick, but in practice is useless. It covers such a narrow <BR>part of
the problem space as to be irrelevant.<BR><BR>If you are concerned that power
failure will loose data get a UPS for <BR>the entire system. It is the only
thing that will help you because it is <BR>the only thing that will allow your
entire system, from software to <BR>hardware to achieve a consistent state
before shutting down. Otherwise <BR>you may save a few bytes of data that was
in cache on the RAID card but <BR>that does not matter since you will still
end up with an incomplete file <BR>system transaction that the journaled file
system is going to delete <BR>anyway.<BR><BR>The linux journaled file systems
are very good at preserving integrity, <BR>even in the face of underlying
hardware failure in some cases. Choosing <BR>a good file system is all you
need to do there to ensure that aspect. As <BR>far as data loss, aside from
backups after the fact the only solution <BR>that will work in practice is
Uninteruptible Power Supplies that will <BR>give you enough time to shutdown
the entire system in a consistent way.<BR><BR>Terrence<BR><BR>>
<BR>> Thank you for your interesting advices. I appreciate that
!<BR>> <BR>> Best regards,<BR>> <BR>>
Daniel<BR>> <BR>> <BR>>
<BR></BLOCKQUOTE></BODY></HTML>