LINUX.ORG.RU
ФорумAdmin

ext4 и 25 терабайт

 


0

2

имееться 25 терабайт массив (raid6 3тб диски 7200 sas6gb)

что хотим - разместить почту - текущий обьем 11 тб

что лучше сделать для проиводительности - так как там почти чистый рандом доступ к 11 тб

и вопросы
1) есть ли какието известные проблемы у ext4 с такими обьемами - то есть что лучше отдать все под одну ext4 - или нарезать обьем скажем по терабайту и на каждой сделать отдельную fs
2) про разбить этот обьем на два рейда и/или заодно поменять raid6 на raid10 и подобное - я и сам понимаю что это улучшит рандомный доступ - но разбить этот массив возможно только на 2

+ ...

?

★★

Ответ на: комментарий от anonymous

А если бы прочитал, то нашел бы еще 'обьем' вместо 'объем', 'какието' вместо 'какие-то' и практически полное отсутствие знаков пунктуации, а их редкое использование также ошибочно, например дефисы вместо запятых.

Но стоит ли из-за этого человека игнорировать или относиться к нему с презрением? Быть может он иностранец, у него не было уроков русского языка и письма в школе, есть и другие причины.

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

kep
()

Maximum file system size (Ext4) - rhel7 - 50TB [ 1EB theoretical ] https://access.redhat.com/articles/rhel-limits

Так что зависит от версии драйвера ФС, ядра на твоей системе

Я, когда пару раз пришлось большой массив запустить, поглядел в табличку (у нас центос-5 была), и выбрал XFS - чисто по спецификации.

Но я не гуру :) По небольшому опыту работы с СХД - спецификации вендоров рулят. Все эти списки совместимости и требовний.

Deleted
()
Ответ на: комментарий от Deleted

вот в том и дело - что оно на нем работало в такой конфигурации - и имхо крайне не удовлетворительно
и меня грызут некоторые сомнения - а не являеться ли ФС - грубо говоря весь обьем ее индексов структур и так далее - некоторым тормазом которые с увеличением обьема начинает ухудщать положение все более и более

чуть раньше это жило на двух 5 и 6 тб массивах - разных массивах - и было куда лучше

вот и возникает вопрос - пока возможно - может переделать

ae1234 ★★
() автор топика
Ответ на: комментарий от Deleted

и дело не в лимитах фс - до тех лимитов как до луны

ae1234 ★★
() автор топика
Ответ на: комментарий от ae1234

некоторым тормазом которые с увеличением обьема начинает ухудщать положение все более и более

понимаю. Тут не имею достаточно опыта, не буду вводить в заблуждение

Deleted
()
Ответ на: комментарий от ae1234

ext4 любит тормозить при работе с большими файлами (по несколько гб, обычно 8-10+ Гб) тогда тебе нужна xfs, она в этом плане пошустрее ну а так да, разбей на n массивов, можно потом при необходимости LVM'ом склеить

avernus
()
Ответ на: комментарий от avernus

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

ae1234 ★★
() автор топика
Ответ на: комментарий от ae1234

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

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

avernus
()
Ответ на: комментарий от kep

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

anonymous
()
Ответ на: комментарий от ae1234

чуть раньше это жило на двух 5 и 6 тб массивах - разных массивах - и было куда лучше

Вполне логично. Если что-то , например, пишет, а другое читает, то лучше, когда эти сущности взаимодействуют с разными рейдами.

что лучше сделать для проиводительности

А собрать разные конфигурации и потестить? Да хоть бы и синтетическим iometer.

cipher ★★★★★
()
Последнее исправление: cipher (всего исправлений: 1)

разместить почту

Конкретнее. В каком виде там будет лежать почта? Maildir'ы пользователей что-ли?

anonymous
()
Ответ на: комментарий от cipher

в том дело
в конфигурации 5 + 6 - все основные используемые существовали на первом массиве - на втором редко используемые почта-бекапы

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

сейчас массив в таком состоянии что ровно за день - rsync-уло на новый ssd массив - 2 терабайта (за 24 часа)
вот как то так печально

ae1234 ★★
() автор топика
Ответ на: комментарий от anonymous

зачем

ZFS в линуксе, если уже есть BTRFS? ZFS к линуксу через одно место стыкуется.

anonymous
()
Ответ на: комментарий от kep

что характеризует более высокий уровень

модерастии

t184256 ★★★★★
()

подведем итоги
думаю лучше всего - все же разделить массив на части по ~2тб
это даст как возможность по экспериментировать с разными ФС так и даст возможность перенося - обновлять их

ae1234 ★★
() автор топика
Ответ на: комментарий от anonymous

да немного - 8-10 тыщ - просто имапы ...

ae1234 ★★
() автор топика
Ответ на: комментарий от cipher

кстати про iometr
для адекватности результата - он должен и мерить ровно такой обьем - 11 терабайт - тут никакого терпения не хватит ждать пока он их на генерирует только

а так по мелочи - fio - да тестировал - показывали вполне адекватные для обычных дисков iops-ы

