И все же, как хранить миллионы мелких файлов?

Да никак, если не разделом/образом все это хранить.

dd?

что за хрень? копия сайта с размещенными турами.

сессии таришь =)

а так да, лучше снапшотом их, снапшотом

reiserfs

алсо можно их в БД загнать.

Твоюжматьменяажпередернуло.

Зачем ты так с нами?

Каталогизация @ сквашфс.

Можно попробовать (не обещаю успех!)

1) Установить Oracle Database, хранить данные оракла на raw разделах диска, файлы хранить в blob полях таблицы.

2) Для работы с файлами таким образом написать специальную прогу с веб-интерфейсом (например, на Java). (Вместо написания своей софтины попробовать заюзать нечто вроде Alfresco, но боюсь что оптимизация у Альфрески на объемах в 6M мелочи - «не, не слышал»).

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

4) Если веб-интерфейс не канает, и нужно именно физическое наличие на диске - написать небольшую прогу-переливалку (из БД на целевой диск).

Еще можно попробовать посмотреть, с какой скоростью на таких данных отрабатывает master-slave репликация самого Оракла (и дальше копировать данные через нее) или встроенный в БД бэкап.

5) И конечно везде надо замерять перфоманс и делать выводы.

Ипать, и это ради одного сайта =)

что за хрень? копия сайта с размещенными турами

блин, не дочитал до конца, пропустил эту строчку :( ну тут сам бох велел попробовать хранить всё не на диске, а в базке, и бэкапиться встроенным бэкапом (или если это нужно для распределения нагрузки - встроенное репликацией). Только базка должна быть не sqlite и вероятно не mysql, а хотя бы postgres, лучше oracle (если рука поднимется её пиратить).

Тема про «хранить», а нытье про «медленно копируется». WTF? Мелочь ты все равно быстро не скопируешь, тут в иопсы все упирается, т.е. если ты на _постоянной_ основе переносишь файлы, то тебя спасет только громоболт с внешним ssd. Ну и рабочую копию тоже только на ssd. А чтобы спать спокойно, бекапы делать через dd.

как вариант - преобразовать пачками в tiff.

e4defrag

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

P.S: Вроде бы KRoN73 проводил какие-то исследования на эту тему пару лет назад.

да, в чем минус распихать их по «образам»?

лалка, ты кроме толксов больше разделов не знаешь?

Например по каким?

какая разница? пусть будет squashfs для ro и jfs для rw.

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

Именно исследований не проводил, адекватные тесты разработать всё ломает. Но по факту, если есть структура кешей с большим количеством файлов (от сотен тысяч и выше) и относительно высокой вложенностью (глубиной в 2-4 подкаталога) и надо это барахло регулярно сканировать (find для удаления, rsync для копирования), то ext4 начинает на таком очень быстро тормозить ужасающе. А переход на reiserfs сильно разгружает систему, даже когда ФС развёрнута не на отдельном разделе, а в loop-образе на ext4.

xfs пока на этот счёт так и не щупал. Когда-то она страшно тормозила на удалении, поэтому выпадала из рассмотрения, сейчас, говорят, в этом плане сильно улучшили. Но я пока так и не экспериментировал.

http://juick.com/Balancer/2225516

http://juick.com/Balancer/2229209

http://juick.com/Balancer/2762617

то ext4 начинает на таком очень быстро тормозить ужасающе

Ради интереса, а не вспомнишь опции монтирования?

Вот бы мне какой файл-контейнер. Типа дисков для виртуалок. Сразу размеченный одним фрагментом на 100-150 ГБ. А в него мелочь писать.

Рабочая копия на ссд. Архивное хранение на винтах в 10м рейде. Но когда надо туда сюда прогнать один большой тур - начинается трата времени.

???

Что такое, ntfs не тянет ничего дальше «писечки скачать бесплатно»?

\что за хрень? копия сайта с размещенными турами.

я бы предложил переделать движок туров, чтобы он не с отдельными мелкими файлами работал, а хранил всё в больших файлах-контейнерах и индексировал их самостоятельно

в геймдевелопменте такая проблема есть - хранить и читать много-много файлов с текстурами, иногда больше, чем у тебя, но они её решают, кучей мелких файликов не хранят

спросонок понял что надо хренову тучу картинок хранить, а не копию сайта с разными файлами

а мелкие картинки удобно складывать в tiff как отдельные страницы/кадры.

ИМХО не поможет, все равно в IOPS упрешься, хоть твое файло будет в одном образе. Ты его примонтировал, а дальше что? Правильно, ты всю эту мелочь будешь читать, и хоть они и в одном большом файле, от тормозов это не очень поможет. Создай файл размером сколько тебе надо, да отформатируй. Контейнер готов.

файлов миллионы, а диск один?

нужно добавить дисков, это очевидно. а какая там фс всё равно.

Ради интереса, а не вспомнишь опции монтирования?

Они у меня более-менее одинаковые всюду. Что-то типа:

rw,noatime,nodiratime,commit=290,barrier=0,data=writeback

Да, все расслабленно донельзя, особенно commit=290). Thx.

Nodiratime входит в noatime, а reiserfs ожидает barrier=none судя по коду, не уверен, что 0 будет обработан.

Nodiratime входит в noatime

Я в курсе. Это осталось с каких-то древних экспериментов.

а reiserfs ожидает barrier=none

Я привёл мои опции монтирования для ext4 :) С resierfs — только noatime и то не всюду. На кешах, как раз, включено, чтобы видеть к чему давно не было обращений.

На отдельном разделе в формате ext4.

Разве это какая-то чудесная ФС и с ней таких проблем не будет?

https://www.opennet.ru/opennews/art.shtml?num=36153

В файловой системе Ext4 добавлена поддержка inline-хранения данных, что позволяет значительно увеличить эффективность хранения очень мелких файлов за счёт размещения данных прямо внутри inode, что значительно экономит дисковое пространство. По умолчанию размер inode составляет 256 байт, а размер блока данных 4 Кб. Ранее, даже если файл занимал несколько байт, ему всё равно выделялся блок в 4 Кб. Отныне, содержимое файлов, размером несколько байт, может сохраняться прямо в inode без выделения дополнительных блоков данных. При хранении исходных текстов ядра новая возможность позволяет сэкономить примерно 1% дискового пространства, для типового раздела /usr экономия составляет 3%. Кроме экономии дискового пространства хранение данных в inode также позволило заметно увеличить скорость доступа к мелким файлам, за счёт сокращения числа перемещений головки и минимизации операций чтения с диска;

Я так хранил научные измерения: 1 минута - 1 файл. Суточные измерения. Файлов много. Раздел на Ext4 полностью устроил меня. Так как использовалась Windows, то приходилось копировать данные на диски ntfs. В Ext4 файлы копируются в 2 раза быстрее.

Файлов много.

Сколько?

http://itmages.ru/image/view/3165993/692ce64b

У меня больше файлов. В 5 раз :) А месте меньше.
Пичалька.