Странности с диском RAM:

[tnt23]

Дано: система с 2M чипа и 64М фаста.

Берем файл-болванку размером 14M и копируем в рам-диск, допустим, в файл junk1.
Повторяем копирование, на этот раз в junk2.
В третий раз забрасываем невод, получаем junk3.

Итого на диске RAM: лежат 3 файла размером 14М каждый. Свободной памяти около 19M:

[code]Unit Size Used Free
RAM: 41M 42998 0
42570 blocks used[/code]

Казалось бы, можно и четвертую болванку туда засунуть (свободно 19M, размер болванки 14M). А вот фигушки - система жалуется на нехватку RAM.

Кто-нибудь может повторить этот чрезвычайно интеллектуальный эксперимент и дать эмоциональное объяснение результата?

[easy_john]

А какое при этом максимальное место одним куском?

[tnt23]

Хороший вопрос. Не знаю, а это принципиально? RAM драйв отличается от настоящего диска тем, что на нем собственная файловая система (я так понял) и в общем случае его потенциально возможный макс.объем равен всей свободной памяти. Оверхед на всякие там структуры не должен влиять, и фрагментация памяти тем более.

[tnt23]

Папы этого ответ
Помещаю в книжке:

http://eab.abime.net/showpost.php?p=941454&postcount=2

Короче говоря, все дело в максимальном размере свободного куска памяти.

[easy_john]

Так и думал. Поставь какой-нить дефрагментатор памяти, глядишь получится одним куском аллоцировать.

[tnt23]

[quote="easy_john"]Так и думал. Поставь какой-нить дефрагментатор памяти, глядишь получится одним куском аллоцировать.[/quote]

Что такое "какой-нибудь дефрагментатор"? AVAIL FLUSH по совету из того же треда не помогает. Похоже, RAM: драйв устроен очень примитивно и не умеет распихивать контент по мелким фрагментам. В принципе, наверное, ему и не надо.

[easy_john]

[quote="tnt23"]AVAIL FLUSH по совету из того же треда не помогает. Похоже, RAM: драйв устроен очень примитивно и не умеет распихивать контент по мелким фрагментам. В принципе, наверное, ему и не надо.[/quote]
Разбираемся с фрагментацией памяти

Как вы знаете у AmigaOS есть проблеммы с фрагментацией памяти. Сейчас есть задумки как от нее избавится, но как правило работу с памятью оставляют на совести разработчиков программ.
Есть две помогающие нам утилиты:
Первая - PoolMem и требует установки FragCure после себя.
Вторая - использоваться недавно разработанный MemOptimizer и вобще не использовать FragCure. (В документации объясняется почему).
Лично мы предпочитаем MemOptimizer. Неизвестно, на столько ли он эфективен, как PoolMem, скорее всего нет, однако он 100% совместим с AmigaOS и не вызывает проблемм ни с камими другими программами.
Для обоих патчей - тщательно читайте документацию, там есть много тонкостей.
Так же помните, что сами по себе Exec44.1 и Amber Ram расчитанны на небольшое уменьшение фрагментации памяти.
WBAllocFast: Небольшой патч, заставляющий WorkBench использоваться Fast память всместо Chip для некотрых типичных задач. Смысл использования очевиден. Не очень похоже на честный патчь, но про тестировании не выявлено программ, с которыми бы он не был совместим. Устанавливается после PoolMem или MemOptimizer. (Есть заметки, что данный патч может конфликтовать с DOpus и AfA)

[tnt23]

Странно, но под UAE я таких проблем не наблюдаю. Правда, там не чистая система, а ClassicWB и фиг знает как устроена работа с памятью.

Покамест нашел шикарный тест памяти MBRTEST-2, прогоню его пару раз. Может, это у меня что-то напортачено в контроллере памяти.

[tnt23]

Вы не поверите, но все дело в параметре BUFFERS команды COPY. По умолчанию (у меня WB 3.1) BUFFERS=0, что означает использование буфера размером с копируемый файл. Если указать BUFFERS=100 или 1000 или любое иное разумное число, то дуло исчезает.

[easy_john]

Не знал.

[Vinnny]

[quote="tnt23"]Вы не поверите, но все дело в параметре BUFFERS команды COPY. По умолчанию (у меня WB 3.1) BUFFERS=0, что означает использование буфера размером с копируемый файл. Если указать BUFFERS=100 или 1000 или любое иное разумное число, то дуло исчезает.[/quote]
что-то подобное я тоже думал, только про T:, да не смог додумать

[tnt23]

[quote="Vinnny"][quote="tnt23"]Вы не поверите, но все дело в параметре BUFFERS команды COPY. По умолчанию (у меня WB 3.1) BUFFERS=0, что означает использование буфера размером с копируемый файл. Если указать BUFFERS=100 или 1000 или любое иное разумное число, то дуло исчезает.[/quote]
что-то подобное я тоже думал, только про T:, да не смог додумать [/quote]

Еще подробностей: этим страдает только COPY из WB 3.0, которая у меня как раз и стоит. Дотошный товарищ с EAB разжевал:

"I just noticed that the bug was mentioned in the V38_V39_OS_Changes document on the Amiga Developer CD 2.1:
[code]The default size for the buffers used was always equivalent to (BUF=0)
which caused the buffers to be the size of the files being copied.
This was contrary to the docs, and caused problems when copying large
files through Envoy, as it could easily eat up all the memory in the
system, not leaving enough for the memory needed by Envoy. The
default size is now BUF=128 which gives a 64K buffer.
[/code]"

http://eab.abime.net/showpost.php?p=941938&postcount=18