Кент Оверстрит (Kent Overstreet) объявил (https://lkml.org/lkml/2015/8/21/22) об эволюционировании блочного устройства для кэширования доступа к медленным жестким дискам на быстрых SSD-накопителях Bcache (http://bcache.evilpiepirate.org/) в полноценную файловую систему Bcachefs (http://evilpiepirate.org/git/linux-bcache.git/log/?h=bcache-dev). Благодаря использованию накопившихся за годы разработки Bcache решений, в Bcachefs удалось добиться сочетания высокой производительности с расширенными возможностями, такими как включение в раздел нескольких устройств, репликация, кэширование, прозрачное сжатие данных и верификация целостности по контрольным суммам.
В Bcachefs также реализовано большинство базовых возможностей POSIX ФС, в том числе xattrs и ACL. Из пока недоступных, но запланированных к реализации, возможностей отмечаются предварительное резервирование места (fallocate), квоты и снапшоты. Файловая система основана на использовании механизма Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.
Отмечается, что в один прекрасный момент разработчики осознали, что созданные для Bcache технологии и наработки содержат заметную часть функциональности файловой системы, и если развивать код в нужном направлении, благодаря продуманной архитектуре, удастся получить отличную ФС. В конечном счёте, участники проекта поставили перед собой цель создания файловой системы, находящейся на уровне btrfs и zfs с позиции функциональности и ext4 и xfs в плане производительности и надёжности.
Код новой файловой системы находится в альфа-стадии разработки (дисковый формат может измениться), но субъективно достаточно стабилен (в своё время, Bcache разрабатывался для Google). В настоящее время код Bcachefs функционально более-менее завершён, что позволяет перейти к стадии полномасштабного тестирования для выявления неочевидных проблем. В простейшем случае для тестирования достаточно собрать ядро (http://evilpiepirate.org/git/linux-bcache.git) и инструментарий (http://evilpiepirate.org/git/bcache-tools.git) из Git, после чего можно отформатировать (bcacheadm format -C /dev/sda1) и примонтировать раздел (mount -t bcache /dev/sda1 /mnt).
URL: https://lkml.org/lkml/2015/8/21/22
Новость: http://www.opennet.me/opennews/art.shtml?num=42839
>сочетающая функциональность btrfs/zfs с производительностью ext4/xfs
>удастся получить отличную ФСЭто Ubuntu-style новость. Ничего ещё нет. И с вероятностью 90% ничего и не будет.
Заголовок звучал бы честнее в виде, например: "Кеш Bcache планирует эволюционировать до полноценной ФС"
Всё основное там уже есть. Нет снапшотов, но их уже почти допилили. По стабильности хоть и альфа может конкурировать со многими "стабильными" ФС, опыт и методы разработки в Google дают о себе знать.
Т.е. вы всерьез считаете, что у того, о чем тут написано по сравнению с zfs "только снапшотов не хватает, ну еще кой-чего по мелочам"?Даже не вдаваясь в обсуждение вагона отсутствующих вещей, предлагаю оценить:
1) когда появился xfs (1993), сколько лет прошло с момента появления до попадания в ядро linux (2001 - 8 лет), сколько лет прошло с момента попадания до того, когда крупные дистростроители объявили о 100%-ной стабильности и рекомендовали к использованию в продакшене без каких-либо опасений (2009-2014 в зависимости от вендора, т.е. еще порядка 8-13 лет)? [на IRIX он стал стабильным, безусловно, намного раньше, но я этого никогда не видел и могу комментировать - но там он вообще немного другой и умеет кучу всего, чего нет в linux-версии]2) когда началась разработка zfs (2001), сколько лет прошло до внедрения в development-версию solaris (2005 - 4 года), сколько лет прошло до полноценного использования в продакшене (~2009, хотя многие важные фичи стали доступны только в 2011 - т.е. спустя еще 4-6 лет).
3) когда началась разработка btrfs (2007), когда вошел в стабильное ядро (2013 - 6 лет спустя) и сколько еще лет пройдет, пока можно будет использовать в продакшене без безумных сюрпризов и потери данных на стабильно работающем железе (неизвестно)?
Можно найти и другие аналогичные примеры. А теперь прикиньте, сколько времени должно пройти, прежде чем некая Bcachefs станет пригодной для реального использования. Примеры времени, необходимого для "вызревания" файловых систем от момента появления до реального использования перед вами... Файловых систем, разрабатываемых кучей крутейших разработчиков, оплачиваемых крупными компаниями (которые как никто больше заинтересованы в том, чтобы внедрить "как можно быстрее" и затраты на разработку начали окупаться, замечу).
>4 годане так много.
она разрабатывается не на пустом месте. А из системы кэширования.
у нее отличные шансы обогнать btrfs.
>когда началась разработка btrfs (2007), когда вошел в стабильное ядро (2013 - 6 лет спустя)
>was finally accepted into the Linux kernel mainline in 2009в 2009. году, а не в 2013.
Эта эпопея с btrfs длится очень давно и до сих пор нестабольное.
> Эта эпопея с btrfs длится очень давно и до сих пор нестабольное.При том - обычно на словах тех кто ей и близко не пользуется :)
>> Эта эпопея с btrfs длится очень давно и до сих пор нестабольное.
> При том - обычно на словах тех кто ей и близко не
> пользуется :)потому что те, кто пользую#$@$&&^%$%451245…
Ты несёшь какую-то лютую уйню...> когда появился xfs (1993), сколько лет прошло с момента появления до попадания в ядро linux (2001 - 8 лет)
в линуксе оно появилось примерно сразу как код XFS открыли под GPL, случилось это как раз в 2000 + некоторое свосем небольшое время ушло на портирование.
> сколько лет прошло с момента попадания до того, когда крупные дистростроители объявили о 100%-ной стабильности и рекомендовали к использованию в продакшене без каких-либо опасений (2009-2014 в зависимости от вендора, т.е. еще порядка 8-13 лет)?
100%-ую стабильность никто никогда не объявляет, зачем несёшь такую глупую отсебячину. Где-то с 2004-2006 было обычным делом видеть XFS в продакшене, для использования на серверах уже тогда XFS была достаточна стабильна. Позже её стали рекомендовать некоторые дистриубиты в качестве основной ФС, это не значит что кто-то объявил эту ФС 100%-но стабильной.
Собственно в линуксе XFS практически не разрабатывали с нуля, в основном портировали, пилили баги и допиливали некоторые минорные фичи. Потому её внедрение и доведение до приемлемого стабильного уровня заняло всего несколько лет. Сама разработка в IRIX заняла около года.
> когда началась разработка zfs (2001), сколько лет прошло до внедрения в development-версию solaris (2005 - 4 года), сколько лет прошло до полноценного использования в продакшене (~2009, хотя многие важные фичи стали доступны только в 2011 - т.е. спустя еще 4-6 лет).
Полноценное использование zfs началось примерно с 2006 - 2007, итого ушло лет 6 до доведения такой адски сложной ФС до продакшн уровня.
> когда началась разработка btrfs (2007), когда вошел в стабильное ядро (2013 - 6 лет спустя)
Нет такого понятия как "войти в стабильное ядро", есть экспериментальные части ядра которые поставляются вместе с релизом всего ядра. btrfs туда засунули в 2009, стали её рекламировать в дистрибутивах к 2012.
> и сколько еще лет пройдет, пока можно будет использовать в продакшене без безумных сюрпризов и потери данных на стабильно работающем железе (неизвестно)?
У btrfs была непростая судьба, в процессе разработки она неожиданно стала не нужна своему основному разработчику (случилось это около 2009-2010 когда сдох sun и вместе с zfs отошёл ораклу), долгое время её пилили условных потора человека. Да и сейчас она не особо кому нужна.
> Можно найти и другие аналогичные примеры. А теперь прикиньте, сколько времени должно пройти, прежде чем некая Bcachefs станет пригодной для реального использования.
Ты даже тут не смог найти никаких аналогов, смешал в кучу разрозненные примеры: XFS и ZFS пилил полноценный штат сотрудников, пилили каждую ФС соразмерно её сложности. А btrfs получала ресурсы эпизодически, к этой же серии долгостроев можно ещё отнести ReiserFS 4.
По своей сложности сабж занимает промежуточное место между xfs и btrfs и как долго его будут доводить до приемлемого уровня зависит исключительно от финасирования. Итого, если найдётся заинтересованное лицо, то сабж допилят за 3-4 года, если нет - будет долгострой вроде btrfs.
Прикольно. Квинтессенция опеннета. Совешенно бредовый ответ на вменяемый камментP.S. И это еще user294 не подключился!
Я извиняюсь но можно расшифровку термина мироная фича
> в линуксе оно появилось примерно сразу как код XFS открыли под GPL, случилось это как раз в 2000 + некоторое свосем небольшое время ушло на портирование.Что не так? Я и написал "2001 год, 8 лет с момента появления xfs в 1993 году". Оно закрытое все эти годы не развивалось, что-ли?
> Где-то с 2004-2006 было обычным делом видеть XFS в продакшене, для использования на серверах уже тогда XFS была достаточна стабильна
Ага, попадая на баги типа повреждения метаданных, которые fsck.xfs не чинил, повреждения журнала, не уходящие без xfs_repair, и прочие радости типа https://bugzilla.redhat.com/show_bug.cgi?id=250843 - исправили только в 2009. Не надо мне рассказывать про xfs в продакшене в 2004, я пытался несколько раз в то время. В итоге на больших разделах, где ext3 не катил постепенно везде ушел на jfs, и оно так и жило, пока ext4 не стал совсем-совсем stable. Вот там действительно не было ни одного бага, не считая несколько повышенной тенденции к фрагментируемости (с чем у ext4 и xfs лучше).
Пока файловая система общего назначения (я не говорю про специализированные) не катит под rootfs или /boot из-за внутренних багов, рассказы про "стабильность" это лапша на уши.
Только когда это все в той или иной степени ушло (2009 и позже), она стала "стабильной". Сейчас, конечно, в продакшен - без проблем.
> Потому её внедрение и доведение до приемлемого стабильного уровня заняло всего несколько лет
2009 - 1993 = 16 лет минимум. Причем тот же RH официально предложил использовать ее как ФС для произвольных задач (а не только больших хранилищ) в 2014.
> Полноценное использование zfs началось примерно с 2006 - 2007, итого ушло лет 6 до доведения такой адски сложной ФС до продакшн уровня.
Это такая шутка, да??? В 2006 году она была эээ в девелопмент-билде Nevada, глючном как неизвестно что. Первые специализированные сторейдж-решения на zfs от Sun появились в конце 2008 года и первые месяцы никто это в продакшен не внедрил. Блин, да поддержка загрузки с zfs в grub'е и rootfs на zfs появилась в стабильной солярке в октябре 2008 года! О каком 2006 идет речь? Поэтому я и написал - реальное использование zfs в продакшене отсилы началось в 2009.
Насчет "доведения до продакшен уровня за 6 лет" - а представляешь себе объем ресурсов, которые Sun влила в zfs (включая подготовку к использованию в своих Sun Storage) и сравни его с тем, который дает гугл & co в эту bcachefs..
> Нет такого понятия как "войти в стабильное ядро", есть экспериментальные части ядра которые поставляются вместе с релизом всего ядра. btrfs туда засунули в 2009, стали её рекламировать в дистрибутивах к 2012.
Не нужно придираться к терминам. Я имел ввиду перевод из экспрементальной категории в ядре в нормальную. Так-то в некотором роде все ядра > 2.6 условно стабильные...
> Ты даже тут не смог найти никаких аналогов, смешал в кучу разрозненные примеры: XFS и ZFS пилил полноценный штат сотрудников, пилили каждую ФС соразмерно её сложности. А btrfs получала ресурсы эпизодически, к этой же серии долгостроев можно ещё отнести ReiserFS 4.
Я привел примеры известных ФС, развивашихся "с нуля" (а не итерационно, типа ext4, потому что там по срокам нечего оценивать), чтобы показать, что не вижу ни одного примера, когда бы современная фичастая ФС становилась стабильной за время от начала разработки < 5 лет. brfs и zfs сюда приплел не я, это из комментария, на который я отвечал - где человек заявил, что по сравнению с btfs и zfs в этой новой, только что объявленой ФС есть все основное, кроме снапшотов, которые "почти допилили", а по стабильности она уже может конкурировать с другими ФС. Только и всего.
> Итого, если найдётся заинтересованное лицо, то сабж допилят за 3-4 года, если нет - будет долгострой вроде btrfs.
Ага, btrfs, значит, "особо никому не нужен" (а что еще использовать под задачи, где фичастость COW требуется - zfsonlinux со всеми его проблемами типа фрагментации кэша и роста потраченной впустую памяти по мере работы?), а тут заинтересованное лицо найдется. Ну-ну...
> Ага, попадая на баги типа повреждения метаданных, которые fsck.xfs не чинилдля людей недалёких: fsck.xfs ничего не чинит. вообще. он вообще ничего не делает с фс.
Ага, а еще reiserfs нельзя проверять, если на нем есть образ другого reiserfs.. А еще у fsck.reiserfs вечно были нестандартные ключи и он ломался при запуске с обычными.В этом и заключается один из аспектов стабильности - когда файловая система прописывается в fstab, как ожидается, а потом выясняется, что в какой-то момент все ломается и запускаемый при запуске fsck ничего не делает (xfs), или того хуже, всегда ругается, что его запустили с такими-то ключами (с которыми скрипт запускает любой fsck) и всегда выходит с кодом 1 (reiserfs), это становится проблемой само по себе. Понятно, что может быть тысяча причин, почему оно так, мало ли что было в голове у разработчиков (и думали ли они вообще о принятых в мире linux вещах), но внедрению в качестве универсальной ФС это мешает очень сильно.
Можно, конечно, переучить пользователей: в том же ZFS потратили до фига сил на популяризацию, почему fsck не нужен. Ну так там вообще революционный подход, и в vfstab прописывать не нужно..
> В этом и заключается один из аспектов стабильности - когда файловая система
> прописывается в fstab, как ожидается, а потом выясняется, что в какой-то
> момент все ломается и запускаемый при запуске fsck ничего не делаетА тут все просто: логика работы разных ФС - весьма разная. Поэтому попытки их всех под одну гребенку - имеют свои, скажем так, особенности и странности :).
Как таковой fsck в его классическом понимании, выполняемый при загрузке ОС - имел смысл для нежурналируемых ФС. Потому что корректность метаданных при крахе не гарантирована. Журналируемые ФС так или иначе должны приходить в консистентное состояние без залета на fsck. В этом пойнт журнала и состоит, ибо время ребута измеряемое часами почему-то вызывает возражения. Если журналом отыграть в консистентное состояние не получилось - это существенный развал механики ФС (бэд сектора и прочие нестандартные ситуации) или серьезный баг (некорректное журналирование, etc). Дальнейшие действия по починке или data recovery - вероятно потребуют человеческого внимания и интерактивной процедуры. Кроме всего прочего - полное сканирование всех метаданных немеряного стоража может занять буквально часы. Ждать загрузки системы ЧАСАМИ - на любителя.
> кодом 1 (reiserfs), это становится проблемой само по себе.
Как таковой "один fsck во все щели" - вполне себе повод для дебатов. Не укладывающееся в многие юзкейсы решение. Мало кому нравится время загрузки сервака с большим сторажем в пять часов. А хомяк на мобилке - не сделает интерактивное восстановление ФС, хоть там что. Там ФС должна сама отбрыкаться. А если не смогла - уже минимум рефлеш. А то и поход в гарантийку. А fsck при загрузке там никому не уперся.
> в голове у разработчиков (и думали ли они вообще о принятых в мире linux вещах),
В Linux не принято пи...ть новичков по причине "здесь так принято". И юзкейсов у Linux немеряно. Вон у squashfs - что должен делать fsck, например? А для initrd - нужен fsck?
> но внедрению в качестве универсальной ФС это мешает очень сильно.
В случае рейзера - мешает скорее общее сочетание факторов. В случае btrfs - да в общем то уже ничего не мешает. Но некоторые подходы там иные. Частично по мотивам zfs.
> Можно, конечно, переучить пользователей: в том же ZFS потратили до фига сил
> на популяризацию, почему fsck не нужен.ИЧСХ, в _этом_ дизайне _некоторый_ пойнт в этой мысли есть. Скорее всего - восходящий к мысли что 5 часов чекать невъ...й стораж до того как сервак вообще стартанет - так себе идея. Намного логичнее попробовать прицепить стораж, чтобы он стал доступен, а метаданные сканировать в фоне. Другое дело что эти умники сначала только вопили про сферические идеальные случаи в вакууме, а план Б на случай если все-таки не вышло - у них был не проработан. И поэтому перец с Лисяры закатывал солнце вручную, хексэдитором. Не больно то приятно в навороченной файлухе хексэдитором колупаться лишний раз.
> Ну так там вообще революционный подход, и в vfstab прописывать не нужно..
А btrfs чем-то похож в этом плане - для него fstab понятие растяжимое. Он на ходу может менять из каких девайсов пул составлен. В этом плане подход с fstab просто не маппится 1 в 1. Да и например - ну вот надо мне rootfs смонтировать. Для того чтобы прочитать fstab ... надо чтобы rootfs уже был. Яйцо и курица, однако. Поэтому rootfs зачастую указывается где-то сбоку.
> сколько еще лет пройдет, пока можно будет использовать в продакшене без безумных сюрпризов и потери данных на стабильно работающем железе (неизвестно)?Уже прошло, доказано фейсбуком.
> Уже прошло, доказано фейсбуком.Экий ты у них батхерт вызвал. А на форониксе недавно была новость что им понравилось и они скоро внедрят и на других серверах :)
> Экий ты у них батхерт вызвалТак контингент что здесь, что на лоре, на 90% состоит из дрессированных обезьянок, которые бабахают при малейшем выходе за пределы шаблона)
> Так контингент что здесь, что на лоре, на 90% состоит из дрессированных
> обезьянок, которые бабахают при малейшем выходе за пределы шаблона)Еще бы ты не бабахал при виде MESA и успехов амдшников :)
тогда она станет не нужна задолго до того времени как станет полноценной ФСуже сейчас есть SSD на 16Тб, а "за 6 лет" еще и скорость их увеличится
> уже сейчас есть SSD на 16Тб,Уже сегодня есть двухпалубные "аэробусы". Зачем какие-то чудаки покупают мелочевку от Cessna?!
Ты серьёзно думаешь что производство HDD сохранится ещё на долго? 8-о
От хорошей ситуации они 8TB диски за $260.00 продают ага ... лет 5-10 и привет как дискетам.
Именно. Нормальный анонс звучал бы как-то так: "Мы тут в порядке эксперимента попробовали из BCache сделать FS - как ни странно, вроде получается, и даже с такими-то занятными возможностями. Разумеется, никакую надёжность не обещаем, хотя у нас самих вроде ведёт себя прилично. В общем, время покажет. что из этого выйдет. а пока приглашаем заинтересованных камикадзе на тест-драйв".Скромнее надо быть.
обидно что поверил в btrfs ?
Ещё чего. Я вообще не верю в комбайны. Одна сущность - одна ответственность.
вот из этого вашего юниксвэя чтобы узнать список файлов нужно распаковать весь многогигабайтный архив.
> вот из этого вашего юниксвэя чтобы узнать список файлов нужно распаковать весь
> многогигабайтный архив.не делай тарболы, тебя никто не заставляет.
> вот из этого вашего юниксвэя чтобы узнать список файлов нужно распаковать весь
> многогигабайтный архив.tar -tf, xz --list, gzip --list, не?
> tar -tf, xz --list, gzip --list, не?А один фиг - для получения списка придется очень много прочитать с диска и все это распаковать. Потому что в tar и прочая нет "концентрированного" оглавления. Вся информация о файлах - рядом с файлами. В результате для оглавления надо распаковать весь архив.
Само название "tar" намекает что это - Tape ARchive. Ленту долго отматывать, поэтому оно оптимизировано на последовательный доступ. Но вот быстренько получить список всех файлов там, действительно нельзя. И это вполне себе недостаток этого подхода.
> И это вполне себе недостаток этого подхода.Недостаток конкретно этого формата уже недостаток подхода?
> А один фиг - для получения списка придется очень много прочитать с диска и все это распаковать.
Если использовать не очень подходящие инструменты, напрочь игнорируя полезные "новшества" типа DAR ...
>> И это вполне себе недостаток этого подхода.
> Недостаток конкретно этого формата уже недостаток подхода?недостаток подхода «стриминг очень дешёвый, seek'и очень дорогие». под который и заточен формат.
натурально, вышенаписаное никак не означает, что других подходов не существует.
>удачно сочетающая функциональность btrfs/zfs с производительностью ext4/xfsВот так будет вдвойне Ubuntu-style!
> участники проекта поставили перед собой цель создания файловой системы, находящейся на уровне btrfs и zfs с позиции функциональности и ext4 и xfs в плане производительности и надёжности.Молодцы! Давайте дерзайте! А то пока дождешься когда допилят btrfs уже свет в черном туннеле увидишь.
А кофе она не варит и завтрак не готовит, не? Прям фантастика от манагеров толкальщиков...
Кофе варит кофемашина а завтрак готовит жена, никакой фантастики, Люк.
>, Люк.Папа, вали нахрен со своей кофемашиной смерти:)
Хз что там кто дожидается, а я уже год ею пользуюсь без проблем.
> Хз что там кто дожидается, а я уже год ею пользуюсь без проблем.Ей уже целый фэйсбук пользуется. И ничего, фоточки котят вроде живы, а последний крупный раунд багфиксов был в 3.19. По итогам тестового запрыга в Facebook как раз.
На HDD не работает?
> Отмечается, что в один прекрасный момент разработчики осознали, что созданные для
> Bcache технологии и наработки содержат заметную часть функциональности файловой системы,
> и если развивать код в нужном направлении, благодаря продуманной архитектуре, удастся
> получить отличную ФС.
>> "I and the other people working on bcache realized that what we were working on was, almost by accident, a good chunk of the functionality of a full blown filesystem - and there was a really clean and elegant design to be had there if we took it and ran with it."Вот прочитал я это и подумал: ""Если бы они не схватили и побежали, а сели бы и подумали, то, может, и полегчало бы. Может, и догадались бы, "всем коллективом", да, что если в нём уже почти готовая ФС, то надо не костылять до "ещё одной"тм ф.с., а привести эту самую архитектуру в порядок и выкинуть _лишнее_.""
Благо не мердж-реквест, а фороникс -- сильных словечек от Торвальдса не услышим, рассказов про мегакомбайны, совершенствование общей инфраструктуры ядра. Толерантненько всё, позитивненько так.
> Код новой файловой системы находится в альфа-стадии разработки (дисковый формат может измениться),
Понятие лишнего у всех разное.
> Новая ФС Bcachefs, сочетающая функциональность btrfs/zfs с производительностью ext4/xfsи старым добрым названием - Reiser4
crc32c это как то фигово, что-то более надежное поддерживается?
> crc32c это как то фигово, что-то более надежное поддерживается?Вы знаете более надежную 32-х битную контрольную сумму? По-моему с crc32 ничего не сравнится - один из лучших (хотя и тормозной, к сожалению). Во всяком случае, fletcher, применяемый в zfs (да, я знаю что при использовании дедупликации и даже без нее там можно поставить sha256, но где вы таких маньяков в жизни видели?) точно проигрывает crc32 по качеству хэширования. Хотя и быстрее.
В файловой системе нет задачи защиты от умышленной модификации данных, когда нужна криптографическая хэш-функция, только от искажений этих самых данных.
sha256 вполне можно использовать если есть AVX.
> если есть AVX.Довольно поганое допущение. Вендорлок называется.
> crc32c это как то фигово, что-то более надежное поддерживается?поди в книжке про криптографию прочитали (уж не буду сразу думать, что просто бездумно чужие слова пересказываете)? Вопрос с подвохом: В чем ненадежность?
хинт: цели разные у разных типов хешей. И хотя, например, sha512 какой-нибудь, если плевать на скорость и размер, тоже очень даже пригоден для тех же целей что и crc32 (обратное утверждение обычно неверно), но это ж весьма лютый overengineering.P.S. CRC-4 и CRC-8 даже вполне себе в ходу, для определенных применений, разумеется.
> просто бездумно чужие слова пересказываете)? Вопрос с подвохом: В чем ненадежность?В том, что на современных объемах данных, если например вы налетите на мусор - есть совсем не нулевой шанс принять его за валидные данные. Просто потому что блоков данных обрабатывается много и 4 байта чексуммы в таком масштабе - как-то совсем и не дофига.
>> просто бездумно чужие слова пересказываете)? Вопрос с подвохом: В чем ненадежность?
> В том, что на современных объемах данных, если например вы налетите на
> мусор - есть совсем не нулевой шанс принять его за валидные
> данные. Просто потому что блоков данных обрабатывается много и 4 байта
> чексуммы в таком масштабе - как-то совсем и не дофига.Подсказка про подвох не помогла. Подвох в том, что зависит от условий применения. Если считать crc на многогигабайтные файлы (вы почему-то только этот случай видите), то может быть шанс коллизий и непомерно большой становится (да и то вовсе не факт из-за второго подвоха - зависит от характеристик появления ошибок). Но фишка в том, что так никто (ну может почти никто) не делает, да и не собирается. Поэтому кричать про ненадежность глупо в этом случае.
А для посекторной защиты, например, на блоки по 512 байт или по 2к, или даже по 4к, в чем проблема? А вот если для этого использовать тот же sha-2, к примеру, то любой здравомыслящий лишь пальцем у виска покрутит, хотя задача проверки целостности будет решена (правда в ущерб кое-чему другому).
Сами погуглите где применяется (десятилетиями) crc-4, crc-6, crc-8 и подумаете почему там этого более чем достаточно и никто даже не поднимает вопрос о "ненадежности"?
Для всего остального есть OpenZFS
> В Bcachefs также реализовано большинство базовых возможностей POSIX ФС, в том числе xattrs и ACL ... в тестах Bcachefs уже заметно обгоняет btrfs, но пока отстаёт от ext4.Отлично. Из перспективной ядерной подсистемы для эффективного кеширования сделали очередного монстра-прослойку которую теперь ещё лет десять будут доводить до юзабильного состояния. Благо есть над чем поглумиться всё это время, т.е. над btrfs
Если будет всё так как заявлено, то это айс. Перейду на неё с btrfs.
Пока ее допилят, надобность в НЖМД на рабочих станциях отпадет.
А там, где надо хранить много архивной инфы, это приблуда нафиг не уперлась.
еще btrfs не запилили, а уже еще одну ФС создают, гагагаг
> еще btrfs не запилили, а уже еще одну ФС создают, гагагагГаа-га, Гаа-га!
Бедные бояздэ-виндузоиды. Никак не могут понять, как можно иметь более 2 ФС на выбор :)
Какому идиоту пришла мысль сравнить btrfs и zfs, равносильно жопу с пальцем. Ну они рядом не стояли, а тут ещё с zfs сравнили очередную недоделку, блин слов нет придурки.
плох тот солдат, что не мечтает стать генералом, так и тут, плохая Фс, не мечтает стать ZFS
Плоха та кофемолка, что не мечтает стать кухонным комбайном! Как и система инициализации, что не мечтает вырасти в полноценный СкайНет и захватить мир!
твоя фетишная zfs такая же фс, как системдос — система инициализации
Отличная?
дубина-фанбой, ни то, ни другое не является тем, чем называется
Зачем изобретать brtfs и эту недоделку? Зачем изобретать колесо в 21 веке? Уже есть zfsonlinux, работает и все там есть.
Кому-то хочется разобраться и сделать что-то своё. Вместо изучения чужого кода разработать свой и стать его хозяином. Разве это плохо?Вот, например, в линуксе ближаший аналог UFS2 - XFS, но она не "своя", а заимствованная. (Аналогично Btrfs, как попытка ответа Oracle на вызов Sun "комбайна" ZFS.) Но всё это - привнесённое в ядро извне корпорациями и продвинутыми энтузиастами, почти не добавляющими собственных компетенций остальным разработчикам ядра. Отсюда и кризис сообщества - нужно тащить "чемодан без ручки", в котором не можешь разобраться, а без него ядро особо неинтересно для сферы долговременного и надёжного хранения данных. Эти важные части ядра полностью зависимы от воли желаний отдельных корпораций и личностей. (Хотя ZFS и отчасти Btrfs уже отчуждены от хозяев).
Так что создание новой "стекируемой" CoW ФС, я считаю, хорошим признаком развития технологий хранения данных, конечно, при условии подключения к ней большого числа тестеров и потенциальных пользователей - это даст лучшую ответную реакцию и стимул к доработке и разработке новых востребованных фич.
А как же HAMMER1/2 DragonflyBSD? Читал его даташиты вроде бы дико фичастая штука и стабильная, но медленная конечно.
Фичастая - да, стабильная - нет. Неделю назад потерял файло в результате ребута резетом. Как назло, крайний снапшот был раньше. Пришлось лососнуть. Так что поиграться можно на досуге, а в продакшон я бы не стал ставить.
ЗЫж Это про первую, а вторая - вообще недопиленный полигон ишшо.
> А как же HAMMER1/2 DragonflyBSD?
> Читал его даташиНе ври.
> Вот, например, в линуксе ближаший аналог UFS2 - XFS,Скорее нечто между EXT2 и EXT3. В UFS даже до сих пор нет нормальных экстентов - это ж надо все переделывать. Всем лень, "на это нет ресурсов".
> "своя", а заимствованная. (Аналогично Btrfs, как попытка ответа Oracle на вызов
> Sun "комбайна" ZFS.) Но всё это - привнесённое в ядро извнеПардон, у оракля нынче и то и другое. Только ZFS им даром не уперлось развивать - оно их базы не потянет. В отличие от btrfs.
> (Хотя ZFS и отчасти Btrfs уже отчуждены от хозяев).
В btrfs как и прежде зажигает Крис Мэйсон. Главный центр компетентности по ФС. Тот кто разработал core дизайна и наваял первый прототип. Никто у него ничего не отчуждал. А ZFS - так у сана маркетинговый булшит победил здравый смысл. Ну, ок. Линуксоиды не бояздэшники, их на пoнт дешевыми маркетинговыми фокусами не возьмешь.
> Так что создание новой "стекируемой" CoW ФС, я считаю, хорошим признаком развития
> технологий хранения данных,Что за нафиг? У изена какой-то приступ здравомыслия сегодня. Да не боись, в винде тебе это не грозит - микрософт предпочитает кормить хомяков дисковыми технологиями из начала девяностых. А что, пипл хaвaeт. В бздях - как обычно нет ресурсов ни на что. Так что выбирай себе из двух тормозил наздоровье. Тебе какое тормозилово - архаичное или энтерпрайзное? :)
>> Вот, например, в линуксе ближаший аналог UFS2 - XFS,
> Скорее нечто между EXT2 и EXT3.Нет у них fsck в фоне и снапшоты не работают, в отличие от XFS и UFS2.
> В UFS даже до сих пор нет нормальных экстентов - это ж надо все переделывать. Всем лень, "на это нет ресурсов".
Зато есть дописывание блоков, что сказывается на компактности хранения, особенно для мелких файлов на больших томах.
>> "своя", а заимствованная. (Аналогично Btrfs, как попытка ответа Oracle на вызов
>> Sun "комбайна" ZFS.) Но всё это - привнесённое в ядро извне
> Пардон, у оракля нынче и то и другое. Только ZFS им даром не уперлось развивать - оно их базы не потянет. В отличие от btrfs.ZFS у Oracle уже своя и отцепилась от авторского кода по версиям и возможностям. Новые фичи системы хранения ZFS запатентованы и открываться не спешат. Oracle сертифицировало использование ZFS для файловых хранилищ и СУБД. Btrfs же пока что для СУБД не сертифицирована, статус файлового хранилища на ней не определён.
>> (Хотя ZFS и отчасти Btrfs уже отчуждены от хозяев).
> В btrfs как и прежде зажигает Крис Мэйсон. Главный центр компетентности по
> ФС. Тот кто разработал core дизайна и наваял первый прототип. Никто
> у него ничего не отчуждал. А ZFS - так у сана
> маркетинговый булшит победил здравый смысл. Ну, ок. Линуксоиды не бояздэшники, их
> на пoнт дешевыми маркетинговыми фокусами не возьмешь."Хозяева" в данном случае: владельцы прав интеллектуальной собственности.
>> Так что создание новой "стекируемой" CoW ФС, я считаю, хорошим признаком развития
>> технологий хранения данных,
> Что за нафиг? У изена какой-то приступ здравомыслия сегодня. Да не боись,
> в винде тебе это не грозит - микрософт предпочитает кормить хомяков
> дисковыми технологиями из начала девяностых. А что, пипл хaвaeт.Пока что милионам пользователей дисковые технологии Microsoft не доставляют особых хлопот. А в современных операционных системах дисковые тома обслуживания (дефрагментации) практически не требуют - все рутинные операции выполняются автоматически, фоновыми процессами. Аналогично и в UFS2, в ZFS. (Да, можно выключить, если нужно.) В GNU/Linux до сих пор такое невозможно - нужно явно запускать fsck и/или ждать, пока он отработает перед началом использования ФС; про дефрагментацию нет смысла даже говорить.
> В бздях - как обычно нет ресурсов ни на что.
В бздах сумели довести порт ZFS до промышленного уровня в 2008 году, в GNU/Linux родную Btrfs — ещё нет.
> Так что выбирай себе из двух тормозил наздоровье. Тебе какое тормозилово - архаичное или энтерпрайзное? :)
Не пользуюсь тормозиловом. Меня раздражает то, что отнимает у меня время.
> В бздах сумели довести порт ZFS до промышленного уровня в 2008 годуВ 2009-м.
> Уже есть zfsonlinux, работает и все там есть.Единственная проблема: мне не требуется на системном разделе файлуха, которую майнлайновое ядро не подцепляет. И вообще, совсем не круто, если после обновления ядра я внезапно останусь без основной rootfs.
А вот снапшоты на системном разделе - это очень удобно. И позволяет оперировать железными машинами в том же духе что и с виртуалками. Т.е. если результат не понравился - отмотал на снапшот за полминуты - и порядок.
> Зачем изобретать brtfs и эту недоделку? Зачем изобретать колесо в 21 веке?
> Уже есть zfsonlinux, работает и все там есть.zfs и "эта поделка" по говнокодости - одного порядка/поля "ягоды".
btrfs (при всей его неадекватности) - хоть код выглядит более-менее вменяемым и поддающимся дальнейшему развитию.
Революция отменяется, сабж - то ещё тормозилово уже сейчас: https://phoronix.com/scan.php?page=news_item&px=BCacheFS-5-W...
> Революция отменяется, сабж - то ещё тормозилово уже сейчас: https://phoronix.com/scan.php?page=news_item&px=BCacheFS-5-W...Если бы Вы внимательно почитали конфигурацию тестера, то увидели бы, что у него всё УЖЕ на ССД. Если бы он использовал для остальных ФС ХДД, а для данной ХДД + ССД, то результат был бы иной. Он бы ещё в РАМ всё запихал и тестил...
Вот мне бы например умный кэш такой на ноуте пригодился. Подключаешь внешний ССД для игрушек через усб 3.0, и на него всё кэшится. Ресурс не тратится почти, и скорость будет гутт. Можно конечно ручками копировать, но это не труЪ.
Вот интересно, а РАМ-диск можно этому bcache скормить? Пару-тройку гигов дать, и может пободрее будет Нью-Вегас запускаться после вылета. Надо потестить как-нибудь )
> Если бы Вы внимательно почитали конфигурацию тестера, то увидели бы, что у него всё УЖЕ на ССДЕсли ФС в 2015 году не блещет скоростью на SSD, то и нафиг она вообще тогда нужна?
Потому что не допилена ещё. Она не для того немного. Это типа технологии SuperFetch в винде, или preload в линухе, как я понял. Только кэшируется на ссд, а не в оперативку.
> Она не для того немногоОна названа полноценной ФС.
> Потому что не допилена ещё
В статье сказано, что она уже обгоняет Btrfs, тогда как в реале она отстаёт.
> Она названа полноценной ФС.Понятия о полноценности ФС - варьируются. Кому readonly squashfs на 4 мега выше крыши. А кому пул на 20 дисков подавай.
> В статье сказано, что она уже обгоняет Btrfs, тогда как в реале она отстаёт.
Ну ты же понимаешь, что каждый автор программы пытается показать себя с наилучшей стороны :). С другой стороны - еще одна простая но шустрая CoW-like файлуха вряядли помешает.
Только в ядре уже есть NILFS (довольно странная штука, весьма медленная), уже пытался пролезть Tux3 (оказавшийся на поверку быстрой эрзац-перепилкой Ext4, с кучей недоработок и проблем на ровном месте). Этому "aффтaру" придется придумать что-то убедительное, чтобы его восприняли всерьез.
> Потому что не допилена ещё. Она не для того немного.Ну так в btrfs тоже оптимизацией еще только начали заниматься.
> Только кэшируется на ссд, а не в оперативку.
Ну так вон ZFS тоже умеет со своим L2ARC, равно как и всякие bcache могут так "для блочных устройств вообще". Идея использовать более быструю память для более часто используемых данных - вообще далеко не новая :)
Отложенная запись пусть сами жрут. Наелись.
Неодураченный по принципу git будет делать
Сильно отложенная? ;-) ИБП надо?
> Сильно отложенная? ;-) ИБП надо?Не знаю как у этих, а в btrfs интервал между чекпойнтами настраивается. Но как обычно это компромисс между менее оптимальной и более частой записью (хуже производительность, а SSD еще и больше протирается) vs более масштабная потеря данных при крахе.
> Отложенная запись пусть сами жрут. Наелись.Или трусы или уж что-то для SSD.
http://lwn.net/Articles/353411/
гы! фс на базе btree - пепел МАКА стучит
> гы! фс на базе btree - пепел МАКА стучитЧто, неужели бинарные деревья запатентовал Эппл? :)
>> гы! фс на базе btree - пепел МАКА стучит
> Что, неужели бинарные деревья запатентовал Эппл? :)только радиусы закруглений, деревья без закруглений прокатят