[Home]

Summary:ASTERISK-19595: Inefficient wav49 disk writes
Reporter:Byron Clark (byronclark)Labels:
Date Opened:2012-03-26 12:38:26Date Closed:2013-08-08 13:42:01
Priority:MajorRegression?
Status:Closed/CompleteComponents:Formats/format_wav_gsm
Versions:1.8.10.1 10.2.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gsm_wav_only_update_header_on_close.patch
Description:Writing to a wav49 looks a lot like this:
# Write GSM frame to end of file
# Seek to end of file
# Seek to header
# Update file size
# Seek to end of file
# Repeat

This pattern negates any attempt to use the stdio buffering setup in ast_writefile(). It also results in many small writes that require a seek going to the disk each second which translates to terrible disk performance when there are multiple wav49 files being written at the same time.
Comments:By: Byron Clark (byronclark) 2012-03-26 12:39:35.311-0500

The attached patch: [^gsm_wav_only_update_header_on_close.patch] modifies format_wav_gsm to behave more like format_wav. Instead of updating the header after each GSM frame is written, the header is updated when the file is closed.
By: Byron Clark (byronclark) 2012-03-26 12:40:47.700-0500

Attached patch is against 1.8 but the issue is present in 10.x and trunk also.
By: David Woolley (davidw) 2012-04-05 06:57:12.170-0500

Unix-like systems generally use write back caching, so a stdio level seek won't actually translate into a device seek.  Nonetheless, crossing the user/kernel space boundary is not particularly cheap, although the cost is in CPU, rather than disk arm, time.
By: Byron Clark (byronclark) 2012-04-05 12:14:06.491-0500

After running my tests again, David's response is correct, for a local filesystem. When I store the voicemail on ext4, I don't see as many write operations in the iostat output as are actually being performed. Unfortunately, when I move to the NFS mount where I did my initial testing, I see _many_ more write operations.