Опубликована (http://google-opensource.blogspot.com/2011/05/linux-file-sys...) видеозапись доклада Майкла Рубина (Michael Rubin), занимающегося системами хранения данных в Google, о причинах миграции с файловой системы Ext2 на Ext4. В докладе показаны результаты исследования производительности EXT2, достоинства и недостатки различных файловых систем, доступных в Linux, причины выбора файловой системы Ext4 для использования на серверах Google.
Некоторые тезисы:
- Файловая система Ext2 очень надежна, но имеет проблемы с производительностью при высокой интенсивности ввода/вывода. Из всех дисковых операций 40% было связано с обработкой мета-данных и только 60% с самими данными. При высокой нагрузке удаление 8 Мб файла иногда длилось до 800 секунд, наблюдались проблемы с фрагментацией. Как вариант решения проблемы все мета-данные можно было кэшировать, но это потребовало бы больших затрат оперативной памяти. Еще один недостаток Ext2 - очень долгое выполнение во...URL: http://google-opensource.blogspot.com/2011/05/linux-file-sys...
Новость: http://www.opennet.me/opennews/art.shtml?num=30478
Вполне ожидаемые, если не очевидные, результаты...
>В Btrfs реализованы очень интересные возможности, но код еще не готов для промышленного применения;Разве не готов? вроде в убунте, в федоре со следующего релиза хотели уже на нее переходить. Когда же готов то будет?
Так "промышленное" и "поиграться в системах, на которых тестируют все новое, необкатанное" - это несколько разные вещи.Вот выйдет пару релизов федоры, сотни и тысячи юзеров помучают этоу ФС под разные задачи - может Гугл и посмотрит на нее с большим доверием. Да они небось и сами ее в тесте гоняют уже не первый день, но что-то не понравилось им либо в коде, либо в поведении... Благо, ресурсы и аудит кода сделать, и погонять тесты на железе у них есть.
> Вот выйдет пару релизов федоры, сотни и тысячи юзеров помучают этоу ФС под разные задачи - может Гугл и посмотрит на нее с большим доверием.Абсолютно уверен в том, что Гуглу наплевать на мнение этих "тысяч юзеров".
btrfs давно в настоящих дистрибутивах (Debian, RHEL). Кому надо - давно использует.
> Когда же готов то будет?Ну так потестируйте на себе, чем больше тех кто тестирует, тем быстрее обезглючат. Но можно просрать данные, уж извините :)
Не все данные одинаково полезны. Можно например на разделе для торрентов потестить.
в бинарных дистрах можно и для /usr юзать - какая разница, если всё можно быстро восстановить?
с другой стороны есть проблема в кернелпаниках и как они будут воздействовать на систему вцелом.
Юзал я месяц назад этот btrfs в продакшене (нужно было том с компрессией сгородить).
основная нагрузка - запись больших файлов в несколько (до 10) потоков.
кернелпаники через день.
Снес нафиг и поставил xfs - полет нормальный.
не так давно ставил дебиан тестинг и попробовал btrfs, "показались" тормоза, а потом вспомнил что кое-что забыл сделать при установке, решил поставить заново но уже на ext4 и скорость существенно выросла даже при установке пакетов было заметно, почему не знаю, оставил ext4
В btrfs до сих пор нет fsck. Если что нибудь произойдет то данным кранты. С учетом того что 99.99999% пользователей никогда не делают бекапов (а остальные 0.00001% тоже не делают но смеются на форумах над последними) использовать эту файловую систему нельзя даже для домашнего компьютера.Просьбы о скорейшем написании fsck ГОДАМИ вежливо отклоняются (ну вот именно сейчас надо решить более важную проблему, вот мы решили я начал писать, продолжаю писать, ой открылось окно патчей в ядро щас выложу патчи и точно-точно-буду-писать-fsck.btrfs).
Сначала fsck, только потом переход.
Анадысь рассматривал линуксовые ФС на предмет возможности использования в след. проекте, которые стартует в начале лета, нужно будет хранить 100ТБ. Смотрел-смотрел, пришел к выводу, что екст4 рулит, начал пробовать. Надо ли говорить, что я был в шоке, когда узнал, что мейнстрим ФС до сих пор! В 21 веке! Не может отформатировать раздел размером более 16ТБ. Гуглил, оказалось ФС поддерживает практически безграничные разделы по размерам, но вот не задача, утилиты обслуживания ФС древнючие и не умеют форматировать разделы более 16ТБ. При этом задача по фиксу этой баго-фичи имеет наивысший приоритет, если верить разработчикам, написано это было пару лет назад, не помню уже от какого числа пост был. До сих пор не сделано. Интересно почему? Это так сложно или они в своем коде разобраться не могут? На помойке место у екст4 до тех пор, пока сопровождающие утилиты не будут давать пользоваться всеми возможностями ФС.
Если у Вас не будет миллионов мелких файлов, то лучше использовать XFS -- не новая, отлаженная, быстрая, многопоточные чтение-запись (по потоку на каждый экстент), есть дефрагментатор, утилиты восстановления.
> Если у Вас не будет миллионов мелких файлов, то лучше использовать XFS
> -- не новая, отлаженная, быстрая, многопоточные чтение-запись (по потоку на каждый
> экстент), есть дефрагментатор, утилиты восстановления.Не поверите, но у меня как раз таки миллионы мелких файлов :) (по 5-30Мб).
А в XFS меня пугает требования к объему памяти для чекдиска, хотя, вроде, можно указать сколько памяти максимум использовать.
Вообще да, скорее всего XFS и буду использовать, JFS уже не развивается.
> Не поверите, но у меня как раз таки миллионы мелких файлов :)
> (по 5-30Мб).Я под мелкими имел в виду размер в 5-30 кб, XFS не умеет с такими оптимально работать.
> А в XFS меня пугает требования к объему памяти для чекдиска, хотя,
> вроде, можно указать сколько памяти максимум использовать.Да, это можно задать и лучше заранее посмотреть как :)
Хотя за всё время использования у меня проблем с XFS разделами не было, хотя около полугода с ней просидел без UPS, а зимой иногда во всём доме эл-во выбивает.
Дефрагментация тоже не пригодилась -- файловая система сама справляется даже на разделах с торрентами (на разделе свободно около 5%):
# xfs_db -r -c frag /dev/sdc1
actual 76712, ideal 73345, fragmentation factor 4,39%
> Да, это можно задать и лучше заранее посмотреть как :)
> Хотя за всё время использования у меня проблем с XFS разделами не
> было, хотя около полугода с ней просидел без UPS, а зимой
> иногда во всём доме эл-во выбивает.
> Дефрагментация тоже не пригодилась -- файловая система сама справляется даже на разделах
> с торрентами (на разделе свободно около 5%):
> # xfs_db -r -c frag /dev/sdc1
> actual 76712, ideal 73345, fragmentation factor 4,39%Ну вы домашний комп и промышленный файловый сервер с iowait >90% почти всегда не путайте :)
а я вот не путаю - xfs отличный вариант.
зыж
про мелкие файлы - xfs отлично развилась за последние 2-а года... но кому я это говорю?!!!
> Ну вы домашний комп и промышленный файловый сервер с iowait >90% почти
> всегда не путайте :)Ну вот на таком сервере я бы с удовольствием попробовал XFS... :)
Я и попробую, скорее всего именно XFS и будет, ибо вариантов особо больше нету.
> промышленный файловый сервер с iowait >90% почти всегдаЭто называется начальника жаба душит дать денег на апгрейд железа, которое можно сказать прогнулось по полной. С таким "iowait >90% почти всегда" сервер на промышленный как-то не тянет:)
> С таким "iowait >90% почти всегда" сервер на промышленный как-то не тянет:)С другой стороны, если у вас железо не полностью загружено - вы зря заплатили за него деньги.
Бедность не порок: одни устанавливают железо под пиковые нагрузки, другие мирятся с лагами при пиковых нагрузках.
> Дефрагментация тоже не пригодилась -- файловая система сама справляется даже на разделах
> с торрентами (на разделе свободно около 5%):
> # xfs_db -r -c frag /dev/sdc1
> actual 76712, ideal 73345, fragmentation factor 4,39%Это вы, батенька, как то скромно живете на XFS
# xfs_db -r -c frag /dev/sdd1
actual 297119, ideal 1911, fragmentation factor 99.36%
Весь раздел - одна большая файлопомойка под торренты.
> actual 297119, ideal 1911, fragmentation factor 99.36%
> Весь раздел - одна большая файлопомойка под торренты.Смотрите, дети, этот сказочный раздолбай качал торенты без преаллокации :)
>Не поверите, но у меня как раз таки миллионы мелких файлов :) (по 5-30Мб).
>А в XFS меня пугает требованияа меня пугают такие "спецы".
зыж
скоко дашь за настройку экст4 на 100Тб и больше? :D
а, потрындеть! :D
понимаю.
>>А в XFS меня пугает требования
> а меня пугают такие "спецы".Мне вот интересно, а на сервере с 100Тб - неужели с оперативкой какие-то проблемы? Или большому диску большой буфер - не его принцип?
1. приведите мне сервер с 100Tб винтами и сколько таких винтов нужно.
в сторону - реально и сейчас какие винты есть? по 2Тб? 3? 5?
так вот, если "вчера" и по 5, то таких нужно 20 штук.
но сегодня таких винтов нет. вот пруф на яндексмарките http://market.yandex.ru/guru.xml?CMD=-RR=0,0,0,0-PF=2142356600~GT~sel~6000-VIS=160-CAT_ID=686672-EXC=1-PG=10&hid=91033
только в сборе хранилища.
итак, сейчас есть только по 3Тб
их нужно - 100/3~=33,(3) - т.е. 34 штуки.
сервер говорите? нюню, видать по дешёвке по интернет магазину заказал :Dно это всё было в сторону. для размышлений о "качестве" местных тролей.
про оперативку - если раздаём по 1Гб/с каналу, то 4Гб ОЗУ хватит и на этот объём с лихвой.
зыж
могу и про эту цифру привести аналогичные очевидные рассуждения. вот только зачем? :D
Как связаны скорость канала и fsck?
никак.
> 1. приведите мне сервер с 100Tб винтами и сколько таких винтов нужно.Мы заказали IBM V7000 на 192 дисках по 600ГБ (2.5" 10000rpm)
> но это всё было в сторону. для размышлений о "качестве" местных тролей.Ну ты понял, да?
> про оперативку - если раздаём по 1Гб/с каналу, то 4Гб ОЗУ хватит
> и на этот объём с лихвой.Не понял к чему тут про канал было написано, но он будет 10Гбит, если что
>Мы заказали IBM V7000 на 192 дисках по 600ГБ (2.5" 10000rpm)а фс не выбрали? оригенально.
>Ну ты понял, да?с каких пор на ты?
>Не понял к чему тут про канал было написано, но он будет 10Гбит, если чтону не понял, так не понял.
А как выбирать ФС без железа? Будет железо - буду тестить, что шустрее бегает
железо как железо. с выбором то его уже определились.
фс надо выбирать под задачи.
а вот их то вы как раз и не описали, как и то будут ли рэйды, лвм и т.д.
и даже такой вопрос - а зачем вам всё нужно иметь именно таким большим куском? его обслуживание - простой всей конструкции.
и почему не рассматривали кластерные распределённые фс?
Задача - хранилка под не жатое видео (покадрово, каждый кадр по слоям). Файлый - изображения размером 5-30Мб, раздаваться будут по самбе или нфс, не суть. Эти файлики будут собирать в видео несколько человек, т.е. один человек может одновременно работать с парой сотней гигов, раскиданных по всех хранилки. Почему одним разделом? Да так удобнее просто, можно и на 2-3 побить в принципе, только что это даст?По поводу аппаратной реализации. Как уже говорил будет 192 диска по 600гб. Они будут объединены в 6-ые рейды, например по 24 диска, т.е. 8 рейдов. Эти рейды хранилкой будут соединены с логический "агрегат", ОС будет видеть все это дело как один 100ТБ хард. Зачем все 192 диска соединять? Чтобы получить как можно большее кол-во iops на выходе, т.к. этот параметр для нас крайне важен.
Про кластерные ФС: зачем она в этой задаче?
> По поводу аппаратной реализации. Как уже говорил будет 192 диска по 600гб.
> Они будут объединены в 6-ые рейды, например по 24 диска, т.е.
> 8 рейдов. Эти рейды хранилкой будут соединены с логический "агрегат", ОС
> будет видеть все это дело как один 100ТБ хард. Зачем все
> 192 диска соединять? Чтобы получить как можно большее кол-во iops на
> выходе, т.к. этот параметр для нас крайне важен.ZFS же
>ZFS жеНа чем?
>>ZFS же
> На чем?
> По поводу аппаратной реализации. Как уже говорил будет 192 диска по 600гб.
> Они будут объединены в 6-ые рейды, например по 24 диска, т.е.
> 8 рейдов. Эти рейды хранилкой будут соединены с логический "агрегат", ОС
> будет видеть все это дело как один 100ТБ хард. Зачем все
> 192 диска соединять? Чтобы получить как можно большее кол-во iops на
> выходе, т.к. этот параметр для нас крайне важен.6-й рейд? IOPS? "взаимоисключающие параграфы детектед".
> 6-й рейд? IOPS? "взаимоисключающие параграфы детектед".А какой рейд надо?
Только RAID-10, он по записи не пролетает так жутко как все остальные. Ну и контроллеры подороже, с батарейкой, хотя это очевидно.
Во-первых, у 10-го рейда избыточность 50%, в курсе, да? И стоимость СХД от этого увеличивается почти в два раза.
Во-вторых, в моей задаче 98% операция чтения, судя по мониторингу.
Все правильно, не слушай дураков. 640 килобайт всем хватит c избытком. А уж подождать пару недель пока рейд6 поелозит головками чтения записи и повосстанавливает разбросаные по всем дискам куски файлов при сбое - святое дело! Дались им эти несчастные несколько лишних дней. Монтажеры фильма опять же, вместо дурацкой лихорадочной работы за 2-3 дня до окончания срока смогут поехать в лес на шашлыки. Во всем выгода!
Еще раз: есть бюджет, в который внатяг протолкнули 192 диска, после долгих дебатов, собраний и т.д. Чтобы сделать 10-ый рейд - железа надо в два раза больше (дисков и полок).
Про пару недель не понял, это речь идет о ребилде? Так ребилд 600Гб диска 10000rpm в шестом рейде идет пару часов, боевые серваки, которые сейчас есть (на 24шт 1ТБ 7200rpm дисках) ребилдятся за сутки-полтора, при этом работать-то можно, тормозит, но работает.
Откуда дровишки про пару недель - не понятно.
> Мне вот интересно, а на сервере с 100Тб - неужели с оперативкой
> какие-то проблемы? Или большому диску большой буфер - не его принцип?На сервере, который будет подключен к хранилке, будет 8Гб памяти.
xfs_check с дефолтными параметрами требует по 2Гб на каждый 1Тб. Т.е. мне надо 200Гб оперативки XD
Но там есть опции, которые задают, сколько максимально памяти использовать, но я еще не пробовал.
> xfs_check с дефолтными параметрами требует по 2Гб на каждый 1Тб.Где такие волшебные требования?
В документации к XFS, причем эти требования подтверждены практикой, у меня один серв. уже есть на XFS 20ТБ, там 8Гб памяти, так вот чекдиск в сег файлт падал, пока своп огромный не сделал.
то что память может закончится при xfs_check - да, указано, но именно про "по 2Гб на каждый 1Тб" - не видел. к тому же xfs действительно быстро развивается - http://xfs.org/index.php/XFS_Status_Updates
>XFS status update for January 2010
>...
>The biggest changes in xfsprogs 3.1.0 were optimizations in xfs_repair that lead to a much lower memory usage, and optional use of the blkid library for filesystem detection and retrieving storage topology information.и на одной конференции ещё в 2008 утверждалось следующее
• Memory usage reductions
– allow larger filesystems to be checked in small RAM configs
– Introduce more efficient indexing structures
– Use extents for indexing free space
вот пруф http://xfs.org/index.php/XFS_Status_Updates
зыж
а как себя ведёт xfs_repair? у него другой апи, а xfs_check - скрипт-оболочка вокруг xfs_db. такую проблему не замечал ни разу - но у нас и памяти всегда хватает. не выставлять же?
> В документации к XFS, причем эти требования подтверждены практикой, у меня один
> серв. уже есть на XFS 20ТБ, там 8Гб памяти, так вот
> чекдиск в сег файлт падал, пока своп огромный не сделал.Какой ей памяти надо RAM или VM ?
> Какой ей памяти надо RAM или VM ?Свап прокатывает, когда 22Тб раздел проверял.
> а меня пугают такие "спецы".
> зыж
> скоко дашь за настройку экст4 на 100Тб и больше? :D
> а, потрындеть! :D
> понимаю.Когда пытался 22ТБ раздел в екст4 форматнуть - гуглил но решения не нашел. В вики екст4 написано следующее:
Currently, Ext3 support 16 TB of maximum file system size and 2 TB of maximum file size. Ext4 adds 48-bit block addressing, so it will have 1 EB1 of maximum file system size and 16 TB of maximum file size
....
The code to create file systems bigger than 16 TB is, at the time of writing this article, not in any stable release of e2fsprogs. It will be in future releases.Так вот, если есть какое-то реальное решение - написал бы, а не умничал.
Судя по этому:
> Ext4 adds 48-bit block addressing, so it will have 1 EB1 of maximum file system size and 16 TB of maximum file sizeТо есть максимальный размер раздела один _эксабайт_, максимальный размер одного _файла_ 16 Тб.
А вообще да, проблема в e2fsprogs такая имеется, видимо тянут для совместимости с ext3, в котором ограничение 16 Тб. Насколько я понял из списка рассылки разрабов, придётся ломать ABI чтобы сделать форматирование разделов более 16 Тб.
Вот тут есть древние патчи для поддержки 64-битного режима в ext4dev http://www.bullopensource.org/ext4/
Но это всё голяк, стоит посмотреть в сторону git-версии, там валяются всякие вкусности типа дефрагментатора для ext4.
Так я об этом и писал, поддержка в ядре большой ФС есть, а вот утилит для создания такой ФС нет.
Вот патчи e2fsprogs https://github.com/tytso/e2fsprogs-64bit
> Вот патчи e2fsprogs https://github.com/tytso/e2fsprogs-64bit"Че-та я очкую, Славик" (С)
Хрен знает каким боком этот костыль потом выйдет. Кроме как создать ФС, ее еще потом обслуживать надо, так что я бы не рискнул. Судя по всему все же будет XFS
>> Если у Вас не будет миллионов мелких файлов, то лучше использовать XFS
>> -- не новая, отлаженная, быстрая, многопоточные чтение-запись (по потоку на каждый
>> экстент), есть дефрагментатор, утилиты восстановления.
> Не поверите, но у меня как раз таки миллионы мелких файлов :)
> (по 5-30Мб).
> А в XFS меня пугает требования к объему памяти для чекдиска, хотя,
> вроде, можно указать сколько памяти максимум использовать.
> Вообще да, скорее всего XFS и буду использовать, JFS уже не развивается.у меня был хард с потерей информации (графика главным образом, видео, пдф, немного текста), на нём была установлена ехт журналируемая, после частичного форматирования и записи фс вообще не инитилась. Читал с хард-а форемост-ом (надо сказать отличнийшая штука, проприетарный коммерческий р-студио не лучше фри-форемоста). Так вот графич файлы на предмет их "гожести" я просматривал в наутилус-е в виде эскизов, увеличивая скролом до нужного. Фото исчислялись десятками тысяч, естественно отобразить такое количество за раз в эскизах сложно, тем более если файлы битые. Сначала пробовал порционить по 500 штук, потом до 300шт, потом до 100шт.если 100 еще просматривать можно, то чуть больше кол-во или битости фс сжирает весь рэм и этот жестокий инпут/аутпут. писал тоже на ехт журналируемый. КОнфигурация компа:коре 2 ггц, 3гб озу, видео отдельное 256мб.Если в опреленный момент я с виртуальной консоли не убью наутилус, то выход только ресет. на ехт 4 вообще были пропажи (год назад). С ХФС всё у меня изменилось. никогда не было такого беспредельного поведения, и очень много опций для конфигурирования/монтирования. Использую хфс только не на вар-е и бут-е (домаш. комп, старый рабочий бук), т.к. у неё (фс) слабое место удаление мелких файлов. А вот рекурсивный поиск, запись, многопоточный доступ, равномерный инпут/аутпут, обслуживание (дефраг) реализованы в достаточной мере. Еще бы можно было размер раздела с ней уменьшать :)
Под мелкие файлы XFS великолепно тюнится. Гуглится с первого раза...
С 2000-х годов почти под сотню серверов работает. Постоянное изучение альтернатив
(по совокупным критериям - надёжность,скорость,масштабируемость и т.д.) пока ни к чему не привели...
> Под мелкие файлы XFS великолепно тюнится. Гуглится с первого раза...Раньше XFS тормозил если метаданных много, что как раз и есть в случае мелочи. Но в новых ядрах его прилично допилили по этому поводу. Стало вообще хорошо :)
> Раньше XFS тормозил если метаданных много, что как раз и есть в
> случае мелочи. Но в новых ядрах его прилично допилили по этому
> поводу. Стало вообще хорошо :)В новых - это каких? Я планирую использовать дебиан 6, там в репах 2.6.32
> там в репах 2.6.32Фи,... в 2.6.32, ещё delaylog нету.
> Фи,... в 2.6.32, ещё delaylog нету.Ну придется собрать ядро
> Под мелкие файлы XFS великолепно тюнится. Гуглится с первого раза...
> С 2000-х годов почти под сотню серверов работает. Постоянное изучение альтернатив
> (по совокупным критериям - надёжность,скорость,масштабируемость и т.д.) пока ни к чему
> не привели...У меня с мелкими файлами только небольшой раздел (200 гиг) под /home, тут меня больше reiserfs устраивает, где-то с 2003-го года так её использую, а для больших разделов уже вылазят её проблемы с маштабируемостью на большие размеры и многопроцессорность
> У меня с мелкими файлами только небольшой раздел (200 гиг) под /home,
> тут меня больше reiserfs устраивает,Только почему-то в интернете попадается много случаев когда fsck диск убил. Одна небольшая проблема. Зато какая.
> Только почему-то в интернете попадается много случаев когда fsck диск убил. Одна
> небольшая проблема. Зато какая.У меня где-то в 2007 была глючная МВ, глухо вешала систему на голом месте, 2 раза корень с ext3 уходил.
Рейзер после каждого зависания тупо отказывал последние изменения и работал дальше, ни разу не было проблем за 8 лет использования.
всё тоже самое, только фс нужно поменять местами.
оракель, 300 гб база, корень с екст3 не проблемма.
рэйзер - корень в акуе, база в дауне. (и это не впродакшене, рэйзер вообще для оракеля не точто не сертифицирован, даже не на всех сайтах найдешь упоминания - на девелоперском окружении юзал. после завала брал копию с продакшена. потом надоело)
> всё тоже самое, только фс нужно поменять местами.
> оракель, 300 гб база, корень с екст3 не проблемма.
> рэйзер - корень в акуе, база в дауне. (и это не впродакшене,
> рэйзер вообще для оракеля не точто не сертифицирован, даже не на
> всех сайтах найдешь упоминания - на девелоперском окружении юзал. после завала
> брал копию с продакшена. потом надоело)reiserfs для баз данных противопоказан -- постоянный sync базы убивает его преимущества, а откаты журнала при ошибках убъют базу.
Я для оракла использовал только xfs с выносом журнала на отдельный диск ещё с 2005-го годаА вот для /home с миллионами мелких файлов на однопроцессорных системах -- это одна из лучших fs (хотя в 33-м ядре работу с несколькими cpu и улучшили, но если на неё копировать файлы файлы в несколько гиг, то всё равно впадает в ступор).
100Тб чего, если не секрет?
> 100Тб чего, если не секрет?В каком смысле чего? Содержимое? Не жатое видео по слоям и кадрам
Спасибо, ясно.
это он выше про мелкие файлы говорил. :D
> В каком смысле чего? Содержимое? Не жатое видео по слоям и кадрамXFS с ним неплохо справится. Особенно в свежих ядрах, где работу с метаданными ускорили. А если это несколько дисков, было бы очень умно размазать на них XFS с правильными параметрами. Поскольку она пишет данные параллельно, скорость может взлететь пропорционально числу дисков в массиве.
yt поверишь, но "правильные" параметры она подбирает сейчас сама.
проверял. я конечно не супер-пупер, но автомат справился лучше.
короче, xfs - очень хорошая фс. уже и для обычного применения.
> Анадысь рассматривал линуксовые ФС на предмет возможности использования в след. проекте,
> которые стартует в начале лета, нужно будет хранить 100ТБ.XFS по вашему видео плачет. Разложить на страйп с грамотными параметрами. Взлетит просто. Особенно на более-менее крупных файлах. SGI делало станции видеомонтажа, сами понимаете что там за файлы.
> XFS по вашему видео плачет. Разложить на страйп с грамотными параметрами. Взлетит
> просто. Особенно на более-менее крупных файлах. SGI делало станции видеомонтажа, сами
> понимаете что там за файлы.У меня аппаратный рейд будет, зачем еще какой страйп?
>> SGI делало станции видеомонтажа, сами понимаете что там за файлы.
>У меня аппаратный рейд будет, зачем еще какой страйп?Вот это интересный вопрос, далеко не каждый hw-рейд может потягаться с полноценным sw-рейдом. Уже не раз натыкался на статьи, где это обсуждалось. Как я понял, основная проблема, что зачастую в рейдах используется старое слабое железо, а переделать под новое - дорого стоит. И годами прошивки не исправляются. А ведь hw-рейд - это просто еще один маленький комп :)
так что советую, пока будете настраивать, прогнать тесты, даже на вашем суперрейде.
Попробуем, но V7000 покупаем как раз потому, что DS3512 не умеет рейды в логические диски объединять, не хотелось это делать на уровне ОС. V7000 - железка новая, сравнительно недавно продаваться начала, так что должно быть все нормально там с контроллерами, посмотрим.
> XFS - отличная производительность, но большая усложнённость реализации;Я большинство разделов перевёл на XFS пару лет назад и до сих пор не жалею, а по сложности реализации btrfs и zfs её сильно обойдут из-за кучи дополнительных фич.
только корень оставил на Ext3 -- что-то не хочется быть тестировщиком Ext4.
На работе на части серверов аналогичная разбивка.
Главное чтобы система была 64-битной.
> Я большинство разделов перевёл на XFS пару лет назад и до сих
> пор не жалею,XFS хороша для больших файлов, типа торентов всяких, видео, даже нежатого и прочая.
> а по сложности реализации btrfs и zfs её сильно обойдут из-за кучи дополнительных фич.
XFS журналит только метаданные. Упомянутые журналят все, не теряя в скорости. Да еще и снапшоты попутно могут делать. Некоторая разница.
> только корень оставил на Ext3 -- что-то не хочется быть тестировщиком Ext4.
EXT4 объявили стабильной чуть ли не 10 версий ядер назад. У многих она уже по умолчанию в дистрибутивах. Теперь она и у гугла. У вас настолько крутой энтерпрайз что гугл ему в подметки не годится? Или вы видите массовые вопли пострадавших от EXT4?
> На работе на части серверов аналогичная разбивка.
> Главное чтобы система была 64-битной.Тем не менее, на кучу небольших файлов EXT4 получше будет.
>XFS хороша для больших файлов, типа торентов всяких,сразу ясно - человек не понимает о чём говорит.
> сразу ясно - человек не понимает о чём говорит.Слишком толсто. Конкретнее, Склифосовский!
конкретнее?
торент юзает мелкие фрагменты файлов. (и пишит ими же в фс)
преалокация большого куска таки есть уже даже в ufs. но в рамках которого торент и гоняет эту мелочёвку - то качает, то раздаёт рандомно. естесно кэш ос об этом запросе на следующий мелкий кусок очередного клиента не догадывается и юзает свой алгоритм.
есть ещё вопросы? http://ru.wikipedia.org/wiki/BitTorrent
зыж
и тем не менее он в одном прав - xfs отличный выбор и для торрентов.
почему?
потому что эта современная много-потоковая (подчеркну!) фс отлично уже работает и с мелкими файлами.
не зря её красная шапка дорабатывала и теперь отлично поддерживает в своём рхел. и в полном стэке применения - от виртуалок, до файлопомоек.
А как там на счет файлов, забитых полностью нулями? Приходилось читать про эту особенность фс при сбоях системы. Опасность сия сильно преувеличена или как?
> А как там на счет файлов, забитых полностью нулями?Дочинивалось в .28 ядре, чтоли. Более свежие этим особенно не страдают вроде.
>ZFS - отличная производительность, высокая надежность и богатые возможности с одной стороны,вам ехать?
>но с другой стороны несовместимая с GPL лицензия на код;
или шашечки?
На пост о том как отформатировать и юзать 100TB - это тоже ответ
Это мне про ZFS?
А на чем ее крутить? На бзде? Спасибо - идите мимо. Особенно в свете последних событий с ораклом и ко.
Лол. Ну юзайте 16гиговый ext4, профессианал :)))
> Лол. Ну юзайте 16гиговый ext4, профессианал :)))Во первых, 16Тб != 16Гб, дилетант. Во вторых, для 100Гб файлов есть хоть тот же XFS, который на них рулит и педалит.
>> Лол. Ну юзайте 16гиговый ext4, профессианал :)))
> Во первых, 16Тб != 16Гб, дилетант. Во вторых, для 100Гб файлов есть
> хоть тот же XFS, который на них рулит и педалит.У вас диск на 16 Терабит?
PS. С формулой 16Тб != 16 Гб согласен.
> У вас диск на 16 Терабит?16 Терабод :)
> У вас диск на 16 Терабит?Не вижу никаких проблем набрать составной том на 16Тб. Всего 8 HDD по 2Гб и готово. Мелко плаваете, на хабре юзеры собрали домашнюю файлопомойку на 90Тб.
> Это мне про ZFS?
> А на чем ее крутить? На бзде? Спасибо - идите мимо. Особенно
> в свете последних событий с ораклом и ко.курите на дебиане (kfreebsd) ну или на opensolaris/nexenta
ps. но лучше на freebsd :)
> курите на дебиане (kfreebsd) ну или на opensolaris/nexenta
> ps. но лучше на freebsd :)Опенсолярис мертв, всякие гибриды как-то не очень доверие вызывают, хотя можно будет попробовать. А во фре ZFS отстает сильно и не достаточно стабильна, я считаю
> Опенсолярис мертв, всякие гибриды как-то не очень доверие вызывают, хотя можно будет
> попробовать. А во фре ZFS отстает сильно и не достаточно стабильна,
> я считаюда не так уж она отстает во фре. v15 сейчас. в следующем релизе будет v28 с дедупликацией и прочим. обновить потом пул и все. можно и сейчас уже юзать v28 на current ветке.
а насчет стабильности это вы зря. сколько не пробовал ее убить (дергал питание, винты) не получилось.
самое главное, что для ваших задач ZFS это просто идеальный вариант, учитывая все ее плюшки. и так как вы к этому не пришли сами, у меня складывается впечатление, что вы с ней мало знакомы. почитайте статейки и маны, вам понравится, правда) или боитесь freebsd? ;) начните знакомство с debian kfreebsd
> да не так уж она отстает во фре. v15 сейчас. в следующем
> релизе будет v28 с дедупликацией и прочим. обновить потом пул и
> все. можно и сейчас уже юзать v28 на current ветке.
> а насчет стабильности это вы зря. сколько не пробовал ее убить (дергал
> питание, винты) не получилось.
> самое главное, что для ваших задач ZFS это просто идеальный вариант, учитывая
> все ее плюшки. и так как вы к этому не пришли
> сами, у меня складывается впечатление, что вы с ней мало знакомы.
> почитайте статейки и маны, вам понравится, правда) или боитесь freebsd? ;)
> начните знакомство с debian kfreebsdА зачем ZFS вообще? Что в ней такого? Она хороша для реализации программных СХД и рейдов, а у меня все железное и снапшоты и дедубликация. Какие у нее преимущества перед XFS?
Сам я с ZFS знаком на уровне тестовых серверов. FreeBSD не боюсь, наоборт люблю, но в своем круге задач (интернет-шлюз, хостинг и тд), а для файлового сервера лучше линукс полходит, по крайней мере мне так удобнее.
> А зачем ZFS вообще? Что в ней такого?У ZFS много полезных плюшек, но при таком соотношении disk/ram (100Tb/8Gb)
она скорее всего вообще не будет работать. Ну то есть абсолютно.
8Gb памяти на ТАКИЕ объемы
говорит о НЕВЕРОЯТНОМ жлобстве и глупости вашего руководства.> Она хороша для реализации
> программных СХД и рейдов, а у меня все железное и снапшоты
> и дедубликация.Снепшоты и ОСОБЕННО дедупликация требует огромных объемов ОЗУ
при массиве в 100Tb. Тем более при мелких файлах, искать описание дедупликации
мне лень. Ройте oracle.com.
Это не ваш вариант совершенно точно!> Какие у нее преимущества перед XFS?
На сайте Oracle расписаны все "фичи".
Насколько я понимаю, вам они не нужны.> Сам я с ZFS знаком на уровне тестовых серверов. FreeBSD не боюсь,
Если вы не *разработчик* FreeBSD и не готовы им платить, то...
Где-то проскакивали весьма-а-а-а-а удручающие бенчмарки FreeBSD+ZFS против Nexenta.
Впрочем, я их не воспроизводил.
> У ZFS много полезных плюшек, но при таком соотношении disk/ram (100Tb/8Gb)
> она скорее всего вообще не будет работать. Ну то есть абсолютно.что ей мешает работать при таком соотношении? непонятно
> 8Gb памяти на ТАКИЕ объемы
> говорит о НЕВЕРОЯТНОМ жлобстве и глупости вашего руководства.не могу не согласиться.
> Снепшоты и ОСОБЕННО дедупликация требует огромных объемов ОЗУ
> при массиве в 100Tb. Тем более при мелких файлах, искать описание дедупликациидедупликацию пока не пробовал, жду релиза фри с zfsv28. но опять же непонятно про требования к оперативке. 8гб оперативки все таки не так уж мало. zfs можно тюнить под количество оперативки и все такое. вы бы хоть дали ссылки на почитать что ли...
> Если вы не *разработчик* FreeBSD и не готовы им платить, то...
> Где-то проскакивали весьма-а-а-а-а удручающие бенчмарки FreeBSD+ZFS против Nexenta.тоже почитал бы. надеюсь не фороникс)
> А зачем ZFS вообще? Что в ней такого? Она хороша для реализации
> программных СХД и рейдовэто да
> а у меня все железное и снапшоты
> и дедубликация.а на чем у вас железные снапшоты и дедубликация?..
> Какие у нее преимущества перед XFS?
ну в общем то снапшоты, дедубликация, программные рейды, менеджер томов)
> Сам я с ZFS знаком на уровне тестовых серверов. FreeBSD не боюсь,
> наоборт люблю, но в своем круге задач (интернет-шлюз, хостинг и тд),
> а для файлового сервера лучше линукс полходит, по крайней мере мне
> так удобнее.с момента появления zfs лично для меня под файловый сервер лучше подходит именно zfs. тут конечно кому что нравится, это всего лишь инструменты. но есть и объективные причины, уж больно она удобна.
>а на чем у вас железные снапшоты и дедубликация?..Писал же уже IBM Storwize V7000
>ну в общем то снапшоты, дедубликация, программные рейды, менеджер томов)
Из этого мне ничего не надо, я имею ввиду именно какие преимущества в плане базовых функций ФС.
> вам ехать?
>>но с другой стороны несовместимая с GPL лицензия на код;
> или шашечки?Может быть вы и не догоняете, но сервер состоит не только из файловой системы. К тому же ZFS очень разборчив к нагрузке, наворочен и толком не имеет утилит для восстановления серьезно порушенной ФС.
> К тому же ZFS очень разборчив к нагрузке, наворочен и толком не имеет утилит для восстановления серьезно порушенной ФС.ZFS чуть проще XFS, исходный код лучше откомментирован и оттестирован. Утилиты восстановления для CoW-ФС находятся в самой ФС и отдельно запускать не требуется. Если уж всё сдохло на CoW-ФС, то и восстанавливать, как правило, не имеет смысла.
>>ZFS - отличная производительность, высокая надежность и богатые возможности с одной стороны,
> вам ехать?
>>но с другой стороны несовместимая с GPL лицензия на код;
> или шашечки?ZFS требует 1Г памяти на каждый 1Т данных.
> ZFS требует 1Г памяти на каждый 1Т данных.Это откуда такие требования? Быстрому кэшу ARC нужно минимум 1ГБ RAM, а L2ARC имеет динамически изменяемый размер.
>ReiserFS и JFS не рассматривались в Google как варианты для миграции из-за недостаточной поддержки кодовой базы;Эх Рейзер… Как же мне нравилась эта ФС ( . Я думал, намного будет… Намного лучше будет это всё.
Поддерживать кодовую базу ReiserFS больше никто не может ( .
Это прискорбно.
> XFS - отличная производительность, но большая усложнённость реализации;Что они там не осилили в ней?
выбирали 2 года назад.
xfs изменилась с тех пор как и экст с 3 до 4.
"Всякой задаче - свой инструмент"(с)Люди
У меня даже на домашней машинке несколько разных FS.
/ - reiserfs
/boot - ext3
/home - reiserfs
/local_multimedia - XFS
/docs - reiserfs
/net_storage - zfs
Я так думаю, что такая картина у многих, кто ищет инструмент для задачи, а не проповедует религию...
А теперь попробуем со всем этим взлететь))!
>А теперь попробуем со всем этим взлететьУже который год... Полёт нормальный!
/ - reiserfs #множество мелких файлов, необходимо журналирование
/boot - ext3 #стабильный состав, простая FS
/home - reiserfs #множество мелких файлов, необходимо журналирование
/local_multimedia - XFS #довольно крупные файлы, создаются/стираются относительно редко
/docs - reiserfs #множество мелких файлов, необходимо журналирование
/net_storage - zfs #множество разнообразных файлов, необходимо гибкое управление массивом
#дисков, подключение по NFS, SMB, FTP. У меня - под управлением
#NexentaStorCE
Разные задачи - разные инструменты.
>[оверквотинг удален]
> /home - reiserfs #множество мелких файлов, необходимо журналирование
> /local_multimedia - XFS #довольно крупные файлы, создаются/стираются относительно редко
> /docs - reiserfs #множество мелких файлов, необходимо журналирование
> /net_storage - zfs #множество разнообразных файлов, необходимо гибкое управление массивом
>
> #дисков, подключение по NFS,
> SMB, FTP. У меня - под управлением
>
> #NexentaStorCE
> Разные задачи - разные инструменты.В общем согласен, кроме /boot под ext3, максимум ext2, и монитровать c noauto.
Или xfs/reiserfs без журнала и можно выкинуть из ядра поддержку EXT*FS
> Уже который год... Полёт нормальный!А вот некоторые другие с рейзером почему-то ругаются, когда им fsck превращает том в вермишель.
>> Уже который год... Полёт нормальный!
> А вот некоторые другие с рейзером почему-то ругаются, когда им fsck превращает
> том в вермишель.А вот у меня этот самый fsck отрабатывает нормально... да ещё и "битый" диск смог восстановить...
а я вот я выбираю единственный NTFS, и не разбираюсь в этой кучке непонятных ФС.
ну это-то понятно.
но тут пишут те, кто разбирается.
хотя бы чуть чуть.
> а я вот я выбираю единственный NTFS,Надеюсь она у Вас используется как корневая ФС, причём на том же разделе где и Windows 7?
И все это работает через FUSE и ntfs-3g?
>а я вот я выбираю единственный NTFSА я вот с недавних пор NTFS-у доверяю только саму Windows, а все данные храню на сетевом диске под управлением "Nexenta CE", а там - "православная ZFS".
А последней каплей стало падение двух дисков NTFS "на ровном месте": после перезагрузки Windows испортились обе копии MFT.
> /boot - ext3А в чем смысл ext3? Почему не выбрать обычную ext2?
а в чем смысл отдельного /boot?
Корень на ФС, которой не умеет бутлоадер.
> Корень на ФС, которой не умеет бутлоадер.у меня reiserfs,ext2,ext3,ext4,fat запилены в ядро и думаю не только у меня.
раньше тоже держал отдельный бут на ext2 но потом понял что с ним гемороя больше
ибо очень часто забывал маунтить при обновлении ядра:)
>>ФС, которой не умеет бутлоадер.Закрузчик, как то: lilo, grub...
>у меня reiserfs,ext2,ext3,ext4,fat запилены в ядро
>часто забывал маунтить при обновлении ядра:)Читать научитьсь, яколка.
>>>ФС, которой не умеет бутлоадер.
> Закрузчик, как то: lilo, grub...дыг этот самый grub отлично все понимает.
просто некоторые использующие отдельный /boot все еще никак не отойдут от разморозки и поэтому не замечают что на дворе уже 2011 год:)
Мдэ. Ладно люди /home не жалеют, у большинства там ничего полезного нет.
Но систему то жалко, ее ж переставлять придется, конфиги переписывать...
/net_storage - понятие сильно растяжимое, чтоб делать какие-то выводы
о пригодности/предпочтительности zfs.
/net_storage - понятие сильно растяжимое, чтоб делать какие-то выводы о пригодности/предпочтительности zfs.
А у меня это "домашний сетевой диск" для всех компов (2 сына, дочь, жена, я). Очень приятна дедупликация, "растяжимость-на-лету" (это когда добавляешь диск), ну и так... по мелочи...
> А у меня это "домашний сетевой диск" для всех компов (2 сына,
> дочь, жена, я). Очень приятна дедупликация, "растяжимость-на-лету" (это когда добавляешь
> диск), ну и так... по мелочи...OpenSolaris для дома для семьи? Или zfs на линуксе?
> OpenSolaris для дома для семьи? Или zfs на линуксе?NexentaStor CE. В общем - да, OpenSolaris в какой-то степени. :)
Для дома, для семьи...
Какой я счастливый человек! Использую ReiserFS в корне, на внешнем usb HDD изначально стоит NTFS. Всё вроде нормально. Зачем все парятся с этими ФС?
У вас с "Гуглом" разные сценарии применения ФС. = К.О.
>Какой я счастливый человек!...Тут ведь как оно: можно всё кушать ложкой. И не париться. Да вот только мясо вилкой как-то поудобнее будет. А лапшу - палочками... Впрочем, палочками тоже можно всё кушать...
Приятного аппетита!
>ReiserFS и JFS не рассматривались в Google как варианты для миграции из-за >недостаточной поддержки кодовой базы;ну, ReiserFS понятно. а JFS каким боком?
по мне - неплохая фсистема.
Есть у jfs проблемы с большими размерами томов. И не факт, что они будут когда-либо решены, если судить по их сайту. Остался только один человек, если не ошибаюсь, который в свободное личное время правит найденные баги. А ведь великолепная классическая фс... Жаль, что не получила развития в сообществе. По-моему, гораздо лучше семейки ехт.
ext4 с опциями по умолчанию все еще тормозит при использовании ее на разделе с образами виртуалок?
Образы разные бывают. И файловая система ни причем, тут важно как отрабатываются барьеры и fsync, и в железе жесткого диска, и в контроллере, и в ядре. Скорее всего "все еще тормозит" означает что файловая система использует барьеры, но в железе они реализованы плохо. Есть вариант отключить (-o barrier=0) но тогда не плачьтесь по форумам что данные пропали.
тема nilfs2 не раскрыта.
А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит когда разделом пользуются долго и свободного места на диске все меньше и меньше.Традиционные ext* более предсказуемые.
> А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные
> файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит
> когда разделом пользуются долго и свободного места на диске все меньше
> и меньше.Не надо обобщать. ZFS не страдает от такой фигни как заполненность диска.
>> А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные
>> файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит
>> когда разделом пользуются долго и свободного места на диске все меньше
>> и меньше.
> Не надо обобщать. ZFS не страдает от такой фигни как заполненность диска.Врать-то зачем? Сходу пример:
http://groups.google.com/group/fido7.ru.unix.bsd/tree/browse...и далее по треду, где даже не 95% заполненности.
>>> А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные
>>> файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит
>>> когда разделом пользуются долго и свободного места на диске все меньше
>>> и меньше.
>> Не надо обобщать. ZFS не страдает от такой фигни как заполненность диска.
> Врать-то зачем?А я и не вру:
% zpool list store
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
store 1,73T 1,70T 30,9G 98% ONLINE -% zpool upgrade store
This system is currently running ZFS pool version 15.Pool 'store' is already formatted using the current version.
% uname -rsm
FreeBSD 8.2-STABLE amd64
интересно, а почему google не инвестирует в разработку reiser4.
лично считаю, что деньги бы пошли на пользу. многие бы это приветствовали. фс очень быстра, стабильная. допилили бы и было бы просто круто !!
разработчиков мало заинтересованных?
проект сам по себе бурно бы развивался, будь большое кол-во приверженцов.
> разработчиков мало заинтересованных?
> проект сам по себе бурно бы развивался, будь большое кол-во приверженцов.ев*
асно :) тогда ворпос, просто сам напрашивающийся, а почему их мало?
т.е. нужна реклама, я так понимаю? чтобы мир узнал об этом ?
> асно :) тогда ворпос, просто сам напрашивающийся, а почему их мало?
> т.е. нужна реклама, я так понимаю? чтобы мир узнал об этом ?Со стороны Ганса было достаточно антирекламы в LKML, когда он забил болт на reiserfs3
и демонстративно отказался нормально объяснить "почему именно плагины" в reiserfs4.
> интересно, а почему google не инвестирует в разработку reiser4.а зачем гуглю инвестировать в сомнительную коммерческую затею человека, который сидит и сидеть будет вечно?
Запустите reiserfsck, чем более старую тем лучше - то что вы видите, и есть коммерческая модель этой разработки, пока автор не подсел - вроде бы успешная, этих $25 хватало на хлеб с колбасой - ему, и с маслом - команде (и там на три четверти был бывший наш народ ;)
Никакой технологической целесообразности у этой затеи не было и в помине (просто на фоне тогдашней ext3 годилось абсолютно что угодно, лишь бы сделанное руками)> лично считаю, что деньги бы пошли на пользу.
Гансу - не пошли бы. Что ему в тюряге с ними делать.
рейзерфсу - пошли бы, ну а гуглю-то оно зачем, улучшать мир за свой счет? Гугль взял лучшее из _уже_ допиленного, о чем точно было известно что особых взбрыков можно не ждать, манипуляцией со штатными настройками получил приемлемые для своих условий результаты, и купил ключевого разработчика, чтобы оно и дальше было для него приемлемым, независимо от колебаний генеральной линии. Он почти всегда именно так и делает.Значительно смешнее вопрос почему гугль не инвестирует (в значимых масштабах, в рамках обычной благотворительности - инвестирует) btrfs, раз уж ему оракле не велит пользоваться zfs'ом.
Собственно моё IMHO не сколько инное чем у остальных участников флейма.
ext4 отлично показала себя при работе с крупными так и с мелкими файлами. Дефрагментации нет, скорость чтение/записи высокая.
P.S. это лишь мое скромное/yжасное мнение
Аналогично. Все стандартные системы - на ext4, ибо мейнстрим. Городить зоопарк ради растопыривания пальцев смысла нет, проще добавить диск в RAID, сменить RAID Level или добавить машину в кластер - в зависимости от потребности.
>Файловая система Ext2 очень надежна, но имеет проблемы с производительностью при высокой интенсивности ввода/вывода.ВНЕЗАПНО