Нужна ли дефрагментация ext4? А дедупликация?

После «залива» фрагментации то откуда взяться?
А дедупликацию ext4 не умеет.

squashfs с любым сжатием gz/lzma/xz для rw aufs/overlayfs или любую другую «стековую» на вкус.

Не знаю :)

Заливается все в тар архивах по 500-8000мб. Потом распаковка.
Я больше имел ввиду не саму фрагментацию, а «менее компактное расположение файлов» что ли. Хз как пояснить.

Хм. А я думал дедубликацию можно каким-нибудь патчем там, а не только на уровне фс.

squashfs с любым сжатием gz/lzma/xz для rw aufs/overlayfs или любую другую «стековую» на вкус.

6 незнакомых слов в одном предложении...
Извините, был неправ. Пойду дальше тыкать мышкой в венду %(

Заливается все в тар архивах по 500-8000мб. Потом распаковка.

а не легче сразу распаковывать в каталог назначения?

Ну оно так и происходит примерно.

Извините, был неправ.

А ты гугли.

Если что squashfs для проблемы «кучи мелких файлов со сжатиями и дедубликациями» заруливает ext4.

А ещё на файлах «до 100кб» фрагментация вообще не возможна

Я больше имел ввиду не саму фрагментацию, а «менее компактное расположение файлов» что ли. Хз как пояснить.

Data consolidation. e4defrag этого не умеет и спец. утилит для ext4 нет. Если только перемещать файлы на другой раздел и затем обратно, или уменьшать размер фс до минимума через resize2fs.
Но зачем? Не такая уж и большая разница в производителности начала и конца диска.

Тогда вопрос снят)
Да благо и нагрузка на сайт маленькая.

8-)

Нее, я в кАпилачку дабабляю все новые словоформы от нашего дк-
абгрейд (С) дедубликация(С) :-))


Ничего личного, просто прикольно у тебя получается.

в старину с дебрагментацией и бубликацией бобролись с помощью dump | restore , так у Немет (rip) было написано, кажись.

\покраснел

А с абгрейдом то что не так?)

u_P_grade

аптдбкгрейдгт

Хм. А я думал дедубликацию можно каким-нибудь патчем там, а не только на уровне фс.

И называется этот патч «симлинк».

Была такая мысль. Но там такая дикая вложенность и структура, что я даже хз.

А что там, в корне картинок кладёшь пустой файл и дальше можно просто при помощи find найти нужные, хоть по размеру если названия различаются, удалить их и создать симлинки.

Ну вообще дедупликация так же подразумевает copy-on-write, и тут симлинк не поможет.

Ну мне помог бы. Тк записи в файлы в принципе быть не может.

Вообще «около 0.5М файлов по 25кб» это около 20 файлов? Я бы не стал париться.

0,5 миллиона файлов )

http://ru.clihelper.com/find/

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

Нужна ли дефрагментация ext4?

Очень нужна, но пока нормальной нет. e4defrag дефрагментирует только файлы (а с этим у ext4 итак хорошо), но не консолидирует свободное пространство и не сортирует файлы. И с этим у ext4 ужасно. Через год-два-три активной работы начинает тормозить чудовищно.

там такая дикая вложенность и структура

Тогда reisrefs без вариантов. ext4 на кешах, типа cache/[00-ff]/[00-ff]/files тормозит чудовищно.

http://juick.com/Balancer/2762617

Самое смешное, что кеши работают быстрее в reisrefs/loop-образе на ext4, чем в голой ext4 :D

Хранятся долго? Можно найти или сварганить скрипт, который найдёт дубликаты и склеит их через хардлинки.

В ext4 нет дедупликации. Юзай бд или другую фс.
Часто чекаю на фрагментацию, но ее все еще нет. А у тебя скорее inode закончатся. Опять же, почему бы не хранить данные в бд? Работать станет проще и быстрее.

Емнип для вагона мелких файлов лучше всего reiserfs. Я в нём /usr/portage держал, пока не перекатился на ssd.

У меня до 2кк файлов на разделе, фрагментации нет, тормозов в моем понимании нет (поиск долгий да, но там это не критично).

а в более компактном расположении на диске файликов для ускорения их загрузки. Или это наивняк?

