Board.KolibriOS.org

1. в байтах. Округляется вверх до размера страницы.
2. кол-во в штуках. Сильно желательно, или будет утечка страниц. Возвращает физ. адрес первой страницы.
3. физ. адрес первой страницы + флаги доступа PG_READ PG_WRITE PG_USER и т.п.

Я вернулся! Хорошо жить в частном секторе: свой двор, огородик, вода греется газом, своё отопление хоть на дровах, можно и электрогенератор купить. Плохо только когда перед праздниками вырезают кабель интернета. А бывают чудесные дни, когда через пол месяца всё-таки всходит капуста, а винда перестаёт срать кирпичами по поводу созданных файлов. В общем, дело идёт гораздо медленнее чем я ожидал, но всё-таки, обществу с отсутствующей ответственностью для осторожного тестирования представляется код с ограниченными возможностями. Поддерживается создание (копирование) файлов если есть место в файловой таблице и в узле каталога, иначе вежливо отправляет дописывать. Также, карта раздела кэшируется кусками по 32кб, что эквивалентно 1гб дискового пространства (не тестировалось). Тут только возник вопрос: сколько памяти использует сама колиби (сколько должно быть свободно) ?

Работает однако. Немного конечно, но уже что-то.

Pathoswithin
pg_data.pages_free хранит число доступных страниц памяти. Процентов 10 можно брать безболезненно.

Мне почему-то показалось что 64 мб это много (а это только при разделе 2 тб). Сначала сделал экономию, а потом задумался, нужна ли она. Я смотрю, что 150 мб всегда чем-то заняты.
А, ещё нужно решить, сколько места резервировать под $MFT. Сейчас данные записываются с середины раздела, но у жёсткого диска скорость снижается от начала к концу.

Pathoswithin, по умолчанию резервируется 12%, а при переполнении динамически меняется, что естественно создаёт фрагментацию... Первые 16 записей $MFT дублируется в начале (медленная часть, с меньшим LBA) и в середине диска, а остальные записи идут в начале диска, после первых 16 записей. Копия по середине резервная и служит для восстановления диска в случае повреждения $MFT.
источник, например: ixbt: Файловая система NTFS.

$MFT это главный файл и желательно, чтобы он не был фрагментирован. Он состоит из записей по 1кб на файл. Windows XP по умолчанию резервирует для него 12.5% раздела (что мягко скажем дофига), в реестре можно увеличить до 50% (такой себе тролинг от мелкомягких). Vista учла ошибку, и резервирует кусками по 200мб (200 000 файлов). Резервирование чисто программное, на диске не отмечается. С одной стороны лучше резервировать побольше, с другой стороны жёсткий диск, в отличии от CD, пишется от края к центру и имеет фиксированую скорость вращения, так что резервировать лишнее - терять скорость. Нужно выбрать оптимальный размер.

kiv, $MFTMirr дублирует первые 4 записи $MFT, но к резервированию это не относится, он сам по себе.

Я смотрю, что 150 мб всегда чем-то заняты

Дисковые кеши и виртуальный диск /tmp/0

Serge, а подробней? Я смотрю в XP тоже всего 2096, выделено 200, но доступно только 1750, а предел 1950, и системный кэш 150. А минимум для колибри вроде мизерный?

Это не троллинг мс, если у тебя будет много мелких файлов, то вполне логично увеличить $MFT (маленькие файлы могут писаться напрямую в $MFT), а если в $MFT много свободного места, а на диски мало, то MFT автоматически сокращается не обращая внимания на эти ваши 12,5%. достаточно пары таких циклов переполнения диска и $MFT фрагментируется в силу естественных причин. Да, и в самой $MFT первой записана $MFT, где собственно и записано сколько зарезервировано под неё, т.ч. всё там отмечается...
Расположение $MFT у более медленного края (ближе к шпинделю) логично т.к. там выше скорость рандомного доступа, что полезно для записей о файлах, собственно маленьких файлов и баз данных (вот почему для БД существует отдельный класс НЖМД) для максимально быстрого доступа к конкретной записи или маленькому файлу. У современных НЖМД также существует особенность позволяющая балансировать между скоростью последовательного и рандомного доступа, которую пока не использует ни один из существующих программных кодов...
Говорить 12,5% это мало или много неверно. Стоит говорить, что 12,5% много для файлов не меньше стольки-то Кб. Тогда для того чтобы ответить на твой вопрос надо знать среднестатистическое распределение количества файлов по их размеру... И вообще, 0.125 это красивое число 1/8
Есть такие варианты:
- скачать W10 и посмотреть как это сделано там, чтобы поддерживать последнюю версию NTFS;
- взять за основу совместимую версию помладше (плохо с т.з. будущей совместимости, но может быть чуть проще);
- писать свою версию NTFS.

Pathoswithin
Ядру для загрузки достаточно 5 Мб. Для загрузки всего окружения 8 Мб, после 1.1-1.3 Мб будут свободны. На каждый физический диск под кеш резервируется 1/32 свободной памяти но не меньше 128 Кб и не больше 1024 Кб.

kiv, что-то ты перестарался, вопрос то простой как валенок. Это просто немного влияет на скорость и всё. Можно резервировать процент, можно размер, можно даже адаптивно выбирать (в три строчки кода). Можно пока оставить как есть.

Расположение $MFT у более медленного края (ближе к шпинделю) логично т.к. там выше скорость рандомного доступа

Это у CD данные располагаются от центра к краю, меняется скорость вращения и скорость случайного доступа. У жёстких дисков всё наоборот.

Serge
1мб на диск? А у меня 150мб занято, что-то многовато получается.

Странно, а я грешным делом полагал, что угловая скорость постоянна, а мир устроен логично... согласен, вопрос не критичный, но про стратегию стоит подумать т.к. старая версия NTFS с NT не совместима с более новыми... В любом случае, думать не мне

Pathoswithin
Так у тебя наверное tmpdisk грузится, а он по умолчанию 10% забирает. Посмотри rd/1/settings/autorun.dat