> Отказ девайса это всё же немного другая ситуация, когда точно известно что
> данные там-то -- больше недоступны.Я просто не понимаю что вы тестировали и зачем - реально устройства ТАК не отказывают.
> И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их
> в принципе не сможет восстановить, а raid6 смог бы
В случае btrfs - сможет. В терминах RAID5 (минимальный пример): с1=a1^b1. Для a1 и b1 там чексум, отдельно, в метаданных, у метаданных может быть и иная схема, скажем raid1c3. Далее чекаем a1 и b1, если не сходится 1 из сум, XOR с parity и потом проверка по сумме еще раз. Сразу видим прокатило ли. Если померла парити, видно что a1^b1 != c1 хотя суммы верны, тогда c1 можно пересчитать из данных. Хранить и считать суммы блока c1 (парити) излишне.
> (если флипнулось только на 1 девайсе из N+2), но он этого не делает
> в принципе (я тоже проверял).
Btrfs может в отличие от обычного RAID делать более информированные решения из-за чексум. Обычный RAID не имеет такого инфо, для RAID1 и RAID5 задник. Даже если мы видим несовпадения, неизвестно какая копия/блоки неверные. Чексумы позволяют это понять, улучшая свойства.
> 'checksum on a checksum' (касательно хеша на блоки чётности) и то
> что они этого не сделали,
Чексум на чексум проверяемый пересчетом из блоков данных не дает никакого нового знания, зато дает оверхед на счет и хранение. Хинт: чексумы блоков проверяют коректность данных, а парити считается из данных, можно сравнить посчитаное и сохраненное, поняв верен ли блок.
> и любой случайный битфлип может ниасилить, как раз из-за того, что
> не всё записанное на дисках рейда отхешено.
Я для себя предпочитаю чтобы ФС справлялась с реалистичными проблемами, а не тестами моделирующими ХЗ что: сторажи не отказывают вон так. А более реалистичные тесты на сыпучках (найденых btrfs'ом опять же) оно с должными схемами хранения переживает. Даже DUP - делает единичный проблемный девайс снова юзабельным, ценой ополовинивания. В древние времена он имел проблемы с repair т.к. не массовая штука. Но грю же - мы решаем проблемы совместными усилиями. В этом пойнт опенсорса.
>> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
> Вот уже начинаются пляски с бубном :)
Управление гипердвигателем лучше делать с иной семантикой чем ДВС, введя точные координаты в назначение. Личное телепание педальки и руля уже не актуально. И какой смысл бенчить реакцию на педальку, если я выкинул это действо совсем? Это еще быстрее. Сильно быстрее. Попробуйте, увидите.
При этом я имею инфо для полного, честного отката на known good, и даже время чтобы составить мнение - хочу я новое состояние или нафиг. На злобу дня, только что откатил неудачный апгрейд Deb12 -> Deb11. Железки на конкретной машине - взбрыкнули, разбираться прямща было не с руки, так что машина времени вернула как было - теперь можно НЕСПЕШНО пнуть причастных. В фоне. Пока все работает. А без снапшотов что б вы вообще делали? Бонусом writeable снапшотов, Deb12 на самом деле есть, и в writeable версии оного можно будет сделать тесты. Когда будет фикс.
> (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ
В пиковом случае дефраг есть. Что до fsync() его в последних нескольких ядрах разогнали в разы. Но я от этого в том кейсе ничего не выигрваю - в виде "а мы типа гипердрайв" я вообще не телепал руль и педальку. В этих терминах, весь dist upgrade - транзакция, уровня ФС. В виде подконтрольном мне. И я сам решаю потом, commit или rollback.
Да, эффективное и безопасное пилотирование звездного крейсера с гипердвигателем требует неких знаний CS. Но я был любопытным и нашел нужные лекции. И теперь могу комбинировать транзакции в эффективном виде сам, не глядя как "мы так привыкли" делают. Наука об осмысленном использовании знаний а не ритуалах и зубрежке.
> openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок
> диска под линейный лог зарезервирован --
В btrfs сие разогнали в разы последние пару ядер. Но как видите я просто пересмотрел что есть sync и точки начала-конца транзакции, это не костыль, это применение CS себе во благо. Работает намного круче глупого заучивания ритуалов.
> остаётся фактом -- там было *МЕДЛЕННО*.
Можете бенчмаркнуть с новыми кернелами типа 6.3 какого. Впрочем я с этого в вон том случае ничего не выиграю - вооооон то и так было супер быстрым. Даже пищет относительно последовательно. Inplace бы seek в патчимый регион делал, а cow это не надо и он с моим пересмотром семантики как раз свои сильные стороны выпятит, оформив записи куда ему там удобно и быстро. Да, я получаю полный журнал со скоростью безжурнальной фс.
> модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее,
Не вижу ничего геморного набрать btrfs sub snap <what> <where>.
> надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).
Не "надо" а "удобно делать так". Можно и иные варианты, просто уровень на 1 выше / с разными вариантами состояний вселенных, где мы можем путешествовать в ключевые точки пространства и времени - прикольная концепция. Логично что попадаем туда только после "сдвига измерений" (в более высокую абстракцию) содержащую в себе "все". Такой стиль понятен любому кто смотрел sci-fi и понимает концепцию ключевых точек, путешествий во времени и разветвления на мультивселенные с разным развитием событий. Это весьма буквальная реализация, writeable снапшоты тоже описываются этой идеей.
А так - subvolume при снапшоте не может содержать в себе subvolume (вместо него снапшотнется пустой дир): если сделать sub-in-sub, будет кольцевая зависимость экстентов друг на друга - и как это обрабатывать?! Не отменяет возможности снапшотнуть "что видишь" куда-то еще. Просто потом рулить менее удобно, а вон та абстракция "на уровень выше /" делает это удобным, логичным, и без "сдвига измерений" сложно снести снапшот нечаянно (по крайней мере файловыми операциями, типа F8 в миднайте на диру subvolume).
> Во1 насколько я понял, преаллокации в btrfs как таковой нет,
Это как бы не очень хорошая нагрузка для cow - но и сказать что фатальная и работать не будет - да вообще, работает. Просто если это основной кейс для стоража, btrfs может и не быть лучшим выбором, если записей много и часто так что дефрагнуть не вариант.
> Во2, не очень понял про кеш торрент-клиента, какой бы он ни был
> по размеру, если он кратно меньше чем весь качаемый торрент, то
> совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало,
Может пребуферить большие сегменты и записывать их 1 операцией. При этом число фрагментов здорово снижается: 1 дело экстенты по 10 кил, другое по 10 мегз. Суть одна, а соотношения разые, второй случай = в 1024 раза меньше метаданных! И это не только про CoW но и про проблемы экстентных аллокаторов вообще. И вы еще не видели что XFS делает если это соотношение фиговое. Никогда не видали DVD-sized торент стираемый минутами? На забитый XFS его качните без преаллокации. Экстентный аллокатор предсказуемо слепит мелких экстентов, получит неудачное соотнощение данные-метаданные, будет тормозить. Это 1 из мест где печальные блочные аллокаторы могли бы хоть чем-то блеснуть но у ZFS CoW на забитом стораже не даст развернуться и как показал дизайнерский пул "от iZEN" - тоже "не очень", и дефрага нет.
> и он всё равно будет вынужден отписывать данные в файлы рандомно.
Чем крупнее экстент тем ниже число фрагментов и лучше соотношение данных и метаданных: быстрее парсинг и линейный доступ. Блочным дизайнам пофиг, там парсинг всегда в наихучшем варианте, с описанием всей аллокации блоков, от чего они и тормозные.
Солидный кеш позволяет клиенту писать готовые блоки большими непрерывными экстентами. Грю же знание CS улучшает жизнь, позволяя ОСМЫСЛЕННО подыграть дизайну ФС...
> И тут-то бтрфс и рассыпется на тысячи фрагментов,
Вопрос в размере фрагмента и соотношении data-metadata. Экстентный аллокатор эффективен если экстенты большие. Zfs пролетает, у него нет экстентов как таковых и оно не может в большой экстент, так что обречено жевать много метаданных на аллокации ВСЕГДА. Поэтому ZFS даже в проекте не конкурент САБЖУ на суперскоростных SSD где низкий оверхед наше все.
> оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов,
Он в принципе любые экстенты пытается сливать. Но в торрентах больше поможет буфер клиента - тот к тому же эффективнее работает т.к. целенаправленно собирает чанки в более-менее непрерывные группы и может играть сообща с шедулером клиента "какие блоки просим у ремоты". Ну все минимально адекватные клиенты как-то так и делают, утягивая чанк(и) приличного размера, держа их в пребуфере пока не скачано целиком и не прошло верификацию и скидывая сразу солидные куски, чтобы экстентные аллокаторы не мучать плохим соотношением.
> на торрентах, особенно многофайловых, он примерно никак.
Там скорее буфер клиента актуальнее. И многофайловые ... в торентах обычно БОЛЬШИЕ файлы. Для кучи мелочи торент не эффективен, лучше упаковать. Хотя-бы чтобы сжать имена файлов которые в таком виде заметный % от данных. Чем-то типа 7z - умеющим жать оглавление архива.
> Я вот как-то на тот фскрипт пытался смотреть, и понял что без
> бутылки я там не разберусь.
Именно. У этого дизайна - довольно много краевых случаев. Это плата за продвинутость. Извините, мелкий аэропорт изначально не предусматривал что межзвездный крейсер захочет запарковаться.
> шифрованных датасетов в openZFS примерно на уровне сложности luks --
...тогда профит в чем? Fscrypt интересен простотой в сетапе и использовани, но в именно btrfs из-за мультиреференсов на экстент, тот fscrypt не делан с идеей что на 1 экстент более 1 раза можно сослаться. И это как бы трабл.
> само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.
У btrfs нет концепций из zfs, на самом фундаментальном уровне, связано с гибким аллокатором, и "файловой" природой RAID. Нет, никто не сдаст сильные стороны этого дизайна. Это весь пойнт его существования. Именно поэтому он nextgen и его просто менеджить. Крипто хорошо, но не ценой слома этой абстракции. Fscrypt в этом смысле наименее интрузивен, он не клещится с тем что хотел продвинутый аллокатор. Но в btrfs валидно 2 раза сослаться на 1 экстент как file1[10..20] и file2[30..40]. Btrfs на уровне дизайна волнует только чтобы блок был идентичного размера и содержимого, логическое размещение пофиг. А вот крипто обычно использует смещения для однозначного формирования nonce. И тут уже некие траблы. Нет, я не проектант запредельно крутых звездолетов и не выдам сходу хорошую логику на такой случай. Это хорошо работало для мелких самолетиков типа EXT4, а звездному крейсеру уже похуже. Но перспективнее вон того, где те понятия вообще не часть дизайна и вся идея дизайна это простое управление им а не жуткие костыли.
> ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых
> снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет
> на дестинейшене перед вливом при помощи ввода пароля).
Ну как бы продвинутым звездолетам свои проблемы походу. Только ваш звездолет - сделан из 4-моторного винтового самолета. Тот дизайн не задумывался для того что вы хотели, просто тогда лучше не умели. Так что вариабельно-блочный аллокатор максимум что из себя смогли вон те тогда выжать. Это имхо не есть лучшее решение. Мне экстентные в целом больше нравятся, все новые дизайны - экстентные, не просто так. Одна из причин по которым btrfs не особо тупит и без подпора гигазами рамы.