ae1234 ★★
() автор топика
Ответ на: комментарий от ae1234

если можешь позволить себе использовать разные 2-тб разделы - делай так.
это даёт тебе не 1 точку отказа, уменьшает размер индексов, структур за которые происходят блокировки на уровне фс.
уменьшает время Recovery после unexpected shutdown

bl ★★★
()

Почему-то никто ещё не предложил рейзер(4) под мелочь, раз уж там maildirы. У нас почта именно на нём. Правда объёмы скромнее - всего 2 ТБ не считая бекапов.

NightOperator ★★★
()
Ответ на: комментарий от NightOperator

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

ae1234 ★★
() автор топика
Ответ на: комментарий от NightOperator

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

vasya_pupkin ★★★★★
()

с недавних пор для улучшения рандомного доступа стали применять грязный хак, Intel SSD на PCIe, и bcache как нижний слой под LVM, а файловую систему ext4. Отлично идет и под базы данных, и под общие хранилища для VMWare.

Bloody ★★
()
Ответ на: комментарий от Viper

письма в подавляющем числе - не мелкие - так что до лимита инодов не дойдет никогда

ae1234 ★★
() автор топика
Ответ на: комментарий от Bloody

Как вам стабильность bcache? Были случаи сбоев, и как решали проблемы? Кеш работает только на чтение или на запись то же?

Deleted
()
Ответ на: комментарий от Deleted

ни единого разрыва, Fedora 23 в продакшене, ядра 4.2.x/4.3.x bcache в режиме

Bloody ★★
()
Ответ на: комментарий от Deleted

ни единого разрыва, Fedora 23 в продакшене, ядра 4.2.x/4.3.x bcache в режиме writeback, данные бэкапятся ежедневно. Раньше использовали только для чтения, но прирост отзывчивости систем от включения настолько велик, что считаем возможным рискнуть.

Bloody ★★
()
Ответ на: комментарий от King_Carlo

Здесь очень не хватает alexferman, который посоветовал бы btrfs

Deleted
()
Ответ на: комментарий от Deleted

Я проводил эти тесты дважды (при каждой покупке нового харда) и каждый раз xfs сосала. Поэтому я искренне удивляюсь, когда её кому-то рекомендуют.

Материалы тестов тут: https://yadi.sk/d/byszZqzdq6uNe методика в fsbenchmark.sh

legolegs ★★★★★
()
Последнее исправление: legolegs (всего исправлений: 1)
Ответ на: комментарий от legolegs

Я переводил почтовик на maildir с ext4 на xfs на том же железе. Прирост был очень явно ощутим. Собственно тормоза как раз и были причиной перехода. Там конечно было не 25 терабайт, а 0.5, но тем не менее. В обоих случаях опции монтирования не крутились. Не знаю уж, почему так, но факт.

Davyd ★★
()
Ответ на: комментарий от ae1234

имелся в виде ессно 3тий

третий рейзер не поддерживает объемов в 25 терабайт.

anonymous
()
Ответ на: комментарий от Deleted

Как вам стабильность bcache? Были случаи сбоев, и как решали проблемы?

Великолепно всё. Главное при создании всего этого хозайства не протупить и выбрать bucket-size правильный, потом поменять уже не удастся. Ну и про тонкие настройки ФС, что поверх оного, забывать не следует (fragment-size, stride, stripe_width и.т.п.). Особенно радует что оно с блоками работает, то бишь и raw виртуалок, и отданные им тома кеширует одинково.

Ну естественно всё нужно выровнять, поднастроить потом, bcache и мониторится и тюнится хорошо, кроме bucket-size, который без пересоздания всего не изменить.

Jameson ★★★★★
()

А те которые тут ext4 ругают, а вы её настраивать пробовали? А перед тем как создавать а не потом? Там достаточно много чего можно крутить... При грамотной настройке, если её bcache например подпереть или вложиться в железный райд с ссд кешем опять же и грамотно всё это отровнять работать будет отлично. Я вот вообще не понимаю зачем мне ext4 менять на что то, всё отлично работает, просто руки надо иметь прямые, в эксплуатируемом железе разбираться и понимать как оно вообще всё вместе работает.

Jameson ★★★★★
()

-=:=-

могу предложить анальное удаление гланд..
Например - бьёте по 1-2тб. ставите ext4 или рейзер(3|4) без сжатия или там упаковки хвостов.
Далее, юзаете unionfs так, чтобы все эти куски собрать в единое пространство - чтобы файло (целиком, каждый файл) распределенно клалось(ложилось|вылаживалось) на каждый раздел. сам не делал, ибо мимокрокодил.
но идея понятна?

KosmiK ★★
()
Ответ на: комментарий от Davyd

Я своему тесту доверяю, т.к. он простой, как гвоздь. А у тебя прирост мог бы быть из-за фрагментации на старой фс (при недостатке места ext4 фрагментируется ещё как), т.е. имхо ты мог бы мигрировать с ext4 на ext4 и тоже получить прирост.

legolegs ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.