On Sat, Feb 25, 2006 at 07:57:55PM +0300, Konstantin A. Lepikhov wrote:
> Hi Денис!
> 
> Saturday 25, at 07:48:56 PM you wrote:
> 
> > On Sat, Feb 25, 2006 at 07:14:12PM +0300, Konstantin A. Lepikhov wrote:
> > 
> > KAL> Новые dvd+rw-tools разучились работать с ядрами 2.6.x (видимо, их автор
> > KAL> заразился от Шиллинга). Так что если кто захочет их собрать в сизиф,
> > KAL> просьба учесть этот неприятный момент (как и то, что в этом случае мы
> > KAL> останемся без средств записи DVD).
> > KAL> Информация к размышлению:
> > KAL> http://lists.debian.org/cdwrite/2006/02/msg00132.html и далее по треду.

6.1 у меня работает:

$ ./growisofs -Z /dev/dvd --dry-run .                                 
WARNING: /dev/dvd already carries isofs!
About to execute 'mkisofs . | builtin_dd of=/dev/dvd obs=32k seek=0'
Using GROWI000.O;1 for  /growisofs_mmc.o (growisofs.o)

$ ./growisofs -Z /dev/dvd --dry-run --use-the-force-luke=bufsize=32M .
WARNING: /dev/dvd already carries isofs!
About to execute 'mkisofs . | builtin_dd of=/dev/dvd obs=32k seek=0'
Using GROWI000.O;1 for  /growisofs_mmc.o (growisofs.o)

$ ./growisofs -Z /dev/dvd --dry-run --use-the-force-luke=bufsize=64M .
:-( unable to anonymously mmap 67108864: Resource temporarily unavailable

Перед этим на growisofs был поставлен suid root - без него проблем
вообще не возникает, так как вызов setrlimit() не проходит, после чего
mlockall(MCL_CURRENT|MCL_FUTURE) молча пропускается.

Кстати, сейчас права root для записи DVD в принципе не обязательны -
достаточно иметь право записи в соответствующее устройство (по крайней
мере, DVD+RW так пишется).  Видимо, стоит предусмотреть для control
growisofs и вариант прав 711.

> > Я правильно понимаю, что он попросту пытается залочить для себя слишком
> > много памяти? Можно ли его от этого отучить тривиальным патчем?

Проблема в том, что при mlockall(MCL_CURRENT|MCL_FUTURE) блокируется и
код процесса (в том числе и libc), а нормального способа определить
его размер, чтобы учесть при выставлении RLIMIT_MEMLOCK, не
существует.  Хотя, вероятно, можно соорудить что-то типа бинарного
поиска (только для проверки придётся делать setreuid() туда-сюда,
поскольку для рута RLIMIT_MEMLOCK не проверяется).

Сейчас там просто выставляется (DEFAULT_BUF_SIZE_MB+4)*1024*1024 -
т.е., к размеру буфера по умолчанию (32 МБ) добавляется ещё 4 МБ на
прочие нужды.  Видимо, в каких-то случаях этих 4 МБ оказывается
недостаточно.

> вопрос зачем ему столько памяти.

Видимо, затем же, зачем и cdrecord.  Хотя SCHED_RR, как cdrecord, он
ставить себе ещё не научился.