I'd be curious to know what you come up with, because we're using MySQL, and I'd rather not!
> -----Original Message----- > From: Aaron Daniel [mailto:[EMAIL PROTECTED] > Sent: Monday, October 09, 2006 2:48 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [asterisk-users] Asterisk RT on Disk On Module > PerformanceandDurability > > > Very very carefully ;) I'm thinking pizza, and maybe some red-bull... > very little time for sleep > > Aaron > > On Mon, 2006-10-09 at 14:19 -0600, Douglas Garstang wrote: > > I'm just going to jump in here, and ask a stoopid question. > > > > How could you possibly write a multi-user front end in AJAX without > > using a database backend like MySQL? > > > > Doug. > > -----Original Message----- > > From: Erick Perez [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 09, 2006 1:58 PM > > To: Asterisk Users Mailing List - Non-Commercial Discussion > > Subject: Re: [asterisk-users] Asterisk RT on Disk On Module > > Performance andDurability > > > > > > 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 <[EMAIL PROTECTED]> 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 > ------------------------------------------------------------ > _______________________________________________ > --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 -- Aaron Daniel Computer Systems Technician Sam Houston State University [EMAIL PROTECTED] (936) 294-4198 _______________________________________________ --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 _______________________________________________ --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