There are RAID controllers (hardware, of course) that have battery backup, so the risk in very minimal in using write cache. Just one (random) example: http://h18000.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html
SAS controllers support SAS and SATA drives, FWIW. On Fri, May 1, 2009 at 08:35, Benny Amorsen <benny+use...@amorsen.dk> wrote: > t...@softins.clara.co.uk (Tony Mountifield) writes: > >> I'm in the process of specifying the hardware for some new Asterisk >> systems which will be running a substantial number of conferences >> with recording. >> >> I was wondering what there is to choose between SCSI, SAS and SATA >> disks, in terms of performance for this kind of application. > > Modern SCSI, SAS, or SATA drives don't perform differently because of > the interface type. You can't get 15kRPM SATA drives because the market > for those is too small though. > > If you record 1 channel in Alaw, you need 2 x 64kbps disk bandwidth, or > 16kB/s. If you record 1000 channels, you need 16MB/s from your disks, > which should be easily achievable with even the cheapest disks. However, > that depends on doing sequential writes. You can only do (best case) 120 > random writes pr second on a 7200RPM disk without write cache, and you > can reach that limit with just 2 channels, if you have to do a seek pr > packet. The solution there is write cache; 1 second gives you 120 > channels and 5 seconds bring you up to 600 channels. > > If you are unlucky and the files are placed widely spaced on the drives, > the performance will be lower than those numbers. > > So, to get decent performance from many streams, you need a lot of disk > write cache, either on the disk itself (with the risk that a power failure > destroys data), on the controller, or in memory. You can gain a factor > of 2 by going to 15kRPM disks, and another factor of two by doubling the > number of spindles (if you get the layout right). The Linux write cache > can be tweaked for this purpose, but again you risk that a power failure > destroys data. > _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users