Маттиас Эккерман (Matthias Eckermann), возглавляющий разработку SUSE Enterprise Linux, считает (http://www.linux.com/news/enterprise/systems-management/6772...), что файловую систему Btrfs (https://btrfs.wiki.kernel.org) уже можно рассматривать как полностью стабильную и готовую для промышленной эксплуатации. Начиная с выпуска SUSE Linux Enterprise 11 SP 2 (http://www.opennet.me/opennews/art.shtml?num=33218), дистрибутив SUSE официально поддерживает Btrfs, наряду с такими ФС, как EXT3, ReiserFS, XFS и OCFS2, и обеспечивает сервис коммерческой поддержки для конфигураций с Btrfs.Предоставление одновременной первичной поддержки сразу для пяти файловых систем обусловлено желанием предоставить клиентам возможность выбора оптимального решения для различных областей применения. При этом по умолчанию для установки предлагается старая и проверенная ФС Ext3. Тем не менее, в примечании к релизу SUSE Linux файловая система XFS рекомендуется для создания хранилища данных, а Btrfs для корневой ФС (использование снапшотов Btrfs позволяет организовать быстрый откат изменений в конфигурации системы и отмену установленных пакетов).
По словам Эккермана, инженеры из проекта SUSE принимают активное участие в разработке Btrfs. Что касается стратегии разработки, то в первую очередь внимание уделяется стабильности, во вторую - функциональности, и в третью - производительности. Код Btrfs в SUSE Linux по сути поддерживается в виде отдельного ответвления (в качестве базы используется ядро Linux 3.0.10, в которое бэкпортируются изменения из новых ядер), патчи в которое принимаются только после строгой проверки и тестирования, поэтому из основной ветки разработки Btrfs переносятся только изменения полностью соответствующие всем стандартам качества SUSE.
Отрицательной стороной подхода помешанного на качестве, является некоторое отставание в поддержке новых возможностей. Например, в SUSE пока не поддерживаются такие возможности Btrfs, как управление несколькими разделами, RAID и хранение данных в сжатом виде. Интеграция fsck.btrfs также пока находится только в планах, но функции сверки контрольных сумм и восстановления целостности (команда scrub) уже реализованы. Из особенностей поддержки Btrfs в SUSE отмечается поставка Snapper (http://www.opennet.me/opennews/art.shtml?num=35101), приложения для управления созданием снапшотов со срезами состояния файловой системы, которое также доступно в пакетах для других дистрибутивов Linux. Также из коробки доступны средства для миграции на использование Btrfs конфигураций с Ext2/3/4, а также для выполнения возвращения с Btrfs на Ext2/3/4, но в этом случае будут преобразованы только данные, имевшиеся до перехода на Btrfs.
Напомним, что компания Oracle ещё в марте объявила (http://www.oracle.com/us/corporate/press/1555025) о полной стабилизации реализации Btrfs и перевела Btrfs в разряд опций, пригодных для промышленной эксплуатации, выпустив ядро Unbreakable Enterprise Kernel Release 2, которое поставляется начиная с дистрибутива Oracle Linux 6.3 (http://www.opennet.me/opennews/art.shtml?num=34218) (по умолчанию в Oracle Linux по прежнему предлагается Ext4).
URL: http://www.linux.com/news/enterprise/systems-management/6772...
Новость: http://www.opennet.me/opennews/art.shtml?num=35561
Что-то я не понял, зюзя поддерживает ext3 и btrfs, а ext4 не поддерживает? Как это понять?
стандарты качества SUSE не позволяют :)
Оно и видно, особенно в свете этой новости =)
Из того, что по умолчанию предлагают ext3, делается вывод, что ext4 не поддерживается вообще. Как это понять? Всё просто: у вас понималка сломалась.
Написано саппорта нет, то-есть если у вас что-нибудь гепнится на ext4 можете Сюсе пофигу.
Потому что с ядра 3.0.* было починено несколько невкусных багов в ext4, а бэкпортить фиксы видимо они не стали. Древний кернель имеет свои проблемы.
Скорее всего потому, что у сюси ни одного разработчика ext4...
> Скорее всего потому, что у сюси ни одного разработчика ext4...Тоже вариант. Хотя ext3 они же поддерживают как-то, а ext4 - те же яйца, только малость заапгрейженные.
а если на btrfs - прибегут помогать чинить?
Внезапно, да.
> Внезапно, да.Да ладно? Прям таки и прибегут?
C 11.2 использует по умолчанию. Написано же - "наряду с".
а на домашних ПК может ли быть смысл форматировать себе диск именно на нее вместо ext4? (и чем и она и Btrfs в своих особенностях лучше, чем например NTFS?)
В принципе как тут и описано, корневой раздел лучше на btrfs, для быстрого отката изменений. Но только быстрого отката, быстрой работы (не на ssd) вы не получите. чем дольше будете использовать тем медленнее будет, основная проблема в поиске метаданных и самих данных, разбросанных по харду. Головкам харда будет не сладко :), но в случае неудачного обновления, теоретически (тоже не тривиальная задача для хомяка), можно откатиться на ранний "слепок". А NTFS в линуксе лучше не использовать для хранения данных, хотя-бы потому, что линукс не может починить упавший NTFS, штатными средствами, тоесть придётся искать винду для починки. NTFS стоит использовать только если у вас винда стоит второй системой или внешний хард/флэшка.
Для домашнего пользователя лучше использовать резервное копирование критически важных данных и ext4 - самая универасльная и стабильная ФС. Резервные копии можно хранить где угодно (хоть на яндексдисках), хранить только те файлы , которые Вам нужны (не отслеживая вообще все изменения на диске), создавать столько копий сколько Вам надо и самое для хомяка главное - управлять всем этим через понятное графическое приложение, а не курить маны на каждый чих (особенно если всё упало и данный компьютер был единственным доступом в интернет для курения манов :) )
> ssd) вы не получите. чем дольше будете использовать тем медленнее будет,
> основная проблема в поиске метаданных и самих данных, разбросанных по харду.Ну так снапшоты надо иногда подтирать + дефрагер не для красоты сделан, если что.
Прравильно, делаем из Линукса Венду. На ext4+LVM ничего подтирать не надо и дефрагментировать.
> Прравильно, делаем из Линукса Венду. На ext4+LVM ничего подтирать не надо и
> дефрагментировать.Правда снапшетов нет :))) точнее они есть но учше бы их небыло, чтоб не позориься :)))
> Прравильно, делаем из Линукса Венду.Ну да, ну да, все истребители - хуже кукурузника! Там катапульта есть - предполагается что пилот лох и самолет г-но!
> На ext4+LVM ничего подтирать не надо и дефрагментировать.
Действительно, оно с снапшотаи не ахтецки работает прямо сразу. Что дефрагь, что подтирай...
> Действительно, оно с снапшотаи не ахтецки работает прямо сразу. Что дефрагь, что
> подтирай...Подумаешь всего в 5-10 раз медленнее :-)) вам шашечки или ехать ?.. задом ?.. на красный ? по встречке ? :)))
> Подумаешь всего в 5-10 раз медленнее :-))Это вы про что? Про скорости UFS/ZFS? ;)
>> Подумаешь всего в 5-10 раз медленнее :-))
> Это вы про что? Про скорости UFS/ZFS? ;)Нет это про LVM + снапшеты, а у вас пробел в образовании ? :))
>> ssd) вы не получите. чем дольше будете использовать тем медленнее будет,
>> основная проблема в поиске метаданных и самих данных, разбросанных по харду.
> Ну так снапшоты надо иногда подтирать + дефрагер не для красоты сделан,
> если что.Похоже в линуксе обязательно нужно что то "подтирать" :)))
> Похоже в линуксе обязательно нужно что то "подтирать" :)))А это вообще в любом CoW нужно. Иначе отрастет огромный хвост изменений и в конце концов ты получишь то что у izen'а в плане скорости + забитый до отказа винч :)
>> Похоже в линуксе обязательно нужно что то "подтирать" :)))
> А это вообще в любом CoW нужно. Иначе отрастет огромный хвост изменений
> и в конце концов ты получишь то что у izen'а в
> плане скорости + забитый до отказа винч :)А где у izen'а ? Ссылка есть ?
Искать лень. У него там скорость чтения с RAIDZ 6 мегабайт в секунду. Он этим ещё и гордиться умудрился как-то.
> Искать лень. У него там скорость чтения с RAIDZ 6 мегабайт в
> секунду. Он этим ещё и гордиться умудрился как-то.Меня этой сцылкой пугают на протяжении нескольких менсяцев ... однозначно с понедельника начну бойцо :)))
> Меня этой сцылкой пугают на протяжении нескольких менсяцев ... однозначно с понедельника начну бойцо :)))Ну блин, клацни профайл изена и изучай наздоровье его перлы. Он там где-то отмочил выложив результат где 3-дисковый пул с рэйдом выдал 18Мб/сек. Получается 6Мб/сек на диск.
> Ну блин, клацни профайл изена и изучай наздоровье его перлы. Он там
> где-то отмочил выложив результат где 3-дисковый пул с рэйдом выдал 18Мб/сек.
> Получается 6Мб/сек на диск.А где именно ? :))) До понедельника найдете ? :)))
> У него там скорость чтения с RAIDZ 6 мегабайт в секунду.Сколько раз можно повторять: _С_ВКЛЮЧЕННОЙ_ДЕДУПЛИКАЦИЕЙ_.
>> У него там скорость чтения с RAIDZ 6 мегабайт в секунду.
> Сколько раз можно повторять: _С_ВКЛЮЧЕННОЙ_ДЕДУПЛИКАЦИЕЙ_.На интел-атоме :))) одноголовом :)))
>>> У него там скорость чтения с RAIDZ 6 мегабайт в секунду.
>> Сколько раз можно повторять: _С_ВКЛЮЧЕННОЙ_ДЕДУПЛИКАЦИЕЙ_.
> На интел-атоме :))) одноголовом :)))в гамаке
> в гамакеВ ластах!
Те разделы, которые не жалко (систему, например).
Восстановления для btr в случае сбоя нет и (работающего) не предвидится.
> Восстановления для btr в случае сбоя нетВо первых он сам попытается откатиться до ближайшего автоснапшота.
> и (работающего) не предвидится.
Во вторых - есть. И btrfsck, и утилитка позволяющая недеструктивно вытянуть то что вытягивается, и прочая. Правда на мой вкус - fack пока в сыром состоянии. Но есть.
У меня пол года корень на btrfs с включенным сжатием lzo (/home, /var на ext4). Грузится быстрее, длительность холодного старта программ уменьшилась. Проблем с ФС не было (было пару отключений от сети). На всякий случай раньше делал бекап корня на другой раздел в tar.lzma, потом перестал. При более-менее надежном питании рекомендую под корень использовать.
дома может быть всё что угодно. при наличии прямых рук. но промышленное использование - немного не то, верно?
> дома может быть всё что угодно. при наличии прямых рук. но промышленное
> использование - немного не то, верно?ZFS со всеми ее шутками и прибаутками уже давно в "промышленности" используется, и ничего.
Хотя лично мне она даже для домашнего применения кажется сыроватой и проблемной.
> ZFS со всеми ее шутками и прибаутками уже давно в "промышленности" используется,
> и ничего.
> Хотя лично мне она даже для домашнего применения кажется сыроватой и проблемной.Перевожу на русский. Тебе кажется. Поэтому ты не используешь и соответственно о чём говоришь знаешь исключительно понаслышке. Ты уверен, что твоё мнение очень важно?
Я уже не прошу уточнить, с какими шутками и прибаутками ты сталкивался и уж совсем негоже у тебя уточнять что за ZFS ты имеешь в виду. Архитектуру вообще? ZFS на солярке? на FreeBSD? на Linux? версии? но, боюсь у тя ща стэк переполнится.
> боюсь у тя ща стэк переполнится.Не переполнится, он в ПЗУ :)))
> Не переполнится, он в ПЗУ :)))Стек в ПЗУ? Да, мсье знает толк в извращениях. Это даже круче чем хоккей на траве!
> Стек в ПЗУ? Да, мсье знает толк в извращениях. Это даже круче
> чем хоккей на траве!Хуже только в переключаемой странице (как на спектрумах). В ПЗУ хотя бы результат немного предсказуем :)
> Перевожу на русский. Тебе кажется. Поэтому ты не используешьА вон те граждане загадившие все рассылки нытьем о локапах в sendfile() наверное испытывали массовые глюки? Заметьте, это все - уже после объявления ZFS стабильной. В бзде, ога.
>> Перевожу на русский. Тебе кажется. Поэтому ты не используешь
> локапах в sendfile()Это где ?
>> Перевожу на русский. Тебе кажется. Поэтому ты не используешь
> А вон те граждане загадившие все рассылки нытьем о локапах в sendfile()v15 на сырой 8.0?? ну да. и что-то я воплей много не наблюдал. не туда смотрел?
У меня почему то ровно обратная картина - и скорость копирования меньше, и время запуска увеличилось
Я тоже так считаю, надеюсь Red Hat меня поддержит )
Кто-нибудь, перечислите весомые плюсы миграции на эту фс с ext4.
> Кто-нибудь, перечислите весомые плюсы миграции на эту фс с ext4.От применений зависит. В основном - copy on write. Недеструктивная запись - при аварии или ошибке оператора можно просто отмотать назад и вернуть все как было. Не тормозит при записи, хотя по свойствам как полное журналирование. Снапшоты - во всех мыслимых позах умеет. Ну и всякеие мелкие плюшки типа сжатия и чексумм. Пустячок а приятно.
Позволю себе канонический пример с http://lurkmore.to/%D0%92%D1%8B%D1&...
Unix:
% ls
Foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm: .o no such file or directory
% ls
%Ну вот в btrfs можно сгонять на машине времени к моменту до выстрела и засунуть в барабан холостые, если предыдущий результат вам не понравился :)
тормоза для dpkg на ссд уже пофиксили? а то ставил на ссд эту шуструю фс, apt-get upgrade стал просто заниматьв 10 раз больше времени.(какая-то фигня с синком фс на ссд)
Да, теперь всё летает.
eatmydata
> eatmydataУгу-угу, и полный факап фиг знает где при крахе. Пакетный менеджер же не для красоты fsync-и хреначит, а для поддержки консистентного состояния. Сломать эту механику конечно можно, но в случае аварии это месиво от асфальта отскрeбать будет совсем не весело.
> какая-то фигня с синком фс на ссд)Уточним, какая-то фигня с медленным выполнением fsync() вообще. А dpkg - частный случай. В 3.7 сие прилично подтянули.
> Например, в SUSE пока не поддерживаются такие возможности Btrfs ... RAID и хранение данных в сжатом виде.И ладненько. Хорошо, что Нейла Брауна пока не тронули, пусть занимается полезными вещами...
Вот пускай сами и используют. А мы по старинке - ext3/4
бтрфс и снаппер там разве не давным давно?
Snapper вообще появился чуть больше года назад. А btrfs поддерживается SUSE Linux только с последнего сервис пака, т.е. с февраля.
о чём и говорю, в sle11 sp2 всё было уже, а журналюги вдруг проснулись с новостью
Suse хотят снапшеты :))
Лучше бы тогда next3 и ext4-next сделали. И снапшоты есть, и совместимо с ext3/ext4. Может бы тогда их наконец-то в ядро включили, и в ванильных e2fsprogs для них бы поддержка появилась.
> Лучше бы тогда next3 и ext4-next сделали.Кому лучше? Если примотать к автомобилю проволокой крылья, из оного получится на редкость паршивый самолет. В силу общей незаточенности конструкции на такое применение. Намного лучше когда конструкция самолета изначально спроектирована под задачи самолета, а не сделана из того что было, путем приматывания проволокой кое-как. Вот в btrfs снапшоты - это не довесок где-то сбоку. Это естественное свойство CoW-логики.
Debian ядро 3.6, btrfs на корне. В принципе нареканий нето кроме, одной проблемы: удаляю файл 5 ГБ, а место освобождается после ребута... Что может быть?
Возможно файл кто-то еще держит открытым.
Блин! Точно! Всё забываю про transmission. ССЗБ.
> Блин! Точно! Всё забываю про transmission. ССЗБ.Это вообще типовое поведение ФС в Linux. Не баг а фича, кстати.
Ну вот и понеслась.
Oracle.
SUSE.
RH обещает в 7.
> Ну вот и понеслась.Ну дык допилили более менее, основной набор фич более-менее стабильно заработал. Пора.
> Маттиас Эккерман (Matthias Eckermann), возглавляющий разработку SUSE Enterprise Linux,
> считаетА где тэг реклама? ну SUSE нашло повод напомнить о себе :-) А дальше что? они считали что рейсер стабилен в то время когда у него хватало болячек роста :-) теперь вот и тут "считают" - а данные терять вам.
>> Маттиас Эккерман (Matthias Eckermann), возглавляющий разработку SUSE Enterprise Linux,
>> считает
> А где тэг реклама? ну SUSE нашло повод напомнить о себе :-)
> А дальше что? они считали что рейсер стабилен в то время
> когда у него хватало болячек роста :-) теперь вот и тут
> "считают" - а данные терять вам.Я как бы сам давно использую сузю в продакшене, уже года как 4. Так вот тоже соглашусь что запиливание бтр в продакшен это больше поахнет рекламным ходом, потому что в своё время они так же с РайзерФС поступили и мы купившись на эту новость на него переехали. из за чего через год начали жалеть.
>[оверквотинг удален]
>>> считает
>> А где тэг реклама? ну SUSE нашло повод напомнить о себе :-)
>> А дальше что? они считали что рейсер стабилен в то время
>> когда у него хватало болячек роста :-) теперь вот и тут
>> "считают" - а данные терять вам.
> Я как бы сам давно использую сузю в продакшене, уже года как
> 4. Так вот тоже соглашусь что запиливание бтр в продакшен это
> больше поахнет рекламным ходом, потому что в своё время они так
> же с РайзерФС поступили и мы купившись на эту новость на
> него переехали. из за чего через год начали жалеть.А что вы хотели от OpenSUSE ? Это дистр для беттатестов.
> А что вы хотели от OpenSUSE ? Это дистр для беттатестов.Если зюзя дистр для бетатестов, тогда эта ваша фрибзда - вообще ядерный полигон.
>[оверквотинг удален]
>>> А где тэг реклама? ну SUSE нашло повод напомнить о себе :-)
>>> А дальше что? они считали что рейсер стабилен в то время
>>> когда у него хватало болячек роста :-) теперь вот и тут
>>> "считают" - а данные терять вам.
>> Я как бы сам давно использую сузю в продакшене, уже года как
>> 4. Так вот тоже соглашусь что запиливание бтр в продакшен это
>> больше поахнет рекламным ходом, потому что в своё время они так
>> же с РайзерФС поступили и мы купившись на эту новость на
>> него переехали. из за чего через год начали жалеть.
> А что вы хотели от OpenSUSE ? Это дистр для беттатестов.Вы наверно с ынтырпрайзЗЮЗЕЙ перепутали ? Таки да она для продакшена а опен для тестов на живых хомечках всего того что планируется добавить в продакшен. Дык чего удивляться - холява Сер.
> Вы наверно с ынтырпрайзЗЮЗЕЙ перепутали ? Таки да она для продакшена а
> опен для тестов на живых хомечках всего того что планируется добавить
> в продакшен. Дык чего удивляться - холява Сер.Ага. а FreeBSD - для тестов на хомячках перед добавлением в Mac OS X и JunOS. Халява, сэр :)
Больно видать вас фря покусала, вам бы к доктору.
> Больно видать вас фря покусала, вам бы к доктору.А можно сначала наугала и ко туда отправить?