SSD же.

У федоры есть утиль http://pkgs.fedoraproject.org/cgit/hardlink.git/
бегает по подкаталогу и меняет одинаковые файлы на хардлинки

Этой же ФС сто лет в обед? Как такое может быть то?

Хранятся чуть ли не «навсегда». Не изменяются, не переписываются. Графика.

А не в курсе как с этим в btrfs? Онлайн дефрагментация там вроде есть из коробки + сжатие и дедупликция.

На текущем тарифном плане ссд только на 120гб, а этого очень мало.

И скрипт по мотивам https://code.google.com/p/hardlinkpy/

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

Железо физическое. Файлы - это жипеги тупо. Миллионы и миллионы жипегов. Записи в уже размещенные файлы не бывает.

Этой же ФС сто лет в обед? Как такое может быть то?

Без понятия. Я сам удивился, когда понял. Лет 7 назад, когда ext4 по тестам стала уделывать reiserfs, я на ext4 перешёл целиком и безвозвратно. А года полтора-два назад стал материться, что железо серверное стало намного быстрее, а грузится сильнее, чем раньше. Терпел, терпел, в прошлом году рискнул на пробу поставить давно забытый reiserfs под особенно часто используемый кеш — и прифигел от снижения нагрузки на систему :) Потом ещё несколько подобных переходов. В общем, реально на активной дисковой параллельной работе reiserfs оказывается шустрее, чем старая ext4. Хотя на свежих разделах ext4 шустрее.

У меня до 2кк файлов на разделе, фрагментации нет, тормозов в моем понимании нет

Забыл уточнить (по ссылкам это упоминалось) — речь об активном параллельном многопоточном чтении. Т.е. типовое использование web-сервера со статикой, когда несколько сот клиентов активно шарятся по сотням гигабайт мелкой статики.

А не в курсе как с этим в btrfs?

Нет. Для меня лично (судя по имеющимся отзывам и поднимаемым темам) она пока не созрела :) zfs пока тоже не щупал, т.к. с lvm она бесполезна, а переходить на целиком zfs-тома я совсем не готов.

Ну понятно. Я в свое время в похоже ситуации остановился на ext4, но в работу сайта внесли изменения таким образом, чтобы разбить хранилище файлов на пулы. Т.е. ФС нарезалась на фиксированные куски, скажем, 12-20 гигов. Чтение шло со всех заполненных файлами, а запись только в один. После заполнения кусок переводил в read-only. Сам понимаешь, read-only кусок один раз дефрагментировал и с ним больше проблемы нет. С другой стороны сейчас я уже не поклонник ext4 и больше смотрю на xfs. В данной ситуации ее можно онлайн дефрагментировать.

И вне зависимости от fs я бы попросил ядро не вытеснять метаданные об фс (vfs_cache_pressure). Ведь именно это будет влиять на скорость доступа к файлам.

Терпел, терпел, в прошлом году рискнул на пробу поставить давно забытый reiserfs под особенно часто используемый кеш — и прифигел от снижения нагрузки на систему :)

7 лет-то подождал? Для чистоты эксперимента.

7 лет-то подождал?

ext4 на нагруженных разделах через пол-года тупить начинает, на менее нагруженных — через год. reiserfs я до ext4 (кстати, соврал, я на неё перешёл не 7 лет назад, а 5) использовал 5 лет (2004..2010) и проблем с деградацией не встречал.

Вот где ещё встречал деградацию — это на reiser4. Но там она была стремительная, через пол-года всё тормозило.

Файлы - это жипеги тупо. Миллионы и миллионы жипегов.

Самым ценным советом будет, в данном случае, стереть всё порно, забыть об этом геморрое. :D

Короче говоря, я правильно понимаю, что вся возможная оптимизация расположения файлов для ехт4 - это тупо мув с раздела и потом назад на этот же раздел?

я правильно понимаю, что вся возможная оптимизация расположения файлов для ехт4 - это тупо мув с раздела и потом назад на этот же раздел?

Ну, можно представить ситуации, когда e4defrag будет полезен, но в целом — да, «дефраг мувом» оптимальный выбор для ext4.

\пометил себе не забыть, что НТФС - не торт

: )