Bug 216794 - growisofs buffer size ridiculously small, disregard bufsize option
Summary: growisofs buffer size ridiculously small, disregard bufsize option
Alias: None
Product: Fedora
Classification: Fedora
Component: dvd+rw-tools
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-22 00:43 UTC by Juliano F. Ravasi
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2007-01-15 12:29:00 UTC

Attachments (Terms of Use)
Patch to fix this problem (763 bytes, patch)
2006-11-22 01:58 UTC, Juliano F. Ravasi
no flags Details | Diff

Description Juliano F. Ravasi 2006-11-22 00:43:05 UTC
Description of problem:
When burning DVDs, growisofs is not honoring the --use-the-force-luke=bufsize:X
option, allocating an internal ring buffer ridiculously small, so that DVD
burning is affected by frequent buffer underruns (the speed drops from 8x to as
low as 2x).

I verified via /proc/<growisofs_pid>/smaps that the allocation that seems to be
the ring buffer is not of constant size. It varies for each burn, from 1MB to
4MB, even though k3b informs --use-the-force-luke=bufsize:128M (I have 1GB of
RAM in this machine, so 128M is nothing).

This problem started after the recent update from dvd+rw-tools-6.1-4.1 to
dvd+rw-tools-7.0-0.fc6.2. Downgrading to dvd+rw-tools-6.1-4.1 (from FC6
installation media) fixes the problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. growisofs -Z /dev/hdb=file.iso -dvd-compat -speed=8
2. check memory mappings at /proc/`pidof growisofs`/smaps (here, the ring buffer
is the forth last mapping)

Actual results:
The ring buffer is 1 to 4 MBs in size. High risk of buffer underruns.

Expected results:
The ring buffer should have the size given by the front-end via the
--use-the-force-luke=bufsize:X option.

Comment 1 Juliano F. Ravasi 2006-11-22 01:11:18 UTC
I went to investigate the bug by looking into the source. It seems to be a bug
introduced on dvd+rw-tools version 7.0. The changelog for growisofs.c states:

 * 7.0:
 * - limit ring buffer size to 1/4 of RAM;

But it doesn't match for me, since I have 1GB of RAM and sometimes growisofs
allocates only 1MB of buffer size. So I went down to where this is limited and
found this (growisofs.c:3100):

    size_t phys_mem = (size_t)sysconf(_SC_AVPHYS_PAGES) *
    if (phys_mem)
    {   phys_mem /= 2;  /* normally AVPHYS is a bit smaller, so
                         *  we commonly land on 1/4 RAM */
        while (the_buffer_size > phys_mem) the_buffer_size /= 2;

This is pretty clear the problem. _SC_AVPHYS_PAGES returns the number of
available, really free memory pages, not the total number of memory pages. Linux
tends to use all available memory with buffers and cache, and keep just a bare
minimum of free pages during normal use.

So, this code cuts the size of the buffer in half again and again until it is
less or equal to half the size of free memory.

Right now free informs me that I have 7MB of really free memory, but 594MB of
"available" memory (discounting space used by buffers and cache), out of a total
of 940MB (1GB physical). So, if I started burning a DVD right now, it would give
me 2MB of buffer, that is the biggest power of 2 smaller than 3.5MB, that is
half of 7MB.

Comment 2 Juliano F. Ravasi 2006-11-22 01:58:07 UTC
Created attachment 141860 [details]
Patch to fix this problem

This fixes the problem for me.

I'll ask dvd+rw-tools' maintainer (Andy Polyakov) to take a look here.

Comment 3 Juliano F. Ravasi 2006-12-01 01:18:18 UTC
Andy Polyakov doesn't answer my e-mails.

Could this bug be fixed by Fedora? The patch is in the attachment 141860 [details].

Comment 4 Harald Hoyer 2006-12-13 14:16:52 UTC
dvd+rw-tools-7.0-0.fc6.3 should appear soon in the testing repo

Comment 6 Juliano F. Ravasi 2006-12-14 19:49:13 UTC
Harald: tested dvd+rw-tools-7.0-0.fc6.4 from updates-testing and it worked! Thanks!

I don't have RHEL5, so I can't test the last one.

Note You need to log in before you can comment on or make changes to this bug.