Крис Мэйсон, выступивший на мероприятии SCALE 10x LA, подтвердил (http://www.phoronix.com/scan.php?page=news_item&px=MTA0ODU), что компания Oracle планирует использовать файловую систему Btrfs в своем дистрибутиве Linux, в том числе и для промышленной эксплуатации. Упоминается что Btrfs будет официально поддерживаемой опцией при установке в новой версии Oracle Linux, однако файловой системой по умолчанию в новом выпуске вероятно останется Ext4.Крис также отметил что на 14 февраля намечен крайний срок выпуска программы btrfs.fsck, способной исправлять ошибки на Btrfs-разделах. Дата выбрана для возможности интеграции утилиты btrfs.fsck в следующие версии дистрибутивов Oracle и SLES, у которых скоро истекает время приёма новшеств для будущего выпуска.
<center><iframe width="420" height="315" src="http://www.youtube.com/embed/hxWuaozpe2I?rel=0" frameborder="0" allowfullscreen></iframe></center>
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA0ODU
Новость: http://www.opennet.me/opennews/art.shtml?num=32974
> Крис также отметил что на 14 февраля намечен крайний срок выпуска программы btrfs.fsck, способной исправлять ошибки на Btrfs-разделах.Вроде ж это автоматом делается при монтировании?
Не умеет еще исправлять ошибки.
Пока что только может их находить.
По словам разработчиков, сейчас некоторые ошибки испоравляются молча и налету.
Как-то не нравится лично мне молчаливое исправление неведомо каких ошибок. Не UNIX-way это. А потом сюрприз при открытии важного файла - чексуммы не бьются и кирдык, да? Спасибо, нет пути.
Да исправление ошибок вообще не юниксвейно. Их надо делать, а не исправлять.
Если их исправлять - придет Патрик и покарает (ничуть не бредовее вашего "чексуммы не бьются").
> Как-то не нравится лично мне молчаливое исправление неведомо каких ошибок. Не UNIX-way
> это. А потом сюрприз при открытии важного файла - чексуммы не
> бьются и кирдык, да? Спасибо, нет пути.Мне кажется, с вашим уровнем знаний о работе файловых систем ("чексуммы не бьются и кирдык") несколько самонадеянно рассуждать о целесообразности решений и сущности unix-way в данной области.
Позвольте поинтересоваться, вы еще и "поттероподелия" в том же стиле критикуете?
Делается что? Запуск fsck которого нет? :))При монтировании журналирующая файловая система анализирует корректность шатдауна и если ее срубили абы как, без корректного слива буферов и прочая, так что данные и метаданные на диске могут быть несинхронны, файловая система должна что-то предпринять для восстановления их синхронности, так что метаданные описывают то что по факту есть, а не то что должно бы было бы быть, но вот как оказалось - не судьба. Обычная журналирующая ФС при этом обычно реплеит журнал, просматривая записи в нем и проверяя что на диске из этого по факту есть, приводя в соответствие данные и метаданные, так что то что описано метаданными начинает соответствовать тому что реально есть на диске. В случае btrfs рекавери в этом случае как я понимаю сводится к простому откату на последний автоматический снапшот (делается раз в 30 секунд). Это простая стандартная логика рекавери при монтировании. Она рассчитана на просто быстрое восстановление после вещей типа внезапного слета питания прямо в середине записи на диск.
fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись что они действительно не противоречивы и по мере возможности пофиксив то что сломано и хоть как-то поддается починке (некоторые метаданные избыточны и при их повреждени и отсутствии можно в принципе их перестроить и по другим метаданным, например, или даже отбросить). При монтировании делать полный проход по всем структурам ФС которые есть на томе - не вариант из-за значительного времени потребного на такую операцию на большом диске, для детектирования краха используются более быстрые методы. Подобный подход позволяет fsck восстановить до монтируемого состояния даже довольно порушенный том (например, на котором вылезли бэд-сектора), стандартной логикой рекавери при монтировании такое замечено не будет, а вот потом, когда драйвер ФС напнется на нечитаемый сектор с метаданными - вот тут уже будет невкусно, т.к. драйвер опять же прессуется реальным временем и не может полчаса внутри себя починять весь мыслимый дестрой, попутно забив на запросы к ФС и вместо этого радостно перелопачивая полтома. А вот fsck реальным временем не прессуется, он может себе позволить потарахтеть диском полчаса, если дело совсем дрянь, а отколупать данные охота.
Боюсь, с fsck не все так просто. Если на выходе fsck требуется получить полностью целостную fs(не монтируемую, не просто с целостностью (мета)данных) со всеми ее фичами, то у btrfs есть "небольшие" сложности. Форматы хранения (мета)данных dup, raid1, raid10 в некоторых случаях могут потребовать ЗНАЧИТЕЛЬНОГО времени восстановления целостности, слабо коррелирующего c "может себе позволить потарахтеть диском полчаса".
> Боюсь, с fsck не все так просто. Если на выходе fsck требуется
> получить полностью целостную fs(не монтируемую, не просто с целостностью (мета)данных)
> со всеми ее фичами, то у btrfs есть "небольшие" сложности. Форматы
> хранения (мета)данных dup, raid1, raid10 в некоторых случаях могут потребовать ЗНАЧИТЕЛЬНОГО
> времени восстановления целостности, слабо коррелирующего c "может себе позволить потарахтеть
> диском полчаса".Могут. Правда в случае именно метаданных - в нормальной ситуации они не должны занимать существенный процент тома. В случае данных... хм... в самом плохом случае - да, вероятно. А какая альтернатива предлагается? Слить данные, раздестроить пул и пересобрать его обратно? А это будет проще и быстрее? :)
Сноэпшот - да. Вариант быстрый.>fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись...
На самом деле fsck должен пройтись по основным структурам и по журналу. Зачем бежать по всем(!) структурам если есть журнал? Ну а по всему винту пусть бегает утилита восстановления с элементами ИИ (подвожу к мысли что это должен быть не fsck вовсе).
У btrfs нет журнала.
> У btrfs нет журнала.В каком-то роде оно один сплошной журнал. Поэтому оно может просто и быстро отбросить неудачный хвост до момента последнего снапшота и сделать вид что его вообще не было. Поскольку запись не разрушающая, это ведет к ФС в логически корректном состоянии, где метаданные и данные синхронны и состояние ФС - то что было в момент снапшота. Просто, круто, работает.
Верно, хорошая формулировка.
> Сноэпшот - да. Вариант быстрый.
>>fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись...
> На самом деле fsck должен пройтись по основным структурам и по журналу.
> Зачем бежать по всем(!) структурам если есть журнал? Ну а по
> всему винту пусть бегает утилита восстановления с элементами ИИ (подвожу к
> мысли что это должен быть не fsck вовсе).Журнал в JFS помогает гарантировать целостность в 100% случаев, не?
> Журнал в JFS помогает гарантировать целостность в 100% случаев, не?Во первых в современных ФС обычно журналят только метаданные, поскольку делать абсолютно честные транзакции, вгоняя в журнал еще и данные - в классическом дизайне получается очень медленно: надо записать данные сперва в журнал, обозначив намерения, а потом закоммитить их в основную область, реализовав то что обозначено. Двойная запись и дикая просадка скорости - обеспечены, поэтому обычно идут на компромисс и делают двойную запись только для метаданных. При этом метаданные всегда могут быть быстро приведены в какое либо из валидных состояний, но вот данные моут оказаться в некоем промежуточном состоянии, когда полфайла новые а полфайла старые. Потому что нет сведений о том как довести дело до конца или откатить применительно к данным, раз уж это писалось только для метаданных ФС.
В CoW и похожих по смыслу дизайнах этот момент довольно технично обжулили, превращая файловую систему в один сплошной журнал, сделав запись недеструктивной (вместо перезаписи данных - копирование + дозапись отличий в сторонку). Раз нет основной области фс то и коммитить в нее из журнала ничего не надо, ну а значит и двойной записи данных уже нет, впрочем и метаданных тоже. Удачная транзакция - та которую удалось дописать до конца в журнал. А не удалось - так хвост просто отбрасывается как будто его и небыло :)
Ну и кроме всего прочего - в этой логике нигде не учитывается что будет при вылезании бэда, это все-таки довольно нештатная ситуация. Это не значит что потом не захочется отскрести том от асфальта.
У них День Святого Валентина типа как у нас 1 мая и 7 ноября - дедлайн для рапорта о трудовых свершениях.
в этот день к уложившимся в срок любовь начальства будет платонической, а к неуложившимся - плотской
Внезапно рабский синдром. Вы в интернете - забудьте про начальство (тут только большой брат).
> Внезапно рабский синдром.Ах вот как теперь элита офисного планктона называет "ответственность".
Скорее как у них (а теперь и у нас) к дню выборов. Дедлайн для рапорта о свершениях лучезарной всерегулирующей невидимой руки рынка настояшего свободного общества.
Интересно, никакущую скорость при работе с файлами-контейнерами виртуальных машин починили?Когда-то проводил такой эксперимент - берем готовый файлик CentOS5.img (у меня там была минимальная конфа + настроенный postfix), скармливаем его qemu-kvm и засекаем время запуска.
Так вот, при прочих равных условиях, на ext4 сей образ подымался менее чем за 20 секунд (с учетом того, что 5ая центось достаточно неторопливо грузится). На том же самом разделе, но отформаченном в btrfs, загрузка того же образа занимала около 25 минут(!) и работать с той виртуальной машинкой после загрузки было достаточно сложно (ну ооочень неторопливая :) ).
P.S. Впрочем, справедливости ради хочу сказать, что ноут с какой-то там древней Федорой (14?) настроенный на полное использование btrfs (окромя /boot) просто работал и нужды в fsck в ходе работы не возникло. Правда хитрые фичи типа сжатия и снапшотов там не использовались.
давно использую бтр, а с декабря перебросил на неё всё - 500гб винт на ноуте, сделаны субволумы под рут, хом и тд. да чё говорить? вот:
# btrfs subvolume list /
ID 257 top level 5 path root
ID 259 top level 5 path home
ID 265 top level 5 path u02
ID 270 top level 5 path u01
ID 271 top level 5 path u03
ID 275 top level 5 path portage
ID 276 top level 5 path calculate
ID 277 top level 5 path root_snapshot_2012_01_28
ID 278 top level 5 path home_snapshot_2012_01_28
ID 279 top level 5 path portage_snapshot_2012_01_28
ID 280 top level 5 path calculate_snapshot_2012_01_28
ID 281 top level 5 path u02_snapshot_2012_01_28
субволум u03 полностью отдан под виртуалки - и vb, и kvm. центос (с графикой) грузится ~20c
использую lzo компрессию. но тут трабл - граб нужно ставить из жита, иначе можно использовать только zlib компрессию.
доволен как слон - недавно ставил гном3, не понравился. перегрузился в снепшот - и у меня опять гном2.
с версии ядра 3.2 - рекомендую. не продакшн, но уже точно не альфа. на мой взгляд твёрдый rc4-5.
зыж
посмотрите презентаху в сабже.
там есть реальные примеры использования на примере vb.
А виртуалка в вашем случае одна крутится или много? У меня их до десятка одновременно может быть с одного раздела пущено (куча запросов на чтение/запись в параллель), начиная с центосей всех видов(гигов на десять каждая) и кончая Win2k8 (там уже под сотню гигов образа дисков весить могут).P.S. Впрочем, попробую еще раз, благо, времени это должно занять относительно немного.
>А виртуалка в вашем случае одна крутится или много?много порой.
и виртуалбоксе, и кластер на квм.
>У меня их до десятка одновременно может быть с одного раздела пущеноа какая разница с какого раздела одного диска то?
в бтр понятие разделов вообще если не отменяется, то нивелируется.
там всё - субволумы. и самый главный с субволид=0, и все снепшоты, и собстно субволумы.зыж
>P.S. Впрочем, попробую еще раз, благо, времени это должно занять относительно немного.у меня гента - всё самое последнее, если что.
жду вот ещё ядро 3.3
>а какая разница с какого раздела одного диска то?Ну, разделы далеко не всегда на одном диске живут. ;) Да и в случае даже одного диска есть приличная разница в скорости для раздела в начале диска и для раздела в конце.
>в бтр понятие разделов вообще если не отменяется, то нивелируется.
>там всё - субволумы. и самый главный с субволид=0, и все снепшоты, и собстно субволумы.Спасибо, об этом я в курсе. Но вы упускаете одну важную вещь - все, сказанное вами, справедливо, когда под btrfs отдан диск(или диски) целиком.
А я ведь и извратиться могу (и извращаюсь) - с разделами, LVM, mdraid (или аппаратной его реализацией). И только поверх всего это тонким слоем нанесу btrfs :)>у меня гента - всё самое последнее, если что.
>жду вот ещё ядро 3.3У меня нечто похожее - в качестве хост-машин Fedora 16 (ядро 3.2.x). Там многолетний аптайм не нужен - если что, виртуалки уползают на другой хост, пока я терзаю этот.
P.S. Когда удостоверюсь в достаточной надежности и управляемости btrfs, тогда отдам ей диски массива в полное и безоговорочное пользование без всяких посредников.
> Спасибо, об этом я в курсе. Но вы упускаете одну важную вещь
> - все, сказанное вами, справедливо, когда под btrfs отдан диск(или диски)
> целиком.
> А я ведь и извратиться могу (и извращаюсь) - с разделами, LVM,
> mdraid (или аппаратной его реализацией). И только поверх всего это тонким
> слоем нанесу btrfs :)Хех. И вы еще жалуетесь на низкую производительность?
>Хех. И вы еще жалуетесь на низкую производительность?Ага :)
Только не забывайте, что при прочих равных условиях (стопицот уровней абстракций и LVMов) ext4 работает нормально, а btrfs в том же самом месте при работе именно с образами виртуалок безбожно тормозит (точнее тормозила на время теста).
P.S. Кстати, https://bugzilla.redhat.com/show_bug.cgi?id=689127 до сих пор не закрыт ;) Так что не один я такой отморозок.
> Только не забывайте, что при прочих равных условиях (стопицот уровней абстракций и LVMов) ext4 работает нормальноНапомните, с каких пор в ext4 появился встроенный менеджер и реализация рейда?
> Напомните, с каких пор в ext4 появился встроенный менеджер и реализация рейда?Менеджер томов // selffix
А это здесь причем?Просто диск/mdraid/hardware-raid -> partitions -> LVM -> ext4 или btrfs -> VirtualMachine.img
Еще раз...Я НЕ ругаю btrfs, я лишь говорю, что конкретно в такой-то ситуации (VM на btrfs) наблюдаются тормоза именно по вине btrfs (ext4/xfs там же работают нормально). И наблюдается подобное не у меня одного.
Смотреть, как идет обмен данными со скоростями примерно 80-100 КИЛОбайт/сек меня несколько напрягало. И, ясен пень, пришлось остаться на более примитивной (но на три порядка более быстрой) ext4.
P.S. Уж поверьте, я бы от сжатия, снэпшотов и встроенного управления разделами и настройкой рейда в одном флаконе просто так бы не отказался.
> Еще раз...Я НЕ ругаю btrfs, я лишь говорю, что конкретно в такой-то
> ситуации (VM на btrfs) наблюдаются тормоза именно по вине btrfsСкорее где-то на стыке технологий они плохо друг на друга наложились.
Хм. Касательно ваших проблем с производительностью: точно сказать не могу, но, возможно, виртуальные мишины часто дёргают fsync, а для btrfs это в некотором роде врождённая проблема. С этим борятся, да, но пока иногда оно работает не всегда хорошо.Если вы заинтересованы - то напишите куда-нибудь на #btrfs или в рассылку, но будьте готовы, что вам сразу же предложать собрать последнее ядро из git :)
>Еще раз...Я НЕ ругаю btrfs, я лишь говорю, что конкретно в такой-то ситуации (VM на btrfs) наблюдаются тормоза именно по вине btrfs (ext4/xfs там же работают нормально). И наблюдается подобное не у меня одного.вообще то чем бтр хороша - она использует уже имеющиеся структуры ядра, а не вносит свои (как например zfs). в частности она задействует:
>If Btrfs were to rely on device mapper or MD for mirroringhttps://btrfs.wiki.kernel.org/articles/m/u/l/Multiple_Device...
или по-русски:
>сильная интеграция с Device mapper для поддержки многочисленных устройств с несколькими встроенными алгоритмами для работы с RAIDhttp://ru.wikipedia.org/wiki/Btrfs
так что...
у меня ноут с 500Гб винтом и полностью задействованным бтр. использовать lvm и мета-устройства мне не зачем. нет смысла.
но подозреваю что и с ними проблем не будет.
> у меня ноут с 500Гб винтом и полностью задействованным бтр. использовать lvm и мета-устройства мне не зачем. нет смысла.А я бы md raid поставил только за то, что в нем есть поддержка 5/6 уровней :)
Для btrfs raid5/6 - первоочерёдная вещь на реализацию, сразу после btrfsck.
> Для btrfs raid5/6 - первоочерёдная вещь на реализациюУже года четыре, AFAIK :)
Касательно "хитрых фич типа сжатия и снапшотов", кстати: сжатие влияет на загрузку процессора (но на LZO, на мой взгляд, вообще незначительно), а снапшоты вообще никакого отрицательного влияния не оказывают.
Я просто не понял или это именно так: этот товарищ сказал, что в бтрфс на 7 гигов данных выделяется 1 гиг метаданных :/ Дескать, на его 8-и меговый файл выделился 1 гиг метаданных, и туда, в этот раздел с 1 гигом метаданных, он мог засунуть еще 7 гигов данных. Потом, получается, фс выделит еще 1 гиг метаданных и так далее. Если это именно так, то какой же пустой расход места получается, что для домашних машин с относительно небольшими винтами не особо подходит, лишь для сервачков. Стоит ли расход места на ПК тех плюшек, которые обещает эта фс?
>Я просто не понял или это именно так: этот товарищ сказал, что в бтрфс на 7 гигов данных выделяется 1 гиг метаданных# btrfs filesystem df /
Data: total=215.00GB, used=210.85GB
System, DUP: total=8.00MB, used=32.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=3.50GB, used=2.34GB210.85 данных - 2.34GB метаданных
или вы думаете журнал юзает меньше?!!!
То есть мужичок на видео врет на счет 1 гига метаданных на 7 гигов данных? Или вы не пользуетесь всеми возможностями по снятию снимков, которые показывал он? Откуда расхождения взялись у него и у вас, вот что я спрашиваю. Это не попытка докопаться или подколоть - просто любопытно.
У этой ФС очень велик оверхэд на хранение маленьких объектов. На их большом количестве как раз можно получить такое.
> У этой ФС очень велик оверхэд на хранение маленьких объектов. На их
> большом количестве как раз можно получить такое.Он у любой ФС очень велик. Внезапно.
Кроме рейзера, который хранит их прямо в журнале
> Кроме рейзера, который хранит их прямо в журналеЭто пресловутый tail packing, заметно снижающий скорость и создающий риск факапа то? Не, я понимаю что экономия места - круто. Но не такой же ценой?!?!
> Это пресловутый tail packing, заметно снижающий скорость и создающий риск факапа то?Нет, это пресловутый tail packing, заметно повышающий скорость, снижающий расход места и не отражающийся на надежности.
Btrfs же хранит в журнале маленкие файлы.Оверхед, конечно, есть. Я не считал сколько, но со слов Hugo Mills:
" ... at a minimum of 413 bytes of metadata overhead for an inline file, plus the length of the filename. "
> Btrfs же хранит в журнале маленкие файлы.Извиняюсь, не в журнале, а в метаданных, прямо в дереве FS_TREE.
> Btrfs же хранит в журнале маленкие файлы.
> Оверхед, конечно, есть. Я не считал сколько, но со слов Hugo Mills:
> " ... at a minimum of 413 bytes of metadata overhead for
> an inline file, plus the length of the filename. "Ага, а еще и dup/raidXY, hugo это признает :( Впрочем, смотрите первоисточник - исходники.
По поводу отношения data/metadata - есть у меня фс 30Гб с отношением data/metadata около 0.8.
>У этой ФС очень велик оверхэд на хранение маленьких объектов. На их большом количестве как раз можно получить такое.хм.
могу ещё раз привести мою статистику:
210.85 данных - 2.34GB метаданных
если нужны пояснения - это весь винт под системой, включая /usr, ../lib, ../src (гента всё-таки), плюс коллекция фоток/музыки и тд, и тп
в общем есть масса мелких файлов, а есть и крупные виртуалки - на всё ушло 210.85 гигов.
при этом метаданных - 2.34GB.
и я не считаю это сильно большой жертвой для такой функциональности.
понятно что при каждом создании снепшотов резервируется место, может у него там дофига снепшотов
> понятно что при каждом создании снепшотов резервируется место, может у него там
> дофига снепшотовЭто понятно. Он об этом сам и говорит - каждые 30 с делается снимок.
Я к тому речь веду, что для ПК это черезчур получается. Хотя, видимо, можно будет настроить.
Просто расход места впечатляет :)
> Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.Старые снапшоты подтираются постепенно, поэтому суммарный расход места вполне вменяемый. Ну если конечно не совать эту ФС на флоппики всякие - ну не для дискеток она, а для жестких дисков и даже создания многодисковых хранилищ.
>> Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.
> Старые снапшоты подтираются постепенно, поэтому суммарный расход места вполне вменяемый.
> Ну если конечно не совать эту ФС на флоппики всякие -
> ну не для дискеток она, а для жестких дисков и даже
> создания многодисковых хранилищ.Вы, похоже, не понимаете суть снапшотов. В человеском языке нет понятия снимка снимка снимка :) А ведь есть еще и ридонли снимок этого всего :) Метадата растет немерянно...
> или вы думаете журнал юзает меньше?!!!dumpe2fs /dev/sda4 | grep -m1 'Journal size'
dumpe2fs 1.42 (29-Nov-2011)
Journal size: 128Mdf -h
/dev/sda4 1,8T 1,1T 777G 58% /homeПолучается, что меньше ;)
>> или вы думаете журнал юзает меньше?!!!
> dumpe2fs /dev/sda4 | grep -m1 'Journal size'
> dumpe2fs 1.42 (29-Nov-2011)
> Journal size:
> 128M
> df -h
> /dev/sda4 1,8T
> 1,1T 777G
> 58% /home
> Получается, что меньше ;)Депендс. В журналируемых ФС журнал иногда зависит от темпа дисковых транзакций.
дело то не только в журнале.
вот к примеру сколько у вас на inode ушло тут не отражается как в моём примере.
> Получается, что меньше ;)Ну и насколько сильную погоду тебе сделает 1-2 Гб на 2Тб диске? Это 0.1% емкости. Другие факторы могут дать в дохрена раз больше оверхеда. Хотя для тех кого давит жаба, есть еще и сжатие, если что. При том LZO имеет свойство распаковываться быстрее чем диск читает :)
Есть у меня фс, которая в последний раз использовалась для каких-то тестов с маленькими файлами (кажется, не помню), правда она 10Гб, а не 8.# df -h /dev/sda8
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sda8 9.9G 6.9G 2.2G 76% /mnt/scratch# btrfs fi show /dev/sda8
failed to read /dev/sr0
Label: 'scratch' uuid: 6cfe1a7d-052d-4f18-bd1e-38311a29c9ee
Total devices 1 FS bytes used 6.85GB
devid 1 size 9.83GB used 9.46GB path /dev/sda8Btrfs Btrfs v0.19-dirty
# btrfs fi df /mnt/scratch/
Data: total=8.65GB, used=6.84GB
System, DUP: total=32.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=384.00MB, used=13.52MBВыглядит не так плохо. А после балансировки ещё лучше:
# btrfs fi bala /mnt/scratch/
# btrfs fi df /mnt/scratch/
Data: total=7.97GB, used=6.84GB
System, DUP: total=32.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=384.00MB, used=11.73MB
Ну вот, всякие анонимусы по религиозным соображениям критиковавший корпорации как такие жуют шляпу. Именно корпорации, в погоне за расширением и нажывой инициируют создание очень полезных и доступных всем вещей. Даже корпорации "зла" типа Oracle и Microsoft в итоге способствуют развитию OpenSource в большей мере, чем если бы этих корпораций небыло вообще и они не мешали зазвитию OpenSource.
> Ну вот, всякие анонимусы по религиозным соображениям критиковавший корпорации как такие
> жуют шляпу. Именно корпорации, в погоне за расширением и нажывой инициируют
> создание очень полезных и доступных всем вещей. Даже корпорации "зла"Похоже, вы, как и другие пренебрежительно упомянутые вами анонимусы, страдаете черно-белмы восприятием мира. Или вы просто копируете их терминологию?
> Oracle и Microsoft в итоге способствуют развитию OpenSource в большей мере,
> чем если бы этих корпораций небыло вообще и они не мешали
> зазвитию OpenSource.Весьма спорный вопрос. Вмешательство крупной корпорации в опенсорс, как правило имеет как позитивные, так и негативные эффекты. Причем, оценка этих эффектов, в зависимости от рассматриваемой исторической перспективы и предпочтений оценивающего, может меняться на прямо противоположную.
Кстати, а что такого хорошего для опенсорса сделал мелкософт, что бы перевесило его нечестную конкуренцию, гетьзефаксы и патентный троллинг?
Пример 1: http://www.apache.org/foundation/thanks.html
Пример 2: http://foundation.gnome.org/Samba, Mono прямое следсвие необходимости создание альтернатив закрытым аналогам. (сразу предполагая срач на тему нужности, альтернатив скажу, что эти продукты таки есть, они OpenSource они выполняют возложеные на них функции и уже своим существованием на рынке создают конкуренции аналогичным OpenSource решениям, заставляя их более интенсивно рзвиватся). В целом существование закрытых альтернатив от Microsoft потсрекает рынок на создание альтернатив OpenSource. Да и вообже флагманы OpenSource это, как правило детеща корпораций.
Даже Mozilla главным образом пилится на деньги Google.
Именно Oracle главные инициатор создания btrsf.
Еще примеры:
WebKit, главный спонсор Apple (он же в последсвии спонсор KHTML, за счет возврата кода).
FreeBSD спонсор Apple
LLVM спонсор Apple, nVidia
Libreoffice, OpenJDK главный вклад все же сделала тоже корпорация Sun (земля ей пузом :) )Разве что плееры живут главным образом без помощи корпораций, ну там и обем наработок относидельно невелик.
Так благодаря Google, Apple имеем Chromium, а в результате даже такой косвенный продукт как node.js.
Список можно продолжать очень долго.
С яблоком - очень неудачные примеры. Ребята весьма потребительски относятся к опенсорсу, так что на долю пользователей и независимых разработчиков хорошего перепадает мало.Насчет хорошего от мелкософта - пример тем более неубедителен. Скорее даже, убедителен в обратную сторону: спонсируется самое известное опенсорсное кладбище проектов.
Похоже, вы вдолбили себе в голову, что корпорации есть Абсолютное Добро, и ничего кроме добра от них опенсорсу никогда не было. Опять же черно-белый взгляд на мир, просто еще один вариант. Скучно...
>что корпорации есть Абсолютное ДоброНу это ваше черно белое восприятие меня.
Какое вообще может быть добро зло в впоросах программного обеспечения. Это инструмент, по выполнению полезной деятельности в реальном мире, а не самоцель. Так можно убивать африканских детей ракетами, на которых используется Linux, при этом отослав полезные патчи соответствующих разработок Линусу :)
>С яблоком - очень неудачные примеры. Ребята весьма потребительски относятся к опенсорсу,Посмеялся :) Тут речь шла о разработке как такой. А WebKit достаточно крупный проект, как, тот же LLVM. Не говоря уже об OpenDarwin. А Вы тут чешите, о каком то потребительском отношении к опенсоурс. OpenSource как раз и открывается, чтобы его без проблем использовали, а не зажимали и не давали не кому пользоватся (почитайте открытые лицензии там все достаточно четко написано, нет пунктов как правило о потребительском отношении :) ).
>самое известное опенсорсное кладбище проектов
Вы видемо не в курсе о доле HTTP сервера Apache? Ну да ладно проехали (и не дано начинать срач на тему аналогов :) ). Посмотрите, кто такие основные пользователи OpenSource, это совсем не те over 0,5-3% пользователей Linux на Desktop (среди которых большая часть эксперементаров, которые просто любях "играть" в настройку Linux). OpenSource главным образом используется на серверах. И как раз таки такие популярные и добрые проекты типа wikimedia, OpenStreetMap активно используют наработки Apache у себя.
Ну и сами же IBM, Google, Microsoft, Facebook и т.п. активно используют проэкты Apache.
Apache-Apache... Просто этот сервер удачнее IIS. M$ никак не могла догнать apache по популярности... и купить не могла, как обычно они это делают. Поэтому просто стали вкладывать деньги, чтобы он лучше работал на Windows...
Я вам о теплом вы мне о кислом. Да что Вы так Microsoft оравдываете. У Вас что акции Microsoft куплены?Верю вам на слово, они руководствувались исключительно не благими намерениями и вкладчики Microsoft могут спать спокойно: их деньги не идут на благотворительность :)
И дополнение, я же забыл опять об Android. Думаю, спорить не будете что количество пользователей Android приближаетс или уже перевалило за количество пользователей Desktop дистрибутивов Linux. Специфика фундации Apache такая, что они как правило делают библиотеки, а не конечное приложение с красивымы кнопачками. Поэтому, и анонимусы вроде вас после того как купят планшет с ОС андроид, установят себе некоторое количество бесплатных (или платных) программ, даже и не догадаются, что вероятно еще паралельно установити себе около десятка двух разнообразных библиотек проекта Apache.Когда "Вася пупкин" решит сделать супер красивое приложение и ему нужно будет там использовать, например метод статистики, а потом результаты оформить и показать в формате SVG, то он просто возьмет и прикрутит к своему приложению математическую библиотеки Apache и библиотеку Apache по работе с SVG. А потом, ему захочется прирутить экспорт/импорт в/из xml, ods. И опять таки он возьмет библиотеки Apache. Захочет он реализовать, сетевую функцию с запросом на wikipedia, опять таки прикрутит проект Apache, таким образом сосредоточется на том, что бы реалезувать именно свою идею и красиво это оформить, чтобы радовать конечного пользователя кнопочками. :)
>Кстати, а что такого хорошего для опенсорса сделал мелкософт, что бы перевесило его нечестную конкуренцию, гетьзефаксы и патентный троллинг?Кстати это как правило касается опять таки не OpenSource как такого, а конкуренции между компаниями. Ну подорожали, например устройства на базе Android из-за действий Microsoft, само же развитие Android не остановилось, наоборот, это теперь открытый проект, теперь, Microsoft косвенно заинтересованна в его развитии, может даже больше чем Google. Конкретно конечный пользователь у себя в KDE/Gnome разве не имеет какой-то функции из-за активности, например, Microsoft? Более того, в такой жестокой борьбе многим приходится открывать код программных продуктов.
> жуют шляпу. Именно корпорации, в погоне за расширением и нажывой инициируют
> создание очень полезных и доступных всем вещей.Из всей огромной корпорации вJOBывал аж целый один вполне Крис Мэйсон, между прочим, поэтому орать о заслугах "оракла вообще" - прикольно, конечно, да :). А так - да, линуховый процесс разработки позволяет корпорациям участвовать в процессе наравне с всеми остальными. Не вижу в каком месте это плохо. Корпорации присоединились к процессу и стали вполне естественной частью оного.
> "зла" типа Oracle и Microsoft в итоге способствуют развитию OpenSource в большей мере,
Спорный вопрос. Вторые довольно сильно пытаются гадить подпольными методами. А ораклу, простите, всякие опенофисы - в общем то непрофильный актив и что там с ними будет им пофигу. А операционка для них - не основной бизнес как для некоторых, а всего лишь подстилка под их БД.
Блин, и ещё раз - блин!
Лучше бы ZFS под GPL перелицензировали!!!
> Лучше бы ZFS под GPL перелицензировали!!!Кому лучше то? И почему? Бтр - более новый дизайн. Ряд тупняков зфс-а в нем устранили. Эти упыри даже аллокатор блочный там оставили, по сути. Хоть и с блоками переменного размера, но мелкими, блин. Накукуй тебе еще одно блочное тормозилово? Ща 2012 год, наверное можно уже освоить экстенты в нормальном виде, да?!
>> Лучше бы ZFS под GPL перелицензировали!!!
> Кому лучше то? И почему? Бтр - более новый дизайн...Мне лучше.
ZFS работает. BTRFS _будет_ работать.
> Мне лучше.
> ZFS работает. BTRFS _будет_ работать.ZFS прекрасно работает по Linux, уже больше полугода как добавили полноценную работу с файловой системой (ZPL) http://zfsonlinux.org
Другое дело, что это никому, кроме разработчиков проекта, не интересно.
>> Мне лучше.
>> ZFS работает. BTRFS _будет_ работать.
> ZFS прекрасно работает по Linux... http://zfsonlinux.org
> Другое дело, что это никому, кроме разработчиков проекта, не интересно.во-первых, не особенно "прекрасно", а во-вторых - интересно многим, только интересующиеся всё больше как-то сами... мучаются...
> во-первых, не особенно "прекрасно", а во-вторых - интересно многим, только интересующиеся
> всё больше как-то сами... мучаются...Наверное секрет в том что дизайн zfs весьма задрючен и довольно странен местами. Плюс лицензия специально выбрана недружественной, что ставит крест на шансы стать майнстримом в майнлайне. А переписать с нуля такое монстило - долго, и если уж так долбаться то не понятно зачем принимать неоднозначные решения еще раз, если можно учесть опыт предшественников и сделать лучше. Btrfs как раз и является чем-то типа этого. При его создании посмотрели на сильные и слабые места уже существующих ФС (включая zfs) и попробовали избавиться от недостатков и выдернуть преимущества. ИМХО вполне годно получилось.
> Мне лучше.Так идите и переписывайте. Или вы думаете что то что надо ВАМ будет делать кто-то еще?
> ZFS работает.
Ну если она у вас работает - пользуйтесь. В чем проблемы?
> BTRFS _будет_ работать.
Да она вообще-то уже вполне прилично работает, если что. Вон там кто-то правильно написал - примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как минимум при типовых операциях - "доктор Ватсон не заметил явных проблем". Так что шли б вы уже погулять. Если вы надеетесь указывать толпе людей что им надо делать - они вам тоже что-нибудь укажут. Не очень приличными жестами.
>Так идите и переписывайте. Или вы думаете что то что надо ВАМ будет делать кто-то еще?так я и так...
>...примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как минимум при типовых операциях...А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...
Багрепорт отправил...
>...указывать толпе людей что им надо делать..."Да ни боже мой!!!" С чего бы это?... Моё личное мнение не считаю обязательно верным для кого бы то ни было...
> так я и так...Ну и здорово. Если здоровья хватает и цель нужна - way to go. Правда если честно я не думаю что это начинание имеет большие перспективы.
>>...примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как
>>минимум при типовых операциях...
> А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...Не замечал такого. Это под каким-то специфичным workload? И в каком ядре/конфиге? Такое по любому отлавливать надо. Тем не менее, я не думаю что порт zfs вышел бы принципиально беспроблемным. Вы список рассылки nginx почитайте например - увидите пачку бсдшников зазря канифолящих мозг окружающим. А то у них вон то sendfile() криво работал, то система виснет, то еще какие-то приколы ;). Как вы понимаете, такой большой пепелац еще и отладить надо. И если честно - я думаю что в весьма обозримом будущем качество btrfs обгонит качество порта zfs в фряхе. Попробуйте с 3 раз догадаться почему.
> Багрепорт отправил...Ну и на том спасибо. Надо б посмотреть подетальнее под
> "Да ни боже мой!!!" С чего бы это?... Моё личное мнение не
> считаю обязательно верным для кого бы то ни было...Упс, тогда сорри, я что-то излишне позлословил в ваш адрес.
>А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...вот как раз iowait в бтр у меня на порядок ниже стал, чем в ext4.
что характерно, скорость копирования некоторые проги показывают почти в 2 раза бульше, чем раньше.
и меня это слегка напрягает - ну не может этого быть!
> Блин, и ещё раз - блин!
> Лучше бы ZFS под GPL перелицензировали!!!ZFS нынче полезна главным образом в плане выжимания денег со старых клиентов санок.
Судя по всему, оракл не собирается ее развивать, в отличие от. Видимо, преимущества дизайна btrfs все-таки значительны.
> ZFS нынче полезна главным образом в плане выжимания денег со старых клиентов
> санок.
> Судя по всему, оракл не собирается ее развивать, в отличие от.Продавальщики хреновы...
Как собака на сене - ни сам не гам, ни другому не дам...
> Как собака на сене - ни сам не гам, ни другому не дам...Ну так за санки уплачено же. А так - ну вон бсдунам ее вывалили. Правда все на что их хватает - кой-как интегрять хяляву в свое ядро.
Думаю что мы сейчас увидим как пингвин опять обойдет кой-кого на повороте, невзирая на крупную фору. Как обычно...
> Судя по всему, оракл не собирается ее развивать, в отличие от. Видимо,
> преимущества дизайна btrfs все-таки значительны.Судя по всему она для оракловой базы (а чего еще оракла волнует?) ну совсем никак не конкурент бтр-у. Вообще, я не вижу причин ожидать сногсшибательных результатов от блочного аллокатора как у некоторых.
>Судя по всему она для оракловой базы (а чего еще оракла волнует?) ну совсем никак не конкурент бтр-у.да кстати. в презентахе сабжа "докладчик" несколько раз о проводимых тестах tpc упоминал.
что какбэ интересно с точки зрения фс и методик её тестирования.
Сдох в ноуте ssd от kingston на 64 ГБ, работавший больше года под btrfs. Внезапно, после ребута вместо бута - ругательства на невозможность монтирования корня. Один раздел на весь диск, два сабволюма: корень и хомяк. Хомяк зашифрован. Прогрузившись с запасного девайса, посмотрел - раздел монтируется, файловая система читается, шифрованные файлы доступны. На винт переустановил ось, стал думать как лучше всего перетянуть файлы. Поскольку юзернейм и пароль в новой системе совпадают со старой, решил тупо заменить файлы .Private и всё такое, загрузившись с LiveCD. SSD пришлось снова вставить в ноут, ибо usb шнурок отказывался его монтировать из-за i/o errors, а напрямую в sata контроллёр ноута оно монтировалось несмотря на. Однако, ноут что-то не захотел грузиться с болванки - мигал капслоком, пока я не изымал болванку из привода. Тут же внезапно обнаружилось, что ноут смог как ни в чём ни бывало загрузиться с ssd в мою старую систему. Просто слил файлы хомяка на винт. В процессе было ругательство на невозможность прочесть какой-то файл - сказал ему игнорировать такие ошибки.
Вывод: btrfs действительно хорошая, надёжная система, которую не так просто развалить в бытовом применении даже не смотря на отсутствие полноценного fschk.