The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Компания Oracle намерена использовать Btrfs в дистрибутиве Oracle Linux

02.02.2012 19:23

Крис Мэйсон, выступивший на мероприятии SCALE 10x LA, подтвердил, что компания Oracle планирует использовать файловую систему Btrfs в своем дистрибутиве Linux, в том числе и для промышленной эксплуатации. Упоминается что Btrfs будет официально поддерживаемой опцией при установке в новой версии Oracle Linux, однако файловой системой по умолчанию в новом выпуске вероятно останется Ext4.

Крис также отметил что на 14 февраля намечен крайний срок выпуска программы btrfs.fsck, способной исправлять ошибки на Btrfs-разделах. Дата выбрана для возможности интеграции утилиты btrfs.fsck в следующие версии дистрибутивов Oracle и SLES, у которых скоро истекает время приёма новшеств для будущего выпуска.



  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
  2. OpenNews: Релиз промышленного дистрибутива Oracle Linux 6.2
  3. OpenNews: Oracle портирует под Linux системы DTrace и Zones
  4. OpenNews: Oracle поглотил компанию Ksplice, развивающую технологию обновления Linux-ядра без перезагрузки
  5. OpenNews: Для Fedora 17 одобрен перенос компонентов из корня в /usr и переход на Btrfs
  6. OpenNews: Особенности Linux-ядра, созданного для дистрибутива компании Oracle
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/32974-oracle
Ключевые слова: oracle, linux, btrfs
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 20:55, 02/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Крис также отметил что на 14 февраля намечен крайний срок выпуска программы btrfs.fsck, способной исправлять ошибки на Btrfs-разделах.

    Вроде ж это автоматом делается при монтировании?

     
     
  • 2.2, Аноним (-), 21:04, 02/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не умеет еще исправлять ошибки.
    Пока что только может их находить.
     
     
  • 3.13, fyjybvec (?), 00:53, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По словам разработчиков, сейчас некоторые ошибки испоравляются молча и налету.
     
     
  • 4.30, Аноним (-), 13:52, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как-то не нравится лично мне молчаливое исправление неведомо каких ошибок. Не UNIX-way это. А потом сюрприз при открытии важного файла - чексуммы не бьются и кирдык, да? Спасибо, нет пути.
     
     
  • 5.34, Аноним (-), 13:57, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да исправление ошибок вообще не юниксвейно. Их надо делать, а не исправлять.
    Если их исправлять - придет Патрик и покарает (ничуть не бредовее вашего "чексуммы не бьются").
     
  • 5.40, Аноним (-), 14:43, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Как-то не нравится лично мне молчаливое исправление неведомо каких ошибок. Не UNIX-way
    > это. А потом сюрприз при открытии важного файла - чексуммы не
    > бьются и кирдык, да? Спасибо, нет пути.

    Мне кажется, с вашим уровнем знаний о работе файловых систем ("чексуммы не бьются и кирдык") несколько самонадеянно рассуждать о целесообразности решений и сущности unix-way в данной области.
    Позвольте поинтересоваться, вы еще и "поттероподелия" в том же стиле критикуете?

     
  • 2.3, Аноним (-), 21:14, 02/02/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Делается что Запуск fsck которого нет При монтировании журналирующая файло... большой текст свёрнут, показать
     
     
  • 3.14, Bx (ok), 01:15, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Боюсь, с fsck не все так просто. Если на выходе fsck требуется получить полностью целостную fs(не монтируемую, не просто с целостностью (мета)данных) со всеми ее фичами, то у btrfs есть "небольшие" сложности. Форматы хранения (мета)данных dup, raid1, raid10 в некоторых случаях могут потребовать ЗНАЧИТЕЛЬНОГО времени восстановления целостности, слабо коррелирующего c "может себе позволить потарахтеть диском полчаса".
     
     
  • 4.16, Аноним (-), 03:07, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Боюсь, с fsck не все так просто. Если на выходе fsck требуется
    > получить полностью целостную fs(не монтируемую, не просто с целостностью (мета)данных)
    > со всеми ее фичами, то у btrfs есть "небольшие" сложности. Форматы
    > хранения (мета)данных dup, raid1, raid10 в некоторых случаях могут потребовать ЗНАЧИТЕЛЬНОГО
    > времени восстановления целостности, слабо коррелирующего c "может себе позволить потарахтеть
    > диском полчаса".

    Могут. Правда в случае именно метаданных - в нормальной ситуации они не должны занимать существенный процент тома. В случае данных... хм... в самом плохом случае - да, вероятно. А какая альтернатива предлагается? Слить данные, раздестроить пул и пересобрать его обратно? А это будет проще и быстрее? :)

     
  • 3.17, Аноним (-), 04:52, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Сноэпшот - да. Вариант быстрый.

    >fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись...

    На самом деле fsck должен пройтись по основным структурам и по журналу. Зачем бежать по всем(!) структурам если есть журнал? Ну а по всему винту пусть бегает утилита восстановления с элементами ИИ (подвожу к мысли что это должен быть не fsck вовсе).

     
     
  • 4.19, fyjybvec (?), 05:42, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У btrfs нет журнала.
     
     
  • 5.45, Аноним (-), 17:43, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > У btrfs нет журнала.

    В каком-то роде оно один сплошной журнал. Поэтому оно может просто и быстро отбросить неудачный хвост до момента последнего снапшота и сделать вид что его вообще не было. Поскольку запись не разрушающая, это ведет к ФС в логически корректном состоянии, где метаданные и данные синхронны и состояние ФС - то что было в момент снапшота. Просто, круто, работает.

     
     
  • 6.76, fyjybvec (?), 02:24, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Верно, хорошая формулировка.
     
  • 4.32, Аноним (-), 13:53, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Сноэпшот - да. Вариант быстрый.
    >>fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись...
    > На самом деле fsck должен пройтись по основным структурам и по журналу.
    > Зачем бежать по всем(!) структурам если есть журнал? Ну а по
    > всему винту пусть бегает утилита восстановления с элементами ИИ (подвожу к
    > мысли что это должен быть не fsck вовсе).

    Журнал в JFS помогает гарантировать целостность в 100% случаев, не?

     
     
  • 5.46, Аноним (-), 17:53, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Во первых в современных ФС обычно журналят только метаданные, поскольку делать а... большой текст свёрнут, показать
     

  • 1.11, YetAnotherOnanym (?), 23:08, 02/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У них День Святого Валентина типа как у нас 1 мая и 7 ноября - дедлайн для рапорта о трудовых свершениях.
     
     
  • 2.12, me (??), 00:38, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в этот день к уложившимся в срок любовь начальства будет платонической, а к неуложившимся - плотской
     
     
  • 3.18, Аноним (-), 04:54, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Внезапно рабский синдром. Вы в интернете - забудьте про начальство (тут только большой брат).
     
     
  • 4.39, Аноним (-), 14:40, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Внезапно рабский синдром.

    Ах вот как теперь элита офисного планктона называет "ответственность".

     
  • 2.15, anonymous (??), 01:24, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее как у них (а теперь и у нас) к дню выборов. Дедлайн для рапорта о свершениях лучезарной всерегулирующей невидимой руки рынка настояшего свободного общества.
     

  • 1.21, dalco (ok), 08:38, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, никакущую скорость при работе с файлами-контейнерами виртуальных машин починили?

    Когда-то проводил такой эксперимент - берем готовый файлик CentOS5.img (у меня там была минимальная конфа + настроенный postfix), скармливаем его qemu-kvm и засекаем время запуска.

    Так вот, при прочих равных условиях, на ext4 сей образ подымался менее чем за 20 секунд (с учетом того, что 5ая центось достаточно неторопливо грузится). На том же самом разделе, но отформаченном в btrfs, загрузка того же образа занимала около 25 минут(!) и работать с той виртуальной машинкой после загрузки было достаточно сложно (ну ооочень неторопливая :) ).

    P.S. Впрочем, справедливости ради хочу сказать, что ноут с какой-то там древней Федорой (14?) настроенный на полное использование btrfs (окромя /boot) просто работал и нужды в fsck в ходе работы не возникло. Правда хитрые фичи типа сжатия и снапшотов там не использовались.

     
     
  • 2.22, ананим (?), 11:54, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    давно использую бтр, а с декабря перебросил на неё всё - 500гб винт на ноуте, сд... большой текст свёрнут, показать
     
     
  • 3.23, dalco (ok), 12:22, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А виртуалка в вашем случае одна крутится или много? У меня их до десятка одновременно может быть с одного раздела пущено (куча запросов на чтение/запись в параллель), начиная с центосей всех видов(гигов на десять каждая) и кончая Win2k8 (там уже под сотню гигов образа дисков весить могут).

    P.S. Впрочем, попробую еще раз, благо, времени это должно занять относительно немного.

     
     
  • 4.25, ананим (?), 12:46, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >А виртуалка в вашем случае одна крутится или много?

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

    а какая разница с какого раздела одного диска то?
    в бтр понятие разделов вообще если не отменяется, то нивелируется.
    там всё - субволумы. и самый главный с субволид=0, и все снепшоты, и собстно субволумы.

    зыж
    >P.S. Впрочем, попробую еще раз, благо, времени это должно занять относительно немного.

    у меня гента - всё самое последнее, если что.
    жду вот ещё ядро 3.3

     
     
  • 5.38, dalco (ok), 14:32, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, разделы далеко не всегда на одном диске живут Да и в случае даже одного ... большой текст свёрнут, показать
     
     
  • 6.42, Аноним (-), 14:49, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Спасибо, об этом я в курсе. Но вы упускаете одну важную вещь
    > - все, сказанное вами, справедливо, когда под btrfs отдан диск(или диски)
    > целиком.
    > А я ведь и извратиться могу (и извращаюсь) - с разделами, LVM,
    > mdraid (или аппаратной его реализацией). И только поверх всего это тонким
    > слоем нанесу btrfs :)

    Хех. И вы еще жалуетесь на низкую производительность?

     
     
  • 7.43, dalco (ok), 14:59, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Хех. И вы еще жалуетесь на низкую производительность?

    Ага :)

    Только не забывайте, что при прочих равных условиях (стопицот уровней абстракций и LVMов) ext4 работает нормально, а btrfs в том же самом месте при работе именно с образами виртуалок безбожно тормозит (точнее тормозила на время теста).

    P.S. Кстати, https://bugzilla.redhat.com/show_bug.cgi?id=689127 до сих пор не закрыт ;) Так что не один я такой отморозок.

     
     
  • 8.53, Аноним (-), 18:33, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Напомните, с каких пор в ext4 появился встроенный менеджер и реализация рейда ... текст свёрнут, показать
     
     
  • 9.54, Аноним (-), 18:34, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Менеджер томов selffix... текст свёрнут, показать
     
  • 9.60, dalco (ok), 19:12, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А это здесь причем Просто диск mdraid hardware-raid - partitions - LVM - ext... текст свёрнут, показать
     
     
  • 10.72, Аноним (-), 21:23, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее где-то на стыке технологий они плохо друг на друга наложились ... текст свёрнут, показать
     
  • 10.78, fyjybvec (?), 02:39, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Хм Касательно ваших проблем с производительностью точно сказать не могу, но, в... текст свёрнут, показать
     
  • 10.85, ананим (?), 13:20, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вообще то чем бтр хороша - она использует уже имеющиеся структуры ядра, а не вно... большой текст свёрнут, показать
     
     
  • 11.86, Аноним (-), 16:58, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А я бы md raid поставил только за то, что в нем есть поддержка 5 6 уровней ... текст свёрнут, показать
     
     
  • 12.88, fyjybvec (?), 20:06, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Для btrfs raid5 6 - первоочерёдная вещь на реализацию, сразу после btrfsck ... текст свёрнут, показать
     
     
  • 13.90, Аноним (-), 03:53, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уже года четыре, AFAIK ... текст свёрнут, показать
     
  • 2.77, fyjybvec (?), 02:31, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Касательно "хитрых фич типа сжатия и снапшотов", кстати: сжатие влияет на загрузку процессора (но на LZO, на мой взгляд, вообще незначительно), а снапшоты вообще никакого отрицательного влияния не оказывают.
     

  • 1.24, Аноним (-), 12:25, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я просто не понял или это именно так: этот товарищ сказал, что в бтрфс на 7 гигов данных выделяется 1 гиг метаданных :/ Дескать, на его 8-и меговый файл выделился 1 гиг метаданных, и туда, в этот раздел с 1 гигом метаданных, он мог засунуть еще 7 гигов данных. Потом, получается, фс выделит еще 1 гиг метаданных и так далее. Если это именно так, то какой же пустой расход места получается, что для домашних машин с относительно небольшими винтами не особо подходит, лишь для сервачков. Стоит ли расход места на ПК тех плюшек, которые обещает эта фс?
     
     
  • 2.26, ананим (?), 12:50, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Я просто не понял или это именно так: этот товарищ сказал, что в бтрфс на 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.34GB

    210.85 данных - 2.34GB метаданных
    или вы думаете журнал юзает меньше?!!!

     
     
  • 3.27, Аноним (-), 13:08, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    То есть мужичок на видео врет на счет 1 гига метаданных на 7 гигов данных? Или вы не пользуетесь всеми возможностями по снятию снимков, которые показывал он? Откуда расхождения взялись у него и у вас, вот что я спрашиваю. Это не попытка докопаться или подколоть - просто любопытно.
     
     
  • 4.28, ы (?), 13:39, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У этой ФС очень велик оверхэд на хранение маленьких объектов. На их большом количестве как раз можно получить такое.
     
     
  • 5.35, Аноним (-), 13:59, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > У этой ФС очень велик оверхэд на хранение маленьких объектов. На их
    > большом количестве как раз можно получить такое.

    Он у любой ФС очень велик. Внезапно.

     
     
  • 6.51, Иван Лох (?), 18:11, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Кроме рейзера, который хранит их прямо в журнале
     
     
  • 7.73, Аноним (-), 21:24, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Кроме рейзера, который хранит их прямо в журнале

    Это пресловутый tail packing, заметно снижающий скорость и создающий риск факапа то? Не, я понимаю что экономия места - круто. Но не такой же ценой?!?!

     
     
  • 8.75, Аноним (-), 01:16, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, это пресловутый tail packing, заметно повышающий скорость, снижающий расход... текст свёрнут, показать
     
  • 7.79, fyjybvec (?), 02:50, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Btrfs же хранит в журнале маленкие файлы.

    Оверхед, конечно, есть. Я не считал сколько, но со слов Hugo Mills:
    " ... at a minimum of 413 bytes of metadata overhead for an inline file, plus the length of the filename. "

     
     
  • 8.89, fyjybvec (?), 20:12, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Извиняюсь, не в журнале, а в метаданных, прямо в дереве FS_TREE ... текст свёрнут, показать
     
  • 8.91, Bx (ok), 20:46, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, а еще и dup raidXY, hugo это признает Впрочем, смотрите первоисточник - ... текст свёрнут, показать
     
  • 5.82, ананим (?), 12:14, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >У этой ФС очень велик оверхэд на хранение маленьких объектов. На их большом количестве как раз можно получить такое.

    хм.
    могу ещё раз привести мою статистику:
    210.85 данных - 2.34GB метаданных
    если нужны пояснения - это весь винт под системой, включая /usr, ../lib, ../src (гента всё-таки), плюс коллекция фоток/музыки и тд, и тп
    в общем есть масса мелких файлов, а есть и крупные виртуалки - на всё ушло 210.85 гигов.
    при этом метаданных - 2.34GB.
    и я не считаю это сильно большой жертвой для такой функциональности.

     
  • 4.29, ander (??), 13:44, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    понятно что при каждом создании снепшотов резервируется место, может у него там дофига снепшотов
     
     
  • 5.33, Аноним (-), 13:54, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > понятно что при каждом создании снепшотов резервируется место, может у него там
    > дофига снепшотов

    Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.  

    Я к тому речь веду, что для ПК это черезчур получается. Хотя, видимо, можно будет настроить.

    Просто расход места впечатляет :)

     
     
  • 6.47, Аноним (-), 18:01, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.

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

     
     
  • 7.92, Bx (ok), 21:03, 05/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.
    > Старые снапшоты подтираются постепенно, поэтому суммарный расход места вполне вменяемый.
    > Ну если конечно не совать эту ФС на флоппики всякие -
    > ну не для дискеток она, а для жестких дисков и даже
    > создания многодисковых хранилищ.

    Вы, похоже, не понимаете суть снапшотов. В человеском языке нет понятия снимка снимка снимка :) А ведь есть еще и ридонли снимок этого всего :) Метадата растет немерянно...

     
  • 3.31, Аноним (-), 13:52, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > или вы думаете журнал юзает меньше?!!!

    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

    Получается, что меньше ;)

     
     
  • 4.36, Аноним (-), 14:00, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> или вы думаете журнал юзает меньше?!!!
    > 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
    > Получается, что меньше ;)

    Депендс. В журналируемых ФС журнал иногда зависит от темпа дисковых транзакций.

     
     
  • 5.81, ананим (?), 12:07, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    дело то не только в журнале.
    вот к примеру сколько у вас на inode ушло тут не отражается как в моём примере.
     
  • 4.48, Аноним (-), 18:04, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Получается, что меньше ;)

    Ну и насколько сильную погоду тебе сделает 1-2 Гб на 2Тб диске? Это 0.1% емкости. Другие факторы могут дать в дохрена раз больше оверхеда. Хотя для тех кого давит жаба, есть еще и сжатие, если что. При том LZO имеет свойство распаковываться быстрее чем диск читает :)

     
  • 2.80, fyjybvec (?), 03:08, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Есть у меня фс, которая в последний раз использовалась для каких-то тестов с маленькими файлами (кажется, не помню), правда она 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/sda8

    Btrfs 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

     

  • 1.37, Аноним (-), 14:25, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну вот, всякие анонимусы по религиозным соображениям критиковавший корпорации как такие жуют шляпу. Именно корпорации, в погоне за расширением и нажывой инициируют создание очень полезных и доступных всем вещей. Даже корпорации "зла" типа Oracle и Microsoft в итоге способствуют развитию OpenSource в большей мере, чем если бы этих корпораций небыло вообще и они не мешали зазвитию  OpenSource.
     
     
  • 2.41, Аноним (-), 14:47, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, вы, как и другие пренебрежительно упомянутые вами анонимусы, страдаете ч... большой текст свёрнут, показать
     
     
  • 3.52, Аноним (-), 18:15, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пример 1 http www apache org foundation thanks html Пример 2 http foundati... большой текст свёрнут, показать
     
     
  • 4.57, Аноним (-), 18:45, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    С яблоком - очень неудачные примеры. Ребята весьма потребительски относятся к опенсорсу, так что на долю пользователей и независимых разработчиков хорошего перепадает мало.

    Насчет хорошего от мелкософта - пример тем более неубедителен. Скорее даже, убедителен в обратную сторону: спонсируется самое известное опенсорсное кладбище проектов.

    Похоже, вы вдолбили себе в голову, что корпорации есть Абсолютное Добро, и ничего кроме добра от них опенсорсу никогда не было. Опять же черно-белый взгляд на мир, просто еще один вариант. Скучно...

     
     
  • 5.59, Аноним (-), 19:07, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это ваше черно белое восприятие меня Какое вообще может быть добро зло в впо... большой текст свёрнут, показать
     
     
  • 6.64, Аноним (-), 20:45, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Apache-Apache... Просто этот сервер удачнее IIS. M$ никак не могла догнать apache по популярности... и купить не могла, как обычно они это делают. Поэтому просто стали вкладывать деньги, чтобы он лучше работал на Windows...
     
     
  • 7.70, Аноним (-), 21:15, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я вам о теплом вы мне о кислом. Да что Вы так Microsoft оравдываете. У Вас что акции Microsoft куплены?

    Верю вам на слово, они руководствувались исключительно не благими намерениями и вкладчики Microsoft могут спать спокойно: их деньги не идут на благотворительность :)

     
  • 5.63, Аноним (-), 19:46, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И дополнение, я же забыл опять об Android Думаю, спорить не будете что количест... большой текст свёрнут, показать
     
  • 3.55, Аноним (-), 18:36, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Кстати, а что такого хорошего для опенсорса сделал мелкософт, что бы перевесило его нечестную конкуренцию, гетьзефаксы и патентный троллинг?

    Кстати это как правило касается опять таки не OpenSource как такого, а конкуренции между компаниями. Ну подорожали, например устройства на базе Android из-за действий Microsoft, само же развитие Android не остановилось, наоборот, это теперь открытый проект, теперь, Microsoft косвенно заинтересованна в его развитии, может даже больше чем Google. Конкретно конечный пользователь у себя в KDE/Gnome разве не имеет какой-то функции из-за активности, например, Microsoft? Более того, в такой жестокой борьбе многим приходится открывать код программных продуктов.

     
  • 2.65, Аноним (-), 20:58, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Из всей огромной корпорации вJOBывал аж целый один вполне Крис Мэйсон, между про... большой текст свёрнут, показать
     

  • 1.44, iCat (ok), 16:29, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Блин, и ещё раз - блин!
    Лучше бы ZFS под GPL перелицензировали!!!
     
     
  • 2.49, Аноним (-), 18:06, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы ZFS под GPL перелицензировали!!!

    Кому лучше то? И почему? Бтр - более новый дизайн. Ряд тупняков зфс-а в нем устранили. Эти упыри даже аллокатор блочный там оставили, по сути. Хоть и с блоками переменного размера, но мелкими, блин. Накукуй тебе еще одно блочное тормозилово? Ща 2012 год, наверное можно уже освоить экстенты в нормальном виде, да?!

     
     
  • 3.50, iCat (ok), 18:08, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Лучше бы ZFS под GPL перелицензировали!!!
    > Кому лучше то? И почему? Бтр - более новый дизайн...

    Мне лучше.
    ZFS работает. BTRFS _будет_ работать.

     
     
  • 4.58, Аноним (-), 18:47, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне лучше.
    > ZFS работает. BTRFS _будет_ работать.

    ZFS прекрасно работает по Linux, уже больше полугода как добавили полноценную работу с файловой системой (ZPL) http://zfsonlinux.org
    Другое дело, что это никому, кроме разработчиков проекта, не интересно.

     
     
  • 5.61, iCat (ok), 19:30, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Мне лучше.
    >> ZFS работает. BTRFS _будет_ работать.
    > ZFS прекрасно работает по Linux... http://zfsonlinux.org
    > Другое дело, что это никому, кроме разработчиков проекта, не интересно.

    во-первых, не особенно "прекрасно", а во-вторых - интересно многим, только интересующиеся всё больше как-то сами... мучаются...


     
     
  • 6.74, Аноним (-), 21:31, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > во-первых, не особенно "прекрасно", а во-вторых - интересно многим, только интересующиеся
    > всё больше как-то сами... мучаются...

    Наверное секрет в том что дизайн zfs весьма задрючен и довольно странен местами. Плюс лицензия специально выбрана недружественной, что ставит крест на шансы стать майнстримом в майнлайне. А переписать с нуля такое монстило - долго, и если уж так долбаться то не понятно зачем принимать неоднозначные решения еще раз, если можно учесть опыт предшественников и сделать лучше. Btrfs как раз и является чем-то типа этого. При его создании посмотрели на сильные и слабые места уже существующих ФС (включая zfs) и попробовали избавиться от недостатков и выдернуть преимущества. ИМХО вполне годно получилось.

     
  • 4.66, Аноним (-), 21:01, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне лучше.

    Так идите и переписывайте. Или вы думаете что то что надо ВАМ будет делать кто-то еще?

    > ZFS работает.

    Ну если она у вас работает - пользуйтесь. В чем проблемы?

    > BTRFS _будет_ работать.

    Да она вообще-то уже вполне прилично работает, если что. Вон там кто-то правильно написал - примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как минимум при типовых операциях - "доктор Ватсон не заметил явных проблем". Так что шли б вы уже погулять. Если вы надеетесь указывать толпе людей что им надо делать - они вам тоже что-нибудь укажут. Не очень приличными жестами.

     
     
  • 5.67, iCat (ok), 21:07, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Так идите и переписывайте. Или вы думаете что то что надо ВАМ будет делать кто-то еще?

    так я и так...
    >...примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как минимум при типовых операциях...

    А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...
    Багрепорт отправил...
    >...указывать толпе людей что им надо делать...

    "Да ни боже мой!!!" С чего бы это?... Моё личное мнение не считаю обязательно верным для кого бы то ни было...

     
     
  • 6.71, Аноним (-), 21:17, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и здорово Если здоровья хватает и цель нужна - way to go Правда если честно... большой текст свёрнут, показать
     
  • 6.83, ананим (?), 12:21, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...

    вот как раз iowait в бтр у меня на порядок ниже стал, чем в ext4.
    что характерно, скорость копирования некоторые проги показывают почти в 2 раза бульше, чем раньше.
    и меня это слегка напрягает - ну не может этого быть!

     
  • 2.56, Аноним (-), 18:39, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Блин, и ещё раз - блин!
    > Лучше бы ZFS под GPL перелицензировали!!!

    ZFS нынче полезна главным образом в плане выжимания денег со старых клиентов санок.
    Судя по всему, оракл не собирается ее развивать, в отличие от. Видимо, преимущества дизайна btrfs все-таки значительны.

     
     
  • 3.62, iCat (ok), 19:33, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ZFS нынче полезна главным образом в плане выжимания денег со старых клиентов
    > санок.
    > Судя по всему, оракл не собирается ее развивать, в отличие от.

    Продавальщики хреновы...
    Как собака на сене - ни сам не гам, ни другому не дам...


     
     
  • 4.69, Аноним (-), 21:11, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Как собака на сене - ни сам не гам, ни другому не дам...

    Ну так за санки уплачено же. А так - ну вон бсдунам ее вывалили. Правда все на что их хватает - кой-как интегрять хяляву в свое ядро.

    Думаю что мы сейчас увидим как пингвин опять обойдет кой-кого на повороте, невзирая на крупную фору. Как обычно...

     
  • 3.68, Аноним (-), 21:09, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по всему, оракл не собирается ее развивать, в отличие от. Видимо,
    > преимущества дизайна btrfs все-таки значительны.

    Судя по всему она для оракловой базы (а чего еще оракла волнует?) ну совсем никак не конкурент бтр-у. Вообще, я не вижу причин ожидать сногсшибательных результатов от блочного аллокатора как у некоторых.

     
     
  • 4.84, ананим (?), 12:51, 04/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Судя по всему она для оракловой базы (а чего еще оракла волнует?) ну совсем никак не конкурент бтр-у.

    да кстати. в презентахе сабжа "докладчик" несколько раз о проводимых тестах tpc упоминал.
    что какбэ интересно с точки зрения фс и методик её тестирования.

     

  • 1.87, Frank (ok), 18:52, 04/02/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сдох в ноуте ssd от kingston на 64 ГБ, работавший больше года под btrfs. Внезапно, после ребута вместо бута - ругательства на невозможность монтирования корня. Один раздел на весь диск, два сабволюма: корень и хомяк. Хомяк зашифрован. Прогрузившись с запасного девайса, посмотрел - раздел монтируется, файловая система читается, шифрованные файлы доступны. На винт переустановил ось, стал думать как лучше всего перетянуть файлы. Поскольку юзернейм и пароль в новой системе совпадают со старой, решил тупо заменить файлы .Private и всё такое, загрузившись с LiveCD. SSD пришлось снова вставить в ноут, ибо usb шнурок отказывался его монтировать из-за i/o errors, а напрямую в sata контроллёр ноута оно монтировалось несмотря на. Однако, ноут что-то не захотел грузиться с болванки - мигал капслоком, пока я не изымал болванку из привода. Тут же внезапно обнаружилось, что ноут смог как ни в чём ни бывало загрузиться с ssd в мою старую систему. Просто слил файлы хомяка на винт. В процессе было ругательство на невозможность прочесть какой-то файл - сказал ему игнорировать такие ошибки.
    Вывод: btrfs действительно хорошая, надёжная система, которую не так просто развалить в бытовом применении даже не смотря на отсутствие полноценного fschk.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру