[asterisk-users] Asterisk RT on Disk On Module Performance and Durability

[Erick Perez]

Jeremy, Cohen, Kris, thanks to all of you.

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

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!).

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.
I started learning asterisk with flat files...it works for me...but
hey...times are changing.

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

Smaller iPBXs will definitely be CF and RAM based and I, at least, will
force VMtoEmail and do all the processing in RAM.

Again,

Thanks to all of you.

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.


On 10/8/06, Kristian Kielhofner <kris at krisk.org> wrote:
>
> Jeremy McNamara wrote:
> > Tzafrir Cohen wrote:
> >  > Hmmmm, I'm not sure that this is exactly the data you're after.
> >>
> >> You're looking for the ammounts of writes for the disk block that gets
> >> the most writes.
> >>
> >> E.g: for a standard ext3 filesystem, the journal area would probably
> >> have very frequent writes, whereas most of the system would remain
> >> mostly unchanged.
> >
> >
> > Again, if the embedded system is setup properly, there is NO writing to
> > the flash during normal operations, thus the device won't be killed by
> > its alleged 2 million write limitation.
> >
> > Kris and I had a quick discussion on this topic, off-list, and his
> > original flash-based device is still in constant operation after 2 years
> > and I have flash modules that I purposely tried to kill with writes. It
> > took significant effort to start causing error situations, which were
> > very easily detected before the system would become unusable.
> >
> > Erick, you should focus on having a quick action restoration plan and
> > extra DOMs always readily available.  Then when a failure situation is
> > detected, you can react very quickly.
> >
> >
> >
> >
> > Jeremy McNamara
>
> Jeremy, Erick -
>
>        I have always pointed to this SanDisk whitepaper:
>
>
> http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf
>
>        While it specifically discusses their industrial line of CF cards,
> it
> is pretty obvious that flash can, and often does, last much longer than
> other components in a system when properly implemented.  You will notice
> that the SHORTEST expected life of a CF card in their test scenarios was
> over 70 years!  How long is your power supply going to last?  Even if
> the consumer level cards had 1/10 the life expectancy, that is still
> seven years.  I expect to get at least that from my original AstLinux
> system.  It's been two so far, I'll let you know how it is doing in
> another five years :).
>
>        JFFS (and similar FSs) are not appropriate for CF cards or
> DOMs.  They
> are meant to be used directly on flash memory and do their own wear
> leveling and in some cases, compression.  All kinds of commercial
> devices use JFFS2.  If you are using a CF or DOM with Linux, ext2 is the
> best FS to use.  CF cards and DOMs use their own wear leveling, so none
> is required in the operating system or file system.  CF cards and DOMs
> hide wear leveling from you and expose themselves as an ordinary IDE
> device.
>
>        I echo Jeremy's conclusions.  With a properly designed operating
> system, decent flash memory, and a reasonable usage pattern, I can tell
> you (with a great amount of certainty) that in most situations, CF cards
> will outlast just about any hard drive (even SCSI) when used 24/7.
> These days, it really is pretty tough to trash flash.
>
>        However, if you are running a MySQL cluster or something with
> several,
> multi-gigabyte databases, no type of flash memory will last very long! :)
>
>        To get back to answering your question, I HIGHLY recommend that you
> avoid MySQL and realtime on your box with a DOM.  Nothing against either
> (MySQL or Realtime), but they will probably make your device more
> complicated than it needs to be while substantially shortening the life
> of your DOM.  If you absolutely have to use MySQL, you might have better
> luck using a MySQL storage engine that uses fewer writes than InnoDB,
> but I am no expert on that.
>
> --
> Kristian Kielhofner
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>



-- 
------------------------------------------------------------
Erick Perez
Panama Sistemas
Integradores de Telefonia IP y Soluciones Para Centros de Datos
Panama, Republica de Panama
Cel Panama. +(507) 6694-4780
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061009/09f7fa00/attachment.htm