<!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.5700.6" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=770471820-09102006><FONT face=Arial color=#0000ff size=2>I'm
just going to jump in here, and ask a stoopid question.</FONT></SPAN></DIV>
<DIV><SPAN class=770471820-09102006><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=770471820-09102006><FONT face=Arial color=#0000ff size=2>How
could you possibly write a multi-user front end in AJAX without using a
database backend like MySQL?</FONT></SPAN></DIV>
<DIV><SPAN class=770471820-09102006><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=770471820-09102006><FONT face=Arial color=#0000ff
size=2>Doug.</FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Erick Perez
[mailto:eaperezh@gmail.com]<BR><B>Sent:</B> Monday, October 09, 2006 1:58
PM<BR><B>To:</B> Asterisk Users Mailing List - Non-Commercial
Discussion<BR><B>Subject:</B> Re: [asterisk-users] Asterisk RT on Disk On
Module Performance andDurability<BR><BR></FONT></DIV>
<DIV>Jeremy, Cohen, Kris, thanks to all of you.</DIV>
<DIV> </DIV>
<DIV>Indeed after reading the Sandisk paper it shed a lot of light on this
matter. The whole idea is to have a large scale system with no moving parts
(we call a large system something with 250 users, at least down here
;-) ) </DIV>
<DIV> </DIV>
<DIV>the whole idea is for a customer that needs an IVR in 4 languages with
autoattendant, extensive CDR and plotted usage patterns as well as voicemail.
Voicemail will be used *a lot*, probably about one thousand voicemails per day
and the customer does not want VM-to-Email (God knows why!). </DIV>
<DIV> </DIV>
<DIV>Oh, and the whole idea of the database is because the developers are
working in an AJAX based interface that does the asterisk
config/plotting/vm/day-to-day stuff with ARA, so a db is needed.</DIV>
<DIV>I started learning asterisk with flat files...it works for me...but
hey...times are changing.</DIV>
<DIV> </DIV>
<DIV>Who knows, maybe the whole thing can be fitted in ram (except for the vm
part)...we'll see. I had to ask anyway, but i don't like Dbs either....it adds
and extra breakup layer (maybe Im kind of outdated).</DIV>
<DIV> </DIV>
<DIV>Smaller iPBXs will definitely be CF and RAM based and I, at least, will
force VMtoEmail and do all the processing in RAM.</DIV>
<DIV> </DIV>
<DIV>Again,</DIV>
<DIV> </DIV>
<DIV>Thanks to all of you.</DIV>
<DIV><BR>P.D. I will later follow this thread with the full working configs
that will take place at user premises. And for the sake of the test. I will
try to kill a sandisk USB with the full config.</DIV>
<DIV><BR> </DIV>
<DIV><SPAN class=gmail_quote>On 10/8/06, <B class=gmail_sendername>Kristian
Kielhofner</B> <<A href="mailto:kris@krisk.org">kris@krisk.org</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Jeremy
McNamara wrote:<BR>> Tzafrir Cohen wrote:<BR>> > Hmmmm,
I'm not sure that this is exactly the data you're after.
<BR>>><BR>>> You're looking for the ammounts of writes for the
disk block that gets<BR>>> the most writes.<BR>>><BR>>>
E.g: for a standard ext3 filesystem, the journal area would
probably<BR>>> have very frequent writes, whereas most of the system
would remain<BR>>> mostly unchanged.<BR>><BR>><BR>> Again, if
the embedded system is setup properly, there is NO writing to<BR>> the
flash during normal operations, thus the device won't be killed by <BR>>
its alleged 2 million write limitation.<BR>><BR>> Kris and I had a
quick discussion on this topic, off-list, and his<BR>> original
flash-based device is still in constant operation after 2 years<BR>> and
I have flash modules that I purposely tried to kill with writes. It <BR>>
took significant effort to start causing error situations, which
were<BR>> very easily detected before the system would become
unusable.<BR>><BR>> Erick, you should focus on having a quick action
restoration plan and <BR>> extra DOMs always readily
available. Then when a failure situation is<BR>> detected, you
can react very quickly.<BR>><BR>><BR>><BR>><BR>> Jeremy
McNamara<BR><BR>Jeremy, Erick -<BR><BR>
I have always pointed to this SanDisk whitepaper: <BR><BR><A
href="http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf">http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf</A><BR><BR>
While it specifically discusses their industrial line of CF cards, it <BR>is
pretty obvious that flash can, and often does, last much longer
than<BR>other components in a system when properly
implemented. You will notice<BR>that the SHORTEST expected life
of a CF card in their test scenarios was <BR>over 70 years! How
long is your power supply going to last? Even if<BR>the consumer
level cards had 1/10 the life expectancy, that is still<BR>seven
years. I expect to get at least that from my original
AstLinux<BR>system. It's been two so far, I'll let you know how
it is doing in<BR>another five years
:).<BR><BR> JFFS (and similar FSs) are
not appropriate for CF cards or DOMs. They<BR>are meant to be
used directly on flash memory and do their own wear <BR>leveling and in some
cases, compression. All kinds of commercial<BR>devices use
JFFS2. If you are using a CF or DOM with Linux, ext2 is
the<BR>best FS to use. CF cards and DOMs use their own wear
leveling, so none<BR>is required in the operating system or file
system. CF cards and DOMs<BR>hide wear leveling from you and
expose themselves as an ordinary IDE
device.<BR><BR> I echo Jeremy's
conclusions. With a properly designed operating <BR>system,
decent flash memory, and a reasonable usage pattern, I can tell<BR>you (with
a great amount of certainty) that in most situations, CF cards<BR>will
outlast just about any hard drive (even SCSI) when used 24/7. <BR>These
days, it really is pretty tough to trash
flash.<BR><BR> However, if you are
running a MySQL cluster or something with several,<BR>multi-gigabyte
databases, no type of flash memory will last very long!
:)<BR><BR> To get back to answering your
question, I HIGHLY recommend that you<BR>avoid MySQL and realtime on your
box with a DOM. Nothing against either<BR>(MySQL or Realtime),
but they will probably make your device more <BR>complicated than it needs
to be while substantially shortening the life<BR>of your DOM. If
you absolutely have to use MySQL, you might have better<BR>luck using a
MySQL storage engine that uses fewer writes than InnoDB, <BR>but I am no
expert on that.<BR><BR>--<BR>Kristian
Kielhofner<BR>_______________________________________________<BR>--Bandwidth
and Colocation provided by <A href="http://Easynews.com">Easynews.com</A>
--<BR><BR>asterisk-users mailing list <BR>To UNSUBSCRIBE or update options
visit:<BR> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</A><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>--
<BR>------------------------------------------------------------<BR>Erick
Perez<BR>Panama Sistemas<BR>Integradores de Telefonia IP y Soluciones Para
Centros de Datos<BR>Panama, Republica de Panama<BR>Cel Panama. +(507)
6694-4780 <BR>------------------------------------------------------------
</BLOCKQUOTE></BODY></HTML>