> Если нету, то тогда помогите определиться между JFS, XFS и ZFS. Основной критерий, понятное дело - надежность и стабильность. Потом уже скорость.

XFS. Тем более, учитывая вашу специфику.

ZFS - отличная ФС, но вам нужно использовать (Open)Solaris, если критерий - надёжность.

> ZFS - отличная ФС, но вам нужно использовать (Open)Solaris, если критерий - надёжность.

Ага, я готов пойти даже на это. Тут другой вопрос тогда. Даже два: легко ли шарится zfs по nfs (чтоб маки могли без проблем работать с массивами) и как там с виртуализацией? А то у меня под редхатом еще kvm крутится с виндами для некоторых специфичных рендеров.

>JFS, XFS и ZFS

Основной критерий, понятное дело - надежность

Facepalm.jpg
ext3

> Даже два: легко ли шарится zfs по nfs (чтоб маки могли без проблем работать с массивами)

Не думаю, что будут какие-либо проблемы (учитывая, что NFS/RPC - это детище Sun)

и как там с виртуализацией? А то у меня под редхатом еще kvm крутится с виндами для некоторых специфичных рендеров.

Есть поддержка Xen. Лично у меня нет опыта использования Xen на солярисе. Ещё там должен быть virtualbox, так же поддержкой хардварной виртуализации

И ещё - а вы учли затраты на такую радикальную смену linux + linux/kvm -> Solaris + Solaris/(Xen/virtualbox)? Это же ещё поддерживать нужно будет.

> >Основной критерий, понятное дело - надежность

Facepalm.jpg

ext3

ext3 поддерживает разделы 24TB?

> И ещё - а вы учли затраты на такую радикальную смену linux + linux/kvm -> Solaris + Solaris/(Xen/virtualbox)? Это же ещё поддерживать нужно будет.

На редхат очень кстати закончилась годовая поддержка. А в оракловской солярке никак не могу понять (ну неопытный я в покупных системах) - что понимается под «1-4 сокета»?

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

Не, ну ачо фейспалм? ext3 поддерживает 24ТБ массивы? У меня нихрена не вышло, может косорукий просто.

См. статистику. Да. Да.

Дяденька, научи. Правда. Вдруг получится. У меня, когда я пытался сделать мкфс.ехт4 выдало, что с блоками размером 4096 не выйдет массива больше 16, по-моему ТБ. А блоки больше делать нельзя. Где я косячу?

>Где я косячу?
В цифре названия ФС

Не, прав или ты или википедия. The current e2fsprogs can only handle a filesystem of 16 TB - это про ext4. А про ext3 - 8kb блоки поддерживаются только в некоторых архитектурах - таких как alpha. А при 4кб блоке можно до 16ТБ. Так что...

> А в оракловской солярке никак не могу понять (ну неопытный я в покупных системах) - что понимается под «1-4 сокета»?

Дайте ссылку, откуда это.

99% - это ограничение количество сокетов для ЦПУ. Т.е. использовать восьмипроцессорные (восем сокетов под ЦПУ, я не ядер ЦПУ) системы на оптеронах с «1-4 sockets» - низзя. Как-то так.

> Дайте ссылку, откуда это.

https://shop.oracle.com/pls/ostore/product?p1=oraclesolaris&sc=ocom_solarispr...

вот там вот, посерединке.

> вот там вот, посерединке.

Здесь речь именно про количество физических «розеток» ака сокетов под процессоры.

А никаких специфических для storage'й продуктов нет?

Про сокеты спасибо, буду знать.

А никаких специфических для storage'й продуктов нет?

Эээ.. У меня или у оракла? )

Если у меня, то в далеком будущем планируется SAN, а так больше ничего специального пока нету.

Если у оракла, то сан я не на их системах собирать буду.

не слушай этого недоумка-нуба

ставь соляру и накатывай ZFS, в принципе, в Линуксе есть аналог - btrfs, но если данные сверхценные, то я бы не рискнул его использовать

xfs хороша при работе с видео, но вот надёжность низкая

> xfs ... но вот надёжность низкая

Пруф?

использовать btrfs в продакшне? ты вообще в своём уме? Оно сырое, что ппц (особенно, сравнивая с xfs)

Полностью согласен.

>использовать btrfs в продакшне?

я и не предлагал его использовать, я лишь упомянул о нём

Пруф?

потеря файлов при пропаже питания

хотя, причём тут продакшн? -))

А про ext3 - 8kb блоки поддерживаются только в некоторых архитектурах - таких как alpha. А при 4кб блоке можно до 16ТБ. Так что...

* facepalmрукаладонь.png срывы шаблонов линуксятников

ZFSv14 сейчас в продакшене на FreeBSD 8.1.

> потеря файлов при пропаже питания

хотя, причём тут продакшн? -))

Всё чудасатее и чудесатее. Отличный критерий нестабильности. Что, по-вашему, должна сделать ФС и ОС, если питание пропадает, а в памяти есть куча незафлашенных буферов?

