Крис Мейсон (Chris Mason), создатель и главный архитектор файловой системы Btrfs, прокомментировал (http://www.heise.de/open/meldung/Btrfs-Erfinder-stuft-sein-L...) появившиеся в прессе домыслы о том, что основные разработчики Btrfs не считают данную ФС стабильной, несмотря на её готовность для промышленного применения в дистрибутивах Oracle 7 и SUSE 12 (в RHEL 7 ФС Btrfs отмечена, как технология для ознакомления). Крис считает, что Btrfs уже является стабильной файловой системой, но добавляет, что несмотря на это данная ФС ещё интенсивно развивается, поэтому не все возможности готовы для промышленного применения. В частности, ещё предстоит доработать встроенную в Btrfs реализацию RAID 5 и 6. Тем не менее данная практика добавления новшеств не является чем то особенным, подобные экспериментальные возможности добавляются и в Ext4 и XFS, но не включаются по умолчанию (как и в Btrfs).
По поводу применения Btrfs по умолчанию в SUSE Linux Enterprise 12, Крис отметил, что компания SUSE является одним из активных участников разработки как компонентов ядра, так и пользовательских утилит Btrfs, поэтому отлично понимает, какие возможности можно предоставлять пользователям, а какие нет. Например, по уровню производительности в нагрузках, свойственных СУБД, Btrfs пока отстаёт от Ext4 и XFS, поэтому SUSE не рассматривает Btrfs как панацею и рекомендует клиентам наиболее оптимальные решения для разных видов приложений (в SUSE Linux 12 ФС Btrfs используется по умолчанию для системных разделов, для разделов с данными рекомендуется XFS). Интерес вызывают причины отключения в SUSE Linux 12 по умолчанию поддержки сжатия данных в Btrfs, Крис Мейсон считает данные возможности стабильными и ждёт пояснений от SUSE о причинах такого решения и готов способствовать устранению проблем, если такие имеются.
Другие разработчики также придерживаются мнения о стабильности Btrfs, что подтверждает совершенное в августе этого года удаление (http://git.kernel.org/cgit/linux/kernel/git/kdave/btrfs-prog...) из кода утилит Btrfs флага, сигнализирующего об экспериментальном характере ФС. Аналогичные предупреждения о нестабильности дискового формата Btrfs были (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) убраны (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) из кода яда Linux ещё в 2013 году.URL: http://www.heise.de/open/meldung/Btrfs-Erfinder-stuft-sein-L...
Новость: http://www.opennet.me/opennews/art.shtml?num=40955
Они упоролись, io шедуллер вешает декстопную подсистему.
Использую F2FS на ArchLinux
Арчешкольник рассуждает об упоротости, смешно.
> Использую F2FS на ArchLinuxпосле этой новости -- перестань :)
> Они упоролись, io шедуллер вешает декстопную подсистему.
> Использую F2FS на ArchLinuxОни не упоролись, просто скоро опять 14 февраля и:
> Крис считает, что Btrfs уже является стабильной файловой системой ...
Гарри Поттеринг на фоне Криса нашего Мэйсона выглядит просто жалким неудачником.
> Гарри Поттеринг на фоне Криса нашего Мэйсона выглядит просто жалким неудачником.Завидуй уж молча, пользователь putty.exe
>> Гарри Поттеринг на фоне Криса нашего Мэйсона выглядит просто жалким неудачником.
> Завидуй уж молча, пользователь putty.exeТы сам-то БТР себе поставил, любитель дыр в баше ?
> Ты сам-то БТР себе поставил, любитель дыр в баше ?Да. Не везде еще, ибо у меня своя голова на плечах и я сам себе гуру в вопросах качества. Но оно уже работает и мне в целом нравится то что я вижу. Для себя я считаю так: ОК для неответственных применений.
> Они упоpолись, io шедуллер вешает декстопную подсистему.
> Использую F2FS на ArchLinuxЭто точно они, а не вы? Каким боком тут Мэйсон и его бтр?
Юзаю btrfs с сжатием, снапшотами и send/receive для бэкапа - проблем не знаю. А какой из " io шедуллеров" у вас "вешает" какую "декстопную подсистему"?
>io шедуллер вешает декстопную подсистему.
>ArchLinuxЭто норма!
В линуксе есть десктопная подсистема? Вот это поворот!
> В линуксе есть десктопная подсистема? Вот это поворот!Если как следует тянуть, можно притянуть за уши drm/kms. Правда, его не клинит. Ни с f2fs, ни без.
> Они упоролись, io шедуллер вешает декстопную подсистему.
> Использую F2FS на ArchLinux:)
А насколько его мнение коррелирует с реальным положением дела?
А то вроде установочник новой Суси должен эту ФС теперь предлагать по умолчанию.
Что? Может просто эта ФС будет светиться в списке возможных при разбивке диска? Или таки как дефолтный вариант?
> Или таки как дефолтный вариантИ пару тысяч наложенных патчей.
Похоже, что дефолтный: http://www.opennet.me/opennews/art.shtml?num=40650
уже вроде год назад как дефолт. криокамера?
Не надо звездеть !Год назад была выпущена openSUSE 13.1 в ней по дефолту была ехт4, а для сапёров была возможность покататься на БТРе.
Читай сюда:
Much effort was put in testing openSUSE 13.1, with improvements to our automated openQA testing tool, a global bug fixing hackathon and more. The btrfs file system has received a serious workout and while not default, is considered stable for everyday usage.
Взято отсюда: https://en.opensuse.org/Portal:13.1
Полезай обратно в машину времени и отправляйся назад в будущее.
Вполне стабильно для обычных компьютеров. Пользуюсь уже год, и проблемы только с GRUB. Проблемы в общем-то не критичные, система от них не страдает, но обязательно раз в два месяца GRUB слетает. Надоело уже. Надеюсь в OpenSUSE 13.2 его наконец починят. Также надеюсь что в 13.2 GRUB наконец научат писать на btrfs.
А что с ним такое вообще? Да ещё так стабильно слетает — раз в пару месяцев.
Релиз через 6 дней, увидим, что и как.
Использую на домашнем десктопе Kubuntu c разделами на btrfs, в т. ч. /boot. C GRUB2 проблем никаких не наблюдается. Ни разе не слетал. В остальном все также отлично. Пользоваться btrfs-снимками уже привык и даже не представляю чтобы делал без них в Ext4.
> Проблемы в общем-то не критичные
> обязательно раз в два месяца GRUB слетаетОтличная реклама стабильной работы!
>> Проблемы в общем-то не критичные
>> обязательно раз в два месяца GRUB слетает
> Отличная реклама стабильной работы!Космический учитель Марк научил нас широким взглядам на понятие стабильности %)
> Космический учитель Марк научил нас широким взглядам на понятие стабильности %)В системе от Марка grub не слетает. Ни с btrfs ни как либо еще. Приветы стабильной зюзе, которая стабильно в зюзю.
> Приветы стабильной зюзе, которая стабильно в зюзю.Ты поосторожнее: за подобную петросянщину одноклассники тебя побьют.
> Ты поосторожнее: за подобную петросянщину одноклассники тебя побьют.Тебе как эксперту по взаимоотношениям с одноклассниками виднее. А мои одноклассники - я даже не знаю где они.
>> Ты поосторожнее: за подобную петросянщину одноклассники тебя побьют.
> Тебе как эксперту по взаимоотношениям с одноклассниками виднее. А мои одноклассники -
> я даже не знаю где они.На домашнее обучение перевели ?
Вряд ли проблемы с GRUB в OpenSuse не связаны с btrfs. При апдейте системы grub в опенсусе часто загибается независимо от используемых фс.
> Вполне стабильно для обычных компьютеров. Пользуюсь уже год, и проблемы только с
> GRUB. Проблемы в общем-то не критичные, система от них не страдает,
> но обязательно раз в два месяца GRUB слетает. Надоело уже. Надеюсь
> в OpenSUSE 13.2 его наконец починят. Также надеюсь что в 13.2
> GRUB наконец научат писать на btrfs.Эпично ...
Как всегда - коррелирует прямо параллельно с реальностью, но Крис не унывает.> Интерес вызывают причины отключения в SUSE Linux 12 по умолчанию поддержки сжатия данных в Btrfs, Крис Мейсон считает данные возможности стабильными и ждёт пояснений от SUSE о причинах такого решения и готов способствовать устранению проблем, если такие имеются.
Берегись, SUSE, Крис строго спросит с тебя за твои проделки, а если надо то и проблемы порешает - всё будет в шоколаде к 14 февраля.
> Как всегда - коррелирует прямо параллельно с реальностью, но Крис не унывает.Файлуха от Криса работает, при том довольно шустро. И умеет в разы больше чем другие. Но вам то с вашим putty.exe завидно, понятное дело. У вас такого еще декаду не будет в вашей максималке.
> Берегись, SUSE, Крис строго спросит с тебя за твои проделки
Крис и его разработчики починили тот редкий но меткий взвис кода сжатия. Зюзя может быть спокойна.
> А насколько его мнение коррелирует с реальным положением дела?Вполне. Если raid5/6 не трогать и понимать отличие CoW от классики то все ОК.
Из моего опыта, всё-таки, btrfs иногда умирает. У меня умирала в общей сложности раза четыре. Всегда с одинаковыми симптомами: внезапно перестаёт создавать/редактировать/удалять файлы на ФС с отмазой "нема места". Читаются файлы при этом прекрасно. Никаких методов адекватной реанимации я в своё время не нашёл.Использовал btrfs на протяжении двух лет в качестве основной fs на arch linux дома и на работе. Умирала на разных системах. Использовал только на SSD, subvolumes не использовал, прозрачное сжатие не включал.
На OpenSUSE 13.1 вот уже как год с btrfs полёт стабильный. Отваливается только богопротивный GRUB, но редко.
> На OpenSUSE 13.1 вот уже как год с btrfs полёт стабильный. Отваливается
> только богопротивный GRUB, но редко.Это мазохизм.
> Это мазохизм.А в убунте не отваливается. Делаем выводы...
По опыту общения с Бубунтой скажу, что там просто другие методы истязаний. Вместо наручников связывают ремнём. :-)
> Это мазохизм.Да нет. Всё равно Linux запускается по дефолту. А переустановить GRUB - 2 секунды. Учитывая, что происходит это раз в два месяца, то особо не волнует.
>> Это мазохизм.
> Да нет. Всё равно Linux запускается по дефолту. А переустановить GRUB -
> 2 секунды. Учитывая, что происходит это раз в два месяца, то
> особо не волнует.Так что именно отваливается? Загрузчик или меню загрузчика?
Если только меню - подозреваю, что баг в разметке диска. Кто-то затирает дополнительную область данных grub (она расположена обычно между MBR и первым разделом, как на GPT - не знаю).
А вот у меня с указанными симптомами ломалась на OpenSUSE 13.1.
Похоже на эту проблему: https://bugzilla.kernel.org/show_bug.cgi?id=76481
> btrfs иногда умирает
> Использовал btrfs на протяжении двух лет в качестве основной fs на archПричина - в arch
>> btrfs иногда умирает
>> Использовал btrfs на протяжении двух лет в качестве основной fs на arch
> Причина - в archПай-мальчик с наложенными патчами на мозг.
> Причина - в archВесьма зависит. Для бтр стоит использовать новые ядра. Желательно последний релиз с кернелорга.
Вот тебе и новые ядра.
https://bugs.archlinux.org/task/42563?project=1&order=dateop...
> Вот тебе и новые ядра.Дак там и написано - починено в 3.18-rc2. Он что, не свежий? ;)
Проблема была в 3.17.1, пофикшена в 3.17.2 Не вижу ничего криминального.
> Использовал btrfs на протяжении двух лет в качестве основной fs на arch linux дома и на работе. Умирала на разных системах.использовал (и использую) btrfs на разных компьютерах -- несколько лет подрят.
работаю с очень большим количеством мелких файлов (в день примерно создаю по 60000 файлов).
btrfs ни разу не умирала. файлы тоже не портила.
идинственное на что могу пожаловаться: раньше (в первые годы когда начал пользовать btrfs) оно работала не сильно быстро. но сейчас (в последние месяцы) -- скорость btrfs на HDD стала явно выше чем раньше.
но а на компьютере в котором SSD -- btrfs вообще работает замечательно. (хотя на SSD так подозреваю что любая файловая система работает замечательно :))
> работаю с очень большим количеством мелких файлов (в день примерно создаю по
> 60000 файлов).Ради интереса сделал торентокачалку с btrfs. Бывало все. Слетало питание, машина ребуталась на всем скаку, etc. Не сдохло до сих пор.
> Из моего опыта, всё-таки, btrfs иногда умирает. У меня умирала в общей
> сложности раза четыре. Всегда с одинаковыми симптомами: внезапно перестаёт создавать/редактировать/удалять
> файлы на ФС с отмазой "нема места". Читаются файлы при этом
> прекрасно. Никаких методов адекватной реанимации я в своё время не нашёл.Эта "проблема" давно известна. У вас просто размер метаданных вылез за все мыслемые пределы - решается через подключенную влешку с расширением filesystem на нее, последующим balance и изъятием последней.
> Использовал btrfs на протяжении двух лет в качестве основной fs на arch
> linux дома и на работе. Умирала на разных системах. Использовал только
> на SSD, subvolumes не использовал, прозрачное сжатие не включал.У меня все в точности наоборот, за исключением того что я тоже использую дома, а в продакшн - пока только под бэкапы.
> Эта "проблема" давно известна. У вас просто размер метаданных вылез за все
> мыслемые пределы - решается через подключенную влешку с расширением filesystem на
> нее, последующим balance и изъятием последней.решается намного проще, и навсегда: выкидыванием бтра в мусорку.
>> Эта "проблема" давно известна. У вас просто размер метаданных вылез за все
>> мыслемые пределы - решается через подключенную влешку с расширением filesystem на
>> нее, последующим balance и изъятием последней.
> решается намного проще, и навсегда: выкидыванием бтра в мусорку.Ох ты ж! Ретрограды с поломанным шифтом потянулись на свет! )
да, мы такие, ретрограды. любим, когда всё нормально работает. это у молодых и задорных дури много, вот они по граблям и прыгают. бешеной собаке семь вёрст не крюк.
> да, мы такие, ретрограды. любим, когда всё нормально работает. это у молодых
> и задорных дури много, вот они по граблям и прыгают. бешеной
> собаке семь вёрст не крюк.Ежели ничего не меняется, то по большей части нечему и ломаться. А "молодые и задорные" двигают вперед это ядро и эту ОС.
угу. системдецы пишут и вяленды. потому что для молодости и задора места хватило, а для ума — нет.впрочем, немолодые идиоты там тоже есть: тот же пакард, например.
Один только arisu стоит в белом пальто, красивый и с ФГМ.
> Один только arisu стоит в белом пальто, красивый и с ФГМ.И чем то неуловимо напоминает новодворскую ...
Вспомнилось, кстати:- Вы мудры.
- Нет, это великое заблуждение - о мудрости стариков. Старики не мудры. Они только осторожны.
- Быть может, это и есть мудрость.
- Это очень непривлекательная мудрость.Премудрым пискарям всегда кажется, что они нереально умны, а вокруг - молодые-зелёные идиоты, делающие глупости и рискующие попусту, хехехе.
"Насыщает не время проведенное в столовой, а количество съеденных беляшей".
> угу. системдецы пишут и вяленды. потому что для молодости и задора места
> хватило, а для ума — нет.
> впрочем, немолодые идиоты там тоже есть: тот же пакард, например.И вас с добрым утром.
>> да, мы такие, ретрограды. любим, когда всё нормально работает. это у молодых
>> и задорных дури много, вот они по граблям и прыгают. бешеной
>> собаке семь вёрст не крюк.
> Ежели ничего не меняется, то по большей части нечему и ломаться. А
> "молодые и задорные" двигают вперед это ядро и эту ОС.Понимаете, тут Важен баланс.
С одной стороны при разработке новых систем получается новый опыт, специалисты, код, который будет использован в иных местах и т.д.
И это прекрасно, независимо от того, стал ли продукт успешным.Но с другой стороны, не надо впадать в другую крайность - когда код пишется ради кода.
И простите, именно "молодые и задорные" часто и этим и занимаются.И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".
> И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".Как показывает практика, вред от старых маразматиков "не-трожь-здесь-так-заведено" обычно с лихвой перевешивает пользу.
>> И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".
> Как показывает практика, вред от старых маразматиковПрактика говорите ? Чья ? Ваша на основании отдельного случая ? Точно также я могу сказать - часто вред от "дерзких и молодых" такой, что никаким старикам не снился.
И могу подпереть фактами.
И вообще мы отвлеклись от темы, вернемся к ней.
Мы обсуждаем фактическое состояние кодовой базы ФС для внедрения в продакшен.
Так вот, суть в том, что простите, требования "надежности", которые были оглашены - не блажь.
Увы, но если копнуть, то ФС этому требованию не удовлетворяет.P.S.
Для саморазвития - отличная болгарская сказка "Почему старикам почёт" - http://www.niworld.ru/Skazki/Skazki_slavian/bolgar/starikam_...
> И могу подпереть фактами.Факт простой: если бы всех все устраивало - мы бы обменивались папирусами через конных курьеров и развлекались наскальной живописью. Вот такой вот "вред" от этих, двигающих технологии вперед.
Именно им поем мы славу. Их мы запишем в учебники и поколения инженеров будут помнить кто был основой технологических достижений. А вас мы будем помнить только как научный курьез и помеху.
>> И могу подпереть фактами.
> Факт простой: если бы всех все устраивало - мы бы обменивались папирусами
> через конных курьеров и развлекались наскальной живописью. Вот такой вот "вред"
> от этих, двигающих технологии вперед.Вы занимаетесь шулерством, подменяя понятия.
Вы, как часто бывает, вместо того, чтобы понять о чем говориться, начали смешивать понятия и приписывать оппоненту то, чего он не говорил и даже не думал.
С какой радости молодость == продвижение прогресса прогресса ?> Именно им поем мы славу. Их мы запишем в учебники и поколения
> инженеров будут помнить кто был основой технологических достижений.Только к молодости/старости это отношения иметь не будет вообще никакого.
Кроме того, говоря о прогрессе как явлении, я уже выше писал свою позицию про "разумный баланс".> А вас мы
> будем помнить только как научный курьез и помеху.Уважаемый, давайте прекращать пустопорожнее словоблудие.
Мы обсуждаем конкретную тему - создатель Btrfs считает, что система готова для прода.
На наши замечания, что есть проблемы реального характера и надо их устранять, такие как Вы начинаете бросаться обвинениями в "ретроградстве" а потом вещать "как научный курьез и помеху".
Может Вы прислушаетесь к гласу разума ?
> Мы обсуждаем конкретную тему - создатель Btrfs считает, что система готова для прода.Так по факту - если и врет, то не сильно. Т.е. для не слишком ответственных применений уже можно опробовать. Но да, свежие фикшеные ядра - наш друг и товарищ.
> Может Вы прислушаетесь к гласу разума ?
Ок, и он говорит мне: идите в пень, зануда. На таких как вы жалко тратить время. У вас там как, DOS 1.0 и FAT 12 уже достаточно стабильны, или еще не совсем? (вопрос риторический)
>> Может Вы прислушаетесь к гласу разума ?
> Ок, и он говорит мне: идите в пень, зануда. На таких как
> вы жалко тратить время.Потратьте не на меня, а на изучения того, как работает ZFS, и как это работает.
Потом поставьте рядом наш предмет обсуждения и сравните.
Может быть тогда Вы поймете степень своего заблуждения.
> Потратьте не на меня, а на изучения того, как работает ZFS,Особенно посмотрите в сорцы и алгоритмы. И увидите в ZFS некое кривое недоразумение с кучей вполне ожидаемых технических проблем.
> Потом поставьте рядом наш предмет обсуждения и сравните.
Автор btrfs хотя-бы понимает что он хочет получить и не компенсирует технические продолбы маркетинговым булшитом.
>> Потратьте не на меня, а на изучения того, как работает ZFS,
> Особенно посмотрите в сорцы и алгоритмы.И вы можете процитировать работы, в которых опубликованы "алгоритмы btrfs"?
>> И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".
> Как показывает практика, вред от старых маразматиков "не-трожь-здесь-так-заведено" обычно
> с лихвой перевешивает пользу."Работает - не трогай, а хорошо работает тем более ..." - не зря придумано ...
> да, мы такие, ретрограды. любим, когда всё нормально работает.Вот и кондыбай отсюда на своей бричке.
>> да, мы такие, ретрограды. любим, когда всё нормально работает.
> Вот и кондыбай отсюда на своей бричке.это ты, конечно, круто сказанул, да. xfs у нас теперь «бричка». а бтр, видимо, «боинг». собраный таджиками, потому что летает хреново и периодически падает на землю.
> бтр, видимо, «боинг». собраный таджиками, потому что летает хреново и периодически
> падает на землю.XFS не умеет снапшоты. И с метаданными работает медленно. И разный RAID разным файлам он не сделает. И журналирует только метаданные, а на участь данных - плевать хотел. Раньше вообще "на всякий" протирал файлы нулями в спорных случаях. А т.к. журналинг только метаданных - таких случаев есть. А боинги у нас нормально летают. Хоть для этого и требуется определенный уровень компетенции.
>> бтр, видимо, «боинг». собраный таджиками, потому что летает хреново и периодически
>> падает на землю.
> XFS не умеет снапшоты.и не собирался уметь: он это оставляет volume manager'у. LVM отлично умеет с XFS взаимодействовать в этом плане.
> И с метаданными работает медленно.
что значит «медленно»? по сравнению с чем? нет, бтр не предлагать, оно нифига не стабильное ещё. вот как стабилизируется — тогда и посмотрим.
> И разный RAID разным файлам он не сделает.
что это и зачем оно надо?
> И журналирует только метаданные, а на участь данных - плевать хотел.
всегда было интересно, чем «журналирование просто данных» отличается от «записываем данные на диск», и как это должно работать вообще.
> Раньше вообще «на всякий» протирал файлы нулями в спорных случаях.
не встречал. а у jfs встречал, кстати.
> А боинги у нас нормально летают. Хоть для этого
> и требуется определенный уровень компетенции.и любовь к экстриму.
> и не собирался уметь: он это оставляет volume manager'у. LVM отлично умеет
> с XFS взаимодействовать в этом плане.За глаза я считаю затею делать снапшоты на блочном уровне тухлой идеей - это тормозно, оверхед адский. И гибкость чугунной гири в комплекте. Себе это оставь, а я хочу чтобы все это работало по человечески. Я уже наелся снапшотирования виртуалок на блочном уровне в их диске-в-файле, достаточно для того чтобы не желать такое же непотребство на файлухе хоста. Если в виртуалках это трудноустранимое зло (не вижу как это красиво и без костылей для VM можно обтяпать по другому, разве что системдец допилят и вируалка сама будет себя снапшотировать получив команду на свой системдец от parent-системдеца), которое зачастую и кладет I/O, получить такое же гэ еще и на железяке? Нет уж, иди в пень. Ты как замшелый ретроград снапшотами поди просто не пользуешься совсем и именно тебе поэтому пофиг как оно работает. Как мой телепатор, сработал? :) Ну а мне надо нормально работающие снапшоты, а не этот LVM на отъ...сь, извини. Сам снапшотируй XFS LVM, имхо. А как по мне так это попытка приделать деревянному биплану крыло с изменяемой геометрией. Как-то летать, конечно, будет. А зачем мне "как-то"? Мне надо best of the best.
> что значит «медленно»? по сравнению с чем?
Да хоть с экст4 элементарным. Да и бтр. И вообще много кем. Продуть xfs в плане работы с кучей мелочи когда ворочание метаданных сравнимо или превышает ворочание данных сможет разве что какой-нибудь FAT. В новых ядрах немного подтянули, но все-равно мне не нравится. У меня есть тома в XFS, они только под большие файлы. Ибо с метаданными XFS тупит.
> нет, бтр не предлагать, оно нифига не стабильное ещё.
Эксперименты показали что в целом он вполне себе работает. Да там бывают баги. И невкусные. Но они бывают и в ext4. И в xfs. И много где еще. Если список коммитов в ядро почитать. Оно не чемпион по скорости. Хотя это тоже обсуждаемо. Покажи еще кого-нибудь кто делает full журналирование данных+метаданных и сделает это быстрее. А то журналить только метаданные - это читерство и ценой оного - потенциально неконсистентные данные. Я конечно понимаю что половинка старого файла и половина нового - это круто, только большинство файлов при этом нечитабельны. Мухлеж с журналингом только метаданных мне не нравится.
> вот как стабилизируется — тогда и посмотрим.
Как по мне так это от уровней требований зависит.
> что это и зачем оно надо?
А затем что мне не очевидно что у меня все файлы с одинаковой ценностью. И мне возможность заказать файлухе как мне размещать файло видится большим шагом вперед над классическими дубовыми схемами raid ориентированными на сферический мир в вакууме, где у файлов одинаковая ценность, у дисков одинаковый объем, а уж переиграть конфигурацию и вовсе никогда не хочется. Ибо разбирать большой райд - удовольствие ниже среднего.
> всегда было интересно, чем «журналирование просто данных» отличается от «записываем
> данные на диск», и как это должно работать вообще.В случае классики типа xfs/ext4/... - тем что файлуху не парит вопрос консистентности данных. Если перезаписывался файл и тут вдруг крах - метаданные конечно будут логически корректны, но вот запись дошла до середины файла. И крах. И чего? У меня половина нового и половина старого файла. Информации для отката или доведения операции до конца нет, ибо на то и журналирование только метаданных. И чего с таким файлом делать? В случае CoW это не будет проблемой, ибо старое состояние файла не разрушается, а новое - или уж допишется, и далее апдейтом метаданных получится новый вид, или уж продолбается и при откате после краха на прошлый чекпойнт - файл останется "как было". EXT4 умеет полный журналинг но на классике это тормозно. XFS так не умеет совсем, to the best of our knowledge. А файлы как живые по метаданным, но черти с чем внутри - как-то не прикольно.
> не встречал. а у jfs встречал, кстати.
Более-менее замочили в районе 2.6.28, когда всех окончательно задолбало. Однако все остальное по части журналинга только метаданных - в силе, см. выше - это очень лайт версия журналирования, проблема которой в том что для данных НЕТ никакого undo или intention лога вообще. И запросто выйдет смесь старых и новых данных.
> и любовь к экстриму.
Ну ездийте на бричках. Только нефиг нам в спину шипеть, когда мы трансокеанские рейсы делаем.
> За глаза я считаю затею делать снапшоты на блочном уровне тухлой идеейэто да, лучше каждый свой велосипед будет придумывать.
> Ты как замшелый ретроград снапшотами поди просто не пользуешься
> совсем и именно тебе поэтому пофиг как оно работает.и ты таки угадал: я в них не вижу особого смысла. нет у меня привычки сначала приводить систему в состояние жопы, а потом радостно откатываться на старый снапшот. мне и LVM хватает.
> А как по мне так это попытка приделать деревянному биплану крыло
> с изменяемой геометрией. Как-то летать, конечно, будет. А зачем мне "как-то"?
> Мне надо best of the best.оно и видно, да. crc32 в качестве хэш-функции — это бэст, не поспоришь. общий бэкграунд авторов в CS показывает очень наглядно.
>> что значит «медленно»? по сравнению с чем?
> Да хоть с экст4 элементарным.ты ещё с прямой записью сравни, ага — где сразу через DMA на диск фигачит в известные области.
> Продуть xfs в плане работы с кучей мелочи
а зачем ты xfs так используешь? не надо. у тебя вообще большинство проблем от того, что ты инструменты не по назначению используешь.
>> нет, бтр не предлагать, оно нифига не стабильное ещё.
> Эксперименты показали что в целом он вполне себе работает.спасибо, когда у меня появятся ненужные файлы… нет, и даже их я не буду на бтр класть, я их просто сотру: они ненужные. я и к ext4 насторожено отношусь, а она более вылизана, чем бтр.
> кого-нибудь кто делает full журналирование данных+метаданных и сделает это быстрее.
а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать это путём создания нового и атомарного rename. а если файл большой — то это, обычно, какая-нибудь БД, и пусть журналом сама БД и занимается: она лучше знает, как со своими файлами работать.
ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно призвано не твои файлы спасать, а FS: чтобы FS после крэша была в консистентном состоянии. это, кстати, не только твоя беда: очень много людей отчего-то считают, что журналирование должно их файлы спасать. это не так; спасение файлов — задача программы, которая с этими файлами работает. а задача FS — не вставать раком, если вдруг что.
>> вот как стабилизируется — тогда и посмотрим.
> Как по мне так это от уровней требований зависит.требование простое: не терять мои файлы. пока что raiser3, jfs и xfs с этим справляются. судя по интернетам, бтр справляется не всегда. будем подождать.
>> что это и зачем оно надо?
> А затем что мне не очевидно что у меня все файлы с
> одинаковой ценностью. И мне возможность заказать файлухе как мне размещать файло
> видится большим шагом вперед над классическими дубовыми схемами raid ориентированными
> на сферический мир в вакууме, где у файлов одинаковая ценность, у
> дисков одинаковый объем, а уж переиграть конфигурацию и вовсе никогда не
> хочется. Ибо разбирать большой райд - удовольствие ниже среднего.пиши разные файлы на разные рэйды. объединяй оверлейной FS. в чём проблемы-то? опять ты инструменты не туда и не так.
>> всегда было интересно, чем «журналирование просто данных» отличается от «записываем
>> данные на диск», и как это должно работать вообще.
> В случае классики типа xfs/ext4/... - тем что файлуху не парит вопрос
> консистентности данных.и это правильно. см. выше.
> Ну ездийте на бричках. Только нефиг нам в спину шипеть, когда мы
> трансокеанские рейсы делаем.пока что я наблюдаю, как вы весело бегаете кругами, периодически собирая свой развалившийся на части мегаболид. а потом ещё: «ой! тут пассажир был! где пассажир? никто пассажира не видел?!»
безумству храбрых, конечно, и всё такое. но я лучше пока что на «бричке» доеду. пока ваш болид круги описывает и проверяет носом стены на прочность.
p.s. претензии, если что, не к тому, что болид разваливается, а к тому, что это выдают за «стабильное состояние, готовое к повседневному применению». нет, не готово пока.
> это да, лучше каждый свой велосипед будет придумывать.Ты внезапно полюбил машины для бритья, делающие всем одинаковую форму лица? Это что-то новое :). Да, я не против нового вела, если он ездит лучше старых.
> и ты таки угадал: я в них не вижу особого смысла.
Вот видишь, я получаю +1 к скиллу телепатии ;). Зато смысл вижу я - БЫСТРОЕ приведение системы и/или данных в вид "как было" за какие-то секунды. Очень здорово исправлять даже серьезные продолбы или последствия экспериментов за единицы секунд.
> нет у меня привычки сначала приводить систему в состояние жoпы,
А я хочу возможность постановки unsafe системных экспериментов с возможностью быстренько сгонять в прошлое на машине времени и отменить эксперимент, если результат не понравился. Да и промахи при работе с файлами можно переиграть. Я человек и поэтому иногда могу делать ошибочные действия. Редко, но достаточно для желания возможности undo.
> а потом радостно откатываться на старый снапшот. мне и LVM хватает.
Кому и брички - выше крыши. Я что, спорю?
> оно и видно, да. crc32 в качестве хэш-функции — это бэст,
Я считаю это небольшим продолбом. В том плане что специально себе простреливать пятки я не намерен, а проблемой это будет разве что когда злонамеренная ремота может файлы с 100% контролируемыми именами вгружать. Оно как бы да, но это нишевая ситуация. А имея доступ к файловым операциям я как бы любую ФС ушатать могу, тюкнув по болючим местам. Worst case у всех хуже average. Это данность.
> общий бэкграунд авторов в CS показывает очень наглядно.
Пользуйся миниксом от одного из светил CS, я не против. А инженерные решения для реального мира балансируют так чтобы нормально работало и умело то что надо. Из какого гуано и палок и что там слеплено очень отдельный вопрос, интересный паре эстетов на планете.
> ты ещё с прямой записью сравни, ага — где сразу через DMA
> на диск фигачит в известные области.EXT4 - вполне сравнимый по общим идеям в логике работы. Деревья, эктенты, журнал только метаданных. Вполне сравнимые экспонаты. Ну да, ext4 несколько более лайтовый и упрощенный а xfs более навернутый, но имхо это разные перепевки похожих наборов идей.
> а зачем ты xfs так используешь? не надо. у тебя вообще большинство
> проблем от того, что ты инструменты не по назначению используешь.Читать учись. Я ж сказал что для больших файлов юзается. Для мелочи это сакс. Регулярно проверяю чисто из научного интереса. Сакс. Менее сакс чем было, но все-таки. Файлуха для любителей нелинейного монтажа и т.п. - SGI и есть SGI :).
> я и к ext4 насторожено отношусь,
Хз, он дефолтный в куче дистров и массовых воплей нет. Была парочка жирных багов, но - нишевых и на них маловероятно нарваться при обычных применениях. А в целом судя по изменениям оно не только стабильное, но и это вероятно по состоянию на сейчас один из наиболее протестированных кодов ФС вообще.
> а она более вылизана, чем бтр.
Это совпадает с моими наблюдениями над коммитами, но см. выше. И мое мнение валидно для here and now - 3.17+. Я не археолог, в винтажных ядрах пусть другие колупаются.
> а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать
> это путём создания нового и атомарного rename.Это всего лишь гнусный костыль по поводу у..щных свойств файлухи. Ясен пень, большинство програмеров забывает это вкостылить.
> а если файл большой — то это, обычно, какая-нибудь БД,
Очередное левое допущение. Если ты еще не понял - меня не прет обрубать мои задачи под умения первобытных инструментов.
> и занимается: она лучше знает, как со своими файлами работать.
Скажу БТРу chattr +C на файл базы и он для нее и журналов станет обычной подложкой. Гибкость файлухи под разные сценарии - это хорошо.
> ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно
> призвано не твои файлы спасать, а FS: чтобы FS после крэша
> была в консистентном состоянии.Буллшит. По нормальному журнал делает логику все или ничего. И я получаю или новое состояние или старое. Это логично. Но оказалось что писать данные на диск дважды - тормозно, поэтому применяют такой tradeoff целостности данных на скорость. Я не приветствую такие инженерные подходы и поэтому считаю CoW epic win'ом, хоть это и несет свои проблемы.
> не так; спасение файлов — задача программы, которая с этими файлами
> работает. а задача FS — не вставать раком, если вдруг что.Я считаю иначе и предпочел бы это видеть свойством файлухи а не программ. Построить 1 файлуху - реально. А всех програмеров планеты - не очень. Поэтому я за делегирование этого на уровень файлухи, и ниипет. Так оно реально будет работать. А строить всех програмеров на костылирование у...щных ФС - это без меня. Я считаб неспособность ФС обеспечить честную транзакционность техническим дефектом.
> требование простое: не терять мои файлы. пока что raiser3, jfs и xfs
> с этим справляются. судя по интернетам, бтр справляется не всегда. будем
> подождать.Ну это все как бы логично. А с моей колокольни я вижу что btrfs'ная алгоритмика может справиться с рядом проблем на которые все традиционно клали с прибором. Меня это утомило и очень хорошо что Мэйсон решил показать этим "я так привык" как такое на самом деле надо было делать.
> пиши разные файлы на разные рэйды. объединяй оверлейной FS. в чём проблемы-то?
В том что опять же фигово с гибкостью и геморно в управлении. У btrfs это красивее сделано. Есть девайсы, есть заказ разложить вон то вон так. А btrfs юзая свободное место этих девайсов может запрос разрулить. Убедительный и храбрый шаг вперед, мистер Мэйсон. Намного более умный подход к управлению томами и местом на них, имхо.
> опять ты инструменты не туда и не так.
Как я уже сказал - я труба шатал изгибаться буквой зю под кривые инструменты и постоянно обрубать мои нужды под их у...щность.
> и это правильно. см. выше.
А я хочу иное поведение ФС, мне не нравится журналинг только метаданных и я с удовольствием с такими халтурными технологиями распрощаюсь.
> пока что я наблюдаю, как вы весело бегаете кругами, периодически собирая свой
> развалившийся на части мегаболид.Ммм? И чего я собирал по частям? Кстати там еще и годный тул для неразрушающего восстановления есть. Это вообще круть и аналогом является разве что пара коммерческих прог для виндовых ФС. А тут такое штатный тул ФС. Вот это да, крутотень. А остальные просто забили на проблематику и их ответ - "используйте photorec" :).
> безумству храбрых, конечно, и всё такое. но я лучше пока что на
> «бричке» доеду.Да пожалуйста, кому хуже то?
> Вот видишь, я получаю +1 к скиллу телепатии ;). Зато смысл вижу
> я - БЫСТРОЕ приведение системы и/или данных в вид "как было"
> за какие-то секунды. Очень здорово исправлять даже серьезные продолбы или последствия
> экспериментов за единицы секунд.
>> нет у меня привычки сначала приводить систему в состояние жoпы,
> А я хочу возможность постановки unsafe системных экспериментов с возможностью быстренько
> сгонять в прошлое на машине времени и отменить эксперимент, если результат
> не понравился.у меня для этого всего есть няшные виртуальные машины. я ещё не окончательно долбанулся, чтобы рисковать рабочей системой. там и снапшоты есть, кстати.
> Да и промахи при работе с файлами можно переиграть.
как-то ещё со времён ДОСа привык трижды думать и делать копию, а потом уже насиловать файл. всё равно по закону подлости как раз то, что я нечаянно угробил, в снапшот попадёт или старое, или никакое.
>> оно и видно, да. crc32 в качестве хэш-функции — это бэст,
> Я считаю это небольшим продолбом. В том плане что специально себе простреливать
> пятки я не намерен, а проблемой это будет разве что когда
> злонамеренная ремота может файлы с 100% контролируемыми именами вгружать. Оно как
> бы да, но это нишевая ситуация. А имея доступ к файловым
> операциям я как бы любую ФС ушатать могу, тюкнув по болючим
> местам. Worst case у всех хуже average. Это данность.а это всё потому, что ты тоже имеешь хреновый CS background. я уже говорил, что всё дело в другом: в том, что эта идея вообще голову посетила. у человека с нормальным базовым багажом знаний такой идеи не могло появиться в принципе. вообще. то есть, со знаниями по таким вот простым структурам данных у авторов бтр большие проблемы. а раз даже с тем, чему учат всех cs-студентов там проблемы, то я боюсь предположить, как обстоят дела с более продвинутыми алгоритмами и структурами данных. читать весь их говнокод перед использованием я не готов.
конечно, в конце концов более умные и опытные люди вычистят говнокод… ну, вот и посмотрим лет через десять. а пока… неа, пусть пионеры пионерят без меня.
>> общий бэкграунд авторов в CS показывает очень наглядно.
> Пользуйся миниксом от одного из светил CS, я не против. А инженерные
> решения для реального мира балансируют так чтобы нормально работало и умело
> то что надо. Из какого гуано и палок и что там
> слеплено очень отдельный вопрос, интересный паре эстетов на планете.это не «инженерное решение», а таджикский самопал. crc32 — она даже не самая быстрая для хэширования, прикинь. не говоря уже о том, что она для хэширования не подходит. просто таджикский программист не в курсе, ему без разницы на это всё, трясти надо.
> Ну да, ext4 несколько более
> лайтовый и упрощенный а xfs более навернутый, но имхо это разные
> перепевки похожих наборов идей.мотороллер и R1 тоже «разные перепевки похожих наборов идей». ну да, мотороллер несколько более лайтовый, чо.
>> а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать
>> это путём создания нового и атомарного rename.
> Это всего лишь гнусный костыль по поводу у..щных свойств файлухи. Ясен пень,
> большинство програмеров забывает это вкостылить.а не надо использовать говнософт. файлы, кстати, тоже костыль. тебе вон к завалишину, у его «фантома» файлов нет. правда, «фантома» тоже нет, тащемта, но это мелочи.
>> а если файл большой — то это, обычно, какая-нибудь БД,
> Очередное левое допущение. Если ты еще не понял - меня не прет
> обрубать мои задачи под умения первобытных инструментов.«первобытные инструменты» — это те, которые с файлами работают. что такое этот «файл», зачем он нужен вообще? однако ж под файлы ты спокойно «прогибаешься». ты уж или трусы, или крестик, а то смешно выглядит.
>> и занимается: она лучше знает, как со своими файлами работать.
> Скажу БТРу chattr +C на файл базы и он для нее и
> журналов станет обычной подложкой. Гибкость файлухи под разные сценарии - это
> хорошо.а ещё лучше — разные инструменты для разных задач. тут вон какой-то гений и /boot на бтр держит, если я верно прочитал.
>> ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно
>> призвано не твои файлы спасать, а FS: чтобы FS после крэша
>> была в консистентном состоянии.
> Буллшит. По нормальному журнал делает логику все или ничего.я и говорю: хреново понимаешь.
>> не так; спасение файлов — задача программы, которая с этими файлами
>> работает. а задача FS — не вставать раком, если вдруг что.
> Я считаю иначе и предпочел бы это видеть свойством файлухи а не
> программ.а я — нет. код FS должен быть простым. чем проще код, тем меньше там багов. вот и всё. кому надо — может использовать в своей программе библиотеки для журналируемой работы с файлами, их есть. кому не надо — может не использовать. а FS остаётся простой.
вообще, современные тенденции делать из FS чёртичто ни к чему хорошему не приведут.
> Я считаб неспособность ФС
> обеспечить честную транзакционность техническим дефектом.да на здоровье. а я вот считаю, что это — ни разу не задача FS.
>> требование простое: не терять мои файлы. пока что raiser3, jfs и xfs
>> с этим справляются. судя по интернетам, бтр справляется не всегда. будем
>> подождать.
> В том что опять же фигово с гибкостью и геморно в управлении.
> У btrfs это красивее сделано. Есть девайсы, есть заказ разложить вон
> то вон так. А btrfs юзая свободное место этих девайсов может
> запрос разрулить. Убедительный и храбрый шаг вперед, мистер Мэйсон. Намного более
> умный подход к управлению томами и местом на них, имхо.и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного монстрика. я такую идеологию не разделяю.
> А я хочу иное поведение ФС, мне не нравится журналинг только метаданных
> и я с удовольствием с такими халтурными технологиями распрощаюсь.возьми библиотеку журналируемой работы с файлами и засунь в LD_PRELOAD. и будут тебе «честные журналы» на любой FS и у любой софтины. это называется «composition». это юниксвэй, аднака. у меня, например, таким образом все программы отлично понимают 9P, хотя авторы некоторых из этих программ, наверняка, даже не в курсе, что такое 9P.
>> безумству храбрых, конечно, и всё такое. но я лучше пока что на
>> «бричке» доеду.
> Да пожалуйста, кому хуже то?(пожимает плечами) точно не мне. у меня все довольны, брат жив, батя грит малацца.
> у меня для этого всего есть няшные виртуальные машины. я ещё не
> окончательно долбанулся, чтобы рисковать рабочей системой. там и снапшоты есть, кстати.Только есть такая малюсенькая разница между снапшотами ВМ и снапшотами ФС.
>> Да и промахи при работе с файлами можно переиграть.
> как-то ещё со времён ДОСа привык трижды думать и делать копию, а
> потом уже насиловать файл. всё равно по закону подлости как раз
> то, что я нечаянно угробил, в снапшот попадёт или старое, или
> никакое.Чаще надо делать снапшоты. А если на каждый чих "трижды думать и делать копию" - то и производительность труда будет соответствующей.
> а это всё потому, что ты тоже имеешь хреновый CS background. я
> уже говорил, что всё дело в другом: в том, что эта
> идея вообще голову посетила. у человека с нормальным базовым багажом знаний
> такой идеи не могло появиться в принципе. вообще. то есть, со
> знаниями по таким вот простым структурам данных у авторов бтр большие
> проблемы. а раз даже с тем, чему учат всех cs-студентов там
> проблемы, то я боюсь предположить, как обстоят дела с более продвинутыми
> алгоритмами и структурами данных. читать весь их говнокод перед использованием я
> не готов.А по делу можете что-нибудь сказать? Или вы больше по сферическим коням в вакууме специализируетесь?
> конечно, в конце концов более умные и опытные люди вычистят говнокод… ну,
> вот и посмотрим лет через десять. а пока… неа, пусть пионеры
> пионерят без меня.От вас помощи никто и не ждет )
> это не «инженерное решение», а таджикский самопал. crc32 — она даже не
> самая быстрая для хэширования, прикинь. не говоря уже о том, что
> она для хэширования не подходит. просто таджикский программист не в курсе,
> ему без разницы на это всё, трясти надо.Во-первых не crc32, а crc32c - которая имеет аппаратную поддержку в большей части современных процов и бОльшую стойкость к коллизиям, а во вторых она используются не в качестве хэш-функции, а в качестве проверки целостности (checksum) - чего впринципе нет у XFS.
>> Ну да, ext4 несколько более
>> лайтовый и упрощенный а xfs более навернутый, но имхо это разные
>> перепевки похожих наборов идей.
> а не надо использовать говнософт. файлы, кстати, тоже костыль. тебе вон к
> завалишину, у его «фантома» файлов нет. правда, «фантома» тоже нет,
> тащемта, но это мелочи.Что-то поносом попахивает...
> «первобытные инструменты» — это те, которые с файлами работают. что такое
> этот «файл», зачем он нужен вообще? однако ж под файлы ты
> спокойно «прогибаешься». ты уж или трусы, или крестик, а то смешно
> выглядит.Туда-же.
> а ещё лучше — разные инструменты для разных задач. тут вон какой-то
> гений и /boot на бтр держит, если я верно прочитал.Держу весь корень в одной btrfs filesystem на разных subvolume - в чем "гениальность"?
>>> ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно
>>> призвано не твои файлы спасать, а FS: чтобы FS после крэша
>>> была в консистентном состоянии.
>> Буллшит. По нормальному журнал делает логику все или ничего.
> я и говорю: хреново понимаешь.Расскажете? Или гои недостойны, как обычно? )
>>> не так; спасение файлов — задача программы, которая с этими файлами
>>> работает. а задача FS — не вставать раком, если вдруг что.
>> Я считаю иначе и предпочел бы это видеть свойством файлухи а не
>> программ.
> а я — нет. код FS должен быть простым. чем проще код,
> тем меньше там багов. вот и всё. кому надо — может
> использовать в своей программе библиотеки для журналируемой работы с файлами, их
> есть. кому не надо — может не использовать. а FS остаётся
> простой.FAT - ваш выбор, ну или на край UFS.
> вообще, современные тенденции делать из FS чёртичто ни к чему хорошему не
> приведут.Ну что же вы так скромно. "современные тенденции ни к чему хорошему не приведут" - так будет лучше )
>> Я считаб неспособность ФС
>> обеспечить честную транзакционность техническим дефектом.
> да на здоровье. а я вот считаю, что это — ни разу
> не задача FS.Считайте дальше )
> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
> монстрика. я такую идеологию не разделяю.Юниксвей уже даже Линусу не уперся - что вы забыли на этом ядре?
> возьми библиотеку журналируемой работы с файлами и засунь в LD_PRELOAD. и будут
> тебе «честные журналы» на любой FS и у любой софтины. это
> называется «composition». это юниксвэй, аднака. у меня, например, таким образом
> все программы отлично понимают 9P, хотя авторы некоторых из этих программ,
> наверняка, даже не в курсе, что такое 9P.Кому сейчас нужен Plan9 акромя исследовательского интереса?
> (пожимает плечами) точно не мне. у меня все довольны, брат жив, батя
> грит малацца.Слова девяти из дести слакварьщиков.
изыди, дурачина, не с тобой беседа была.
> изыди, дурачина, не с тобой беседа была.ЧИТД )
нет, не требовалось. ты уже давно доказал, что дурак.
> Чаще надо делать снапшоты. А если на каждый чих "трижды думать и
> делать копию" - то и производительность труда будет соответствующей.Угу, думать вообще вредно.
>> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
>> монстрика. я такую идеологию не разделяю.
> Юниксвей уже даже Линусу не уперсяС чего вы взяли?
> Кому сейчас нужен Plan9 акромя исследовательского интереса?
Читали басню дедушки Крылова про свинью и дуб?
>> Чаще надо делать снапшоты. А если на каждый чих "трижды думать и
>> делать копию" - то и производительность труда будет соответствующей.
> Угу, думать вообще вредно.Угу, а думать о вещах, о которых должен "думать" компьютер - это как раз-таки цель всего IT, так получается?
>>> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
>>> монстрика. я такую идеологию не разделяю.
>> Юниксвей уже даже Линусу не уперся
> С чего вы взяли?http://www.itwire.com/business-it-news/open-source/65402-tor...
Linus Torvalds: So I think many of the "original ideals" of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation.
There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality.
>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
> Читали басню дедушки Крылова про свинью и дуб?Читал. Тока вышеперечисленное больше смахивает на басню про оптический прибор и примата.
> Угу, а думать о вещах, о которых должен "думать" компьютерК сожалению, падаван, компьютер не способен "думать", даже в кавычках. В т.ч. и в данном конкретном примере. Как минимум, требуется подумать на тему - как, где и когда что-то сохранить. Плюс, как потом быстро найти это сохраненное.
>>>> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
>>>> монстрика. я такую идеологию не разделяю.
>>> Юниксвей уже даже Линусу не уперся
>> С чего вы взяли?
> http://www.itwire.com/business-it-news/open-source/65402-tor...И причем тут "юниксвей"? Если там что и обсуждается - так разве "do one thing and do it well". Между тем, это только один из принципов. "Не пиши на C без крайней нужды, придурок" - другой, не менее важный.
> There's still value in understanding the traditional UNIX "do one thing and
> do it well" model where many workflows can be done as
> a pipeline of simple tools each adding their own value, but
> let's face it, it's not how complex systems really workЯ бы сказал, что Git - вполне себе контрпример этому троллингу от Линуса.
Впрочем, он уже упомянул Emacs как traditional counter-example этой "simple UNIX model" - что символизирует всю "глубину" этого мнения.
>>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
>> Читали басню дедушки Крылова про свинью и дуб?
> Читал.Нужно пояснить чем ваше выссказывание про Plan9 напоминает ту хрюшку?
>> Угу, а думать о вещах, о которых должен "думать" компьютер
> К сожалению, падаван, компьютер не способен "думать", даже в кавычках. В
> т.ч. и в данном конкретном примере. Как минимум, требуется подумать
> на тему - как, где и когда что-то сохранить. Плюс,
> как потом быстро найти это сохраненное.Конечно прошу прощеня, но к вам в падаваны даже за деньги бы не пошел ) А "подумать на тему - как, где и когда что-то сохранить" e.t.c решается один раз, в отлиичие от исходного "как-то ещё со времён ДОСа привык трижды думать и делать копию, а потом уже насиловать файл", не находите?
>[оверквотинг удален]
>>> С чего вы взяли?
>> http://www.itwire.com/business-it-news/open-source/65402-tor...
> И причем тут "юниксвей"? Если там что и обсуждается - так
> разве "do one thing and do it well". Между тем,
> это только один из принципов. "Не пиши на C без
> крайней нужды, придурок" - другой, не менее важный.
>> There's still value in understanding the traditional UNIX "do one thing and
>> do it well" model where many workflows can be done as
>> a pipeline of simple tools each adding their own value, but
>> let's face it, it's not how complex systems really workСм. выше. "а ещё лучше — разные инструменты для разных задач." - это прямое противопоставление с "...the traditional UNIX "do one thing and do it well" model ... their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time." Ну или английский подучите как-нибудь )
> Я бы сказал, что Git - вполне себе контрпример этому троллингу от
> Линуса.Без комментариев )) Хотя... Почему git pull, merge, mv e.t.c - это не отдельные утилиты, а?
> Впрочем, он уже упомянул Emacs как traditional counter-example этой "simple UNIX model"
> - что символизирует всю "глубину" этого мнения."Глубине" мнения Линуса, конечно-же никогда не сравняться с вашими глуюинами )
>>>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
>>> Читали басню дедушки Крылова про свинью и дуб?
>> Читал.
> Нужно пояснить чем ваше выссказывание про Plan9 напоминает ту хрюшку?Если честно, нихера не напоминает ) Напоминает arisu, который плюет в колодец из которого пьёт ( ну или по крайней мере делает вид )
> А "подумать на тему - как, где и
> когда что-то сохранить" e.t.c решается один разАх, если б ( "Решатель" из ТП хостера, я угадал?
> См. выше. "а ещё лучше — разные инструменты для разных задач." -
> это прямое противопоставление с "...the traditional UNIX "do one thing and
> do it well" modelВ каком месте тут что чему противопоставляется?
> ... their own value, but let's face
> it, it's not how complex systems really work, and it's not
> how major applications have been working or been designed for a
> long time." Ну или английский подучите как-нибудь )Вам надо перевести? Так прямо бы и попросили.
>> Я бы сказал, что Git - вполне себе контрпример этому троллингу от
>> Линуса.
> Без комментариев )) Хотя... Почему git pull, merge, mv e.t.c - это
> не отдельные утилиты, а?А почему должны?
>> Впрочем, он уже упомянул Emacs как traditional counter-example этой "simple UNIX model"
>> - что символизирует всю "глубину" этого мнения.
> "Глубине" мнения Линуса, конечно-же никогда не сравняться с вашими глуюинами )Да, это не моя. Почитайте что-ли книжку ESR на досуге, там подробно обсасывается и этот миф о "traditional counter-example".
>>>>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
>>>> Читали басню дедушки Крылова про свинью и дуб?
>>> Читал.
>> Нужно пояснить чем ваше выссказывание про Plan9 напоминает ту хрюшку?
> Если честно, нихера не напоминает )Ну а как же. Сидит, умник, поплевывает свысока на исследователей - "конгресс, немцы какие-то" (ц). Тут 100500-ю FS надо писать, причем срочно. Эвана - студент-недоучка "создал Linux" (тм), значит могем?! А то структуры данных, алгоритмы - "голова пухнет" (ц).
Правда если вспомнить, что студент-то - начал с того что кривоватенько передрал POSIX...
> e.t.ctriplefacepalm
> возьми библиотеку журналируемой работы с файлами и засунь в LD_PRELOAD. и будут
> тебе «честные журналы» на любой FS и у любой софтины. это
> называется «composition».Это еще называется - мэээдленна.
> Это еще называется - мэээдленна.а чего медленного-то? как напишешь — так и будет.
> как напишешь — так и будет.People who think that userspace filesystems are realistic for anything but toys are just misguided. (ц)
>> как напишешь — так и будет.
> People who think that userspace filesystems are realistic for anything but toys
> are just misguided. (ц)йопта… а создатели БД-то и не знают! у них, фактически, навороченая userspace FS. идиоты. пойду, расскажу, что без ядерного модуля они в бирюльки играются.
>>> как напишешь — так и будет.
>> People who think that userspace filesystems are realistic for anything but toys
>> are just misguided. (ц)
> йопта… а создатели БД-то и не знают! у них, фактически, навороченая userspace
> FS. идиоты. пойду, расскажу, что без ядерного модуля они в бирюльки
> играются.Только почему-то никто в БД файло старается не хранить и виртуалки поверх БД не запускают. Пора бы тебе перестать пить слабительное для креативных мыслей.
воспитанников интерната для умственно отсталых я в обсуждение не приглашал.
>>> как напишешь — так и будет.
>> People who think that userspace filesystems are realistic for anything but toys
>> are just misguided. (ц)
> йопта… а создатели БД-то и не знают! у них, фактически, навороченая userspace FS.Они-то как раз - знают, потому у них и нет этой самой "навороченной FS".
> Они-то как раз - знают, потому у них и нет этой самой
> "навороченной FS".breaking news, аднака.
Мне не интересно соревноваться с вами в духе специальной олимпиады. Если вы не понимаете откуда здесь оверхед - просто рассмотрите что происходит при записи данных в такой "FS" vs файл на обычной журналируемой FS.
> Мне не интересно соревноваться с вами в духе специальной олимпиады.а получается отлично, тем не менее.
> Они-то как раз - знают, потому у них и нет этой самой
> "навороченной FS".Файловая система - это простая иерархическая база данных. "Ключ" - это имя файла, "значение" - содержимое файла. Возможны, разумеется, всякие извращения вроде нескольких ключей, связанных с одним значением (hard-link), нескольких значений для одного ключа (потоки NTFS) и т.д.
Но с высоты птичьего полёта файловые системы - это простые базы данных, встроенные в ОС. Кстати, если подумать, становится ясно, какое же это извращение - реестр Windows ;-).
>> Они-то как раз - знают, потому у них и нет этой самой
>> "навороченной FS".
> Файловая система - это простая иерархическая база данных.Угу. А все компьютерные языки - не имеют существенных отличий от брайнфака. Полнота по Тьюрингу, нех.
> Но с высоты птичьего полёта
На известной высоте полета, все люди - обИзьяны.
>> Файловая система - это простая иерархическая база данных.
> Угу. А все компьютерные языки - не имеют существенных отличий от
> брайнфака. Полнота по Тьюрингу, нех.Вы слишком долго программировали на БФ. Аналогом "файловая система - это простая иерархическая база данных" является "брейнфак - это не очень удобный язык программирования".
> Эта "проблема" давно известна. У вас просто размер метаданных вылез за все
> мыслемые пределы - решается через подключенную влешку с расширением filesystem на
> нее, последующим balance и изъятием последней.Весело у вас.
> У меня все в точности наоборот, за исключением того что я тоже
> использую дома, а в продакшн - пока только под бэкапы.А зачем?
Пробовал для теста использовать btr со сжатием под раздел с портами в генту.
Прожила около 4 месяцев потом умерла. Использование под такой раздел райзера и ext4
ни когда проблем не вызывало. Кроме того бросалось в глаза сильное проседание по скорости.
Пока для себя считаю btr не готовым, и разумеется ни каких продакшенов.
Использую Btrfs со сжатием и под дерево портежа, и под /usr/src, и под систему вообще. Всё работает быстро и стабильно вот уже почти год. Наверное, кое-кому стоит вытащить руки из задницы.
Подтверждаю.
Медленнее, чем на ехт4, но работает стабильно уже >2 лет (гланое не делать даунгрэйд ядра/утилит. Хотя,.. я не пробовал. Но есть убеждённость, что не стоит)
а всего то надо было перемонтировать без space_cache.
Использовал на 3Тб хдд. Умерла аналогичным образом. А после попытки fsck перестала монтироваться. Спас почти все файлы при помощь restore. Опасаюсь пользоваться в дальнейшем.
Вероятно, вы не знаете особенности SSD. discard не забыли включить? Более 60% занимать не рекомендуется. Возможно она в паре с контроллером просто защищали вас от «непоправимого»...
> Из моего опыта, всё-таки, btrfs иногда умирает. У меня умирала в общей
> сложности раза четыре. Всегда с одинаковыми симптомами: внезапно перестаёт создавать/редактировать/удалять
> файлы на ФС с отмазой "нема места". Читаются файлы при этом
> прекрасно. Никаких методов адекватной реанимации я в своё время не нашёл.Ты это, как работает CoW вообще представляешь, не?
> Использовал btrfs на протяжении двух лет в качестве основной fs на arch
> linux дома и на работе. Умирала на разных системах. Использовал только
> на SSD, subvolumes не использовал, прозрачное сжатие не включал.Ты это. Маны бы покурил там. Концепции. Чтобы лучше просекать, что ты, собственно говоря, используешь.
Ждем комменты Шишкина! Он в свое время хорошо по полочкам разложил - какая это дрянь эта ваша заливная рыба.
Своей головы нет?
> Своей головы нет?Думать вредно, от этого голова болит. Лучше цитировать других, выбирая их по желанию левой пятки. Ну или самому, но тогда просто бред нести.
> Ждем комменты Шишкина! Он в свое время хорошо по полочкам разложил - какая это дрянь эта ваша заливная рыба.Учитывая "прогресс" в интеграции reiser4 в mainline, квалификация Шишкина в области разработки файловых систем вызывает оч-чень серьезные вопросы.
> Учитывая "прогресс" в интеграции reiser4 в mainline, квалификация Шишкина в области разработки
> файловых систем вызывает оч-чень серьезные вопросы.а вот квалификация людей, использующих crc32 как алгоритм для хэширования, вопросов никаких не вызывает вообще. не может вызывать вопросы то, чего нет. привет авторам btrfs, пользуйтесь самыми надёжными FS от людей, не знающих азов CS.
reiser4 никогда не включат в основную ветку по одной только причине - нет команды (финансово устойчивой) которая бы поддерживала ее там. и это не зависит от квалификации Шишкина. Одного гения мало :))) А свою квалификацию уже доказал - сам тянет reiser4 и те кто ей пользуется - довольны. А его работы по этой тематике хорошо цитируются
> какая это дрянь эта ваша заливная рыба.Единственная проблема: кушать нам хочется, а у шишкина в ассортименте вообще нечто несъедобное. Так что его критика заливной рыбы делу совсем не помогает.
Дооооооооо, почитайте ради интереса майл-лист Btrfs, там такое всё стабильное сейчас, стабильность из ушей прёт.Вкратце - с ветки 3.14.хх, на что-либо новее переходить пока просто нельзя.
Что-либо старее использовать тоже в общем случае самоубийство.
Но ради справедливости на 3.14 всё работает замечательно.
> Вкратце - с ветки 3.14.хх, на что-либо новее переходить пока просто нельзя.на 3.17 можно переходить.
и да -- btrfs там работает норм.. если конечно не будешь пытаться делать там всякие btrfs-raid и хитрые квоты.
Поставь btrfs на продакшен, пусть тебя шеф анально покарает!
> Поставь btrfs на продакшен, пусть тебя шеф анально покарает!интересно, это за что он должен меня покарать? за то что всё просто работает и не ломается? :-)
у меня вполне себе хватает времени на то, чтобы раз-в-две-недельки обновить версии ядер на служебных серверах.
(предпочитаю ситуации когда проблемы не возникают, чем ситуации когда проблема возникла, но её героически решили.. так что обновляю весь софт -- заблаговременно ещё до того момента когда known-bugs начнут выползать внаружу)
**************************************************
или ты считаешь что "продакшен" -- это *только* ситация при которой *заплывший-жиром* системный администратор раз в два года настроил сервер и больше там ни чего не делает? в стиле "работает? не трогай!" ...?
нет это не мой случай. я буду "трогать" даже когда "работает". потому что если вдруг перестанет работать -- то я буду нести убыток. :)
но если ты , как раз являешься тем-сымым системным администратором, который *заплыл-жиром* -- то я тебя не виню. это твоё начальство виновато, что заставляет тебя работать именно в стиле заплывшего-жиром-сус-админа..
> я буду "трогать" даже когда "работает". потому что если вдруг перестанет работать -- то я буду нести убыток. :)Правильно, падаван. Лучше сразу денюшку работодателя в нуль вдуть посредством твоей ИБД.
:-}
> нет это не мой случай. я буду "трогать" даже когда "работает". потому что если вдруг перестанет работать -- то я буду нести убыток. :)То есть в ситуацию, что всё перестанет работать *после* обновления, ты не веришь?
> То есть в ситуацию, что всё перестанет работать *после* обновления, ты не веришь?ну бывало пару раз..
не смертельно :-}
>> нет это не мой случай. я буду "трогать" даже когда "работает". потому что если вдруг перестанет работать -- то я буду нести убыток. :)
> То есть в ситуацию, что всё перестанет работать *после* обновления, ты не веришь?Хороший сисадмин - не тот, который не обновляется, а тот, у которого все готово на случай проблем при обновлении.
>>> нет это не мой случай. я буду "трогать" даже когда "работает". потому что если вдруг перестанет работать -- то я буду нести убыток. :)
>> То есть в ситуацию, что всё перестанет работать *после* обновления, ты не веришь?
> Хороший сисадмин - не тот, который не обновляется, а тот, у которого
> все готово на случай проблем при обновлении.Физический бэкап?
> Физический бэкап?Я откачу снапшот за хренадцать секунд. А тебе удачи в раскатывании бэкапа на пару терабайт. Нет, снапшоты бэкап не заменяют, но могут в случае факапа позволить все быстренько переиграть и без длительного раскатывания бэкапа.
правильное создание инкрементальных бэкапов рулит, однако. кто ж тебе виноват, что из инструментов для бэкапа ты только dd знаешь?
Вот товарищи уже перешли:
Unrecoverable btrfs corruption with 3.17
https://bugzilla.kernel.org/show_bug.cgi?id=87021
https://bugzilla.kernel.org/show_bug.cgi?id=87061
> Вот товарищи уже перешли:
> Unrecoverable btrfs corruption with 3.17
> https://bugzilla.kernel.org/show_bug.cgi?id=87021
> https://bugzilla.kernel.org/show_bug.cgi?id=87061Подброшу свои 5 копеек (а именно попытку физически вывести мой SSD из строя):
https://bugzilla.kernel.org/show_bug.cgi?id=85581
> Дооооооооо, почитайте ради интереса майл-лист Btrfs, там такое всё стабильное сейчас, стабильность
> из ушей прёт.
> Вкратце - с ветки 3.14.хх, на что-либо новее переходить пока просто нельзя.Пруфов как всегда нет, ещё один петух на заборе.
>> Дооооооооо, почитайте ради интереса майл-лист Btrfs, там такое всё стабильное сейчас, стабильность
>> из ушей прёт.
>> Вкратце - с ветки 3.14.хх, на что-либо новее переходить пока просто нельзя.
> Пруфов как всегда нет, ещё один петух на заборе.На самом деле были траблы с сжатием на ядре 3.16 (лень искать пруфы - найдете в рассылке Linux BTRFS), а также потеря данных с ro-снапшотами при использовании send/receive в 3.17.0 (http://www.spinics.net/lists/linux-btrfs/msg38412.html http://www.spinics.net/lists/linux-btrfs/msg38151.html ). Но эти ядра не используются ни в одном production-дистрибутиве.
У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?
> У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?Да. Попробуйте на этой файловой системе собрать ядро командой make oldconfig ; make -j10 (если в системе 8 ядер). Огребете зависон. Патч против этого появился только в 3.17.
>> У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?
> Да. Попробуйте на этой файловой системе собрать ядро командой make oldconfig ;
> make -j10 (если в системе 8 ядер). Огребете зависон. Патч против
> этого появился только в 3.17.http://storage8.static.itmages.ru/i/14/1029/h_1414574704_815...
Где обещанный зависон? Возмутительно!
>>> У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?
>> Да. Попробуйте на этой файловой системе собрать ядро командой make oldconfig ;
>> make -j10 (если в системе 8 ядер). Огребете зависон. Патч против
>> этого появился только в 3.17.
> http://storage8.static.itmages.ru/i/14/1029/h_1414574704_815...
> Где обещанный зависон? Возмутительно!Попробуйте еще раз.
Патч, решающий проблему, кстати, включили в 3.16.2
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st...
Я пилю скрипт для автоматизированной сборки ядра. После обновления на 3.16 в процессе отладки скрипта я ядро собирал раз двадцать. Всё ок. Возможно, мне просто неописуемо везёт.
> Я пилю скрипт для автоматизированной сборки ядра. После обновления на 3.16 в
> процессе отладки скрипта я ядро собирал раз двадцать. Всё ок. Возможно,
> мне просто неописуемо везёт.Возможно. Сколько ядер процессора, сколько памяти, zgrep CONFIG_SL.B= /proc/config.gz ? (у меня 8 ядер, 16 GB RAM, SLUB)
Слушайте, хватит нести чушь.
Уже >2 лет гента на ноуте с бтр живёт.
И да, ядро (как и всё остальное) всё время собирается из сырцов. Не говоря уже про портэжи и оверлеи с КУЧЕЙ мелких файлов.
Вот жду, чтобы broadcom-sta под 3.17 стал компилиться и перейду на это ядро.Зыж
Ещё раз повторяю, это не разовая операция как в других дистрах, это штатная работа. Такова идеология генту.
> Слушайте, хватит нести чушь.
> Уже >2 лет гента на ноуте с бтр живёт.
> И да, ядро (как и всё остальное) всё время собирается из сырцов.
> Не говоря уже про портэжи и оверлеи с КУЧЕЙ мелких файлов.
> Вот жду, чтобы broadcom-sta под 3.17 стал компилиться и перейду на это
> ядро.
> Зыж
> Ещё раз повторяю, это не разовая операция как в других дистрах, это
> штатная работа. Такова идеология генту.Ну почему вы такой упертый? Вам же привели ссылки на рассылку - вы думаете там народ с разрабами от нечего делать переписывается? Проблема была, причину нашли, патч выкатили. "У меня все работает" - это совершенно не аргумент, как и обратное. btrfs - в поряде, но проблемы встречаются, особенно на необкатанных ядрах.
У меня 8 потоков (core i7 2600), 8 Гб памяти, CONFIG_SLAB=y
Понятно, спасибо. Похоже, SLUB (который сейчас по умолчанию) чаще размещает новые объекты на месте старых удаленных и поэтому приводит к условию, которое ранее неверно проверялось. Если хотите воспроизвести проблему, попробуйте пересобрать и перезагрузить ядро с CONFIG_SLUB=y. После чего еще раз пересобрать :)
> мне просто неописуемо везёт.Там реально был баг - посадили при переходе с самопала на ядерные workqueue. Но зато -1 самопальный вел в пользу штатных услуг ядра. Так что ядра с 3.14 до 3.16 с сжатием могут взбрыкнуть. Так для того и нужны летчики-испытатели, чтоб пассажиры летали без страха.
> У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?Лучше начинать уже делать резервные копии.
>> У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?
> Лучше начинать уже делать резервные копии.Их так-то по умолчанию надо иметь. В любое время суток и вне зависимости от используемой ФС.
>>> У меня ядро 3.16 и используется сжатие lzo. Мне уже начинать паниковать?
>> Лучше начинать уже делать резервные копии.
> Их так-то по умолчанию надо иметь. В любое время суток и вне
> зависимости от используемой ФС.Тогда зачем начинать паниковать? )
такие новости НЕЛЬЗЯ постить без серьезных бенчей на нормальных стореджах. истории успеха на локахостах не показатель. как впрочем и крики хейтеров с дивана.
Ну так сделай бенчи и доложи. А мэйсон в фэйсбуке это внедряет IIRC.
> Ну так сделай бенчи и доложи. А мэйсон в фэйсбуке это внедряет
> IIRC.если у пейцбука потеряется кучка лайков и посты с фотографиями юзера и его сраной кошки — ничего страшного не случится.
Она уже научилась количество свободного места на диске корректно показывать?
> Она уже научилась количество свободного места на диске корректно показывать?А почему вы спрашиваете ?
> Она уже научилась количество свободного места на диске корректно показывать?btrfs filesystem df как-бэ уже давно существует.
Вот когда все распространенные системы мониторинга научатся вызывать этот ваш btrfs filesystem df из коробки по умолчанию, тогда и поговорим. А пока - в сад.
> Вот когда все распространенные системы мониторинга научатся вызывать этот ваш btrfs filesystem
> df из коробки по умолчанию, тогда и поговорим. А пока -
> в сад.А в детсаду не учат, разве, как настраивать "все распространенные системы мониторинга" не по умолчанию? )
>> Вот когда все распространенные системы мониторинга научатся вызывать этот ваш btrfs filesystem
>> df из коробки по умолчанию, тогда и поговорим. А пока -
>> в сад.
> А в детсаду не учат, разве, как настраивать "все распространенные системы мониторинга"
> не по умолчанию? )В саду учат совершенно обратному: "не выпендривайся".
Видомо уз угла вы там не выходите.
> В саду учат совершенно обратному: "не выпендривайся".Это особенности детсада. Учреждение дошкольного образования as is.
В школе умников будут терпеть, а в универе - даже поощрять.
>> В саду учат совершенно обратному: "не выпендривайся".
> Это особенности детсада. Учреждение дошкольного образования as is.
> В школе умников будут терпеть, а в универе - даже поощрять.штука, правда, в том, что «умные люди» и «умники» — непересекающиеся множества.
> Вот когда все распространенные системы мониторинга научатся вызывать этот ваш btrfs filesystem
> df из коробки по умолчанию, тогда и поговорим. А пока -
> в сад.Кстати:
# df -h | head -n2
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 55G 15G 39G 28% /# btrfs filesystem df /
Data, single: total=18.01GiB, used=14.14GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=2.01GiB, used=565.72MiB
GlobalReserve, single: total=192.00MiB, used=0.00B
Александр, мне кажется, что Вы не туда камнями кидаетесь.
Все расспост. системы позволяют написать и использовать свои модули.
Icinga(Nagios).
Если для Вас проблема накидать за час обертку к df, не стоит ли рассуждать о ФС ?
> Александр, мне кажется, что Вы не туда камнями кидаетесь.
> Все расспост. системы позволяют написать и использовать свои модули.
> Icinga(Nagios).
> Если для Вас проблема накидать за час обертку к df, не стоит
> ли рассуждать о ФС ?Написать это для меня не проблема, проблема оттестировать. И еще проблема в самой необходимости такое писать, тестировать и не забывать подключить для каждого отдельного админа.
>> Александр, мне кажется, что Вы не туда камнями кидаетесь.
>> Все расспост. системы позволяют написать и использовать свои модули.
>> Icinga(Nagios).
>> Если для Вас проблема накидать за час обертку к df, не стоит
>> ли рассуждать о ФС ?
> Написать это для меня не проблема, проблема оттестировать. И еще проблема в
> самой необходимости такое писать, тестировать и не забывать подключить для каждого
> отдельного админа.Если нужны фишки btrfs то надо писать и тестировать (кстати, что значит "подключить для каждого тдельного админа"?). А если не нужны - тогда о чем речь вообще?
>[оверквотинг удален]
>>> Все расспост. системы позволяют написать и использовать свои модули.
>>> Icinga(Nagios).
>>> Если для Вас проблема накидать за час обертку к df, не стоит
>>> ли рассуждать о ФС ?
>> Написать это для меня не проблема, проблема оттестировать. И еще проблема в
>> самой необходимости такое писать, тестировать и не забывать подключить для каждого
>> отдельного админа.
> Если нужны фишки btrfs то надо писать и тестировать (кстати, что значит
> "подключить для каждого тдельного админа"?). А если не нужны - тогда
> о чем речь вообще?Плохо выразился. Мысль была такая. Каждый конкретный админ (в том числе тот, который получил btrfs как нечто пришедшее как настройка по умолчанию в особо новом дистре) должен не забыть написать этот btrfs-специфичный скрипт вместо того стандартного скрипта для графиков и алертов про свободное место, который шел в комплекте поставки системы мониторинга. Ключевое слово тут - "не забыть".
>[оверквотинг удален]
>>> отдельного админа.
>> Если нужны фишки btrfs то надо писать и тестировать (кстати, что значит
>> "подключить для каждого тдельного админа"?). А если не нужны - тогда
>> о чем речь вообще?
> Плохо выразился. Мысль была такая. Каждый конкретный админ (в том числе тот,
> который получил btrfs как нечто пришедшее как настройка по умолчанию в
> особо новом дистре) должен не забыть написать этот btrfs-специфичный скрипт вместо
> того стандартного скрипта для графиков и алертов про свободное место, который
> шел в комплекте поставки системы мониторинга. Ключевое слово тут - "не
> забыть".Хотя бы один из "каждого конкретного админа" для начала может просто постучаться в багтрекер своей системы мониторинга, если это ему действительно надо.
>[оверквотинг удален]
>>> "подключить для каждого тдельного админа"?). А если не нужны - тогда
>>> о чем речь вообще?
>> Плохо выразился. Мысль была такая. Каждый конкретный админ (в том числе тот,
>> который получил btrfs как нечто пришедшее как настройка по умолчанию в
>> особо новом дистре) должен не забыть написать этот btrfs-специфичный скрипт вместо
>> того стандартного скрипта для графиков и алертов про свободное место, который
>> шел в комплекте поставки системы мониторинга. Ключевое слово тут - "не
>> забыть".
> Хотя бы один из "каждого конкретного админа" для начала может просто постучаться
> в багтрекер своей системы мониторинга, если это ему действительно надо.С этим согласен.
> Написать это для меня не проблема, проблема оттестировать. И еще проблема в
> самой необходимости такое писать, тестировать и не забывать подключить для каждого
> отдельного админа.Тут на самом деле ситуация такова, что такое глобальное изменение должно сопровождаться подготовкой.
Нельзя-же все сразу взять и перевести.
В рамках подготовки должно быть проведено тестирование, которое ориентировано на решаемые в организации задачи и выявлению всех проблем и прикидок их решения.
Так вот, это мое умничание к тому, что в списке вопросов к Btrfs, мелкий вопрос к мониторингу, который решается за пару часов, стоит в самом конце.
На фоне проблем с .... см. расслыки
> Так вот, это мое умничание к тому, что в списке вопросов к
> Btrfs, мелкий вопрос к мониторингу, который решается за пару часов, стоит
> в самом конце.
> На фоне проблем с .... см. расслыкиСогласен на 100%. Мелкий вопрос с мониторингом действительно стоит, и действительно есть более приоритетные проблемы.
> Вот когда все распространенные системы мониторинга научатся вызывать этот ваш btrfs filesystem
> df из коробки по умолчанию, тогда и поговорим. А пока - в сад.Сразу после того как все сельские аэродромы для кукурузников научатся принимать сверхзвуковые самолеты.
У меня, видимо, карма бела и блестяща, если я за почти год использования сабжа ни разу не огребал проблем с ней. Ну или просто не пользуюсь глюкодромами типа Рача.
С марта месяца на Btrfs висит все кроме /boot. Использую LZO и опцию -o ssd. Полет отличный, нареканий нет.
Утверждение в целом не то, чтобы спорное, но есть некие лукавства. Без сжатия, квот и и т.д. неких особых вопросов нет. к ветке 3.14.
А в целом полностью переводить - страшновато
Возможно, она и готова в представлении разработчиков. Вон, смотрю, и на локалхостах у многих вроде как жива.Однако среди серьезных вендоров не так уж и много тех, кто это объявил и рекомендовал исплользовать, ьем более уж по умолчанию. И ни разу я тут пока не видел комментария, чтобы кто-то рассказал, как эксплуатирует хранилище хотя бы на десяток терабайт на btrfs, какой там RAID при этом, что скорость и надежность подтверждены месяцами без проблем и т.д. Реальная жизнь, похоже, далековата от мечт разработчиков...
> какой там RAID при этом,У btrfs нет hardcoded уровней RAID. Ты и правда мамонт с твоими представлениями о дисковых технологиях XXI века..
apt-get install btrfs-tools
=
kernel ops при загрузке.
но зато стабильно при каждой загрузке. Стабильнее некуда
Для COW-fs признаком стабильности будет удаление fsck из списка сопровождющих утилит. Или перевод оной утилиты в раздел (debug|develop)ing-tools. Такчто пока btrfs Крису не по зубам
