Как я могу предсказать размер файловой системы ISO 9660?

Спасибо за подробное обновление. Я удовлетворен тем, что ваша текущая стратегия упаковки в мусорные ведра довольно эффективна.

Что касается вопроса: «Именно сколько служебных данных занимает файловая система ISO 9660 для n файлов общим объемом b байт?» есть только 2 варианта ответа:

1. Кто-то уже написал эффективный инструмент для измерения именно этого. Однако быстрый поиск в Google ничего не дал, что обескураживает. Возможно, кто-то на SO ответит ссылкой на свой самодельный инструмент, но если вы не получите больше ответов в течение нескольких дней, то, вероятно, он тоже отсутствует.
2. Вам необходимо прочитать готовые спецификации ISO 9660 и создать такой инструмент себе.

На самом деле есть и третий ответ:

(3) Вы не заботитесь об использовании каждого байта на каждом DVD. В этом случае возьмите небольшую репрезентативную горстку файлов разного размера (скажем, 5), дополните их, пока они не станут кратными 2048 байтам, и поместите все 2^5 возможных подмножеств через genisoimage -print-size. Затем сопоставьте уравнение nx + y = iso_size - total_input_size для этого набора данных, где n = количество файлов в данном прогоне, чтобы найти x , который представляет собой количество байтов служебных данных на файл, и y, который представляет собой постоянный объем служебных данных (размер файловой системы ISO 9660, не содержащей файлов). Округлите x и y в большую сторону и используйте эту формулу для оценки размеров вашей файловой системы ISO для заданного набора файлов. В целях безопасности убедитесь, что вы используете самые длинные имена файлов, которые появляются где-либо в вашей коллекции, для тестовых имен файлов, и поместите каждое из них в отдельную иерархию каталогов, такую ​​же глубокую, как и самая глубокая иерархия в вашей коллекции.

Я не знаю точно, как вы это делаете в настоящее время — согласно моим гуглениям, «Bubblesearch» относится к способу выбора порядка элементов, который в некотором смысле близок к жадному порядку, но в вашем случае порядок добавления файлов на DVD не меняет требований к пространству, поэтому этот подход тратит время на рассмотрение нескольких разных порядков, которые составляют один и тот же набор файлов.

Другими словами, если вы делаете что-то вроде следующего для создания списка файлов-кандидатов:

1. Произвольно перемешать список файлов.
2. Начиная с верхней части списка, жадно выбирайте все файлы, которые, по вашему мнению, поместятся на DVD, пока больше не останется.

Тогда вы ищете решение неэффективно — для любого окончательного набора кандидатов из n файлов вы потенциально рассматриваете все n! способы производства этого множества. Мое предложение:

1. Отсортируйте все файлы в порядке убывания размера файла.
2. Отметьте верхний (самый большой) файл как «включенный» и удалите его из списка. (Он должен быть включен в какой-нибудь DVD, так что мы могли бы включить его сейчас.)
3. Can the topmost file in the list be included without the (estimated) ISO filesystem size exceeding the DVD capacity? If so:
   • With probability p (e.g. p = 0.5), mark the file as "included".
4. Удалите самый верхний файл из списка.
5. Если список теперь пуст, у вас есть список файлов-кандидатов. В противном случае перейдите к пункту 3.

Повторите это много раз и выберите лучший список файлов.

Предложение Tyler D также хорошо: если у вас есть ~40000 файлов на общую сумму ~500 МБ, это означает, что средний размер файла составляет 12,5 КБ. ISO 9660 использует размер блока 2 КБ, что означает, что эти файлы тратят в среднем 1 КБ дискового пространства или около 8% своего размера. Таким образом, сначала упаковав их вместе с tar, вы сэкономите около 8% места.

Не можете использовать tar для хранения файлов на диске? Неясно, пишете ли вы для этого программу или просто делаете резервные копии.

Может быть, поэкспериментировать и перестраховаться — немного свободного места на диске не помешает.

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

Недавно я провел эксперимент, чтобы найти формулу для аналогичной оценки заполнения на DVD, и нашел простую формулу с учетом некоторых предположений ... из вашего исходного поста эта формула, вероятно, будет для вас низким числом, похоже, у вас есть несколько каталоги и более длинные имена файлов.

Предположения:

• все файлы ровно 8,3 символа.
• все файлы находятся в корневом каталоге.
• никаких расширений, таких как Joliet.

Формула:

174 + floor(count / 42) + sum( ceil(file_size / 2048) )

• count - это количество файлов
• file_size - размер каждого файла в байтах
• результат в блоках по 2048 байт.

Пример скрипта:

#!/usr/bin/perl -w
use strict;
use POSIX;

sub sum {
    my $out = 0;
    for(@_) {
        $out += $_;
    }
    return $out;
}

my @sizes = ( 2048 ) x 1000;
my $file_count = @sizes;

my $data_size = sum(map { ceil($_ / 2048) } @sizes);
my $dir_size = floor( $file_count / 42 ) + 1;
my $overhead = 173;

my $size = $overhead + $dir_size + $data_size;

$\ = "\n";
print $size;

Я проверил это на дисках с файлами до 150 тыс., размером от 200 байт до 1 МБ.

Хорошая мысль, Джей Рэндом. Конечно, мне не нужен каждый последний байт, это в основном для развлечения (и хвастовства за обедом). Я хочу иметь возможность набрать du на компакт-диске и получить его очень близко к 4700000000.

Я просмотрел спецификацию ECMA, но, как и большинство спецификаций, она довольно болезненная, и я не уверен в своей способности сделать это правильно. Также кажется, что не обсуждаются расширения Rock Ridge, а если и обсуждают, то я пропустил это.

Мне нравится ваша идея № 3, и я думаю, что продолжу ее немного дальше: я попытаюсь построить довольно богатую модель того, что происходит, а затем использовать genisoimage -print-size для ряда наборов файлов для оценки параметров модели. Затем я могу использовать модель, чтобы сделать свою оценку. Это хобби-проект, так что это займет какое-то время, но со временем я этим займусь. Я опубликую ответ здесь, чтобы сказать, сколько потерь устранено!