Разработчик Дэниел Филипс, работающий в компании Samsung, сообщил (http://www.phoronix.com/scan.php?page=news_item&px=MTY0NTA) в неформальной беседе во время Linux Foundation Collaboration Summit, что его файловая система Tux3 (http://tux3.org/) возможно скоро будет включена в основное ядро Linux. По заявлению разработчика, компания Samsung заинтересована в использовании данной файловой системы во встраиваемых системах даже больше чем в недавно включённая в состав ядра ФС F2FS, также разработанной сотрудниками Samsung. Отмечается, что разработчик Tux3 взаимодействовует в том числе и с командой разработчиков F2FS.
Файловая система Tux3 разрабатывается (http://www.opennet.me/opennews/art.shtml?num=17130) с 2008 года и является версионной файловой системой. В 2009 году работа над Tux3 была приостановлена, но в начале 2013 года проект возродился (http://www.opennet.me/opennews/art.shtml?num=35741) и начал интенсивно развиваться. Для хранения большинства структур используются b-tree и предложенные автором Tux3 версионированные указатели. Файловая система обеспечивает атомарные транзакции и запись в произвольные области ("write-anywhere").
Особый интерес представляют заявления разработчиков о скорости работы данной файловой системы. Например, Tux3 известен тем, что в одном из тестов смог обогнать tmpfs, что ранее считалось невозможным, так как tmpfs является довольно тонкой прослойкой между VFS и SWAP. Дополнительно разработчик отмечает, что имеются планы по поддержке сжатия на лету и снапшотов.
В данный момент файловая система уже достигла состояния, когда разработчик ведет разработку, используя Tux3 на своей системе. Тем не менее, по словам разработчика, потребуется еще порядка 3 лет на оптимизацию, стабилизацию и отладку до уровня при котором станет возможным промышленное внедрение данной файловой системы.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTY0NTA
Новость: http://www.opennet.me/opennews/art.shtml?num=39434
> Например, Tux3 известен тем, что в одном из тестов смог обогнать tmpfs, что ранее считалось невозможным, так как tmpfs является довольно тонкой прослойкой между VFS и SWAP.Стоять, а разве tmpfs не в RAM? Т.е. SWAP это вообще в другую стезю.
Судя по выше сказанному tmpfs работает поверх виртуальной памяти (ram+swap), что логичнее, чем сурово забивать оперативку...
но если свопа нет, то получается что tmpfs == ram, или не так?
Прикол в том что сначала никто не верил что tmpfs вообще можно побить по скорости. А оказалось - МОЖНО.
Скорее всего они получили буст в случае когда tmpfs по-факту в swap. Типа сжатия на лету, а-ля zram.
Чему тут удивляться?
> Например, Tux3 известен тем, что в одном из тестов смог обогнать tmpfsДате тесты SYNC RANDOM WRITE!
> Дате тесты SYNC RANDOM WRITE!Кстати конкретно этот на них пожалуй даже и не обоcpeтся особо. Ты только представь себе, при запросе на запись он должен 1) пхнуть блок в первое попавшееся свободное место и 2) проапдейтить указатель. Тормозить там особо нечему.
И вообще, CoW/версионники/каквытамэтоназываете - на запись как раз не особо тормозят несмотря на полное журналирование :). Это одна из фич такого подхода.
Вот тут бенчмарк: http://lkml.iu.edu//hypermail/linux/kernel/1305.0/03713.html
--
tmpfs асинхронно:
# dbench -t 30 1
1 41542 239.09 MB/sec warmup 1 sec
1 84616 236.68 MB/sec warmup 2 sec
1 127702 235.88 MB/sec warmup 3 sec
1 170882 234.70 MB/sec warmup 4 sec
1 214226 234.61 MB/sec warmup 5 sec
...
tmpfs синхронно:
# dbench -s -t 30 1
1 41828 242.34 MB/sec warmup 1 sec
1 85490 239.80 MB/sec warmup 2 sec
1 129270 238.10 MB/sec warmup 3 sec
1 172759 236.54 MB/sec warmup 4 sec
1 216506 237.07 MB/sec warmup 5 secxfs асинхронно:
dbench -t 30 1
1 18073 116.31 MB/sec warmup 1 sec
1 50540 144.63 MB/sec warmup 2 sec
1 83490 155.40 MB/sec warmup 3 sec
1 116315 160.97 MB/sec warmup 4 sec
1 148634 163.62 MB/sec warmup 5 secxfs синхронно:
# dbench -s -t 30 1
1 39 1.38 MB/sec warmup 1 sec
1 72 1.57 MB/sec warmup 2 sec
1 103 1.59 MB/sec warmup 3 sec
1 143 1.52 MB/sec warmup 4 sec
1 190 1.52 MB/sec warmup 5 sec
Разницу между 150 MB и 1.5 видишь? С удовольствием соглашусь,
что Tux3 в синхронном режиме будет выдавать 3 мега в сек. :D
> что Tux3 в синхронном режиме будет выдавать 3 мега в сек. :DВесьма зависит от оверхеда на сброс служебных структур. У tux3 он судя по всему небольшой. А XFS кстати по жизни отличался тормознутостью в работе с метаданными. Их подтянули где-то в 3.5 ... 3.8, но все-равно не фонтан.
> И вообще, CoW/версионники/каквытамэтоназываете - на запись как раз не особо тормозят несмотря на полное журналированиеОга. Дафай, расскажи это тем, у кого сторадж на zfs заполнен на >85%.
b-tree изжил себя, фрактальные индексы интереснее
https://www.youtube.com/watch?v=88NaRUdoWZM
> b-tree изжил себя, фрактальные индексы интереснеекомпилятор тебе в руки, за чем дело стало?
А еще ламповые усилители и двухтактные двигатели, ага.LMDB обгонишь - тогда приходи, поговорим.
> b-tree изжил себя, фрактальные индексы интереснееКак только DDR будет работать по принципу броуновского движения.
> b-tree изжил себя,Громкое заявление. Ибо довольно фундаментальная структура, на которой много чего держится.
Да, разумеется включат.
Линус уже давным-давно делает всё, что ему говорят Samsung, Google, HP, IBM, список можете продолжить сами.
Эти монстры вваливают в линукс столько денег каждый год, сколько простому смертному за всю жизнь не заработать
> Эти монстры вваливают в линукс столько денег каждый год, сколько простому смертному
> за всю жизнь не заработатьОни вкладывают в Linux потому что зарабатывают с помощью него, было бы странно не инвестировать доходную кормушку
> было бы странно не инвестировать доходную кормушкуТы не поверишь, но многим эта мысль не приходит в голову. Они предпочитают пилить собственные реализации, чем поддерживать существующие. Как же так - делиться кодом с вероятным противником? Усраться и не поддаться.
> Линус уже давным-давно делает всё, что ему говорят Samsung, Google, HP, IBM, список можете продолжить сами.Линус включает в ядро только грамотные и толковые патчи. А поступают такие патчи - сюрприз! - от профессиональных разработчиков, которые в фуллтайме пишут вещи, полезные не только их работодателям.
В любом случае, разработкой Linux сейчас де факто управляют корпорации.
А я против этого.
> В любом случае, разработкой Linux сейчас де факто управляют корпорации.
> А я против этого.гайка ждет тебя :-)
Какой Гайка?
> Какой Гайка?Полагаю, Haiku OS
А может из Чип и Дейл.
> А я против этого.А что мешает повторить путь Турвалдса? Нопейсать своё ядро, с шахматами и поэтессами, и, как он, популяризировать?
Нет, будет тебя слушать)
Очень интересная вещь. Будущий конкурент Btrfs, судя по всему.
> Очень интересная вещь. Будущий конкурент Btrfs, судя по всему.Я бы так не сказал, поскольку Btrfs уже используют некоторые дистрибутивы, а tux3 имеет на данный момент только слова которые даже тестами не подкреплены. Стабилизация 2 или 3 года, потом активное тестирование, потом внедрение. Btrfs пока немного впереди его уже сипользуют
Я и сказал: в будущем.
> Я и сказал: в будущем.На фичи btrfs vs tux3 форумные аналитики даже не пробовали смотреть. Это слишком сложно, да? :)
Btrfs хороша снапшотами, в сабже снапшоты тоже обещают.
> Btrfs хороша снапшотами, в сабже снапшоты тоже обещают."Боинг летает. Вася тоже обещал что его дельтаплан полетит". Следует ли отсюда что дельтаплан Васи и Боинг - одинаковы по возможностям?
BTRFS не версионная, насколько я помню.
> BTRFS не версионная, насколько я помню.То есть точно ты не знаешь, верно?
>> BTRFS не версионная, насколько я помню.
> То есть точно ты не знаешь, верно?Гм... Ну теперь-то я точно знаю :)
> BTRFS не версионная, насколько я помню.Она Copy-on-write. Не то чтобы это принципиально отличается - это по сути подвиды одного и того же класса алгоритмов. То-есть общая идея - при записи не гробится старое состояние, вместо этого делается выносок вбок и оформляется новое состояние. Отличия в деталях реализации этой механики, кто-то оптимизирует в одну сторону, кто-то в другую.
В принципе да, при желании версионирование можно впилить в Btrfs, т.к. механизм памяти состояний файла уже реализован.
> В принципе да, при желании версионирование можно впилить в Btrfs, т.к. механизм
> памяти состояний файла уже реализован.Просто это по сути подвиды одной и той же идеи, отличающиеся между собой лишь некоей конкретикой реализации. Считать их принципиально разными IMHO как-то криво.
> Очень интересная вещь. Будущий конкурент Btrfs, судя по всему.Скорее, замена ext4. По фичам ему до btrfs как до китая пешком. Но вот версионирование и скорость работы могли бы ему позволить заменить классические EXTы. Все-таки классика не может делать полное журналирование с хорошей скоростью, как ни крути.
Вижу только безудержное самовосхваление. А реальных результатов - с гулькин хрен.> Тем не менее, по словам разработчика, потребуется еще порядка 3 лет на оптимизацию, стабилизацию и отладку до уровня при котором станет возможным промышленное внедрение данной файловой системы.
Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода, год, максимум полтора - все будет". Так что реально срок допиливания Tux3 стоит предполагать где-то в году 2020-м.
> Вижу только безудержное самовосхваление. А реальных результатов - с гулькин хрен.Какой универ закончил? Тема диплома? Где работаешь? Должность? Ссылки на работающие проекты?
> так что реально срок допиливания Tux3 стоит предполагать где-то в году 2020-м.Форумные аналитеги. Ты её хоть пробовал? Тух3 и 5 лет назад рабочим был. И чудесно работал.
> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
> год, максимум полтора - все будет".А слушать не надо, надо использовать.
BTRFS уже можно пользоваться.
Ога, да Btrfs можно пользоваться, да, только вот по скорости она не шибко быстрая, а что касается надёжности - смотрим changelog сежего стабильного ведра, например 3.10.34 (https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.34) и что мы видим?Btrfs: fix data corruption when reading/updating compressed extents
Гоп-ца-ца! Сударь, а вы данные не боитесь потерять, если до сих пор в этой поделке обнаруживаются такие ошибки, а?
Не-не, что бы там не говорили нанятые ораклом пиарщики из facebook-а и тд, оно для пром. использования не годится. Да и для домашнего тоже, если нет желания в момент срочной надобности информации хвататься за голову и с криком "профукались мои данные!" прыгать в окно.
> ведра, например 3.10.34Вот чего-чего а если btrfs использовать - надо использовать свежие кернелы.
> Гоп-ца-ца! Сударь, а вы данные не боитесь потерять, если до сих пор
> в этой поделке обнаруживаются такие ошибки, а?А вы ченжлоги к другим ФС смотреть не пробовали? Но да, страшилок меньше становится в основном только в самых свежих ядрах. Поэтому ваши заявы про "стабильные ядра" - булшит. У майнлайна каждый релиз одинаково стабилен, а что там майнтайнеры вашего дистра про стабильность пиндят - это их личная отсебятина уже, на стабильность ядра сие влияет мало. То-есть, даже вот 3.14 RC2 спокойно набрал 2 месяца аптайма. Очень интересно, если это тестовая версия такая, то уж релиз называть НеСтабильным - это вообще наглости надо набраться :).
> Не-не, что бы там не говорили нанятые ораклом пиарщики из facebook-а
О как, оказывается оракл платит фэйсбуку. Treason uncloaked! :)
> тоже, если нет желания в момент срочной надобности информации хвататься за
> голову и с криком "профукались мои данные!" прыгать в окно.Ну а бэкапы конечно не для вас.
> Ну а бэкапы конечно не для вас.А Вы лично после каждой файловой операции на боевой машине снимаете бэкап, да?
Ну, а что касается btrfs - у Вас был опыт установки этой фс на боевой nginx-фронтэнд с RPS более 2000 на раздел с горячим кэшем? или может на video on demand - сервер(nginx flv|mp4), который заливает под завязку канал в 2 гбит?Просто, какбэ огульно утверждать, что у btrfs всё тип-топ, даже под такими нагрузками я бы не стал, ибо лично видел как на таких нагрузках btrfs вставал раком и даже не по производительности, а как раз по стабильности - кернэл паник возникал где-то после получаса - пары часов работы, как раз как сервер полностью загружался юзерами... (ядра январские, все lts с kernel.org).
А вот, например, xfs или старый-добрый ext4 работали как миленькие по полгода и больше.
Вы бы ещё уточнили, в каком году это было, на каком ядре и с какими параметрами монтирования.
> А Вы лично после каждой файловой операции на боевой машине снимаете бэкап, да?Нет, разумеется. Ну так не каждая файловая операция представляет из себя ценность, если что.
> Ну, а что касается btrfs - у Вас был опыт установки этой
> фс на боевой nginx-фронтэнд с RPS более 2000 на раздел с
> горячим кэшем? или может на video on demand - сервер(nginx flv|mp4),
> который заливает под завязку канал в 2 гбит?Нет, разумеется, у меня был опыт ее установки на более-менее обычный файлопомоечный раздел на десктопнике. Ну, работает вроде. Вполне сравнимо с другими.
> раз по стабильности - кернэл паник возникал где-то после получаса -
> пары часов работы, как раз как сервер полностью загружался юзерами...В каком ядре, опять же? А то знаете, у меня он падал и при просто копировании файла mc. Но это было давно.
> (ядра январские, все lts с kernel.org).
Я не думаю что в LTSы кто-то сильно портирует фиксы btrfs'а и честно говоря считаю затею с LTS ядрами достаточно кривой, т.к. совместимость в ядрах ломают редко и если у вас нет вопиющей блоборасии которая может отвалиться - занятие этим онанизмом имхо ни к чему хорошему при желании погонять нечто свежее не ведет. Так что если вы хотите кушать этот стабилизец - флаг вам в руки и барабан на шею.
Вот только
1) Ваши данные о стабильности экспериментальной ФС на ядрах которым чуть ли не полгода не особо кому-то интересны. Это WIP. Там много меняется. И данные "от января" вы можете себе оставить, имхо.
2) С формальной точки зрения зеленого свистка вверх с объявлением btrfs стабильным официально не было, так что при таком подходе жаловаться придется в спортлото. Ну или платите ораклу или зюзе, тогда вас выслушает их саппорт.> А вот, например, xfs или старый-добрый ext4 работали как миленькие по полгода
> и больше.Да вот блин, велосипед Украина тоже 20 лет ездит и хоть бы что сломалось. То ли дело Боинг - за 20 лет куча техобслуживаний и замены частей. Следует ли отсюда что Украина лучше Боинга? А хрен. Функциональность сравнить забыли. Если на то пошло, XFS вообще не умеет полный журналинг, а ext4 конечно умеет, но скорость при том чебурашья. Снапшоты? Ну их можно кой-как прикрутить через ж..., но если нечто дизайнили как самолет - оно летает лучше чем запорожец к которому крылья приварили на скорую руку.
>> А Вы лично после каждой файловой операции на боевой машине снимаете бэкап, да?
> Нет, разумеется. Ну так не каждая файловая операция представляет из себя ценность,
> если что.Смешно, Вы это попробуйте паре тысяч пользователей объяснить.
>> Ну, а что касается btrfs - у Вас был опыт установки этой
>> фс на боевой nginx-фронтэнд с RPS более 2000 на раздел с
>> горячим кэшем? или может на video on demand - сервер(nginx flv|mp4),
>> который заливает под завязку канал в 2 гбит?
> Нет, разумеется, у меня был опыт ее установки на более-менее обычный файлопомоечный
> раздел на десктопнике. Ну, работает вроде. Вполне сравнимо с другими.Это не боевой сервер, это даже не тестирование. Это на посмотреть.
>[оверквотинг удален]
> В каком ядре, опять же? А то знаете, у меня он падал
> и при просто копировании файла mc. Но это было давно.
>> (ядра январские, все lts с kernel.org).
> Я не думаю что в LTSы кто-то сильно портирует фиксы btrfs'а и
> честно говоря считаю затею с LTS ядрами достаточно кривой, т.к. совместимость
> в ядрах ломают редко и если у вас нет вопиющей блоборасии
> которая может отвалиться - занятие этим онанизмом имхо ни к чему
> хорошему при желании погонять нечто свежее не ведет. Так что если
> вы хотите кушать этот стабилизец - флаг вам в руки и
> барабан на шею.Админ локалхоста. На продакшене ничего не "гоняют". Там работает с минимальным простоем заявленный функционал.
> Вот только
> 1) Ваши данные о стабильности экспериментальной ФС на ядрах которым чуть ли
> не полгода не особо кому-то интересны. Это WIP. Там много меняется.
> И данные "от января" вы можете себе оставить, имхо.
> 2) С формальной точки зрения зеленого свистка вверх с объявлением btrfs стабильным
> официально не было, так что при таком подходе жаловаться придется в
> спортлото. Ну или платите ораклу или зюзе, тогда вас выслушает их
> саппорт.Мне интересны, потому как проводить нагрузочное тестирование этой ерунды мне некогда.
А вот мнение админа локал хоста мне не интересно
И да я плачу RH. Но вот ни разу не приходилось обращаться в техподдержку по поводу не стабильной работы ФС.>[оверквотинг удален]
>> А вот, например, xfs или старый-добрый ext4 работали как миленькие по полгода
>> и больше.
> Да вот блин, велосипед Украина тоже 20 лет ездит и хоть бы
> что сломалось. То ли дело Боинг - за 20 лет куча
> техобслуживаний и замены частей. Следует ли отсюда что Украина лучше Боинга?
> А хрен. Функциональность сравнить забыли. Если на то пошло, XFS вообще
> не умеет полный журналинг, а ext4 конечно умеет, но скорость при
> том чебурашья. Снапшоты? Ну их можно кой-как прикрутить через ж..., но
> если нечто дизайнили как самолет - оно летает лучше чем запорожец
> к которому крылья приварили на скорую руку.
> BTRFS уже можно пользоваться.Тонко !
Не знаю как для продакшена (думаю рановато), а для домашней системы использование btrfs очень удобно. К примеру, root на btrfs позволяет быстро проводить обновления в стороне с помощью снапшотов, (пользуюсь генту), и позволяет всегда иметь рабочую ОС нескольких версий без бездумного копирования. :) Это одно из немногих применений, есть еще настройки пользователя на отдельном субволуме и прочие удобства. В общем btrfs я доволен. С интересом гляну на tux, когда появится.
> Вижу только безудержное самовосхваление. А реальных результатов - с гулькин хрен.Ну как бы код есть и работает, обслуживая нужды разработчика. А самовосхваление было сугубо по заявкам слушателей и в приватном порядке, если что.
> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
> год, максимум полтора - все будет".ИЧСХ, уже более-менее есть :).
> Так что реально срок допиливания
> Tux3 стоит предполагать где-то в году 2020-м.У него желаемый набор фич меньше.
>> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
>> год, максимум полтора - все будет".
> ИЧСХ, уже более-менее есть :).Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS - это вроде как клон zFS, то есть планы-то у него такие же - это всё, что касается управление данными на блочных устройствах, то есть полная замена mdadm, lvm, файловой системы + в некотором будущем всего-то распределённая фс (нечто вроде drbd+clvm+gfs2|ocfs2) так что - извините, уважаемый, но скорее "менее есть", чем "более есть".
>> Так что реально срок допиливания
>> Tux3 стоит предполагать где-то в году 2020-м.
> У него желаемый набор фич меньше.Здесь нет наполеоновских планов, но набор фич заявлен серьёзный и основной функционал _уже_ реализован, так что автор фс реально смотрит на вещи, в отличии от сказочников из оракла.
> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS -
> это вроде как клон zFS,По возможностям - да. Более того - догнать и перегнать. Что они, кстати, уже успешно делают. Например в btrfs можно местами отключить CoW, если он мешается. А базам данных он как раз мешается. Ибо не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая к повторной работе на нескольких уровнях, это сажает производительность. Работа с снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило, управление кешом - интегрировано с ядром, а не как в ZFS.
> то есть полная замена mdadm, lvm, файловой системы +
Ну да. Это дает некие специфичные плюсы. Ну и некие специфичные минусы. Ну например, видит такой монстрик по ошибке чексуммы - ой, побились данные. Может слазить на другую копию RAID и посмотреть не прокатит ли чексумма если данные взять оттуда. Если прокатит - отлично, починили данные на автомате из исправной копии. Это если ФС и RAID плотно повзаимодействовать могут. А если не могут - RAID сам по себе не знает какая копия данных верная.
> Здесь нет наполеоновских планов, но набор фич заявлен серьёзный
Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти все прямо сразу, сугубо за счет принципа работы. Было бы сранно их НЕ заявлять при этом.
> и основной функционал _уже_ реализован, так что автор фс реально смотрит
> на вещи, в отличии от сказочников из оракла.У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять.
> У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять.Ась? что, по сети можно вольюмы объединять в файловые системы? или возможна загрузка с btrfs-raid5-тома?
> А если не могут - RAID сам по себе не знает какая копия данных верная.
Да ну? Насколько я в курсах, а мне приходилось не только слышать от коллег (как, видимо автору этого заявления) что mdadm в принципе работает, но и собирать массивы, которые были развалены, в том числе под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Кстати, failed-диски, это как раз те диски за актуальность данных которых то самый рэйд, который "сам по себе не знает какая копия данных верная" не ручается, поэтому и метит такой диск как failed. Кроме того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно сказать какая группа блоков содержит актуальные данные, кроме того восстановить недостающие/повреждённые блоки информации.
А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более чем крепко и хорошо если ведёрко не панкнёт.
А что касается сказочников из оракла - дооо, конечно работает! вопрос только в качестве работы - я, конечно, понимаю, что для Вас потеря данных на продакшне - это какбэ фигня, никто не заметит же, ну а для всех остальных надёжность фс - это один из ключевых параметров. Мало кому хочется копируя один файл попортить или профукать другой, не менее важный, а btrfs как раз этим-то и грешит, особенно под хорошим грузом.
Он наверняка не юзает бтрфс, а все возможности по ченджлогам ядра рассказывает.
> А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором
> вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший
> такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более
> чем крепко и хорошо если ведёрко не панкнёт.А вы не сделаете снапшот без COW вообще.
> Да ну? Насколько я в курсах, а мне приходилось не только слышать
> от коллег (как, видимо автору этого заявления) что mdadm в принципе
> работает, но и собирать массивы, которые были развалены, в том числе
> под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих
> рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.Это не так важно, пользуны могут подождать часик, им главное -- чтобы их данные целыми оставались.
Важно в MD RAID то, что он корректно транслирует Write Barrier'ы -- DM/LVM, кстати, замечены были за читерством в этом тонком месте.
Соответственно, если читерить с WB, тогда с хорошей вероятностью от того же, от чего развалился MD -- от внезапного Power Failure (от Cord Unplugged бесперебойник не защищает, если что) -- данные на XFS могут превратиться в тыкву. ;)
> Ась? что, по сети можно вольюмы объединять в файловые системы?Это вообще уже не к дисковой ФС вопросы а к надстройкам над ними.
> или возможна загрузка с btrfs-raid5-тома?
На каком-то фундаментальном уровне не вижу чему это будет противоречить. Если бутлоадер может прочесть ядро и рамдиск, разумеется. Linux можно грузить вообще с любой похабщины, ему самому по себе все-равно и там возможностей по костылированию странных вещей в процессе загрузки - хоть отбавляй. Так что если кому сильно надо - имхо сделают. Может и с костылями, да. Вот только для начала, код RAID5/6 в ядре без году неделю и он был добавлен как нестабильный. Я бы им пока вообще не пользовался. Он сырой и грабельный. Хотя если хочется получть граблями по лбу и показательно демонстрировать шишку - вы по адресу. Особенно хорошо получится если взять ядро подревнее, без багфиксов в этом коде. В самых первых ядрах там журналирование с райдом работало некорректно. Так что вы берите ваши суперстабильные, LTSные, как раз получите термоядерный стабилизец с нефикшеным кодом райдов, если фиксы не портировали.
> от коллег (как, видимо автору этого заявления) что mdadm в принципе
> работает, но и собирать массивы, которые были развалены, в том числе
> под нагрузкой, ничего, норм собиралось,Понятно. На уровне алгоритмов вы по нулям. Если данные на дисках разошлись, RAID не знает какая из копий правильная. Как минимум зеркало и raid5 - точно. Там нет чексумм в их нормальном понимании. Поэтому если диск не сдох совсем, а начал подвирать в выдаваемых данных - это само по себе обнаружено на уровне RAID не будет. А науке известны самые разные глюки, от "вернул не тот сектор" до "ошибка чтения проскочила через CRC/ECC как правильные данные" или "фирмваре сдурело и вернуло шум океанов марса".
> рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Ваше мямление говорит о том что вы не в курсе как это работает. FAIL.
> того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно
> сказать какая группа блоков содержит актуальные данные,А вы давно смотрели как тот же RAID5 сделан? Там вообще-то данные на дисках + избыточный XOR на n+1 по ширине блоке. Если какой-то диск совсем выпал, путем нехитрой математики восстанавливается что выпавший блок данных (с использованием XOR блока), что сам блок с XOR (с использованием блоков данныз). Вот только для этого надо знать что диск проблемный и игнорировать его, считая его данные отсутствующими. А если диск скажем подвирает в данных - тут уже возможны варианты. Логика работы RAID5 не предусматривает данный случай и полноценный рекавери из него. Даже если мы видим что N блоков != XOR, мы не знаем какой из дисков нам соврал. При этом есть несколько вариантов какими на самом деле были данные. Неверными может быть как каждый из блоков данных, так и XOR-блок. Нет никакого способа узнать какой из вариантов на самом деле был правильный. Если ФС подыграет, отдельно храня чексумму - можно опробовать все варианты и понять какой из них ведет к корректной чексумме. Но это требует хранения какой-то относительно компактной и надежной чексуммы где-то сбоку, это не про простые блочные RAID.
> кроме того восстановить недостающие/повреждённые блоки информации.
Недостающие - может. А вот с повреждениями - см. выше.
> А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер
А это зачем? У БД обычно есть своя журнальная логика, сделанная под вполне конкретные допущения. Снапшотить сие - затея странная. А вы вообще понимаете что будет с базой после отката снапшота, для начала? База уже сказала клиентам в рамках транзакционной модели "вот это записано!". Пришел кулсисоп. Откатил снапшот. Записи испарились. Но клиенту то сказали что все записано. Хорошая идея. Был у меня миллион на счете. Я его снял. А тут база забывает что я транзакцию сделал. Очень удобно: у меня снова миллион на счете. Как вы думаете, сколько вам вазелина потребуется? :)
> А что касается сказочников из оракла - дооо, конечно работает!
Пока-что я детектировал тут другого сказочника, который снапшотит базы данных и восстанавливает во всех случаях данные глупными блочными RAIDами.
> данных на продакшне - это какбэ фигня, никто не заметит же,
Так сабж как раз об этом.
> особенно под хорошим грузом.
Кэп намекает что сабж как раз для того и затеян. И да, ваши репорты давностью в квартал с вашим стабилизцом имеют околонулевую ценность когда вопрос о WIP. Если с того момента вышло 3-4 новых ядра - результаты тестирования на мегастабильном ядре (с бажным кодом btrfs) - вообще ни о чем.
>> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS -
>> это вроде как клон zFS,
> По возможностям - да. Более того - догнать и перегнать. Что они,
> кстати, уже успешно делают. Например в btrfs можно местами отключить CoW,
> если он мешается. А базам данных он как раз мешается. Ибо
> не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая
> к повторной работе на нескольких уровнях, это сажает производительность. Работа сдиванный аналитег не имеет идей что с этим делать, статью на хабарахабар никто не написал по этой "проблеме"? подсказка: те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать, cow им не мешает при этом.
> снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало
> ZFS даже когда пешком под стол ходило, управление кешом - интегрировано
> с ядром, а не как в ZFS."не как в zfs под линукс" имелось ввиду, я надеюсь? а где там, кстати, бенчи были, где оно обижало zfs ?
>> Здесь нет наполеоновских планов, но набор фич заявлен серьёзный
> Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти
> все прямо сразу, сугубо за счет принципа работы. Было бы сранно
> их НЕ заявлять при этом.
>> и основной функционал _уже_ реализован, так что автор фс реально смотрит
>> на вещи, в отличии от сказочников из оракла.
> У сказочников из оракла уже работает большинство из фич, которые в tux3
> даже не рискуют заявлять.
> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать,Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил здравый смысл.
> cow им не мешает при этом.
Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов такая мелочь не пугает.
> "не как в zfs под линукс" имелось ввиду, я надеюсь?
И под Linux, и под бзду. ARC везде одинаково не интегрирован с ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там конечно адаптируется, но если он сможет жрать большую часть памяти - программам попросившим большой блок памяти будет отлуп. А оно такое надо? Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным уже не айс.
> а где там, кстати, бенчи были, где оно обижало zfs ?
Да в куче мест. И на форониксе, и на еще куче ресурсов. Обижало оно даже в лохматом 2010 году, или когда там. С тех пор в btrfs впилили немеряно оптимизаций, если что.
>> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать,
> Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил
> здравый смысл.а где ты здесь фанатизм узрел? удобная в управлении fs. ей пользуются.
>> cow им не мешает при этом.
> Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов
> такая мелочь не пугает."настоящие фанаты" знают как приготовить это дело так, чтобы не было "работа разможится". на хабарахабаре не пишут что нужно сделать? ну.. попробуй почитать оф. док-цию, например.
>> "не как в zfs под линукс" имелось ввиду, я надеюсь?
> И под Linux, и под бзду. ARC везде одинаково не интегрирован с
> ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там
> конечно адаптируется, но если он сможет жрать большую часть памяти -
> программам попросившим большой блок памяти будет отлуп. А оно такое надо?на википердии прочел? я вот своими глазами видел как мускл отожрал 70+гб памяти, до этого ее ела zfs. "под бзду", да.
> Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным
> уже не айс.
>> а где там, кстати, бенчи были, где оно обижало zfs ?
> Да в куче мест. И на форониксе, и на еще куче ресурсов.
> Обижало оно даже в лохматом 2010 году, или когда там. С
> тех пор в btrfs впилили немеряно оптимизаций, если что.авторитетнее тестов похороникса, пожалуй, может быть только твое мнение. xD
> Работа с снапшотами гибче,Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в ssh, который отресивить на другой машине и развернуть на другой BtrFS?
> экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило,
И где же это оно его там обижало?
> управление кешом - интегрировано с ядром, а не как в ZFS.
Вы про какой кэш?
Если про блочный -- то ШОА?!
Если про ARC -- так это так и задумано.
Конечно - https://btrfs.wiki.kernel.org/index.php/Main_Page#Features
> Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в
> ssh, который отресивить на другой машине и развернуть на другой BtrFS?Если вы про send и receive - их в btrfs таки сделали. Такие вот чудеса науки.
> И где же это оно его там обижало?Да даже на форониксе, как и в любых иных бенчах. Еще в 2010 году аж. А с тех пор нехило подтянули.
> Если про ARC -- так это так и задумано.
Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы с выдачей памяти - это так и задумано! Но устроит только файлсервер, где никаких программ нет. А в остальных местах обломы выделения памяти при попытке попросить блок пожирнее - как-то совсем не прикольно. Не хочу ничего сказать, но я бы не хотел видеть такую логику поведения на десктопе или сервере приложений.
> Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы
> с выдачей памяти - это так и задумано! Но устроит только
> файлсервер, где никаких программ нет. А в остальных местах обломы выделения
> памяти при попытке попросить блок пожирнее - как-то совсем не прикольно.
> Не хочу ничего сказать, но я бы не хотел видеть такую
> логику поведения на десктопе или сервере приложений.вот скажи, зачем ты свои влажные мечты изливаешь тут?
кратко: ты написал не правду.
Снапшетов в линуксе недождаться никогда?
> Снапшетов в линуксе недождаться никогда?LVM? не? не читали доки?
>> Снапшетов в линуксе недождаться никогда?
> LVM? не? не читали доки?Там не снапшоты, а жалкое их подобие. Нормальные снапшоты в Линуксе есть только в Btrfs.
Есть ещё nilfs2 (на меня не очень хорошее произведение произвела, но может руки кривые), была next3 (но уже похоже померла, под новые ядра модулей уже похоже нет, вроде как планировалась next4, но что-то не видать её), zfs.
Единственная нормальная ФС из них - ZFS, но там такой мудрёж со снапшотами и клонами, мне не понравилось.
?!?!?
То есть ты абсолютный дeбил? Ибо проще и логичнее ZFS-ных снапшотов я не видел. Если таковые имеются - имя в студию.
> не видел. Если таковые имеются - имя в студию.В btrfs? Там с снапшотами можно делать больше, а кривых ограничений на работу с ними - меньше :)
> Снапшетов в линуксе недождаться никогда?русская языка ты говорить мала-мала?