<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>------------------------------------------------------------