После двух лет разработки увидел свет (https://github.com/maharmstone/btrfs/releases/tag/v1.0) первый стабильный выпуск проекта WinBtrfs (https://github.com/maharmstone/btrfs/), в рамках которого подготовлен драйвер, предоставляющий возможность работы с файловой системой Btrfs на платформе Windows. Наработки проекта распространяется под лицензией LGPLv3. Примечательно, что WinBtrfs не основан на коде Btrfs из ядра Linux, а является созданной с нуля альтернативной реализацией. Поддерживается работа с Windows 7 и более новыми выпусками. Отмечается, что драйвер уже пригоден для ежедневного использования, но никаких гарантий относительно сохранения целостности ФС не даётся.
Поддерживается большинство возможностей Btrfs, включая запись и чтение (в том числе в асинхронном режиме), использование RAID0/1/10/5/6, кэширование, автообнаружение разделов, ACL, символические ссылки, подразделы, снапшоты, жесткие ссылки, разряжённые файлы, упреждающее выделение места, сжатие, балансировка, проверка целостности данных, изменение размера раздела. Из специфичных возможностей драйвера отмечается реализация альтернативных потоков данных (https://ru.wikipedia.org/wiki/%D0%90%D0%... обработка символических ссылок, поддержка LXSS (окружение Ubuntu для Windows) и сопоставление идентификаторов пользователей Linux и Windows. Для создания разделов, подразделов и снапшотов подготовлены специальные утилиты.
URL: https://www.heise.de/ix/meldung/WinBtrfs-1-0-erschienen-Date...
Новость: http://www.opennet.me/opennews/art.shtml?num=47140
> никаких гарантий относительно сохранения целостности ФС не даётсяЭто главная фишка этой fs и на Linux.
>> никаких гарантий относительно сохранения целостности ФС не даётся
>
> Это главная фишка этой fs и на Linux.ага! именно в таком свете она и преподносится!
но правда на практике почему-то визгов от поломанных ext4-файловых систем -- слышу больше чем от ситуаций с поломанными btrfs.
вот ведь незадача-то! оказывается btrfs в обычном виде (в ситуации БЕЗ включения всех её фишек, а просто используя как обычную файловую систему) -- оказывается на порядок надёжнее традиционных линуксовских журнализируемых файловых систем
> но правда на практике почему-то визгов от поломанных ext4-файловых систем -- слышу больше чем от ситуаций с поломанными btrfsВерь больше своей секте Oracle.
>> но правда на практике почему-то визгов от поломанных ext4-файловых систем -- слышу больше чем от ситуаций с поломанными btrfs
> Верь больше своей секте Oracle.чего там верить -- почти вся продвинутая функциональность btrfs числится как экспериментальная. когда она выйдет из этого статуса -- не ясно. конца и края этому нет..
производительность Btrfs в сложных ситуаицях -- в двое меньше чем Ext4/XFS ...
...практически единственное чем btrfs может порадовать это только тем что её CoW-архитектура оказалась более стойкая к аппаратных сбоям чем архитектура Ext4/XFS (по отношению к аппаратных сбоям) . больше приемуществ на сегодняшний момент у Btrfs пока-что ещё нет.
# P.S.: ну конечно всегда найдётся каконибудь упёртый неадекват кто начнёт включать всякие опции типа сжатия данных и встроенный-в-фс-raid -- а потом БАЦ и "ой! ой! у меня всё вдруг посыпалось" .. ды ещё и на старых версиях ядра
> чего там верить -- почти вся продвинутая функциональность btrfs числится как экспериментальная.Это какая например? Снапшоты и рефлинки работают уж много лет. Сжатие есть, даже два на выбор. Send/receive тоже ничего, хоть и немного нишевая штука. Если это не продвинуто, то что же тогда продвинутость?
>что же тогда продвинутость?RAID5/6
> RAID5/6Это всего лишь одна из фич. К тому же в вике вроде пишут что для свежих ядер большинство известных проблем починено. Из очевидных shortcomings остался факт что ширина stripe всегда по числу доступных устройств, что может быть неоптимально если стораж собран из очень большого количества накопителей.
в вики оригинала сказано, что парити-райды теряют данные при аварийном отключении в некоторые моменты записи.
>> чего там верить -- почти вся продвинутая функциональность btrfs числится как экспериментальная.
> Это какая например? Снапшоты и рефлинки работают уж много лет. Сжатие есть,
> даже два на выбор. Send/receive тоже ничего, хоть и немного нишевая
> штука. Если это не продвинуто, то что же тогда продвинутость?Снапшоты нерекурсивны. Это полный конец обеда.
То есть если ты размазал базу данных по нескольким томам с разными свойствам сжатия, кеширования, размером блока, COW и так далее, как и нужно делать — то консистентный снапшот этой базы целиком ты можешь сделать, только остановив её.
Или у тебя файлсервер, в момент снапшота какие-то файлы перемещаются с одного подтома на другой. Файл вполне может в момент снапшота ещё не прибыть на один подтом, но уже исчезнуть с другого. Потому что снапшот не атомарен.
Добро пожаловать в 1997 год.
И авторы вообще не видят этой проблемы. Этого нет ни в каких планах.
>[оверквотинг удален]
> свойствам сжатия, кеширования, размером блока, COW и так далее, как и
> нужно делать — то консистентный снапшот этой базы целиком ты можешь
> сделать, только остановив её.
> Или у тебя файлсервер, в момент снапшота какие-то файлы перемещаются с одного
> подтома на другой. Файл вполне может в момент снапшота ещё не
> прибыть на один подтом, но уже исчезнуть с другого. Потому что
> снапшот не атомарен.
> Добро пожаловать в 1997 год.
> И авторы вообще не видят этой проблемы. Этого нет ни в каких
> планах.Я кагбэ хотел бы обратить внимание дискутирующих, что эксплуатацию баз данных на CoW файловых системах не рекомендуют вообще. То есть сама идея размещения БД на одной из таких файловых систем дурно пахнет.
И именно по этому для базы выделяют подтом и ставят на нём NOCOW.
Сжатие - дефолт практически. Рейди кривые да. Ну и снепшоты все юзают конечно
Т. е. ты оцениваешь качество продукта по тому кто разработчик, а не реальному состоянию продукта? Ну-ну.
Возможно это потому, что Btrfs не так часто выбирает юзверем нежели тот же ext4
> Возможно это потому, что Btrfs не так часто выбирает юзверем нежели тот же ext4ты прав -- именно поэтому выборка получается не такая хорошая чтобы я мог бы сделать АДЕКВАТНЫЕ выводы по случаям "рассыпалась система"..
субъективно -- посыпавшаяся Ext4 я встречал случаи и у себя и у друзей. посыпавшаяся Btrfs -- читал только на блогах/форумах (но во всех случаях блогов/форумах -- конфигурация Btrfs была далека от стандартной.. впрочем авторы блогов так и говорили "зачем тогда нам ставить Btrfs если не пользоваться её продвинутыми фишками? я бы тогда Ext4 поставил бы")
Фороникс гоняет тесты btrfs в крейсерском режиме, за все годы у них сыпалось один раз. За те же годы они и другие интересные баги ФС описывали, тот же ext4 превращал раздел в полные макароны если всего лишь записать очень большой файл.
надёжность ext4 вообще, мягко говоря, переоценена: она изо всех сил старается сберечь файлы (чего делать не должна, сохранность значимых данных всегда обеспечена бэкапами), но не даёт совершенно никаких гарантий сохранности самой себя. большой раздел может устроить 40-минутную проверку после краша, потребовать ручного вмешательства в fsck, а в тяжелых случаях вообще сдохнуть. к счастью в 3.15 (или около того) завезли xfs v5, и теперь нет проблем.
> надёжность ext4 вообще, мягко говоря, переоценена: она изо всех сил старается сберечь
> файлы (чего делать не должна, сохранность значимых данных всегда обеспечена бэкапами),
> но не даёт совершенно никаких гарантий сохранности самой себя. большой
> раздел может устроить 40-минутную проверку после краша, потребовать ручного вмешательства
> в fsck, а в тяжелых случаях вообще сдохнуть. к счастью в
> 3.15 (или около того) завезли xfs v5, и теперь нет проблем.Если бы только 40мин! :) У меня бывали случаи, когда около 4 часов тестировалась/восстанавливалась!
бывало и 16 часов.
А вот zfs может поковыряться в себе часов 20, а потом упасть - и из дампа ядра доктор скажет, что 32 гб раа ей не хватает, нужно хотя бы 64 - и тогда она через 60 часов починется.
> А вот zfs
> и тогда она через 60 часов починется.В таких ситуациях btrfs быстро скажет, что неисправима и данные не восстановить. Ну, и какой вариант лучше? А вообще, для разных задач — разные ФС. Для Windows, например, берут NTFS и не парятся по поводу сохранности данных (там её нет и не будет).
> Для Windows, например, берут NTFS и не парятся по поводу сохранности данных (там её нет и не будет).Справедливости ради NTFS надёжнее и легче восстанавливаемая чем EXT4, хотя и значительно медленее. Та же exFAT появшаяся в далёком 2006 фичастее и надёжнее чем не имеющий аналогов ответ на неё в виде F2FS появившейся в 2012-ом. Вот то что майковская ReFS менее фичастая чем btrfs факт, хотя им двоим до zfs далеко-далеко.
> Справедливости ради NTFS надёжнее и легче восстанавливаемая чем EXT4,Убитый EXT4 обычно тупо чинится штатным fsck до монтируемого состояния с минимумом потерь, дальше с него вытаскиваем все что было нужно и вопрос исчерпан. С NTFS такие вещи прокатывают не всегда. Бывает что винда улетает в BSOD на неидеальностях. И если в линухе при этом можно пнуть разработчиков, показав баг драйвера и они его починят, при том при спешке есть шанс получить какой-нибудь экспериментальный патч на проверку весьма шустро, то в винде это глухая ситуация. Как максимум может быть нужные файлы вытащит сторонняя утилита разбирающая NTFS сама, но она стоит отдельных денег и это никак не заслуга ни винды ни майков.
> хотя и значительно медленее. Та же exFAT появшаяся в далёком 2006 фичастее и надёжнее
> чем не имеющий аналогов ответ на неё в виде F2FS появившейся в 2012-ом.Exfat - жалкая пародия на современную файловую систему, зато патентов как блох на собаке. Это так по ms'овски. F2FS по крайней мере хорошо работает с современными флешами, оправдывая свое название. И если что, гугл и самсунг уже понапихали его в ведроид. Винде же осталось 0.8% рынка, покуда андроид держит больше половины мобильного сегмента.
> Вот то что майковская ReFS менее фичастая чем btrfs
> факт, хотя им двоим до zfs далеко-далеко."зелен виноград", типа?
> F2FS по крайней мере хорошо работает с современными флешамиСтранно было бы если бы умела плохо, учитывая что exFAT писали в те времена когда многих аппаратных фишек попросту не было. 6 Лет разницы между релизами это не шуточки. Но всё же есть хоть одно доказательство плохой работы exFAT?
> Exfat - жалкая пародия на современную файловую систему
Да ну?
F2FS
Max. volume size 16 TB
Max. file size 3.94 TB
exFAT
Max. volume size 128 PiB, 512 TiB recommended
Max. file size 128 PiB (theoretical 16 EiB–1)
Или это основано на том, что она разрабатывалась в начале нулевых, когда флеш накопители имели мягко говоря отличались от начала 10-ых?Я так понимаю что единственная причина хейта - лицензия и авторы? А факт того, что exFAT можно считать первой и на протяжении 6 лет единственной ориентированной на твердотельные накопители ФС мы просто игнорируем? И то что F2FS только пару лет как начала получать нормальное распространение - тоже опустим.
> андроид держит больше половины мобильного сегмента
И не один год и далеко не один девайс (lg & samsung) поддерживают exFAT. Дальше то что? Или на лептопах и десктопах с шиндоушс люди SSD не используют с флешками?
> Странно было бы если бы умела плохо, учитывая чточто самсунг - крупнейший производитель флеш памяти и не очень нуждается в услугах ms по созданию ФС в таком формате? :)
> exFAT писали в те времена когда многих аппаратных фишек попросту не было.
Когда делался exFAT, характерные черты flash уже были. Но майк делал exFAT с своими соображениями, без учета чужих наработок и используя технологии даже не уровня NTFS.
> 6 Лет разницы между релизами это не шуточки. Но всё же есть хоть
> одно доказательство плохой работы exFAT?Есть доказательства отличной работы F2FS - на флешках, карточках и SSD рвет всех. При этом не обложено патентами, сразу есть в ядре Linux и не надо платить отчисления.
> Max. file size 3.94 TB
Когда solid state устройства такого размера появятся в таком формфакторе (карта памяти, eMMC, ...) - скорее всего наступит время если не совсем переписать, то сильно адаптировать структуры еще раз. Это будет даже не завтра. А сегодня сложно предугадать как делать удобно технологиям которых еще нет.
> exFAT
> Max. volume size 128 PiB, 512 TiB recommended
> Max. file size 128 PiB (theoretical 16 EiB–1)Флешек такого объема на горизонте не видно, зато на структуры существующего флеша ложится абы как. А еще упрощенные структуры, у них нет причин быть быстрыми. Если туда реально вывалить петабайты, с иерархией под стать - оно имхо загнется по скорости. Зачем тебе 512 терабайтов которые ты будешь вычитывать полжизни?
> Или это основано на том, что она разрабатывалась в начале нулевых, когда
> флеш накопители имели мягко говоря отличались от начала 10-ых?Общая логика флеша как ни странно осталась похожей. Но оптимизации которые работали на NOR и SLC NAND в случае MLC NAND работать частично перестали. С TLC еще сложнее. F2FS сделан так чтобы прилично укладываться на все варианты, особенно с контроллером (как у usb флешей, sd карт и eMMC). Но будущие варианты и он предусмотреть не может.
> Я так понимаю что единственная причина хейта - лицензия и авторы?
Странно платить отчисления и пыхтеть с лицензиями ради заурядной файлухи, без внятных преимуществ, с старыми технологиями и дурным лицензированием. Особенно когда есть бесплатная альтернатива которая лучше работает на реальных накопителях. Этого достаточно.
> А факт того, что exFAT можно считать первой и на протяжении 6
> лет единственной ориентированной на твердотельные накопители ФС мы просто игнорируем?А интернет придумал эппл? Очень смешно. Всем кому реально было надо твердотельные накопители (эмбедовка, андроиды и проч) свои проблемы решали, многие годы назад. Без помощи майка. У майка в мелкой эмбедовке доля 0%, в смартах 0.8%, так что я даже не знаю что они используют.
> И то что F2FS только пару лет как начала получать нормальное
> распространение - тоже опустим.Как отладили, оптимизнули и проверили - так и стала получать распостранение. А тут как раз подходящие флешки подоспели - eMMC пошел в массы недавно. На мелочи в полгига без контроллера народ мог и JFFS2 какой-нибудь использовать.
> Дальше то что?
Догадайся.
> Или на лептопах и десктопах с шиндоушс люди SSD не используют с флешками?
А смысл в exFAT на SSD? Он для такого никогда не позиционировался. Он хоть NT security descriptors умеет? Или системный диск без прав доступа это круто? F2FS то умеет все что положено нормальной линуксной файлухе, типа xattrs, шифрования и проч, его умеют бутлоадеры, поэтому он до кучи сгодится и для root и/или boot разделов на SSD. При этом у файлов будут права доступа, xattrs и прочие прелести к которым мы привыкли в полноценных файлухах.
>> Странно было бы если бы умела плохо, учитывая что
> что самсунг - крупнейший производитель флеш памяти и не очень нуждается в
> услугах ms по созданию ФС в таком формате? :)В "услугах" не нуждается, но денег должна. О славный Новый Мир!
https://hitech.newsru.com/article/29Sep2011/msandroidfrplf>> exFAT писали
>>> Странно было бы если бы умела плохо, учитывая что
>> что самсунг - крупнейший производитель флеш памяти и не очень нуждается в
>> услугах ms по созданию ФС в таком формате? :)
> В "услугах" не нуждается, но денег должна. О славный Новый Мир!
> https://hitech.newsru.com/article/29Sep2011/msandroidfrplfИли не должна? Но платит!!?
https://lwn.net/Articles/563687/
https://lwn.net/Articles/338981/
>>> exFAT писали
> Есть доказательства отличной работы F2FS - на флешках, карточках и SSD рвет
> всех.Да ну ладно. Делает аппаратный апгрейд подлежащего железа, что ли?
> Да ну ладно. Делает аппаратный апгрейд подлежащего железапросто чуть меньше насилует это железо несвойственными ему операциями. Но для этого надо слишком много знать о его внутреннем устройстве.
При этом железо - _знает_ о внутреннем устройстве exfat/ntfs/fat32, и обычно неплохо с ними уживается. Но мы же хотим ext4, и сравнивать будем только с ней ;-)
> При этом железо - _знает_ о внутреннем устройстве exfat/ntfs/fat32,Ничего оно не знает. Там просто flash translation layer, GC и wear leveling в фирмвари. Но поскольку флэш сам по себе крупноблочный - ему удобнее всего если записи идут большими кусками и желательно в разные места (делает жизнь упрощенных FTLов проще). Судя по бенчам F2FS самсунгу удалось сделать жизнь флеша проще. И на SD картах, и на флешках, и на SSD.
>> F2FS по крайней мере хорошо работает с современными флешами
> Странно было бы если бы умела плохо,стесняюсь спросить - вы оба ее вообще видели? Или только "да ее ж использует самсуньг!"
Работает она не плохо, а вообще никак - если только...ты не самсунь! (вот так сюпризец, да?)
потому что для правильной настройки - требует сокровеннейших знаний о скрытом от пользователя внутреннем устройстве флэшки, которое ни самсунь, ни любой другой производитель обнародовать не спешит (да куда там - происхождение чипов под фирменными этикетками и то не очень-то узнаешь). Иначе получаешь ровно обратное желаемому - потерю производительности и неэффективный (двойной) механизм распределения нагрузок.Во всех остальных случаях - пользуйтесь exFat (только, б-же упаси, не в линуксе), fat32 или ntfs (в зависимости от размера) - производители ssd, usb флэшек и всякой sd/tf памяти прекрасно понимают, что ей вряд ли посчастливится попасть в телефон самсуня, поэтому все эти самые внутренние хитрые механизмы перераспределения износа - специально подстроены под особенности именно этих fs (ни разу не ext2+, что характерно) - в том числе особо нежно обходятся с местами, которые те обожают продирать управляющими структурами
про гугль - это гражданин ляпнул неподумавши. Гугль почти никогда не использует f2fs, гугль использует ext4 где можно и где нельзя (почитайте об устройстве несъемных телефонных флэшек, ужаснитесь) - ровно потому, что не самсунь он.
> Я так понимаю что единственная причина хейта - лицензия и авторы?
канешна. (хотя, надо заметить, не лицензия, но патент и убил эту fs. Зачем ms понадобилась эта глупость - хз, ну, опять же это ms времен балмера, там с мозгом уже была напряженка, а вот хватательные рефлексы еще были ого-го)
> стесняюсь спросить - вы оба ее вообще видели?Нене, тут только надутые гуси. Но если посмотришь в хексэдиторе как скомпонован партишн и FAT32 на флехах и SD - увидишь ERASE BLOCK. FTL не знает про FAT или партишн, поэтому если ты форматнешь сам - таблица разделов почти наверняка попадет в тот же erase block что FAT. Там часто делается Read-modify-write и есть шанс что однажды ты останешься без таблицы разделов. С битой копией FAT работать можно, а вот без разделов... Так что основная адаптация - правильно разложенная на фабрике ФС. Можно и самому разложить правильно, но проблема в том что размер ERASE BLOCK и PAGE получить стандартным способом нельзя. F2FS однако старается делать операции в виде не враждебном к такой структуре и там есть несколько настроек под размеры структур. У SSD более навернутые контроллеры, им менее критично, но все-таки, F2FS делает удобно и им. В бенчах за это воздается. Одно дело запись попавшая в ERASE BLOCK целиком и другое - канитель с RMW.
> Или только "да ее ж использует самсуньг!"
Самсунь как один из крупнейших производителей одной из лучших флеш-памятей на планете обладает прекрасной экспертизой в области. В отличие от майкрософта. Самсунгу ФС нужна чтобы выжать лучшее из своей памяти. Так память лучше продается. MS же хочет срубить денег на патентов, на каком-то печальном крапе.
> Работает она не плохо, а вообще никак - если только...ты не самсунь!
Форониксу с их бенчами расскажешь. Если оно даже у Ларабеля нормально работает, это показатель.
> потому что для правильной настройки - требует сокровеннейших знаний о скрытом от
> пользователя внутреннем устройстве флэшки, которое ни самсунь, ни любой другой производитель
> обнародовать не спешитПроблема в том что стандартные наборы команд пытаются мимикрировать под как бы диск, с как бы 512-байтовыми как бы секторами. Чтобы совместимость не рушить. А то что эта абстракция грубо не соответствует реалиям - следствие. Производители флешек не обнародуют геометрию, но кладут фабричную ФС с ее учетом. ERASE BLOCK можно посмотреть на примере партишна, он с фабы в отдельном блоке идет. И если выровнять на ERASE, выравнивание по page случится само - ERASEBLOCK состоит из эн страниц. Еще очень желательно чтобы характерный размер блока файлухи и его выравнивание совпало с page или было удачно кратным. Блоки ФС попавшие на пересечение страниц - могут убить скорость записи в пару раз.
> (да куда там - происхождение чипов под фирменными этикетками и то не очень-то узнаешь).
Если очень надо - можно узнать и что за контроллер и что за чипы флеша. Но это нестандартные вендорспецифичные методы или экстрим.
> Иначе получаешь ровно обратное желаемому - потерю производительности
> и неэффективный (двойной) механизм распределения нагрузок.Можно, но F2FS даже в этом случае будет выглядеть относительно удобоваримо для флеша, в отличие от какого-нибудь FAT, где кривое пересечение кластеров с erase blocks и pages достаточно фатально. Чему примером фороникс и Ларабель, понятия не имеющий как и что там выравнивать. F2FS не только оптимизирует выравнивания, но и в целом меняет природу записи так чтобы это было удобно для флеша. Еще CoW ФС неплохо с флешом дружат, даже без специальных выравниваний.
> Во всех остальных случаях - пользуйтесь exFat (только, б-же упаси, не в линуксе)
Нафиг надо. Некромансерская технология от ms.
> fat32 или ntfs (в зависимости от размера) -
... только вы их все-равно правильно не разложите, если геометрию не угадаете.
> производители ssd,
Эти наименее придирчивы и переживут даже неидеальные сочетания. У них FTL очень крутой.
> usb флэшек и всякой sd/tf памяти прекрасно понимают, что ей вряд
> ли посчастливится попасть в телефон самсуня,Они прекрасно понимают что простой и самый эффективный вариант выжать максимум - оптимально разложить ФС на фабрике. Остальное их не колышет и первый же формат флехи аннулирует эти оптимизации. Поэтому до того как сносить фабричную ФС может быть неплохой идеей прикинуть структуру флеша. Хомяки не в курсе, за что и страдают, теряя в скорости в два раза после первого же форматирования.
> поэтому все эти самые внутренние хитрые механизмы перераспределения износа
> - специально подстроены под особенности именно этих fsСкорее фабричную структуру ФС подстраивают к физике флеша.
> (ни разу не ext2+, что характерно) - в том числе особо нежно обходятся
> с местами, которые те обожают продирать управляющими структурамиУ меня есть выводок карт прекрасно живущий с "etx3 без журнала", если не ошибаюсь аж с 2008 (!!!) года. Это были высокоемкие SD карты, порядка 16 гигов, почти на грани технологий на тот момент. Т.е. скорее всего ранний MLC. Нежный и хрупкий. Редкая карта живет 9 лет даже с FAT. Вот ext'овский журнал - этот да, все портит. Тормозит и повышает износ. Не годится он под геометрию флешек. На SSD однако работает нормально, там FTL выдюживает. И к тому же вывешивает статистику как он ощущает происходящее, можно оценить скорость износа. На SSD ext4 с discard и журналом только метаданных проблем не создает.
> про гугль - это гражданин ляпнул неподумавши. Гугль почти никогда не использует
> f2fs, гугль использует ext4 где можно и где нельзяВ телефонах на ведроиде F2FS сейчас уже довольно частый гость, особенно для внутренней памяти. EXT4 для таких применений - не очень. Ну то-есть вы его или гоняете без журнала, а fsck в телефоне все-таки не рулит, или получаете усиленный wear и тормоза от журнала.
> (почитайте об устройстве несъемных телефонных флэшек, ужаснитесь) -
У меня лежит пара дюжин pdf на NAND и eMMC. Я их читал. Ок, требование рандомизации данных и read disturbance в высокоемких флешках штуки очень интересные. Но в случае карт и флех это проблемы FTL. Если FTL нет, можно на UBIFS посмотреть. Он и FTL и FS для raw nand, которые могут даже в такие причуды.
> канешна. (хотя, надо заметить, не лицензия, но патент и убил эту fs.
> Зачем ms понадобилась эта глупость - хз,Чтобы денег получить. Но платить денег за ФС где нет вообще никаких выдающихся технологий - затея гнилая. Единственным достижением стал саботаж роста емкости карт и флех на долгие годы. Спасибо майкрософту, аж два раза.
> В таких ситуациях btrfs быстро скажет, что неисправима и данные не восстановить.Там всегда можно попробовать "btrfs restore" даже если том вообще не монтируется. Тем не менее, обычно удается прицепить readonly даже порушенные тома с бэдами, даже однодисковой файлухи. У btrfs есть жирный плюс в однодисковой конфигурации: в этом случае метаданные по умолчанию кладутся с схемой DUP - в два разных места накопителя. И если вылез бэд под метаданными, обычная ФС здорово развалится. Btrfs при таком раскладе вытащит метаданные из второй копии. Очень способствует тому чтобы с файлухой потом можно было штатно работать.
> Ну, и какой вариант лучше? А вообще, для разных задач — разные
> ФС. Для Windows, например, берут NTFS и не парятся по поводу
> сохранности данных (там её нет и не будет).А в случае btrfs цель как раз данные не терять лишний раз. Если это не достигнуто - ок, это баг, его следует починить. CoW как таковой дает довольно много возможностей вынуть свои файлы, если понимать как это работает.
>к счастью в 3.15 (или около того) завезли xfs v5, и теперь нет проблем.А resize в сторону уменьшения в XFS уже завезли? Если нет, то у неё таки есть проблемы.
А ты не стесняйся - перечисли у кого есть :) А потом пореши - реально ли это проблема?
NTFS?
>NTFS?А на боевом серваке рискнёшь?
> А на боевом серваке рискнёшь?У меня вполне себе позитивный опыт был, ничего не отваливалось.
> надёжность ext4 вообще, мягко говоря, переоценена: она изо всех сил старается сберечь
> файлы (чего делать не должна, сохранность значимых данных всегда обеспечена бэкапами),В дефолтном виде с журналом только метаданных - на данные файла ext4 как раз пофиг. Но журнал ext4 можно настроить по разному, от отсутствия до полного журналирования. Но ext4 не может то что может любой уважающий себя CoW (в т.ч. btrfs): запись со скоростью как без журнала но надежностью полного журнала. CoW делает хитрый трюк, используя как журнал всю поверность. За это приходится гонять garbage collector, но нужда писать данные дважды для полного журналирования все-таки отпадает и это серьезный шаг вперед.
> но не даёт совершенно никаких гарантий сохранности самой себя.В дефолтовом виде большинства дистров как раз наоборот - саму себя сохраняет, но файл может оказаться наполовину новый и наполовину старый. Большинство типов файлов при этом будет испорчено.
> большой раздел может устроить 40-минутную проверку после краша,
Если не было журнала - нет способа вернуть структуры в корректное состосние быстро. Придется сделать полный обход fsck, если это не сделать - будет риск наломать в процессе работы дров, оперируя некорректными структурами ФС. Это может привести к чему угодно.
> потребовать ручного вмешательства в fsck, а в тяжелых случаях вообще сдохнуть.
Потому что нефиг совсем без журнала гонять, если вы не гугль и не можете восстановить реплику данных с соседней машины.
> к счастью в 3.15 (или около того) завезли xfs v5, и теперь нет проблем.
Там насколько я помню тоже журнал только метаданных. А что будет с данными файла при записи - никто вроде бы и не отвечает за это как раз. Или они что-то сделали по этому поводу? Что-то придумать RH должны, для хоть той же реализации reflink придется сделать что-то типа cow. Но XFS изначально не CoW, RH столько осилит/осилил?
Та самая xfs, которая считает нормальным при аварии питания, сбое оборудования или крэше в ядре или драйвере занулить неизвестное количество произвольных файлов?
В самом деле, ни единой проблемы. Потому что этим просто нельзя пользоваться.
Совсем.
> Та самая xfs, которая считает нормальным при аварии питания, сбое оборудования или
> крэше в ядре или драйвере занулить неизвестное количество произвольных файлов?Справедливости ради это более-менее починили, последние рецидивы в районе 2.6.28, чтоли. Что самое смешное это было специально, чтобы после краха непривилегированный юзер не ухватил себе кусок чужого файла к которому у него могло и не быть доступа :)
> Справедливости ради это более-менее починили, последние рецидивы в районе 2.6.28, чтоли.Совсем недолго пришлось подождать.
> Silicon Graphics began development of the Extents File System or XFS in 1993
> file system was released under the GNU General Public License (GPL) in May 2000.
> XFS update for 2.6.28 - Oct 31 2008
> Что самое смешное это было специально, чтобы после краха непривилегированный юзер не ухватил себе кусок чужого файла к которому у него могло и не быть доступа :)(ядовито) Просто блестящее решение.
Как-то раз у при сбое питания xfs сказала мол поврежден суперблок или что-то такое. И стандартный их fsck послал куда подальше - нету суперблока и запасной тоже поломан, ничего не знаю.
Файлы восстановил какой-то вендовой(!) крякнутой(!) софтиной запущенной из под вайна. Причем с именами и прочим, тоесть структура легко сканится и восстанавливается, но стандартные утилиты фс не умеют это сделать, это просто позор...
> Как-то раз у при сбое питания xfs сказала мол поврежден суперблок или
> что-то такое. И стандартный их fsck послал куда подальше - нету
> суперблока и запасной тоже поломан, ничего не знаю.
> Файлы восстановил какой-то вендовой(!) крякнутой(!) софтиной запущенной из под вайна.
> Причем с именами и прочим, тоесть структура легко сканится и восстанавливается,
> но стандартные утилиты фс не умеют это сделать, это просто позор...Сколько раз подряд свет не выключали, а что-то пока ни разу с таким не сталкивался :))
> Сколько раз подряд свет не выключали, а что-то пока ни разу с таким не сталкивался :))Так ты ж выключателем для лампочки игрался. Ты на щитке выключить попробуй.
Я уже начинаю верить, что ты рядом со свечой стоял :)))
Это, наверное, ещё как постараться нужно или иметь такой раздел, чтобы устроить краш с 40-минутной проверкой :))
> Это, наверное, ещё как постараться нужно или иметь такой раздел, чтобы устроить
> краш с 40-минутной проверкой :))Подскажу как ускорить: сначала отключить журнал в ФС, потом - питание. Получишь желаемое. Можно также срубить питание и до загрузки в ОС испортить журнал ФС. Теоретически это само случаться не должно. Практически железо бывает разным и может врать что кэши записаны когда они на самом деле еще в RAM устройства хранения. И если в этот момент гавкнется питание, допущения ФС о работе устройств будут нарушены. При перезагрузке ФС получит не то что ожидалось. Дальше может быть все что угодно. Еще многие ФС думают что если вы читаете данные то они не портятся, а когда вы перезаписываете сектор, перезаписывается только он. Но это может быть и совсем не так. Особенно на SSD.
А не проще отформатироваться в ext2, а потом уже отключать всё остальное? :))
> А не проще отформатироваться в ext2, а потом уже отключать всё остальное? :))Если проще - отформатируйся, я не возражаю. Проблема в том что реальное оборудование может нарушать допущения с которыми делали ФС. Накопители на основе флеша вообще чревато отключать без отправки команды на шатдаун. SSD даже считают сколько раз их срубили без предупреждения. В фоне в фирмвари может крутиться GC и проч, его внезапно обрубить - никто не поручится что будет. У SD карт не так уж редко случается полное разрушение, когда питание пропадает в середине обновления таблиц трансляции блоков. Блоки оказываются перетасованы как колода карт. И там не то что файлов, там ФС нет, таблицу разделов спасибо если найдешь. Где-нибудь в середине флехи.
Поэтому, представляешь, все может развалиться от всего лишь слета питания. Иногда настолько что умирает стораж, особенно этим грешат SD карты и дешевые флехи.
> А не проще отформатироваться в ext2, а потом уже отключать всё остальное? :))"ext2" != "ext4 без журнала".
Но вы этого ещё не проходили - это уже в 8-м классе у вас будет.
Да, ладн, чувак, успокойся ...тем более, что проблемы явно у меня: это ж надо, чтоб так угораздило в эту бочку дерьма однажды попасть )))
А можно ещё проверять надёжность файловой системы, положив ноутбук в ванну с проточной водой :)))
Это могло бы стать чем-то вроде теста на стойкость ФС к водяному охлаждению :)))
>btrfs не так часто выбирает юзверемв сузе вроде по умолчанию
а в процентном отношении от числа установок?
> а в процентном отношении от числа установок?У фэйсбука на нем дохрена серверов. При том у них нагрузки выше среднего десктопа, раз так в эн. По этому поводу сразу после деплоя был всплеск багфиксов, а потом стало так же как во всех остальных ФС. Т.е. какие-то "дежурные" фиксы в примерно тех же количествах и severity.
>> а в процентном отношении от числа установок?
> У фэйсбука на нем дохрена серверов. При том у них нагрузки выше
> среднего десктопа, раз так в эн. По этому поводу сразу после
> деплоя был всплеск багфиксов, а потом стало так же как во
> всех остальных ФС. Т.е. какие-то "дежурные" фиксы в примерно тех же
> количествах и severity.Важно не сколько, а что на них стоит!
И не надо передергивать и тупо ссылаться на ФБ - обычно вменяемые люди БТР ставят под контейнеры (очень удобно, кстати), и таки да, их много, но нагрузка на ФС мизерная. Зато ФС под данными (неважно базы или что еще) кряхтит и пашет, но там БТР'ом и не пахнет, ибо была бы полная труба! Например, где-то полгода назад я мигрировал дюжину dev-хостов с БТР'а (любимая игрушка шефа) на ЕХТ4, потому как на задачах типа rsync и/или SVN даже с тысячами (а у нас десятки тысяч) небольших файлов БТР просто дохнет/висит несмотря на то, что даже SSD стоит!
> Важно не сколько, а что на них стоит!На них стоит Linux, разумеется. Или это про набор софта? Там по разному - у них есть разные группы серверов под разные задачи.
> И не надо передергивать и тупо ссылаться на ФБ - обычно вменяемые
> люди БТР ставят под контейнеры (очень удобно, кстати), и таки да,
> их много, но нагрузка на ФС мизерная.Еще под виртуалки удобно - еще лучше чем контейнеры, reflink для кучи одинаковых виртуалок то что доктор прописал. Удобно также чинить терабайтнй образ порушеной ФС, сделав рефлинком рабочую копию. Снапшоты пригодятся на системном диске - можно вернуть систему в рабочее состояние за пару минут независимо от масштаба дестроя, даже если это окажется rm -rf /usr /bin/something какой-нибудь.
> Зато ФС под данными (неважно базы или что еще) кряхтит и пашет, но там БТР'ом
> и не пахнет, ибо была бы полная труба!Это сильно зависит от характера нагрузки и как эта нагрузка дружит с устройством ФС. Заставить натужно кряхтеть можно любую ФС.
> Например, где-то полгода назад я мигрировал дюжину dev-хостов с БТР'а
> (любимая игрушка шефа) на ЕХТ4, потому как на задачах типа rsync и/или SVN даже
> с тысячами (а у нас десятки тысяч) небольших файлов БТР просто дохнет/висит
> несмотря на то, что даже SSD стоит!Это здорово зависит от того какие именно операции с этими тысячами файлов делать. Что делает svn - я честно говоря не знаю. Он у меня не установлен уже несколько лет к ряду, увы. Я git'ом пользуюсь, особых проблем с btrfs на проекте размером с линуксный кернел вроде не видно. Более крупных проектов у меня под рукой нет.
>визгов от поломанных ext4-файловых систем -- слышу больше чем от ситуаций с поломанными btrfsЧто такое "выборка" знаешь?
> Что такое "выборка" знаешь?нет
> но правда на практике почему-то визгов от поломанных ext4-файловых систем -- слышу больше чем от ситуаций с поломанными btrfs.См. "парадокс доступности информации".
Журналирование по сути менее безопасно, чем перекидывание указателей
В btrfs еще контрольные суммы всюду
> В btrfs еще контрольные суммы всюдуА в случае если ситуация отлична от идеала - можно еще использовать btrfs restore. Утилса попробует прочитать все что читается, без использования драйвера ФС. Можно руками потыкаться в разные generation если при записи новых данных случилось что-то сильно нестандартное, искусственно вернув себя немного в прошлое, когда все еще работало как надо.
У кого еще такие тулсы есть? Для винды такое есть для fat32 и ntfs, от сторонних производителей типа парагона и за отдельные деньги. А под другие ФС таких программ вообще нет, так что если файлуха не смонтировалась - это все, хана. Можете в хексэдиторе разбирать. Так иногда делают для очень ценных файлов, но сколько файлов вы так достанете?
П-ф-ф-ф, в DragonFlyBSDшном HAMMER такое всегда было.
> П-ф-ф-ф, в DragonFlyBSDшном HAMMER такое всегда было.А чего пффф? Разработчики хаммера еще один пример тех кто не стал утыкаться в технологии 90х и пошел дальше. Беглый взгляд на структуры оставил положительное впечатление. Собственно, их проблема в том что это какой-то узкомаргинальный клон бсды. Файлуха симпатичная, но ОС состоит не только из ФС. И вот в этом месте линукс стрекозу очень обижает.
>[оверквотинг удален]
> btrfs restore. Утилса попробует прочитать все что читается, без использования драйвера
> ФС. Можно руками потыкаться в разные generation если при записи новых
> данных случилось что-то сильно нестандартное, искусственно вернув себя немного в прошлое,
> когда все еще работало как надо.
> У кого еще такие тулсы есть? Для винды такое есть для fat32
> и ntfs, от сторонних производителей типа парагона и за отдельные деньги.
> А под другие ФС таких программ вообще нет, так что если
> файлуха не смонтировалась - это все, хана. Можете в хексэдиторе разбирать.
> Так иногда делают для очень ценных файлов, но сколько файлов вы
> так достанете?Зато у БТР'а вообще нет поддержки multipath'а! :) Вот ты скажи, как можно в реальном производстве, где стоимость бизнеса исчисляется миллионами ТАКОЕ ставить?!..
Можно, конечно, приделать костыль посредством установки БТР'а поверх программного дискового массива (mdadm RAID), и все это будет нормально работать, но это все же костыль.
А для локалхоста, пожалуйста, ставь что хочешь.
> Зато у БТР'а вообще нет поддержки multipath'а! :)А это вообще точно должно быть в именно ФС а не как generic услуга ядра для всех?
> Вот ты скажи, как можно в реальном производстве, где стоимость бизнеса исчисляется миллионами ТАКОЕ ставить?!..
У фэйсбука стоимость бизнеса в миллиардах измеряется. А вся эта гигантомания с попытками сделать Очень Большую Машину - напоминает историю мамонтов.
> массива (mdadm RAID), и все это будет нормально работать, но это все же костыль.
Действительно, костыль.
> А для локалхоста, пожалуйста, ставь что хочешь.
У фэйсбука и гугли забавные локалхосты. И их много. И масштабируются они куда как.
>> Зато у БТР'а вообще нет поддержки multipath'а! :)
> А это вообще точно должно быть в именно ФС а не как
> generic услуга ядра для всех?Нет, для нормальных ФС.
и да, для БТРа, поскольку БТР нативно САМА работает со СВОИМ набором дисков, а иначе практически все ее преимущество и эффективность пропадают.>> Вот ты скажи, как можно в реальном производстве, где стоимость бизнеса исчисляется миллионами ТАКОЕ ставить?!..
> У фэйсбука стоимость бизнеса в миллиардах измеряется. А вся эта гигантомания с
> попытками сделать Очень Большую Машину - напоминает историю мамонтов.Еще раз - БТР там далеко НЕ везде! И читай "(хотя бы) миллионами" - так легче? :)
...
> У фэйсбука и гугли забавные локалхосты. И их много. И масштабируются они
> куда как.Перечитай внимательно мой пост - для контейнеров БТР практически идеальная система ибо позволяет создавать подтома на лету без задержек. Но при интенсивной работе с множеством мелких файлов - тормоза. Такие же тормоза при заполнении ФС.
И их "локалхосты" используют собственные решения, где тот же БТР - лишь частный случай, причем даже не столь уж значительный.
> Нет, для нормальных ФС.Я преклоняюсь перед гуру. Это мощное и убедительное архитектурно-техническое обоснование правоты. А критерии нормальности для ФС можно увидеть, о великий?
> и да, для БТРа, поскольку БТР нативно САМА работает со СВОИМ набором
> дисков, а иначе практически все ее преимущество и эффективность пропадают.БТР в лине с одной стороны делает райд кастомно, чтобы иметь возможность делать его по chunk-ам, без привязки к блочным девайсам и их размерам. С другой реюзает услуги ядра линукс по максимуму. Поэтому в отличие от "нормальных" не прет свой менеджер кэша. И даже чексумы и алгоритмы райд - из модулей ядра линя, они же используются и другими. А как это на устройства потом раскидать - второй вопрос.
Откуда напрямую напрашивается вопрос - где в случае линукса таким вещам на самом деле место. Судя по описанию от этого могут выиграть и другие ФС, не? А распихивание этого в именно ФС ничего уникального не дает вроде?
> Еще раз - БТР там далеко НЕ везде! И читай "(хотя бы) миллионами" - так легче? :)
БТР там напихан довольно много где, более чем достаточно для крупномасштабных тестов, оптимизаций, исправления кучи багов и проч. И поимки нескольких глючных контроллеров на серверах.
> Перечитай внимательно мой пост - для контейнеров БТР практически идеальная система ибо
> позволяет создавать подтома на лету без задержек.Мне рефлинки нравятся. Можно поднять эн похожих виртуалок с жирным диском из шаблона в мгновение, места вся армада почти не займет: хранятся только отличия от readonly шаблона, которые запишутся в сторонку по мере появления отличий. Этот фокус может вызвать отвис челюсти у тех кто не знает что такое рефлинки. Ведь подъем такой армады обычным методом займет добрых полчаса и дико грузит стораж. Главное не сильно наглеть с числом рефлинков, иначе может просесть. Но даже с этим ограничение довольно эпично. Потому что остальные и так не могут.
> Но при интенсивной работе с множеством мелких файлов - тормоза.
> Такие же тормоза при заполнении ФС.У CoW есть поводы для фрагментации. Особенно если ФС забита. Но можно врубить автодефраг и реже чекпойнтить, например. Автодефраг несмотря на название всего лишь пытается оптимизировать записи для более линейного размещения, объединяя их. Возможно имеет смысл дефрагить иногда, если к мелким файлам много кусочков дописывается, так что cow делает много фрагментов. Может быть in place хранение мелких файлов плохо работает. Но я не знаю что за файлы, насколько мелкие и что с ними делают. Может быть ваша нагрузка неудачна для CoW. Так навскидку - git с актуальным линуксным ядром на btrfs работает вполне прилично, хотя файлов там довольно много.
> И их "локалхосты" используют собственные решения, где тот же БТР - лишь
> частный случай, причем даже не столь уж значительный.Это правда, но это и есть правильный способ создания больших суперструктур. А распальцы технологиями похожими на мамонтов выглядят очень спорно. Сколько крутым железом не бряцай, до уровня мордокниги его не отмасштабировать. Да и сказ про надежность для железа сконцентрированного в одной физической локации выглядит неубедительно. Вот то что вы распределенную ФС размазанную по всей планете не убьете даже метеоритом долбанувшим в датацентр - вот это пожалуй.
>> Вот ты скажи, как можно в реальном производстве, где стоимость бизнеса исчисляется
>> миллионами ТАКОЕ ставить?!..
> У фэйсбука стоимость бизнеса в миллиардах измеряется. А вся эта гигантомания свы стоимость бизнеса с угрозой этому бизнесу поксорьте.
Потому что у мордокниги стоимость гигантская, но если навернется чохом процентов даже 20 котиков - ну пожужжат юзвери немножко, забанят еще по разику сцукенберга, напишут что-нибудь обидное - и дальше котиков понапостят, все равно им пойти некуда.
А у какого-нибудь крохотного банчка даже без права выдачи денег физлицам - один фейл, и привет, все причастные лежат в аккуратных ямках в подвале под хорошим слоем качественного бетона, потому что так дешевле, чем увольнять по банкротству предприятия.> У фэйсбука и гугли забавные локалхосты. И их много. И масштабируются они
> куда как.повторяем: фейсбуку и гуле, которую ты на остановке забыл, совершенно, феерически наcpать на сохранность твоих данных. Да и большей части своих тоже - они уверены, в текущей схеме, что не потеряют разом заметную часть, и им этого вполне достаточно. Поскольку сравнивают где-то так: "при такой аварии мы снижаем эффективность подбора рекламы на столько-то и теряем бабки рекламодателей в таком количестве на такое-то время, пока система не наестся снова. Антиаварийные меры стоят на столько-то дороже, поэтому забьем на них."
_свои_ (там где бабки) они при этом не на люстре хранят ни разу.
> вы стоимость бизнеса с угрозой этому бизнесу поксорьте.На фоне распределенных ФС масштаба планеты, блокчейнов и проч это лишь небольшое стадо мамонтов.
> Потому что у мордокниги стоимость гигантская, но если навернется чохом процентов даже
> 20 котиков - ну пожужжат юзвери немножко, забанят еще по разику сцукенберга,
> напишут что-нибудь обидное - и дальше котиков понапостят,Когда кто-то пытается доказать что есть лишь один путь, человеку с мозгом следует посмотреть вокруг и увидеть другой путь. Можно вообще не терять котиков. Никогда и никак. В большой инфраструктуре постоянно что-то отказывает - очень кстати если все автоматически реплицируется и чинится. В лучшем случае пользователи не заметят даже отказ пары ДЦ. Суперструктура просядет по скорости из-за снижения уровня репликации и повышения нагрузки в пересчете на сервер. Когда мощности починятся - производительность и уровень репликации восстановится. А что будет с вашими "супернадежными" технологиями если какое-то ЧП вынесет ДЦ? Ах, скажете "service unavailable" и будете рвать зад в режиме аврала? И этих людей предлагается слушать на предмет надежности? Дааааа?
> А у какого-нибудь крохотного банчка даже без права выдачи денег физлицам -
> один фейл, и привет,Ну вы сами написали почему блокчейны рулят. Попробуйте по такой технологии завалить биткоин?
> на сохранность твоих данных.
Не обязательно. Как вариант есть еще обеспечение надежности на другом уровне абстракций, когда кучка реплик разлетается по географически распределенным машинам. При этом даже отказ целого ДЦ не проблема.
Хинт: отдельно взятому юниту не обязательно быть мощным и надежным для того чтобы получившаяся суперструктура была мощной и надежной.
> Да и большей части своих тоже - они уверены, в текущей схеме, что не потеряют
> разом заметную часть, и им этого вполне достаточно.Конечно, ведь есть такая штука как репликация. Если часть машин отпадет - и фиг с ними. Можно починить в обычном режиме, а не авральном, после чего производительность вернется на исходный уровень.
> Поскольку сравнивают где-то так: "при такой аварии мы снижаем эффективность
> подбора рекламы на столько-то и теряем бабки рекламодателей в таком количестве
> на такое-то время, пока система не наестся снова. Антиаварийные меры стоят
> на столько-то дороже, поэтому забьем на них."Скорее ближе к "в случае крупной аварии ваши котики грузятся немного медленнее". Но никто это и не заметит даже без бенчмарков.
> _свои_ (там где бабки) они при этом не на люстре хранят ни разу.
Да при чем тут люстры? В инсталляциях такого масштаба обычно свои решения под именно их задачи. У гугли есть распределенная ФС, она прозрачно переживает отвал ряда машин, никто ничего не замечает. А машины тем временем можно неспешно починить.
С какого перепоя в нити речь о Гугл пошла, у них своя пропиетарная GoogleFS.Ну Фейсбук так себе пример - достаточно тормозной ресурс, иногда крашащийся и не способный открыть jpg переброшенные через мессенджер, к тому же на пэхэпэ.
> С какого перепоя в нити речь о Гугл пошла, у них своя
> пропиетарная GoogleFS.Это, конечно, немного оффтоп, но слова из песни о современных технологиях хранения не выкинешь. Технологии есть, не учитывать это странно. К тому же большинство достаточно крупных инсталляций рано или поздно приходят к чему-то такому. Не обязательно как ФС, но общая идея остается.
> Ну Фейсбук так себе пример - достаточно тормозной ресурс, иногда крашащийся и
> не способный открыть jpg переброшенные через мессенджер,А ты попробуй сделать лучше и в таком же масштабе - узнаешь почем фунт лиха.
> к тому же на пэхэпэ.
У них там вроде бы свой особый уличный пых, с хипхопом и виртуалками.
Увы, нет. Блоки данных не подписывают (и не видел в плане, но хочу здесь ошибиться).
> Увы, нет. Блоки данных не подписывают (и не видел в плане, но
> хочу здесь ошибиться).Если надо именно цифровые подписи, как предотвращение "разбойного" изменения файлухи, даже атакующим загрузившимся с какой там внешней флехи и проч - это наверное куда-то в сторону IMA смотреть надо. IMA не принципиально какая там ФС, лишь бы xattrs умела. Btrfs в этом плане ничем не хуже других, xattrs он умеет.
> Если надо именно цифровые подписи, как предотвращение "разбойного" изменения файлухи,
> даже атакующим загрузившимся с какой там внешней флехи и проч -
> это наверное куда-то в сторону IMA смотреть надо. IMA не принципиально
> какая там ФС, лишь бы xattrs умела. Btrfs в этом плане
> ничем не хуже других, xattrs он умеет.Я всего лишь про поблочные хэши. Которые подсказывают, что если сумма не бьётся — данные в блоке тю-тю. Мега-актуально для немагнитных носителей информации.
ЭЦП на уровне ФС — как-то всё-таки слишком, на мой вкус. Там обычно шифрования хватает.
> Я всего лишь про поблочные хэши. Которые подсказывают, что если
> сумма не бьётся — данные в блоке тю-тю.В btrfs для блоков считается crc32. Не предел мечтаний, но для озвученных целей - вполне достаточно.
> Мега-актуально для немагнитных носителей информации.
Там для начала своя ECC. Если она уже не тянет, так что апликухи увидели ошибки - накопитель здорово сыпется и просится в мусор. И если уж мы об этом, CRC32 обладает весьма приличными свойствами отлова битовых ошибок характерных для осыпающегося флеша и для этих целей он выглядит весма неплохим компромиссом.
> ЭЦП на уровне ФС — как-то всё-таки слишком, на мой
> вкус. Там обычно шифрования хватает.В случае IMA можно зарубить даже активные атаки при которых атакующий цепляет стораж к своей системе, активно его патчит там, имея на это в своей системе полные права, а потом цепляет обратно к атакуемой системе, в надежде что система купится на это и станет работать с его данными или кодом. В случае IMA такую диверсию можно обнаружить.
А шифрование диска само по себе защищает только от изучения данных атакующим. Но вот если атакующий вместо изучения запишет свои данные, они во что-то расшифруются. Если там не было сильной проверки целостности, атакующий даже не зная ключ может поприкалываться подпихивая системе мусор и устроив fuzzing. Если атакующий может видеть результат расшифровки, за несколько попыток можно более целенаправленно подобрать шифрованный блок, чтобы тот расшифровался во что-нибудь полезное атакующему. Без знания ключа. Можно зарубить сильными хэшами завязаными на ключ, но облом в том что их надо где-то хранить и лобовое шифрование секторов/блоков 1 в 1 тогда уже не получится, надо еще хэши куда-то рассовывать. И умеет ли так хоть кто-нибудь - отдельный вопрос и это надо здорово RTFMать про выбранную схему шифрования.
может быть "визгов от поломанных ext4-файловых систем" больше, потому, что ext4 гораздо чаще используется.
> но правда на практике почему-то визгов от поломанных ext4-файловых систем -- слышу больше чем от ситуаций с поломанными btrfsВероятно это потому, что файловых систем ext4 на пару порядков больше.
Соотношение пользователей ext4/btrfs распространи на кол-во поломанный этих ФС и тогда более точно узнаешь реальность.
Интересно, у меня btrfs два раза вставала колом(было 2 раздела, корень забился при обновлении, /home при повседневной работе), когда заканчивалось место они становились readonly, т.е. даже удалить ничего нельзя, ни файлы, ни снапшоты т.к. нельзя записать, причем по показаниям df занято около 66%, утилиты btrfs выдают вообще полную ересь, ни одно из найденых решений не помогло(балансировки метаданных, что-то типа отключения CoW итд).
> Это главная фишка этой fs и на Linux.Да ты знаешь, в почти всем софте разработчики пишут AS IS и максимально отказываются от гарантий. Поэтому с какого-нибудь рейзера где fsck разнес раздел или майкрософта, где драйвер нтфс мог вынести даже таблицу разделов ты не получишь ни-че-го.
да уж ;) при обновлении сусе это особенно сказывается
Можно подумать, они вообще хоть где-то когда-то делаются.
Будет очень забавно, если в родной версии raid и прочие радости не работают нормально, а в этой написанной с нуля все отлично.
> пригоден для ежедневного использования
> никаких гарантий относительно сохранения целостности ФС не даётсяВыберите что-то одно.
>> пригоден для ежедневного использования
>> никаких гарантий относительно сохранения целостности ФС не даётся
> Выберите что-то одно.Вообще-то в оригинале было веселее написано:
...assume that the driver is going to corrupt your entire filesystem, and you'll be pleasantly surprised when it doesn't.
Словом, удивись, что оно все еще работает!.. :)
> Словом, удивись, что оно все еще работает!.. :)Это еще что, попался тут совет езды на велосипеде: действуйте так, как будто весь мир сговорился вас убить. Пессимистично, не совсем правда, но очень способствует сохранности шкурки невзирая на толпы пофигистов, идиётов, слепые зоны водителей и что там еще.
>> Словом, удивись, что оно все еще работает!.. :)
> Это еще что, попался тут совет езды на велосипеде: действуйте так, как
> будто весь мир сговорился вас убить. Пессимистично, не совсем правда, но
> очень способствует сохранности шкурки невзирая на толпы пофигистов, идиётов, слепые зоны
> водителей и что там еще.не действует ;)
Ты врешь. Если бы способ не работал и ты это проверил - ты бы не смог откоментить и мы бы этого не узнали ;)
> Ты врешь. Если бы способ не работал и ты это проверил -"ошибка выжившего".
Ну, или так: http://zadolba.li/story/2984 (в самом конце там забавный анти-вывод)
Хорошо написано, но вот антивывод сделан на песке и игнорирует долговременные последствия. Если бы работаюший мозг не давал преимуществ, млекопитающие могли бы остановиться в развитт на уровне какой-нибудь землеройки.
так землеройки и живут себе. И ядерную войну, скорее всего, переживут, в отличие от высокоразвитых.
> так землеройки и живут себе. И ядерную войну, скорее всего, переживут, в
> отличие от высокоразвитых.А теперь игнорируется тот момент что люди отгеноцидили немало биологических видов. Знаешь кто такой дронт? Кого не отгеноцидили - ареал обитания сдулся, много живности не любит в городах жить. Некоторых в зоопарки упаковали. А был бы у землеройки мозг больше твоего - в зоопарке был бы ты. А ядерная война была бы для тебя вне понимания. Если бы твой мозг был покруче и у тебя были зачатки самосознания и ты пережил бы это - тогда ты рассказывал бы потомкам как на небе дрались боги, наверное. За отсутствием лучших объяснений наблюдаемому действу.
>> Словом, удивись, что оно все еще работает!.. :)
> Это еще что, попался тут совет езды на велосипеде: действуйте так,
> как будто весь мир сговорился вас убить.А мне при езде на велике вспоминается, как инструктор на вождении говорил: "двухколёсного объезжай так, как будто он УЖЕ грохнулся прямо перед тобой".
Вообще же водительский опыт на дороге настолько полезен вне зависимости от типа ТС, что ещё тогда возникла мысль учить детей в школе, если не в садике, кататься на чём-нить не совсем сразу останавливающемся (детской машинки вполне хватит) и повыскакивать внезапно из-за деревьев, чтоб надёжней понять "с той стороны стекла" и, может, когда-то притормозить да не выскочить...
PS AOT re #5: так это же про винду, там такие параграфы "не конфликтуют" (см. EULA).
PPS: User294? :)
> PPS: User294?Спалил кого? Там можно в статью?
>> Словом, удивись, что оно все еще работает!.. :)
> Это еще что, попался тут совет езды на велосипеде: действуйте так, как
> будто весь мир сговорился вас убить.and you'll be pleasantly surprised когда очнетесь не на том свете, а в реанимации
> and you'll be pleasantly surprised когда очнетесь не на том свете, а в реанимацииА что, по твоему лучше оптимистично думать что пронесет и в результате выиграть бесплатный прием у патологоанатома?
на Win 10 это не нужно, там Linux встроен, какую хошь fs такую и подключай:)
Потому что Win10 не нужен =)
> Потому что Win10 не нужен =)нужен, куча игор в стиме не кроссплатформенные еще, а если и кросс, то у них куча багов, правда в основном не специфичных для линукс ;)
Ну чего же ты про игоры? Они тут все серьёзные программисты. Вон, сам Шигорин постит, а он у них самый главный программист. А ты про свои игоры.
> на Win 10 это не нужно, там Linux встроен, какую хошь fs
> такую и подключай:)Вообще-то нет. В WSL VFS реализован как адаптер к NTFS.
> на Win 10 это не нужно, там Linux встроен, какую хошь fs
> такую и подключай:)Как бы не так. Чтобы вгрузить ядерный модуль - должно быть ядро, при том подходящей версии, функциями которого модуль пользуется. А в винде нет ядра Linux. Если бы было - пришлось сорцы релизить и это был бы номер.
Нет там линукса. Там только программы пространства пользователя
И блочные устройства оно не умеет.
В следующем ядре zstd прикрутят. У ntfs сжатие вообще никакое.
> В следующем ядре zstd прикрутят. У ntfs сжатие вообще никакое.Zstd хорошая штука: распаковывается заметно быстрее zlib и при этом жмет лучше.
>> В следующем ядре zstd прикрутят. У ntfs сжатие вообще никакое.
> Zstd хорошая штука: распаковывается заметно быстрее zlib и при этом жмет лучше.за это нужно платить памятью.
Блоки по 4 кб, вероятно дополнительный расход не будет превышать 1-ого мегабайта в момент чтения.
> за это нужно платить памятью.ФС оперирует мелкими блоками, да и zlibовское ограничение словаря в 32 кило нынче выглядит забавно даже в самой мелкой эмбедовке на которой используется Linux. Чтобы линукс вообще бутануть надо минимум несколько метров оперативы.
ахренеть - похоже, все сделал один-единственный человек за пол-года. (орацле - вы лохи помойные)
Эх... эту б энергию да в развитие zfs.
> ахренеть - похоже, все сделал один-единственный человек за пол-года.Btrfs в линуксе в черновом виде тоже накидал один единственный человек за какие-то месяцы. А потом началась отладка и оптимизация, анализ и починка проблем. Дизайн достаточно сложный, в нем большой задел на будущее. До сих пор даже в линуксе реализовано не все что технически можно. Поэтому анализ краевых условий, тестирование и оптимизации потребуют массу времени. А для этого драйвера все только начинается. Романтика. Но возможность цепануть к винде btrfs'ный том лишний раз, хоть и без гарантий, все-таки неплохо наверное.
> Эх... эту б энергию да в развитие zfs.
Его никогда не будет в Linux в нормальном виде. А совместимость с маргинальщиной типа ныне уже покойной соляры и bsd которых на радаре не видно - менее ценна. В макакоси, единственном сколь-нибудь популярном *никсе, эппл затею с zfs завернул.
> Его никогда не будет в Linux в нормальном виде.так linux - ненужен. И совместимость не нужна.
Нужна файловая система для хранилки (которая все равно на каком железе, не говоря уже - какая там операционка - хоть иллюмос, если в ней ничего кроме zfs snap не дергать, там и kernel panic не будет). С приличными драйверами приличных (читай, новых-модных интеловских) сетевух, поддержкой специфических протоколов (RDMA и вокруг) и т д - это в общем и все, что требуется от операционки. А ходить к ней могут хоть линуксы, хоть винда 2024.шансов что таковая вырастет из btrfs - около нуля, поскольку с одной стороны - орацле и gplно-укушенные, а с другой rhel, уже потративший деньги инвесторов, чтобы проект закoпать (а ведь те спросят, что это у вас за позеленевшие конечности из грядок повыглядывали).
шансов что получится у MS, которая по сей день даже грузиться со своей refs не научилась (но и не угрожает что это write-only fs), в общем-то тоже около нуля.
а вот у zfs шансы есть, причем как-то последнее время основные интересности происходят именно в линуксной ветке - похоже, именно вокруг нее собралось больше то ли вменяемых, то ли просто имеющих много лишнего времени разработчиков.
поэтому и очень жаль усилий, потраченных на пусть презабавную, но почти бесполезную говорящую лягушку, когда человек явно мог и впрямь что-то хорошее делать.
ну и, кстати, насчет никогда - это ж clean room изделие. То есть - точно так же можно было и ту же zfs реализовать. Сохранив совместимость пулов лишь в той мере, чтобы работали send/receive. Под линукс в том числе. Хотя под виндой, конечно, было бы смешнее.
> так linux - ненужен. И совместимость не нужна.Тебя никто и не заставляет им пользоваться. А мне вот Linux нужен. И еще толпе народа.
> Нужна файловая система для хранилки (которая все равно на каком железе, не
> говоря уже - какая там операционка - хоть иллюмос,Нужна всей галактике, как универсальный ответ? Или это лишь ты и твой класс задач? Может, стоит быть скромнее? Я вот не рад что за меня кто-то рассказывает что мне должно быть надо.
> если в ней ничего кроме zfs snap не дергать, там и kernel panic не будет).
А у других людей могут быть и иные сценарии использования ФС. Мне вот твой сценарий не слишком интересен. Зато много других.
> в общем и все, что требуется от операционки. А ходить к
> ней могут хоть линуксы, хоть винда 2024.Btrfs более универсален чем ФС для хранилки. Его можно на системный диск, на мелкий одноплатник, на сервак с виртуалками ради быстрого подъема группы похожих VM. А ZFS под это все - а ну его в болото. Особенно под линуксом, где он внеядерный выкидыш.
> шансов что таковая вырастет из btrfs - около нуля, поскольку с одной
> стороны - орацле и gplно-укушенные, а с другой rhel,В btrfs есть одна сторона - те кому он нужен. Они его и пилят, так как им нужно.
> уже потративший деньги инвесторов, чтобы проект закoпать (а ведь те спросят, что это
> у вас за позеленевшие конечности из грядок повыглядывали).Что редхат сделает? Не будет разрабатывать? Так у них никогда не было серьезных разработчиков btrfs. Да и гранды ядра из области ФС из редхата постепенно перешли в другие компании. Так получилось.
> шансов что получится у MS, которая по сей день даже грузиться со
> своей refs не научилась (но и не угрожает что это write-only
> fs), в общем-то тоже около нуля.Тебе не приходило в голову что все эти storage appliances довольно маргинальный товар? Вот и нет очереди из желающих зарубиться за этот рынок. Его не хватило для удержания санок на плаву, если что.
> а вот у zfs шансы есть, причем как-то последнее время основные интересности
> происходят именно в линуксной ветке - похоже, именно вокруг нее собралось
> больше то ли вменяемых, то ли просто имеющих много лишнего времени разработчиков.А для меня все это - "где-то там". И к storage appliance я дышу ровно. А вот btrfs мне полезен.
> поэтому и очень жаль усилий, потраченных на пусть презабавную, но почти бесполезную
> говорящую лягушку, когда человек явно мог и впрямь что-то хорошее делать.Хорошее для кого? И зачем винде уметь читать файлуху из appliance-а? Это несет какую-то практическую ценность? Человек сделал то что ему было интересно и нужно. Если ты хочешь рассказывать что и кто должен делать - устройся на руководящую должность или предложи много денег. Иначе есть высокий риск получить фак в лицо.
> ну и, кстати, насчет никогда - это ж clean room изделие. То
> есть - точно так же можно было и ту же zfs реализовать.Теоретически в этом мире можно довольно много чего. Не все из этого легко реализуемо или даже имеет смысл затевать. Если ты считаешь что это надо - так вот ты и затевай. Или занеси сотни денег другим, чтобы они вкалывали вместо тебя. А забесплатно командовать другими не очень хорошо получается.
> Сохранив совместимость пулов лишь в той мере, чтобы работали send/receive.
> Под линукс в том числе. Хотя под виндой, конечно, было бы смешнее.Кому все это надо - тот наверное это должен делать. Или можно оплатить эту работу и ее сделают другие, если их заинтересуют предложенные условия.
Только что собрал для Windows (5Тб ЖД, 8Гб ОЗУ)
Если раньше на ntfs подтормаживало то сейчас на btrfs прямо ух
А не падает? Главное же в стабильности!
Пока нет, надеюсь что и не будет
Мне кажется иногда зависит от железа
Вот не прёт GhostBSD на AMD и всё(LiveCD), даже отключив ACPI. А в VirtualBox прёт.
Windows 10 на Самсунг частые BSOD а на Asus нет.
Надо будет накатить тогда.
А у Вас есть 5Тб HD?
Вдруг если меньше, будет виснуть. Осторожно!
> А у Вас есть 5Тб HD?
> Вдруг если меньше, будет виснуть. Осторожно!Причем тут 5Тб?! Зависит от заполнения диска на самом деле.
Это известная бага (фича?) БТРа: до 50% - все хорошо, от 50% до 80% - в зависимости от данных, после 80% - тормоза!P.S. Для справки: чтобы потом не придирались - цифры ориентировочные и зависят от многих факторов... просто чтобы проиллюстрировать проблему.
> Это известная бага (фича?) БТРа: до 50% - все хорошо, от 50%
> до 80% - в зависимости от данных, после 80% - тормоза!Ты удивишься, но в best practices ZFS'а тоже говорится про 80%. Это любого CoW касается, из соображений пространства для маневра для укладывания фрагментов при записи целиком. А так изена спроси насколько можно zfs ушатать, у него в этом экспертиза.
Кстати ушатанный btrfs можно дефрагментнуть накрайняк. А zfs - там дефраг сделали? Или предлагается разобрать и пересоздать весь пул заново?
Таки точно 294, привет :-)
А права?
Чего, винду на btrfs поставил?
> Чего, винду на btrfs поставил?она ж не загрузится. Но юзерские данные перенести вроде можно.
Не не, он ставил прямо на btrfs. Он же так и пишет.
> Он же так и пишет.Рабинович, откройте рот! Так... Закройте. Не вижу патологии, мешающей вам тоже говорить.
>Поддерживается работа с Windows 7 и более новыми выпусками.
Винду не поставить на свой же RAID 0 (с чередованием). Получается с WinBtrfs это возможно?
"поддерживается работа с" вовсе не означает, что, внезапно, оно еще и загружаться оттуда умеет - это немного большее, чем только драйвер.
посыпался раздел на прошлой неделе с ext4. При попытке смонтировать раздел выдавал какойто superblock. Там крутилась 1с 7 под вайном в файловом режиме. Данные так и не вытянул. Сейчас форматнул в xfs.
Если один Эс, то только под вайном! Никаких нативов с виндой и ntfs! Никаких продвинутых инструментов восстановления от Парагона и типа того! Упала xfs - значит упала. Ты же просто не знал, что с ней делать, да? Я тоже не знаю, это не стыдно. Сдулся под-линукс-продакшен - значит сдулся. Перезапускай!
Под линуск r-studio есть.
>> но никаких гарантий относительно сохранения целостности ФС не даётся- Где-то дается такая гарантия???
В ReactOS его уже добавили! быстро, молодцы!