Comments 33
Все же хотелось увидеть сравнение с другими single file virtual filesystem. Как говорится, не squashfs единым. Есть еще whefs, libgsf и т.д.
Вот что бывает когда BigData пытаются запихнуть в бытовое решение. Это как борцу тяжеловесу влезть в пачку балерины…
А для обычного пользователя под Win 7 можно что-то сделать? На одном из дисков 400 тысяч мелких файлов в 70 Gb. Когда туда лезешь — система заметно подтормаживает. Индексацию выключил. Можно поставить на этот диск свою файловую систему так, чтобы OS её понимала?
что-то вроде Solid File System
Как вариант можно сделать отдельный раздел для этой кучи файлов. Если к папке доступ не постоянный это чуток решает проблему. (Но когда туда нырнёте тормоза будут практически такие же.)
Если раздел создать нет возможности\желания можно создать образ диска и монтировать его.
Если это у вас выкаченный сайт, можно скомпилировать в один chm.
Если раздел создать нет возможности\желания можно создать образ диска и монтировать его.
Если это у вас выкаченный сайт, можно скомпилировать в один chm.
Попробуйте PrimoCache. Она, хоть и бета, но помогает — хотя, конечно, от размеров и расположения файлов многое зависит.
Там в настройке есть две фичи, которые вас порадуют:
1. Можно указать, что вы хотите видеть ровный поток данных на запись, даже если готовы подождать указываемое время: скажем, ставите 5 (а может — и 60) секунд, и много меньше переживаете, что пиковая работа с множеством файлов поставит на попа всю систему — за 60 секунд все планируемые изменения имеют шанс записаться и с меньшим напрягом I/O.
2. Можно под кеш выделить отдельный раздел либо диск, которые будут очищены и уйдут только под эту задачу. Это, конечно, не кеши ZFS :), но кой-какая польза вам будем: 60 или 120 Гб SSD отлично справится с задачей (и, наверняка, объемом) кеширования, и вам не придется перекраивать всю ФС.
Я бы на вашем месте попробовал. По поводу что прога платная: она давно платная и давно бета, так вот на их форуме раз в сколько-то дней выкладывают ключик на следующие 90 дней работы (вроде как чтобы бета-тестеры не платили за лицензии) — не забывайте только их вводить. Как только ключик кончает действие, так кеш отключается, и работаете по старинке, без него, т.е. ничего не разваливается.
Сам, кстати, использую именно первую из упомянутых фич, чтобы сделать равномерным поток записи на SSD и тем уменьшить wear-out. Пока доволен :)
P.S. www.romexsoftware.com/en-us/primo-cache/
Там в настройке есть две фичи, которые вас порадуют:
1. Можно указать, что вы хотите видеть ровный поток данных на запись, даже если готовы подождать указываемое время: скажем, ставите 5 (а может — и 60) секунд, и много меньше переживаете, что пиковая работа с множеством файлов поставит на попа всю систему — за 60 секунд все планируемые изменения имеют шанс записаться и с меньшим напрягом I/O.
2. Можно под кеш выделить отдельный раздел либо диск, которые будут очищены и уйдут только под эту задачу. Это, конечно, не кеши ZFS :), но кой-какая польза вам будем: 60 или 120 Гб SSD отлично справится с задачей (и, наверняка, объемом) кеширования, и вам не придется перекраивать всю ФС.
Я бы на вашем месте попробовал. По поводу что прога платная: она давно платная и давно бета, так вот на их форуме раз в сколько-то дней выкладывают ключик на следующие 90 дней работы (вроде как чтобы бета-тестеры не платили за лицензии) — не забывайте только их вводить. Как только ключик кончает действие, так кеш отключается, и работаете по старинке, без него, т.е. ничего не разваливается.
Сам, кстати, использую именно первую из упомянутых фич, чтобы сделать равномерным поток записи на SSD и тем уменьшить wear-out. Пока доволен :)
P.S. www.romexsoftware.com/en-us/primo-cache/
Спасибо. Надо будет глянуть.
Простите… А у вас все эти файлы в одном каталоге лежат, или по немного объектов в немногих каталогах, но с большой вложенностью?
Просто если у вас NTFS (а чему бы там еще быть?), то при небольшом количестве записей в каталоге они сохранятся прямо в записи в MFT (small indexes), при большем числе — будет организовано нерезидентное хранение каталога (large indexes), что нагрузит I/O. Если Вы храните ваши файлы по многу на том же диске, что и всю систему, тормоза прямо просятся.
Я бы на вашем месте, наверное, выделил бы под хранение отдельный раздел (раз объем известен, логично откромсать от основного диска нужное кол-во гогов (не забудьте накинуть хотя бы процентов 30, чтобы NTFS эффективно работала с файлами), отформатировать в NTFS, и туда уже переложить книги. А, если есть возможность, под такие дела купить SSD на 120 Гб, и радоваться ))
Просто если у вас NTFS (а чему бы там еще быть?), то при небольшом количестве записей в каталоге они сохранятся прямо в записи в MFT (small indexes), при большем числе — будет организовано нерезидентное хранение каталога (large indexes), что нагрузит I/O. Если Вы храните ваши файлы по многу на том же диске, что и всю систему, тормоза прямо просятся.
Я бы на вашем месте, наверное, выделил бы под хранение отдельный раздел (раз объем известен, логично откромсать от основного диска нужное кол-во гогов (не забудьте накинуть хотя бы процентов 30, чтобы NTFS эффективно работала с файлами), отформатировать в NTFS, и туда уже переложить книги. А, если есть возможность, под такие дела купить SSD на 120 Гб, и радоваться ))
Файлы на отдельном физическом диске. И к ним обращаешься редко. Смысла SSD им давать нет. Просто архив в свете того, что из Сети начали пропадать то одно, то другое. Но совсем их забекапить и отложить в сторонку тоже не хочется. Иногда заглядываю за книгой или цитатой.
Думал, что есть нечто для такого случая специфическое. Но по видимому возня не стоит времени и сил.
Думал, что есть нечто для такого случая специфическое. Но по видимому возня не стоит времени и сил.
Для того, чтобы избежать фрагментации, указанные файлы приходится создавать в разных файловых системах.
Почему? Индекс же можно записывать на ФС после предварительной подготовки основного файла.
Это делает честь NTFS, т.к. например, структура ext2/ext3 требует для файла минимум 4-байтного числа на каждый 4-Kb блок данных:
То есть, надо дополнительно тратить по байту на каждый килобайт данных, на терабайт выходит гигабайт, а закэшировать гигабайт не так то просто. Впрочем, в ext4 такой проблемы, по-видимому, нет, или она замаскирована с помощью экстентов.
Для справки: в NTFS расположение файла на диске кодируется пофрагментно (каждый непрерывный кусок файла на диске описывается одной структурой). Если файл нефрагментирован, будет одна структура на весь файл, если файл разбит на два куска «первые N кластеров файла расположены в кластерах [A,A+N-1] диска, последние M кластеров — в кластерах [B,B+M-1] диска», то будут две структуры, кодирующие пары (N,A) и (M,B-A) соответственно, и так далее. Кодирование использует переменную длину, отбрасывая ведущие нули или FFки.
UFO just landed and posted this here
Граф сериализуете? :)
Дерево :)
А не пробовали mem mapped файл?
Всё что касается памяти ограничено в размерах.
В данной статье скорее делалось сравнение — вот есть 100млн мелких файлов, что нам может предложить штатная
файловая система и можно ли сделать это быстрее.
Ключевая мысль — пользовательская структура файловой системы это часть данных а не часть архитектуры файловой системы.
Дерево — отличный объект, с которым умеют работать в базах данных.
Так давайте смотреть на файловую систему как на единое дерево где путь к файлу — ключ, а содержимое файла — значение в едином дереве.
В данной статье скорее делалось сравнение — вот есть 100млн мелких файлов, что нам может предложить штатная
файловая система и можно ли сделать это быстрее.
Ключевая мысль — пользовательская структура файловой системы это часть данных а не часть архитектуры файловой системы.
Дерево — отличный объект, с которым умеют работать в базах данных.
Так давайте смотреть на файловую систему как на единое дерево где путь к файлу — ключ, а содержимое файла — значение в едином дереве.
Собственно, почему я заинтересовался. ОС Фантом, над которой я работаю — ОС с персистентной памятью. И мотивация у меня ровно вот такая: стейт современного приложения = граф, и заперсистить его в ФС = всегда война, немцы, потеря времени и здравого смысла. Вместо этого ОС просто гарантирует приложению, что ничего в файл писать не надо, "просто оставь это здесь", оно никуда не денется. Ограничения в размере адресного пространства — это следующий вопрос. В 32 бит они есть, а в 64 уже, считай, не будет. Но — технически это всё реализовано как persistent paging, то есть в традиционных ФС аналог такой техники — memory mapped file. Отсюда мне было бы интересно знать, какая производительность получается, в сравнении с сериализациями графа/дерева в традиционную/оптимизированную ФС, если его положить в mem mapped file. Я полагаю, что характеристические оценки скорости для такого подхода будут оценкой сверху для производительности дисковой подсистемы ОС Фантом.
Мemory mapped file — это такой персональный кусочек свопа, ос выделяет сегмент и мапит его виртуальную память на диск. Как клиент будет работать с этой памятью ос не знает и потому действует довольно консервативно. Скорость чтения из него ограничена физическими возможностями диска.
В этом смысле клиенту выгоднее самому распоряжаться файловым хранилищем т.к. он то знает какая у него политика чтения/записи, где надо кэш побольше, а что сразу сбрасывать можно. Т.е. клиент потенциально организует файловое хранилище более эффективно, чем ОС.
В вашем случае клиент не распоряжается политикой распределения виртуального адресного пространства, а система распоряжается, но понятия не имеет как было бы оптимальнее с точки зрения клиента.
Можно подумать лишь о том, как более эффективно использовать дисковый кэш при чтении из свопа.
В этом смысле клиенту выгоднее самому распоряжаться файловым хранилищем т.к. он то знает какая у него политика чтения/записи, где надо кэш побольше, а что сразу сбрасывать можно. Т.е. клиент потенциально организует файловое хранилище более эффективно, чем ОС.
В вашем случае клиент не распоряжается политикой распределения виртуального адресного пространства, а система распоряжается, но понятия не имеет как было бы оптимальнее с точки зрения клиента.
Можно подумать лишь о том, как более эффективно использовать дисковый кэш при чтении из свопа.
Очевидно. Но, по сути, (как и в процессоре) операции записи нас волнуют примерно никак (степень их отложенности — только вопрос надёжности), а операции чтения мы можем хинтовать — достаточно из параллельной нити трогать данные, которые нам вскорости понадобятся, и пейджинг их подгонит. В этом смысле ничего не меняется по сравнению с "ручной" работой с диском, нет?
Отчасти так, но мы не знаем в какой последовательности данные потребуются пользователям. Пользователи зачастую знают, но у них нет средств подсказать системе.
Фактически все сведется к случайному чтению/записи диска и бороться с этим бессмысленно.
Хотя, для SSD дисков проблема не столь катастрофична.
А вообще, ваша персистентная память до боли напоминает работу СУБД:
Фактически все сведется к случайному чтению/записи диска и бороться с этим бессмысленно.
Хотя, для SSD дисков проблема не столь катастрофична.
А вообще, ваша персистентная память до боли напоминает работу СУБД:
- ядро — СУБД
- процесс — connection
- страница изменилась — update, делаем копию, заносим в ремап, пишем лог
- ос периодически сохраняет состояние процесса — коммит
- время от времени checkpoint с очисткой лога,
- упали — подняли своп — перечитали лог — сбросили лог
Sign up to leave a comment.
DGFS — быстрая файловая система своими руками