Я вам со 100% гарантией скажу, что при пропадании питания на всех ОС и при на всех драйверах ФС незаписанные данные не будут записанны :(

Основной критерий, понятное дело - надежность и стабильность.

Надёжность обеспечивается не ФС, а техническими решениями - регулярные бэкапы (ленточки или множественное реплицирование данных на другие носители - ручной rsync, GlusterFS, ), специализированные СХД, резервное питание для всего оборудования. Никак иначе.

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

>Что, по-вашему, должна сделать ФС и ОС, если питание пропадает, а в памяти есть куча незафлашенных буферов?

такое поведение и характерно именно для xfs

мило

> >Что, по-вашему, должна сделать ФС и ОС, если питание пропадает, а в памяти есть куча незафлашенных буферов?

такое поведение и характерно именно для xfs

Т.е. вы считаете, что остальные ФС и ОС смогут сбросить кэши из памяти и записать их на жёсткие диски при выключенном питании? НО КАК??!

нет, я считаю, что тебе неплохо бы ознакомиться с матчастью

такое поведение и характерно именно для xfs

смешно.

смейся, дурачок

> нет, я считаю, что тебе неплохо бы ознакомиться с матчастью

Пруфлинк. Мне правда интересно, на что опирается такое милое заблуждение, что ФС может как-то записать данные из памяти на диск при отсутствующем питании.

а мне интересно, из чего ты сделал такой бредовый вывод

Egorkkk> сервак на редхате и рейд-массивы на 18, 20 и 24 ТБ

Если нет UPS и железо не имеет избыточности (больше одного БП, два контролера дисков (multipath) и т.д.), то продолжать разговор о выборе надежной бессмысленно.

надежной FS бессмысленно.

> Если нет UPS и железо...

Есть и упс и больше одного бп, и два контроллера дисков - все есть. Так что продолжать разговор очень есть смысл! ) Вот поэтому как раз я начитался про XFS и мне страшно его ставить. Хотя еще неизвестно, что надежнее - она или маковская HFS.

при наличии упса - ставь XFS

>> Вот поэтому как раз я начитался про XFS и мне страшно его ставить.

Если

Есть и упс и больше одного бп, и два контроллера дисков - все есть.

то страшно не должно быть. С качеством кода у XFS проблем нет.

> Надёжность обеспечивается не ФС, а техническими решениями - регулярные бэкапы (ленточки или множественное реплицирование данных на другие носители - ручной rsync, GlusterFS, ), специализированные СХД, резервное питание для всего оборудования. Никак иначе.

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

>Facepalm.jpg

Jfs ЖЕ!

А тогда я еще раз спрошу самое начало - нет ли драйверочка XFS под мак или под тот его macFUSE? Очень неохота по нескольку раз туда-сюда лить. Под ZFS я вроде бы нашел что-то, а вот XFS нету.

> Так что продолжать разговор очень есть смысл! ) Вот поэтому как раз я начитался про XFS и мне страшно его ставить. Хотя еще неизвестно, что надежнее - она или маковская HFS.

Блин, ну включи же мозг - косяки при внезапном пропадании питания будут на всех ФС, чем больше «оптимизации» и кэша в памяти - тем больше данных пропадаёт. Само по себе ничего не пропадает, а если ты будешь ставить жесткие эксперименты и смотреть, что будет, если вырубить питание при копировании 100 000 файлов с одного массива на другой - ну сам себе злобный буратин, хорошим такое не кончится на любой ФС :)

XFS - старая и проверенная ФС + протестированный код в ядре линукса.

Нет к тебе больше доверия, дядя )

Ладно, ладно, понял, не ругайся. XFS мне больше нравится, чем ZFS, пушто не надо будет еще и в солярке разбираться. Вот ее б к маку приконнектить...

А оно было?)

Пока я сидел на ранних версиях -zen, часто ноут приходилось жестко перегружать 5-6 раз в день. Ничего не упало с корнем на JFS.

Ну одно дело ноут, а другое - 20 терабайт съемок целого сезона сериала ) Хоть бы где почитать было про большие системы, хотя б и по-английски. Везде САНы, а у них там свои фс у каждого, по-моему.

что за сериал-то?

выбирай то, что есть в шапке, не смотря на то, что индусы намедни портировали zfs под линукс. Например, я вижу в yum xfsprogs, но не вижу jfsutils. Следовательно, подходит xfs. Остаётся озаботиться бекапами и батарейкой контроллера.

> XFS мне больше нравится, чем ZFS, пушто не надо будет еще и в солярке разбираться. Вот ее б к маку приконнектить...

Разве в маках нет поддержки ZFS? В рекламных брошюрках на сноу-лепард сервер была заявленна поддержка ZFS

Прости, не могу пока сказать. Новый, комедийный.

> Разве в маках нет поддержки ZFS? В рекламных брошюрках на сноу-лепард сервер была заявленна поддержка ZFS Ее вначале пообещали, а потом, по лицензионным соображениям вычистили отовсюду. Там какая-то темная история с CDDL и патентами NetApp'а, я не вникал. Так что ZFS остался только в опенсорсном варианте, что меня ввергает в пучину сомнений.

>а другое - 20 терабайт съемок целого сезона сериала

IBM же писал. Так что выбирай, что больше нравится:

IBM (JFS), SGI (XFS) или SUN (ZFS)

> Хоть бы где почитать было про большие системы, хотя б и по-английски. Везде САНы, а у них там свои фс у каждого, по-моему.

Не знаю, я как бы не админ а embedded SW engineer. Попробуй завести ещё одну тему с реквестом литературы/доков и подождать, когда админы начнут вылазить онлайн

Попробуй поискать на сайтах ibm & бывшего Sun'a. Ну или начать с википедии и дальше по ссылкам ;)

Вот поэтому как раз я начитался про XFS и мне страшно его ставить.

Нужно меньше слушать мнения истеричек и холиварщиков. Если у вас всё так серьёзно, то может быть лучше будет получить консультацию у специалиста за $ при личной встрече.