Проект Fedora отменил (http://lists.fedoraproject.org/pipermail/devel/2011-August/1...) ранее утвержденный (http://www.opennet.me/opennews/art.shtml?num=30831) план по использованию начиная с выпуска Fedora 16 по умолчанию файловой системы Btrfs. Полный переход на Btrfs отложен как минимум до выпуска Fedora 17, в Fedora 16 как и раньше по умолчанию будет использоваться Ext4. В качестве причины подобного решения называется не соответствие текущего состояния поддержки Btrfs критериям выпуска альфа-версии Fedora 16. В частности, обязательным требованием было наличие программы btrfsck для проверки целостности и восстановления ФС после сбоя, но для Btrfs подобное приложение пока не готово. Релиз Fedora 16 запланирован на 25 октября.
Обратим внимание на то, что речь ведется об использовании Btrfs по умолчанию, в настоящий момент в Fedora 15 Linux уже присутствует опциональная возможность установки с использованием файловой системы Btrfs, поддержка Btrfs в загрузчике GRUB, а также...URL: http://lists.fedoraproject.org/pipermail/devel/2011-August/1...
Новость: http://www.opennet.me/opennews/art.shtml?num=31430
а зачем вдруг все дистрибутивы решили менять ext4 на Btrfs?? есть какие-то очевидные различия между ними?
> а зачем вдруг все дистрибутивы решили менять ext4 на Btrfs?? есть какие-то
> очевидные различия между ними?Я так думаю из-за ее фич. А лично я ее поставил ради скорости и экономии места
Как FS экономит место? Данные сжимает?
> Как FS экономит место? Данные сжимает?И это тоже
Если говорить о журналируемых, то разные способы ведения журналов и другие свистоперделки.
дедубликация, СoW
>А лично я ее поставил ради скорости и экономии местаСтранно, а вот товарищ Шишкин иного мнения https://lkml.org/lkml/2010/6/3/313 Выходит, врёт?
>товарищ Шишкин иного мнения
>Выходит, врёт?Высказывет другое мнение. //Чмоки, К.О.
>Странно, а вот товарищ Шишкин иного мненияТоварищ Шишкин, при всем к нему уважении, не замечает бревна в собственном глазу.
> Товарищ Шишкин, при всем к нему уважении, не замечает бревна в собственном
> глазу.А при чём тут вообще Шишкин? Во-первых, таких проблем в рейсере не наблюдается. А во-вторых, проблемы рейсерфс исключительно финансово-организационные.
> Странно, а вот товарищ Шишкин иного мнения https://lkml.org/lkml/2010/6/3/313 Выходит,
> врёт?Товарищ Шишкин выкопал клинический случай в котором файловая система испытывает проблемы - том на аж целых 600Мб, забитый до отказа мелкими файлами. Получив предсказуемый итог - большой оверхед по метаданным. Нынче уже даже флешки крупнее по объему, если что.
Кстати, это сообщение было год назад. Вообще-то, с тех пор много воды утекло, много коммитов было сделано, а разработчики учли многие претензии господина Шишкина. Может быть, пора бы уже отпусить ручной тормоз? Как можно тормозить целый год?!
>Товарищ Шишкин выкопал клинический случай в котором файловая система испытывает проблемы - том на аж целых 600Мб, забитый до отказа мелкими файлами. Получив предсказуемый итог - большой оверхед по метаданным. Нынче уже даже флешки крупнее по объему, если что.Следовательно, тезис об экономии места в корне не верен. И эта файловая система уступает другим в этом отношении.
>а зачем вдруг все дистрибутивы решили менять ext4 на Btrfs??Так обезьяний рефлекс же. systemd c пульсой все начали тащить после федоры. Не говоря про такие вещи, как dracut и всякие *kit-ы
>>а зачем вдруг все дистрибутивы решили менять ext4 на Btrfs??
> Так обезьяний рефлекс же. systemd c пульсой все начали тащить после федоры.
> Не говоря про такие вещи, как dracut и всякие *kit-ыотличная штука systemd. перевел несколько демонов под ее управление - это быстро и безболезненно, ну и рекомендую плотно почитать о фичах systemd.
openrc ничуть не хуже
Вы их лично гоняли хотя бы на тестовых задачах? Или так, на форуме слышали?
>openrc ничуть не хужеОтсутствие сокет-параллелизации и изолированных filesystem namespaces, отслеживание процессов по pid-файлам - это вы называете "ничуть не хуже"? Это ж технологии прошлого века, как паровозы.
>Отсутствие сокет-параллелизации и изолированных filesystem namespaces, отслеживание процессов по pid-файлам - это вы называете "ничуть не хуже"?А также зависимость от dbus, невозможность тонкой настройки, ограничение на файловую систему, необходимость знания c для написания нетривиальных сервисов, отсутствие кроссплатформенности, множество неисправляемых багов .... Короче, толстовато выходит.
А что, openrc тоже от dbus зависит?
> А также зависимость от dbus, невозможность тонкой настройки, ограничение на файловую систему,
> необходимость знания c для написания нетривиальных сервисов, отсутствие кроссплатформенности,
> множество неисправляемых багов .... Короче, толстовато выходит.Не знал, что у openrc так много проблем.
> А также зависимость от dbus,Это у systemd? Ну, допустим даже dbus. И что? Dbus чем-то плох? Платформенно-нейтральный механизм коммуникации между процессами с оговоренными правилами игры, чего так не хватало традиционным позиксным механихмам IPC. IPC это здорово, но надо еще знать что и кому слать и в каком виде они это понимают, кто заинтересован в некоем событии и прочая. Традиционные *никсные IPC механизмы никак не стандартизуют эти моменты. Каждый дро^W как он хочет, а кого некое событие интересует - можно только на картах пораскинуть. В d-bus эти моменты разрулены. Может не идеально но лучше пока все-равно никто не смог, поэтому пользуемся тем что есть.
> невозможность тонкой настройки,
В systemd настроек - побольше чем в большинстве других. Стандартные тонкие настройки вообще сразу есть. Алилуйя - теперь не надо писать десятиэтажные шеллскрипты для типовых операций. Надо же.
> ограничение на файловую систему,
Это как?
> необходимость знания c для написания нетривиальных сервисов,
Сервисам вообще не требуется знать чем их запускают - не их собачье дело. Единственное исключение если сервис вдруг решит как-то продвинуто взаимодействовать с системой инициализации. Кстати, внезапно, демоны и так пишутся на си, поэтому его знание для написания сервиса все-равно понадобится. Что с systemd что без.
> отсутствие кроссплатформенности,
Вообще, законы не запрещают портировать оный хоть на тостеры. А наличие желающих это делать и прочая - вопрос второй. На форумах троллить проще, факт.
> множество неисправляемых багов .... Короче, толстовато выходит.
Ну так набрасывайте тоньше, кто ж не дает?
Хм, мне казалось, что он все это про openrc. Потому что кроме dbus и кроссплатформенности, ни одна из претензий к systemd ни сном не ни духом не относится.
> Хм, мне казалось, что он все это про openrc. Потому что кроме
> dbus и кроссплатформенности, ни одна из претензий к systemd ни сном
> не ни духом не относится.Он наверное systemd видел только на картинке, описание его возможностей читать поленился, но видимо в его любимой системе он не поддерживается, за что в адрес systemd и полетела коричневая масса с дурным запахом без долного обоснования - годная заявка на FAIL.
Вот такая вот телепатия - некоторые люди очень предсказуемы в своем поведении. А вы если я угадал, довольно тонко подъ... того типа ответом про openrc в результате, сами того не желая, это улыбает :)
> Хм, мне казалось, что он все это про openrc. Потому что кроме
> dbus и кроссплатформенности, ни одна из претензий к systemd ни сном
> не ни духом не относится.Таки к systemd. Просто поторопился. И вообще, это паста с рассылки debian, если что.
> Это у systemd? Ну, допустим даже dbus. И что? Dbus чем-то плох?Дополнительная уязвимость, дополнительный демон. На серваке такому не место. Впрочем, необходимость его тоже не раскрыта.
> В systemd настроек - побольше чем в большинстве других. Стандартные тонкие настройки
> вообще сразу есть. Алилуйя - теперь не надо писать десятиэтажные шеллскрипты
> для типовых операций. Надо же.Это каких настроек, простите? Пары опций, вынесенных в юниты? Остальное на сях.
> Кстати, внезапно, демоны и так пишутся на си,
> поэтому его знание для написания сервиса все-равно понадобится. Что с systemd
> что без.Я где-то утверждал обратное? Демон на си, запуска на sh с возможностью тонкой настройки под любые извращения. А вот сишная запускалка этого не позволяет.
>> отсутствие кроссплатформенности,
> Вообще, законы не запрещают портировать оный хоть на тостеры.Не запрещают, но зачем исправлять чьи-то недальновидные поступки? Под вендой тоже много софта завязанного на winapi. Это не означает, что кто-то обязан портировать.
>> ограничение на файловую систему,
> Это как?Ругается на /usr отдельным разделом. И, конечно, Лёня уже заранее открестился от решения этой проблемы. Может и софт кривой, если ему верить, но с другими инитами такой проблемы нет. Не спорю, лет через 5 может решат. Но мне работать надо, а не тестировать.
ЗЫЖ последняя федора с всеми обновлениями, а fsck так и гоняет диск при каждой перезагрузке. Кто будет исправлять? А х.з.
> openrc ничуть не хуже1) А он сможет запустить мне гуестовую виртуалку в KVM в процессе старта хоста? А чтобы это было просто, и без кучи костылей навешиваемых самим мной?
2) А процесс в LXC контейнер затолкать - сможет? Или мне опять городить какие-то костыли там и тут самолично? Я что, завод по производству костыльной продукции?
3) А можно ли в openrc при старте процесса простыми методами задать приоритет процесса отличный от дефолтов? А настроить рестарт сервиса при незапланированном завершении? А расписать сколько времени может выполняться джоб? Или все это предлагается окостыливать лично, как это традиционно делается, выписывая довольно навороченный шеллскрипт отрабатывающий все эти моменты на каждый демон?Это не говоря о том что дергать щелл-интерпретер который в пять раз крупнее иного демона на каждый пшик - глупо и медленно.
1 и 2 это _не_ задача системного демона. И это прекрасно делает libvirt независимо от системы иницилизации.> А настроить рестарт сервиса при незапланированном завершении?
можно
При чем тут Fedora? Это разработано внутри RedHat, которая за многие годы подтвердила уровень своих программистов. Потому и разошлось. Независимо от существования Fedora.
да да. вспомнить только глюк на глюке в pulse audio - которую вылизывали не один год всем миром.
Кстати написанный тем же автором кто писал systemd.
тот же автор сказал что ему наплевать на все другие OS и писать портабельный код он не будет.Ничего не навевает ?
ну и отлично. Во-первых, куда его портировать (и нахрена). Во-вторых, кто пишет портабельный код для продуктов подобного рода?
>Во-первых, куда его портировать (и нахрена).Какой поворот событий. Лет 5 назад линуксятники кричали, что winapi это плохо. Меня удивляет, как мнение одного работника редхат меняет мнения масс.
Если уж говорить про портабельность, то переход на systemd это билет в один конец. Использовать альтернативные иниты на таком дистрибутиве будет просто нереально. Вот и получается у нас redhat-only с кучкой клонов.
Никто не мешает портирвать его на другие платформы. Надо - портируй, но разрабы на это время тратить не будут.
> Лет 5 назад линуксятники кричали, что winapi это плохо.ну и какое это отношение имеет к портабельности? винапи гогно безотносительно к чему-либо, просто уродский дизайн.
> Использовать альтернативные иниты на таком дистрибутиве будет просто нереально.
это что ещё за чушь? берёшь и пишешь свои иниты, но для systemd
> винапи гогно безотносительно к чему-либо, просто уродский дизайн.То-то весь мир на нём пишет. Копрофилы, наверное.
>> винапи гогно
> То-то весь мир на нём пишет. Копрофилы, наверное."Копрофаги". Да -- без "наверное". Типа, "мы принюхамши".
> Если уж говорить про портабельность, то переход на systemd это билет в
> один конец. Использовать альтернативные иниты на таком дистрибутиве будет просто нереально.Вранье, как обычно.
> Вранье, как обычно.Конечно враньё. Успокаивай себя так по ночам.
>тот же автор сказал что ему наплевать на все другие OS и писать портабельный код он не будет.Пожалуйста, перестаньте нагло врать.
"Тот самый автор" честно ответил, что необходимость равняться на отстающие ОС приведет к значительной потере полезной функциональности продукта.
Я вру? Разве автор не сказал что ему наплевать на другие ОС - назвав их отстающими?
А отстающие ОС это какие ?
Linux тоже отстает от Windows - зачем ему равняться на Linux ?и чем это ведет к значительной потере функциональности?
Вот Wine работает везде, X.org тоже, не считая всяких KDE/GNOME/OOO/apache/etc - им не мешает быть кросплатформеными, а вот этому автору мешает.
Помните как его макнули носом в ошибки эмуляции OSS в Pulseaudio ? На что он ответил - не буду исправлять это кривой skype. Так может плохому танцору что-то другое мешает ?
> Я вру?Разумеется, вы врете.
> Разве автор не сказал что ему наплевать на другие ОС
Нет, не говорил. Это сказали за него вы, маленький лгунишка.
> - назвав их отстающими?
Это просто констатация факта.
> А отстающие ОС это какие ?
Те, которые без cgroups, namespaces, fanotify и т.д.
> Linux тоже отстает от Windows - зачем ему равняться на Linux ?
Так он и не равняется =)
> Вот Wine работает везде, X.org тоже, не считая всяких KDE/GNOME/OOO/apache/etc - им
> не мешает быть кросплатформеными, а вот этому автору мешает.Потому, что init - это несколько больше, чем обычная юзерспейсная программа. Почему iptables не может быть кроссплатформенной? А drbdadm? А ipvsadm? Все эти программы существуют только под Linux, однако тролли почему-то не возмущаются по этому поводу.
> Помните как его макнули носом в ошибки эмуляции OSS в Pulseaudio ?
> На что он ответил - не буду исправлять это кривой skype.Ну разумеется, раз вы сами на каждом шагу врете, то и другим не верите. А может, человек, от имени которого вы так любите высказываться, вовсе не врет и проблема действительно в скайпе?
> Linux тоже отстает от Windows - зачем ему равняться на Linux ?В вопросе файловых систем все ровно наоборот: MS просрал все полимеры. Единственное их "достижение" сводится к патентам на фат да ExFAT задизайненому по технологиям 15-летней давности. Они б еще флопики раскопали, некрофилы.
> Я вру?Да.
> Разве автор не сказал что ему наплевать на другие ОС - назвав их отстающими?
Это Ваша произвольная интерпретация, в народе именуемая передёргиванием.
> А отстающие ОС это какие ?
Например, FreeBSD (в данном контексте).
> Вот Wine работает везде, X.org тоже, не считая всяких KDE/GNOME/OOO/apache/etc - им
> не мешает быть кросплатформеными, а вот этому автору мешает.Похоже, Вы катастрофически не понимаете, о чём говорите. У пользователей отстающих ОС текущий плач ярославны -- это KMS в этом самом xorg.
И где вы такие берётесь, что всё-то у вас глючит. С десятой версии использую Федору: уж с чем-чем, но с пульсом ни единого глюка у меня не было. Как, впрочем, и с нетворкменеджером, нынешним системд и фирменными редхатовскими систем-конфиг-*.
У нетворкменеджера регулярно PPPoE ломалось, да и все еще PPPoE воспринимается как локальное соединение, а не как доплнительное (как vpn например)
>С десятой версии использую Федору: уж с чем-чем, но с пульсом ни единого глюка у меня не было.Странно, но у меня звук отстаёт на пару секунд. Так что работа на одном сферическом железе отнюдь не показатель безглючности. К тому же, я не вижу смысла в наличии ещё одной жёстко прибитой прослойки.
> И где вы такие берётесь, что всё-то у вас глючит. С десятой
> версии использую Федору: уж с чем-чем, но с пульсом ни единого
> глюка у меня не было. Как, впрочем, и с нетворкменеджером, нынешним
> системд и фирменными редхатовскими систем-конфиг-*.вам напомнить сколько времени прошло между переводом федоры на pulseaudio и 10ей версией - когда оно стало относительно безглючное? Вы помните когда для многих приложений было рекомендуемое "отключать pulseaudio и давать прямой доступ к alsa" ?
Если мой склероз не изменяет pulseaudio появился где-то в райне федора 4 - то есть порядка 6 лет назад.
федора 10 появилась года 2 назад,
Вот за 4 года его пытались вылизывать и таки вылизали (возможно - ибо сейчас просто выношу что бы не прыгать с бубном).Плохо что вы не знаете историю вопроса.
> Если мой склероз не изменяет pulseaudio появился где-то в райне федора 4
> - то есть порядка 6 лет назад.Изменяет. Он появился в Fedora8.
> Плохо что вы не знаете историю вопроса.
точно
> да да. вспомнить только глюк на глюке в pulse audio - которую
> вылизывали не один год всем миром.Если "всем миром" -- это убунтушниками, в которых и апстрим тыкал палкой позора за кривую имплементацию в дистрибутиве, то всё-таки это с больной головы на менее больную.
PS: сам PA применяю по назначению -- на тонких клиентах.
>Если "всем миром" -- это убунтушниками, в которых и апстрим тыкал палкой позора за кривую имплементацию в дистрибутиве, то всё-таки это с больной головы на менее больную.Чего? В убунте сами реализовывали пульсаудио? А Леннарт любит потыкать палкой. Он и сейчас так открестился от множества багов.
> Так обезьяний рефлекс же.О, так вот почему больше не ездят на лошадях, предпочитая блестящие иномарки! Оказывается - обезьяний рефлекс!
> О, так вот почему больше не ездят на лошадях, предпочитая блестящие иномарки!
> Оказывается - обезьяний рефлекс!На иномарках ездить удобнее. А вот машина-трактор-комбайно-пылесосы почему-то не получили распространения в реальном мире.
> На иномарках ездить удобнее.Вот и systemd пользоваться удобнее.
> А вот машина-трактор-комбайно-пылесосы почему-то не получили распространения в реальном мире.
Вы намекаете, что проект coreutils не нужен?
> На иномарках ездить удобнее.Да, а еще кондей и стеклоподъемник стали нормой жизни. И АКПП стали использоваться. Как по мне - вручную мудохаться с перезапуском сервиса, прописыванием его приоритета где-то сбоку, костылингом чтобы например некий сервер взлетел строго после того как поднимется сеть (а иначе можно обломаться забиндить сокет на нужный ифейс) - несколько достало. Это давно пора объявить чем-то типа кондиционера в машине и втолкать в дефолтную поставку. А если кто хочет на ведре с гайками ездить - ну это его право, только результаты продаж автотаза как-то не очень оптимистичные.
> его право, только результаты продаж автотаза как-то не очень оптимистичные.Наоборот, первое место по России.
/калиновод-кунКстати, скажите мне, как в этом вашем systemd запусить автологин на, скажем, tty3, чтобы там висел шелл юзера vasya без пароля. Я эту проблему решил только после получаса грепа. Где Fucking Manual на эту тему?
И был бы признателен если мне кто-то скажет как в systemd запускать, pppd чтобы при его крахе он перезапускался сам? В sys v init это всегда делал через inittab.
Что бы было чем ответить на "ZFS наше все".
>ответитькто и кому? ZFS и Btrfs - собственность одной компании...
btrfs не является чей-либо собственностью. И когда его начинал развивать оракл, то zfs у них ещё не было. Ну а собственно после покупки интерес к btrfs пропал, теперь её пилят в редхате.
> интерес к btrfs пропал, теперь её пилят в редхате.Собственно Крис регулярно светится в коммитах. Свою основную работу он сделал, теперь очередь остальных подключаться уже. Что и наблюдается. Архитект - не ломовой кодер в общем то. Он вообще кодить от и до не обязан, так что Крис на самом деле уже давно перевыполнил план как архитект на 120%.
Ещё б btrfsck написал...
По его заявлениям эта приблуда должна выйти в течение 2-ух недель. Он именно ей вплотную и занимается помимо исправления ошибок и улучшения кода в ядре. Так что федороделы поторопились. Могли бы подождать немного.
Он обещает "через 2 недели" с ноября 2010. Не шучу, к сожалению.
pbook /home/pro % yaourt -Ql btrfs-progs-unstable| grep btrfsck
btrfs-progs-unstable /sbin/btrfsck
btrfs-progs-unstable /usr/share/man/man8/btrfsck.8.gzНе то?
> btrfs-progs-unstable /usr/share/man/man8/btrfsck.8.gz
> Не то?Хороший у вас йогурт :).Это то самое, но давайте вы на своих йогуртах и проверите как оно файловые системы чинит, заодно написав багрепорты? :)
>> btrfs-progs-unstable /usr/share/man/man8/btrfsck.8.gz
>> Не то?
> Хороший у вас йогурт :).Это то самое, но давайте вы на своих
> йогуртах и проверите как оно файловые системы чинит, заодно написав багрепорты?
> :)А они у меня не ломаются ( Проверить нету возможности.
Они даже свою страничку обновили :) Вот ссылка: http://thread.gmane.org/gmane.comp.file-systems.btrfs/12352/... , а вот ответ:"This part is definitely my fault. I've gone through a bunch of
variations on bigger and smaller tools, and had to juggle the kernel
maintenance as well.Aside from making sure the kernel code is stable, btrfsck is all I'm
working on right now. I do expect a release in the next two weeks that
can recover your data (and many others)".
frank@fqc-book:~$ btrfsck
usage: btrfsck dev
Btrfs Btrfs v0.19Я вообще-то _совсем_ не понял насчёт "для Btrfs подобное приложение пока не готово".
Ну откуда вы такие беретесь. Это просто заглушка, проверяющая некоторые параметры и все. Она не умеет ничего исправлять.
> а зачем вдруг все дистрибутивы решили менять ext4 на Btrfs?? есть какие-то
> очевидные различия между ними?Copy-on-write = полное журналирование данных + метаданных на скорости файловой системы без журнала вообще. А попробуйте врубить журналирование данных на ext4. И как вам скорость работы после этого? А если данные не журналить - при крахе, ВНЕЗАПНО, нет данных для доведени транзакции до конца или полного отката. Файловая система обеспечит непротиворечивость метаданных, но что будет с данными файла?! А будет полуперезаписанный файл например. На логически корректной файловой системе. Ну вот так вот запись в середине оборвалась. И если это был документ - не факт что он вообще прочтется вот такой, даже частично.
Ну и вытекающие достоинства типа очень быстрых снапшотов и развитой работы с ними. CoW система по сути цепочка-лог состояний ФС. Откат к некоему моменту = забивание на хвост цепочки изменений. Просто, красиво, хорошо работает.
переходить еще рано
Не все, Fedora только. А она потому, что она первая тестирует все новшества. В последнее время это были nouveau и PulseAudio.
а ораклыч вот возьмет и запилит btrfsck только для своего Некрушимого или за денежку. Вот будет fail...
> а ораклыч вот возьмет и запилит btrfsck только для своего Некрушимого или
> за денежку. Вот будет fail...Угу, тягомотина с этим уже достала, уже год как обещают "вот вот". Или еще хуже, и исходники выложут и поддерживать будут, а по факту если что важное крякнет надо покупать Oracle Unfackable, потому что там патчик на пару строк который все восстановление делает быстрее и надежнее. Нехороший запах, снесу нахрен все разделы, наигрался за год. Ext4/Xfs теперь наше все, прощайте снапшоты и тормозная загрузка.
Блин а жаль на самом деле, так в ней был уверен, даже САМ Линус сказал что btrfs и есть главная FS на обозримое будущее.
> САМ Линус сказал что btrfs и есть главная FS на обозримое будущее.Не надо быть Линусом чтобы это понимать. Достаточно на ее архитектуру посмотреть и сравнить с другими. Это шаг вперед по сравнению с классическими фс, как ни крути.
Новое - хорошо забытое старой :D Так может всё-таки шаг назад? :)
Log-structured FS же ... всякие там spiralog, logfs и т.п.
> Новое - хорошо забытое старой :D Так может всё-таки шаг назад? :)Знаете, а ракеты делали много столетий. Для фейерверков, например. Но спутники ими выводить на орбиту научились только в 50х годах прошлого века. И вообще, серьезные применения начались лишь когда научились траекторию вычислять. До тех пор оно годилось только на игрушки типа фейерверков. Ну вот и тут так же - у log structured своих проблем - есть. И более-менее научились их решать достаточно недавно. Наступает время брать новые высоты с доведенной до ума технологией, не так ли? ;)
> Знаете, а ракеты делали много столетий. Для фейерверков, например. [...]
> До тех пор оно годилось только на игрушки типа фейерверков.Вообще-то китайцы ещё тогда их применяли в бою. И проблемы там не только расчётного плана, а и чисто инженерного -- например, обеспечение устойчивости горения топлива и стабильной ориентации (попробуйте запустить на пустыре bottle rocket без длинного хвоста, поймёте).
> Log-structured FS же ... всякие там spiralog, logfs и т.п....nilfs2...
Это просто какой-то маразм!Должны же быть объявлены хотя бы какие-нибудь аргументы в пользу замены тщательно протестированной ФС EXT4 на никому не ведомую игрушку бтрфс, находящуюся в стадии альфа-тестирования!!!
> Это просто какой-то маразм!
> Должны же быть объявлены хотя бы какие-нибудь аргументы в пользу замены тщательно
> протестированной ФС EXT4 на никому не ведомую игрушку бтрфс, находящуюся в
> стадии альфа-тестирования!!!Как ой то поток сознания.
Btrfs протестирована уже минимум на 3 выпусках Fedora. Это очень известная игрушка, в том числе благодаря пиару от автора ядра. Огромное количество возможностей, COW, встроенная на этапе дизайна поддержка SSD, контрольные суммы, etc. Нужно бить в анабиозе с отключеным интернетом чтобы не слвшать про нее.
EXT4 "тщательно протестирована" ? Хорошая шутка. Ext3 еще можно так сказать, но EXT4 постоянно пилят хотя на пользовательском уровне изменений не видно но внутри перетрясывают немало. Хотя конечно не альфа.
> встроенная на этапе дизайна поддержка SSDХм, теперь драйвера контролеров винчестеров это FS? Не знал.
> Хм, теперь драйвера контролеров винчестеров это FS? Не знал.SSD - не винчестер.
>> Хм, теперь драйвера контролеров винчестеров это FS? Не знал.
> SSD - не винчестер.Да ладно! Solid-State Drive это не винчестер, хм, тогда и HDD не винчестер!
>>> Хм, теперь драйвера контролеров винчестеров это FS? Не знал.
>> SSD - не винчестер.
> Да ладно! Solid-State Drive это не винчестер, хм, тогда и HDD не
> винчестер!Видимо, для вас и флешка - винчестер, и компакт-диск тоже винчестер.
Выходите из анабиоза, оптимальная логика работы с файловой системой сильно зависит от физической организации и методов работы хранилища информации.
> Да ладно! Solid-State Drive это не винчестер, хм, тогда и HDD не
> винчестер!Винчестер - там где блины, головки и моторчики. HDD - винчестер, SSD - не винчестер.
> Винчестер - там где блины, головки и моторчики.Вообще-то винчестер в оригинале - там где ствол, затвор и прочие пули, ну или город такой еще есть. А уже потом жесткие диски стали так же называть, за кодовое имя одного из айбиэмовских HDD. Однако наверное даже сам IBM уже не скажет - считается ssd за "винчестер" или нет :)
LVM и FS уже несколько лет единое целое.
Вот только LVM это не менеджер физических томов.
> Вот только LVM это не менеджер физических томов.Внезапно, физическими томами он тоже управляет, это часть работы по управлению логическими томами.
> Это очень известная игрушка, в том числе благодаря пиару от автора ядра. Огромное количество возможностей, COW, встроенная на этапе дизайна поддержка SSD, контрольные суммы, etc. Нужно бить в анабиозе с отключеным интернетом чтобы не слвшать про нее.Все это можно было реализовать в качестве плагинов к гораздо более "правильно"
сделанной Reiser4, так нет, сделаем свой велосипед и будем говорить что в ней есть то, то и то.
нельзя, хватит уже нести этот бред по рейзер.
> нельзя, хватит уже нести этот бред по рейзер.Если ты любишь велосипеды, то это не значит что то-что создано для их отсуствия плохо.
> Если ты любишь велосипеды, то это не значит что то-что создано для
> их отсуствия плохо.Он не любит велосипеды, иначе бы он не стал так резко высказываться про рейзер4 (супер-мега-фс, которая очень быстро фрагментируется и начинает тормозить, как и ZFS).
> Все это можно было реализовать в качестве плагинов к гораздо более "правильно"Боюсь что CoW сложно сделать "плагином". На уровне дизайна - это не плагин и не дополнительная возможность. Это костяк технологии, ее ядро. Вбить его молотком и напильником как плагин - можно, наверное, но ничего кроме геморроя и костылей это не даст.
> сделанной Reiser4, так нет, сделаем свой велосипед и будем говорить что
> в ней есть то, то и то.Btrfs не пытается быть всем и вся как рейзер, но вобрал в себя лучшее что было на момент дизайна в файловых системах. Выглядит более практичным подходом.
> Все это можно былоМного чего "можно было", но регулярно чего-то не хватает. Если бы Ганс не болел звёздной, да что там -- хотя бы был мужиком, то ФС имени его версии четыре, может, и стала бы уже production (с плагинами и тестершами). А так, как пошли события -- пока не стала.
> Должны же быть объявлены хотя бы какие-нибудь аргументы в пользу замены тщательно
> протестированной ФС EXT4 на никому не ведомую игрушку бтрфс, находящуюся в
> стадии альфа-тестирования!!!Введите от рута rm -rf /* ;). А теперь подумайте что на btrfs вы могли бы одним движением руки вернуть все в вид как было. Даже после этого. Просто откатив на прошлый снапшот. Можно даже временный, автоматический.
>> Должны же быть объявлены хотя бы какие-нибудь аргументы в пользу замены тщательно
>> протестированной ФС EXT4 на никому не ведомую игрушку бтрфс, находящуюся в
>> стадии альфа-тестирования!!!
> Введите от рута rm -rf /* ;). А теперь подумайте что на
> btrfs вы могли бы одним движением руки вернуть все в вид
> как было. Даже после этого. Просто откатив на прошлый снапшот. Можно
> даже временный, автоматический.А теперь представь, что для этого один черт нужно столько же пространства, сколько занято и если уж и нужны backup'ы, то лучше не извращаться со снапшотами(которые делаются раз в n времени), а настроить зеркальный raid.
Пардон, а как связаны бэкапы и зеркальный RAID? =)))))))))
> Пардон, а как связаны бэкапы и зеркальный RAID? =)))))))))Он хочет сказать, что зеркальные да и любые другие RAIDы не обеспечивают стопроцентной готовности к восстановлению, потому что , к сожалению, rm -Rf / на зеркале ухайдокает все зеркала тоже. И поэтому нужен физический бэкап на ленту вне защищаемой машины.
>> Пардон, а как связаны бэкапы и зеркальный RAID? =)))))))))
> Он хочет сказать, что зеркальные да и любые другие RAIDы не обеспечивают
> стопроцентной готовности к восстановлению, потому что , к сожалению, rm -Rf
> / на зеркале ухайдокает все зеркала тоже. И поэтому нужен физический
> бэкап на ленту вне защищаемой машины.Тем не менее, возврат к снапшоту работает против rm -rf /*, и сказки про вдвое большее место - таки сказки. COW никто не отменял же.
>> Пардон, а как связаны бэкапы и зеркальный RAID? =)))))))))
> Он хочет сказатьХорошо, если так. У многих понимание того, что резервирование дисков и резервное копирование ортогональны и выручают в _разных_ (хоть и пересекающихся) ситуациях -- отсутствует напрочь :(
> А теперь представь, что для этого один черт нужно столько же пространства,
> сколько занято и если уж и нужны backup'ы,Btrfs лепит автоматические временные снапшоты раз в 30 секунд, используются как "milestones" в случае краха - если все навернулось, просто откат на временный снапшот. И файловая система (и данные и метаданные) оказываются в состоянии как оно было в этот момент. Удачи вам бэкапать ВСЕ файлы на диске раз в 30 секунд. А что если я 5 минут назад важное изменение засэйвил? Что ж мне теперь, вручную пинать бэкапы?
> то лучше не извращаться со снапшотами(которые делаются раз в n времени),
А никто и не извращается - в такой файловой системе всегда есть все данные и метаданные для снапшотов. Временные снапшоты делаются автоматически. По сути это лишь пометка что "а вот сейчас мы считаем это состояние данных и метаданных корректным и синхронизированным". А все что новее этой пометки и не зафиксированное в следующей - будет отброшено. Считайте это ролбэком неудачной транзакции, если в классических терминах.
> а настроить зеркальный raid.
Он меня вообще никак не спасет от rm -rf /* ;)
> А что если я 5 минут назад важное изменение засэйвил? Что ж мне теперь, вручную пинать бэкапы?тут на самом деле разницы нет. Всё равно на уровне ФС не сможешь сделать консистентный образ открытого файла. Нужна поддержка от прикладного ПО. Исключения составляют разве что нормальные СУБД. Автоматические снапшоты тут бесполезны.
> тут на самом деле разницы нет. Всё равно на уровне ФС не сможешь сделать
> консистентный образ открытого файла.Файловая система всегда знает что в файле есть (или должно быть) в данный момент. Остальное на совести авторов программ. Что они просят им записать то и должно быть записано.
> Нужна поддержка от прикладного ПО.
Пока что я вижу дичайшие костыли - тем кому надо *надежно* писать в файлы почему-то зверски извращаются с воркэраундами: запись в темповый файл нового файла, удаление старого файла, ренейм темпа в старого файла. И вся эта чехарда - чтобы избежать типовой ситуации когда запись в "типа журналируемой" ФС типа экст3/4 в дефолтном режиме гавкнулась на середине записи файла. Потому что если там просто писать файл и в этот момент все накроется, файл будет наполовину перезаписан. И юзер будет очень недоволен порушеным файлом.
> Исключения составляют разве что нормальные СУБД. Автоматические снапшоты тут бесполезны.
СУБД сами во многом файловые системы напоминают, особенно в части журналирования. Наверное именно поэтому некоторые из них даже умеют в принципе работать с RAW разделами. По той же причине они могут тормозить на CoW - логика журналинга СУБД наложится на CoW и выйдет двойная работа для одного и того же результата. Но вообще-то, когда прикладухам приходится морочиться с журналингом самолично потому что файловая система дескать не может журналить быстро и честно одновременно - это жуткий изврат.
> Файловая система всегда знает что в файле есть (или должно быть) в данный момент.только в вашей фантазии. А в реальности у ФС есть куча кешей в волатильной памяти над которыми она не имеет контроля. Есть обстоятельства не подконтрольные ФС в виде форсмажоров. Т.е. знать то она может, но легко это забывает.
> Пока что я вижу дичайшие костыли - тем кому надо *надежно* писать в файлы почему-то зверски извращаются с воркэраундами: запись в темповый файл нового файла, удаление старого файла, ренейм темпа в старого файла.
вы не доконца понимаете зачем это нужно. На всякий случай поясню: пока процесс занимается модификацией данных файла он может быть нужен другим процессам. Чтобы все остальные не ждали когда же наконец произойдут изменения, делается такой финт. Это реализация простой версионности через файлы и только второй по важности эффект от неё заключается в согласованности данных.
Для обеспечения консистентности используют совершенно другие приёмы - принудительные fsync() и т.п.
Т.е. я вам гарантирую на % 99.9, что при любой позикс ФС такие приложения будут делать ровно тоже самое. И это связано с журналированием данных и CoW только на второстепенных планах.
> Потому что если там просто писать файл и в этот момент все накроется, файл будет наполовину перезаписан.
В любой ФС с позикс интерфейсом он будет именно так недозаписан.
> СУБД сами во многом файловые системы напоминают, особенно в части журналирования.
Скорее наоборот, фс со своими зачаточными журналами и CoW напоминают ACID СУБД.
> Но вообще-то, когда прикладухам приходится морочиться с журналингом самолично потому что файловая система дескать не может журналить быстро и честно одновременно - это жуткий изврат.
ещё раз попробую донести очевидную мысль - позиксная ФС _не_ может предложить приложению достаточный функционал журналирования.
Бывают не позиксные специальные ФС с таким функционалом.
Для Ext4 уже реализованы снапшоты (Ext4dev). Rollback'а, правда, там нет, придётся немного ручками поковыряться.
> Для Ext4 уже реализованы снапшоты (Ext4dev). Rollback'а, правда, там нет, придётся немного ручками поковыряться.Есть очень сильное опасение, что ext4dev в ядро не примут, как и reiser4. Конкуренты btrfs не пройдут.
> Есть очень сильное опасение, что ext4dev в ядро не примут, как и
> reiser4. Конкуренты btrfs не пройдут.Есть очень сильное подозрение что истребитель, созданный для именно именно полетов - летает лучше чем жигуленок, к которому проволокой примотали реактивный двигатель.
Эммм... только вот программку btrfs после rm -rf /* уже неоткуда будет запускать, кроме как с livecd, не? А это уже не одно движение, а pkunzip.zip какой-то.
Наконец-то, федорщики поняли, что не гоже пихать в массы поделку, находящуюся в стадии пре-альфа. Такие вещи пусть будут опционально в дополнении к доброй и надёжной EXT4. Кто хочет, тот пусть тестирует. А заставлять всех подряд хавать не созревший плод -- это уж слишком.Ещё бы они отказались от GNOME3 по умолчанию и вернули бы классический 2-й Гном. Тогда бы всё встало на свои места.
> А заставлять всех подряд хавать не созревший плод -- это уж слишком.федорка именно для этого и существует
Только там все гораздо лучше и обновляется без проблем и поломок по сравнению с убунтой, мандривой, зузей.
> Только там все гораздо лучше и обновляется без проблем и поломок по
> сравнению с убунтой, мандривой, зузей.Попробую угадать: вы используете именно федору :)
>Начиная с первого выпуска в 2003 году, Fedora Linux компании Red Hat является лучшим средством слежения за новейшими разработками в Linux и сопутствующем открытом программном обеспечении.
Федорщики по умолчанию так поступить не могут. Они же тестируют новые фичи...
Соболезную. Ещё год-два мэйнстрим GNU/Linux будет прозябать на древних ФС из-за элементарной нехватки человеческих ресурсов, чтобы допилить btrfsk до нормального состояния, и тестеров Fedora, чтобы ощутить всю прелесть CoW ФС как можно скорее.
несли особо не пилят, значит не очень оно всем нужно. Для подавляющей части инсталляций в принципе так и есть, вполне хватает экст и прочих традиционных фс.
> Соболезную. Ещё год-два мэйнстрим GNU/Linux будет прoзябать на древних ФС из-за элементарной
> нехватки человеческих ресурсов,Особенно лицeмeрно смотрится данная зaявка от человека, с пeнoй у рта дoкaзывающего что fsck файловым системам такого типа вообще, дескать, не нужeн. Во всяком случае, ZFS он свaтает во все дыpы, а отсутствием fsck для неего iZEN нисколько не смущается. Какое эпичное лицeмерие :). Fsck double standards ;)
Кстати, ведь есть же btrfs-progs-0.19, в них входят следующие утилиты:
- btrfs-convert
- btrfs-image
- btrfs-show
- btrfs-vol
- btrfsck
- btrfsctl
- btrfstune
- mkbtrfsсобственно почему решили не переходить на btrfs как на фс по-умолчанию, или не удовлетворяет стабильность работы данных утилит?
там некоторые утилиты просто заглушки.
> там некоторые утилиты просто заглушки.И в частности fsck - пока не слишком готов к продакшну. С другой стороны радует ответственный подход. Контраст с уровнем пионеров типа изена, которые вопят про то что "fsck не нужен", не так ли? ;)
Киллер фича линусковых фс - отлаженный fsck. Если что то пойдет не так то проехaлся им и все, это как последняя инстанция - если уж он не восстановил то можно выбросить диск.Как раз его и не хватает, тот что есть просто тестирует на некоторые ошибки и ругается, исправлять не умеет.
Ну и еще добавь к этому никакая поддержка RAID, очень низкая скорость при fsync. В результате тормоза, неуверенность в том что делать после краха фс.
эта фича в большинстве фс давно уже не работает нормально на современных объёмах носителей и сейчас она всё ещё есть просто как дань прошлому. Для задач btrfs нужны принципиально новые способы проверки консистентности.
> эта фича в большинстве фс давно уже не работает нормально на современных
> объёмах носителейНе знаю у кого там fsck не работает, а мне он немоунтабельный 500Гб ext3 том отколупал недавно, с минимальным дестроем. Вот в такие моменты и понимаешь что спасательная шлюпка - нужна редко, зато очень плохо если ее не оказалось когда она нужна. А почему, собственно, для бтрфс не должно быть утили которая может производить полные и большие по времени проверки и восстановления которые не может себе позволить драйвер, от которого ожидается что он закончит запрос за какое-то разумное время, а не "ой, тут что-то факапнулось - подождите полчаса пока мы все структуры прямо драйвером перечекаем, чтобы вообще понять масштабы факапа, а пока повисите пожалуйста полчасика в вашем write() пока наш драйвер раздупляет что же там с дисками такое".
Понимаешь... 500 гб в наши дни уже мелочь. У меня дома стоит несколько тб со всяким хламом, а в продакшене можно найти в разы больше на одном сервере на одной ФС. ext3 уже на 0.5 Тб проверяет хрен знает сколько долго, а на терабайтах можно вообще угрохать непозволительно много времени. С ext4 ситуация лучше, но всё равно имеет аналогичный недостаток.Восстановление из бекапов с таким fsck может быть гораздо лучшим или иные архитектурные дублирования данных при которых можно просто выкинуть сбойную фс (или её часть) и создать её заново.
Именно по этому традиционный fsck просто не имеет будущего, современные ФС должны иметь адресные механизмы устранения проблем. Как выше уже писали, это достигается за счёт версионности, контрольных сумм, самодиагностики и т.п.
fsck в скором будушем должны заменить утилиты для тонкой работы, типа как xfs_db для xfs, и они не будут предназначены для рядового автоматического использования простыми пользователями или администраторами.
Текущий btrfsck никуда не годится
I have tested some times ago Btrfs and it was not stable like Ext4. Any comments any other have tested it? I missed on which I run it. Sorry.
I believe that it will be good for use in Fedora 17.
Переход Fedora 16 по умолчанию на файловую систему Btrfs отмененФсе, трава кончилась... бтр - не радует, eth0 - не переименовывается,
крокодил не ловиться, не растёт кокос....
8 августа — понедельник, а у кого-то день рождения...
Вообще от бтрфс нет впечатления, что это быстрая добротная фс. Слишком много костылей - то воткнут ущербный онлайн дефрагментатор, чтоб не деградировала скорость записи при работе с мелкими файлами, то вскрываются проблемы при работе с виртуальными машинами(тормозят на ней жутко). Вообще, если почитать те же федоралисты, то видно, что с бтрфс много проблем у юзеров, в основном это тормоза. Я сам как-то пробовал ее - десктоп стал грузится в разы дольше. Снес, списав на сырость, но совсем недавно прочитал подобный отзыв. Лол.
> Вообще от бтрфс нет впечатления, что это быстрая добротная фс. Слишком много
> костылей - то воткнут ущербный онлайн дефрагментатор, чтоб не деградировала скорость
> записи при работе с мелкими файлами,Вообще-то, CoW дизайн по определению предполагает фрагментацию: изменения в файле пишутся в сторону, т.е. являются фрагментом. А поскольку для удаления снапшотов все-равно нужен механизм garbage collector-а, логично его до кучи немного соптимизировать. Заставить не просто прибивать неиспользуемые блоки, но и попутно раскладывать их более оптимально. Раз уж полезли их лопатить - почему не оптимизировать их размещение для ускорения то?!
Вариантов решения этой проблемы CoW дизайна есть два:
1) Забить на проблему и сделать вид что ее нет, как санки в zfs. Пустить маркетологов вещать как все здорово и так далее. Ну а для компенсации тормозов диска с этой вермишелью потреовать десяток-другой гигз озу. В надежде что запись сперва моментом ухнет в озу а потом всяко как-нибудь выдавится на блины, а то что скорость будет дрянь - типа замаскировали огромным буфером в озу.
2) А можно не класть на проблему а при удалении неиспользуемых блоков снапшотов попутно еще и размещение файлов соптимизировать - похожая по смыслу операция, логично совместить.> то вскрываются проблемы при работе с виртуальными машинами(тормозят на ней жутко).
Дело в том что их дисковые файлы в некоторых форматах тоже реализуют технику copy on write, тоже для снапшотов. Поэтому может выйти так что делается двойная работа: сперва CoW сделает программа а потом еще и файловая система. Но с этим эффектом вполне можно бороться и борятся.
> Вообще, если почитать те же федоралисты, то видно, что с бтрфс много проблем
> у юзеров, в основном это тормоза. Я сам как-то пробовал ее - десктоп стал
> грузится в разы дольше. Снес, списав на сырость, но совсем недавно
> прочитал подобный отзыв. Лол.А вы попробуйте полное журналирование в ext3/4 включить и посмотрите как там будет со скоростью работы :))). А то конечно, журналя только метаданные легко пиндеть что CoW тормозит. Правда вот при столь читерском журналинге если запись прервется на середине - вы на этом самом EXT с журналингом только метаданных получите полуперезаписанный файл. Структуры ФС описывающие его будут корректны. Файл прочтется без ошибок. Только это будет смесь старого и нового содержимого, а что вы будете с этим месивом делать - файловую систему при таком журналировании не интересует. Поэтому для надежной записи файлов без шанса на вот такое - программам приходится жутко извращаться с записью в временный файл и потом стирать старый файл и переименовывать в него новый временный файл. В случае с CoW все это становится несколько излишне, файловая система начинает работать так как оно и должно было бы быть с самого начала.
> В случае с CoW все это становится несколько излишне, файловая система начинает работать так как оно и должно было бы быть с самого начала.Это совсем не так. Чтобы приложение могло так использовать CoW ФС, нужны транзакции и спецальное апи-расширение существующего позиксного интерфейса. А обычный интерфейс при обрыве записи всё равно даст неконсистентные состояния данных, но с другим характером неконсистентности.
Чудес за бесплатно (в смысле простоты использования) не бывает.
>Вообще-то, CoW дизайн по определению предполагает фрагментацию: изменения в файле пишутся в сторону, т.е. являются фрагментом.Просто это проблема прецендентая. Был оформлен баг, был придуман способ решения, была добавлена опция монтирования. Вот это и настораживает - такие вещи должны быть продуманы изначально, если, как ты говоришь, такое поведение по опроеделению.
>Дело в том что их дисковые файлы в некоторых форматах тоже реализуют технику copy on write, тоже для снапшотов.
Опять таки - никто и подумать не мог, что такое может случиться?
>А вы попробуйте полное журналирование в ext3/4 включить и посмотрите как там будет со скоростью работы :)))
Ну тут уже другое - за годы работы у меня ниодного потерянного файла. Я готов использовать такую систему и дальше, но десктоп чтоб грузился быстро. :)
Слышал, что BTRFS - это некий аналог ZFS. Если это так, почему для ZFS не требуется никаких утилит, а для BTRFS требуется? Там исключены любые потери при записи на диск, даже в случае сбоя питания, поэтому такая утилита в ZFS не нужна.
> Слышал, что BTRFS - это некий аналог ZFS. Если это так, почему
> для ZFS не требуется никаких утилит, а для BTRFS требуется? Там
> исключены любые потери при записи на диск, даже в случае сбоя
> питания, поэтому такая утилита в ZFS не нужна.Ты не вполне прав. Дело в том, что ZFS тоже может развалиться в дым. И когда такое происходит, случается трындец. SCRUB ничего восстановить обычно в такой ситуации не может. Если нет избыточности (а какое дятло догадалось параметры ZFS Из коробки поменять? Показываю:
root @ ktulhu / # zfs get copies data
NAME PROPERTY VALUE SOURCE
data copies 1 defaultвот этот, например. Ну или состряпать зеркальный пул:
root @ ktulhu / # zpool status rpool
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 0h6m with 0 errors on Mon Aug 8 18:14:38 2011
config:NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
c1t1d0s0 ONLINE 0 0 0errors: No known data errors
Конечно, если сделать зеркало, задать избыточность, и положить бэкап на другой машине или, того лучше, на ленту - тогда никакого нафиг zfsfsck не нужно. Любой скруббинг элементарно рекаверит данные и метаданные на основе избыточности. Причем выполняется он автоматически. self healing Это называется. BTRFS так не умеет, случайно, не?
(фыркаю) Нашли аналог..... ZFS - это volume manager + fs в одном флаконе. Есть ПОЛНОЦЕННЫЕ аналоги, кроме NetApp?
Наверное вы правы, не силен в этом. Я хотел сделать упор на то, почему для zfc утилита не треба, а для btrfs - треба!
> Наверное вы правы, не силен в этом. Я хотел сделать упор на
> то, почему для zfc утилита не треба, а для btrfs -
> треба!Потому что федоровцы рассматривают переходят на btrfs, а не на ZFS.
Если бы обсуждался переход на ZFS, то они явно не поверили бы в туманные рассуждения о ненужности fsck.
(усмехнувшись) А это не вопрос веры. Джефф Бонвик английским языком объяснил - безо всяких религиозностей - почему в ZFS нет и не будет fsck. Потому что она не допускает разрушения данных by design. И это любому, почесавшемуся почитать ее исходники - открытые! - совершенно очевидно.
> (усмехнувшись) А это не вопрос веры. Джефф Бонвик английским языком объяснил -
> безо всяких религиозностей - почему в ZFS нет и не будет
> fsck. Потому что она не допускает разрушения данных by design. И
> это любому, почесавшемуся почитать ее исходники - открытые! - совершенно очевидно.Епископ объяснил, что Солнце вращается вокруг Земли, а не наоборот. И каждому, кто посмотрит на небо - это совершенно очевидно.
> (усмехнувшись)Хорошо смеётся тот, кто улыбается последним.
> Джефф Бонвик английским языком объяснил - безо всяких религиозностей
Надо же.
> почему в ZFS нет и не будет fsck. Потому что она не допускает разрушения данных by design.
Он в это /верит/. А жизнь показывает иное: http://techcrunch.com/2008/01/15/joyent-suffers-major-downti.../ (Solaris/SPARC, если что).
Поэтому фанатам вроде Джеффа я и не верю, есть более достойные того люди.
В ZFS гарантируеться, что на исправном оборудовании данные консистентны. А если оборудование неисправное то и fsсk не поможет. ИМХО fsck это пережиток прошлого. Во всяком случае в текущих реалиях это нифига не разу не панацея от всех болезней даже на исправном оборудовании. Примеров в сети достаточно.
Тоже не вполне верно. ZFS, при обеспечении хотя бы какой-то избыточности, сохраняет операбельность устройства и целостность данных при выходе из строя до 30% поверхности (в случае винчестеров). У меня был случай на SSD (зазеркаленых) когда накрылось 50% блоков, и пул продолжал работать. Btrfs так могет?И - ах, да - это было не на FreeBSD, а, разумеется, в нативной реализации от Sun.
> В ZFS гарантируеться, что на исправном оборудовании данные консистентны.Не знаю как на солярке, а на фре эта гарантия не раз нарушалась. На вполне исправном оборудовании.
Говорим ZFS, подразумеваем солярку... и далее по тексту. Кому нафиг сдалась сраная фря, да ещё и с гарантией чего-то там.
>> В ZFS гарантируеться, что на исправном оборудовании данные консистентны.
> Не знаю как на солярке, а на фре эта гарантия не раз
> нарушалась. На вполне исправном оборудовании.На солярке тоже, см. ссылку в #163.
> Слышал, что BTRFS - это некий аналог ZFS. Если это так, почему
> для ZFS не требуется никаких утилит, а для BTRFS требуется?Потому что сани избрали метод борьбы с проблемой "это слишком сложно, давайте мы на это забьем и пусть лучше маркетологи втирают как у нас все круто".
На самом деле у них есть пара утилиток на такие случаи, но они именно уровня "fsck в совсем зачаточном состоянии". К чему это ведет? На lissyara.ru есть вполне доходчивый рассказ как человек вручую перебирал пул, самолично разгребая дебри дисковых структур и портил транзакцию с целью спровоцировать отбрасывание проблематичных секторов. Ну вот чтобы так не мучаться вручную в случае когда все стало совсем плохо и нужен fsck.
>> Слышал, что BTRFS - это некий аналог ZFS. Если это так, почему
>> для ZFS не требуется никаких утилит, а для BTRFS требуется?
> Потому что сани избрали метод борьбы с проблемой "это слишком сложно, давайте
> мы на это забьем и пусть лучше маркетологи втирают как у нас все круто".Откуда вы всё знаете? Вы разбирали исходники ZFS?
> На самом деле у них есть пара утилиток на такие случаи, но
> они именно уровня "fsck в совсем зачаточном состоянии".Что за "пара утилиток"?
> К чему это ведет? На lissyara.ru есть вполне доходчивый рассказ как человек вручую перебирал пул, самолично разгребая дебри дисковых структур и портил транзакцию с целью
> спровоцировать отбрасывание проблематичных секторов.Он перебирал дисковые структуры FAULTED пула. Когда ZFS больше не может гарантировать целостность данных, она останавливает работу пула и объявляет его FAULTED.
> Ну вот чтобы так не мучаться вручную в случае когда все стало совсем плохо и нужен fsck.
Вот чтобы так не мучиться, с приходом ZFSv28 введена поддержка команды "zpool import -F poolname", позволяющей перемотать поврежденный пул к состоянию, соответствующему более ранней группе транзакций. Это позволяет с высокой вероятностью восстановить повреждённый пул из состояния FAULTED, когда физические носители целы.
fsck в традиционных ФС плевать хотела на целостность данных. Она чинит только структуру ФС, а найденные остатки от файлов складвает кучкой в каталоге /lost+found.
А вот zpool scrub делает гораздо больше — анализирует метаинформацию ФС на предмет непротиворичивости и сверяет контрольные суммы файлов, затем выводит полный список повреждённых файлов, если обнаружит несоответствие контрольных сумм.
у ZFS кстати никакого zfsfsck нет. И вообще никаких средств проверки целостности и восстановления ФС после сбоя у ZFS нет. на это ещё обращал внимание препод из
redcenter.ru этой весной, когда мы обсуждали UFS vs ZFS в рамках курсов SA-200-S10 и SA-202-S10 (Системное администрирование ОС Solaris 10 (часть I и II)).
>И вообще никаких средств проверки целостности и восстановления ФС после сбоя у ZFS нетМягкое и теплое. Не несите чушь а учите матчасть.
>>И вообще никаких средств проверки целостности и восстановления ФС после сбоя у ZFS нет
> Мягкое и теплое. Не несите чушь а учите матчасть.Нет ОТДЕЛЬНЫХ средств. Они встроены by design.
> у ZFS кстати никакого zfsfsck нет. И вообще никаких средств проверки целостности
> и восстановления ФС после сбоя у ZFS нет. на это ещё
> обращал внимание препод из
> redcenter.ru этой весной, когда мы обсуждали UFS vs ZFS в рамках курсов
> SA-200-S10 и SA-202-S10 (Системное администрирование ОС Solaris 10 (часть I и
> II)).Правильно. Он ей ни на фиг не нужен на исправном железе. Что до выходящего из строя - поддерживается и избыточность, и авто-ресильверинг, и селф-хилинг, и автозамена девайсов из хот-спаров...
PS. BTW, есть спецкурс по администрированию ZFS. В SA-202 только самые общие понятия вводятся. Там спорить просто не о чем.
> Правильно. Он ей ни на фиг не нужен на исправном железе. Что
> до выходящего из строя - поддерживается и избыточность, и авто-ресильверинг, и
> селф-хилинг, и автозамена девайсов из хот-спаров...Про встроенный авторазвалинг на ровном местинге см. по ссылке в #163 или даже вот: http://web.archive.org/web/20080119002501/http://www.datacen...
Прошу прощения, но раз уж сказали "а" говорите и "б"А дело было так
"We got bit by a massive ZFS bug", "Joyent was using an older version of ZFS, and the bug in question was fixed nearly a year ago"
Причем было это в далеком 2008 годуВо всем програмном обеспечении есть ошибки и никто от этого не застрахован. ZFS замечательна by design. И как писали выше by design данные консистентны для исправного оборудования
> Прошу прощения, но раз уж сказали "а" говорите и "б"Разумеется.
> А дело было так "We got bit by a massive ZFS bug", "Joyent was using an
> older version of ZFS, and the bug in question was fixed nearly a year ago"Самое главное "б" тут -- потеряли ли они _данные_ (помимо времени в работе) или удалось вытащить всё. Из http://discuss.joyent.com/viewtopic.php?id=19430 это осталось неясным.
> Во всем програмном обеспечении есть ошибки и никто от этого не застрахован.
Всё-таки некоторые люди создавали нетривиальные программные комплексы без известных ошибок. По-моему, стоит равняться на них, а не заранее позволять себе безответственность.
Ну и бить себя пятою в грудь про байдизайн до хотя бы несколькилетней боевой обкатки и вылавливания таких вот багов -- тоже как-то некрасиво.
> Причем было это в далеком 2008 году
А я ещё пару лет на пушечный выстрел не подойду к ответственности за данные на ZFS, надеюсь. Раз есть энтузазисты, вот пусть их лбами такие грабли и вытаптывают...
PS: с btrfs примерно то же: пусть пыль осядет, тогда будем пробовать потихоньку.
>> Правильно. Он ей ни на фиг не нужен на исправном железе. Что
>> до выходящего из строя - поддерживается и избыточность, и авто-ресильверинг, и
>> селф-хилинг, и автозамена девайсов из хот-спаров...
> Про встроенный авторазвалинг на ровном местинге см. по ссылке в #163 или
> даже вот: http://web.archive.org/web/20080119002501/http://www.datacen...Ага: "By Rich Miller January 16, 2008".
Ты дату смотрел?
А размер имени файла теперь увеличиться?
А то надоело, сохранишь web страничку в форточках, а потом на самбу не скопировать.