https://opennet.me/openforum/vsluhforumID3/112163.html После двух лет разработки увидел свет (https://github.com/maharmstone/btrfs/releases/tag/v1.0) первый стабильный выпуск проекта WinBtrfs (https://github.com/maharmstone/btrfs/), в рамках которого подготовлен драйвер, предоставляющий возможность работы с файловой системой Btrfs на платформе Windows. Наработки проекта распространяется под лицензией LGPLv3. Примечательно, что WinBtrfs не основан на коде Btrfs из ядра Linux, а является созданной с нуля альтернативной реализацией. Поддерживается работа с Windows 7 и более новыми выпусками. Отмечается, что драйвер уже пригоден для ежедневного использования, но никаких гарантий относительно сохранения целостности ФС не даётся. <br><br><br>Поддерживается большинство возможностей Btrfs, включая запись и чтение (в том числе в асинхронном режиме), использование RAID0/1/10/5/6, кэширование, автообнаружение разделов, ACL, символические ссылки, подразделы, снапшоты, жесткие ссылки, разряжённые файлы, упреждающее выделение места, сжатие, балансировка, проверка целостности данны https://opennet.me/openforum/vsluhforumID3/112163.html#149 Mon, 23 Sep 2019 17:10:54 GMT И именно по этому для базы выделяют подтом и ставят на нём NOCOW.<br> https://opennet.me/openforum/vsluhforumID3/112163.html#148 Mon, 23 Sep 2019 08:03:32 GMT &gt;[оверквотинг удален]<br>&gt; свойствам сжатия, кеширования, размером блока, COW и так далее, как и <br>&gt; нужно делать &#8212; то консистентный снапшот этой базы целиком ты можешь <br>&gt; сделать, только остановив её.<br>&gt; Или у тебя файлсервер, в момент снапшота какие-то файлы перемещаются с одного <br>&gt; подтома на другой. Файл вполне может в момент снапшота ещё не <br>&gt; прибыть на один подтом, но уже исчезнуть с другого. Потому что <br>&gt; снапшот не атомарен.<br>&gt; Добро пожаловать в 1997 год.<br>&gt; И авторы вообще не видят этой проблемы. Этого нет ни в каких <br>&gt; планах.<br><br>Я кагбэ хотел бы обратить внимание дискутирующих, что эксплуатацию баз данных на CoW файловых системах не рекомендуют вообще. То есть сама идея размещения БД на одной из таких файловых систем дурно пахнет.<br> https://opennet.me/openforum/vsluhforumID3/112163.html#147 Sun, 22 Sep 2019 21:12:15 GMT &gt;&gt; чего там верить -- почти вся продвинутая функциональность btrfs числится как экспериментальная.<br>&gt; Это какая например? Снапшоты и рефлинки работают уж много лет. Сжатие есть, <br>&gt; даже два на выбор. Send/receive тоже ничего, хоть и немного нишевая <br>&gt; штука. Если это не продвинуто, то что же тогда продвинутость?<br><br>Снапшоты нерекурсивны. Это полный конец обеда. <br>То есть если ты размазал базу данных по нескольким томам с разными свойствам сжатия, кеширования, размером блока, COW и так далее, как и нужно делать &#8212; то консистентный снапшот этой базы целиком ты можешь сделать, только остановив её. <br>Или у тебя файлсервер, в момент снапшота какие-то файлы перемещаются с одного подтома на другой. Файл вполне может в момент снапшота ещё не прибыть на один подтом, но уже исчезнуть с другого. Потому что снапшот не атомарен.<br>Добро пожаловать в 1997 год.<br>И авторы вообще не видят этой проблемы. Этого нет ни в каких планах.<br> https://opennet.me/openforum/vsluhforumID3/112163.html#146 Thu, 07 Mar 2019 23:50:17 GMT в вики оригинала сказано, что парити-райды теряют данные при аварийном отключении в некоторые моменты записи.<br> https://opennet.me/openforum/vsluhforumID3/112163.html#144 Fri, 22 Sep 2017 11:41:03 GMT Интересно, у меня btrfs два раза вставала колом(было 2 раздела, корень забился при обновлении, /home при повседневной работе), когда заканчивалось место они становились readonly, т.е. даже удалить ничего нельзя, ни файлы, ни снапшоты т.к. нельзя записать, причем по показаниям df занято около 66%, утилиты btrfs выдают вообще полную ересь, ни одно из найденых решений не помогло(балансировки метаданных, что-то типа отключения CoW итд).<br> https://opennet.me/openforum/vsluhforumID3/112163.html#143 Tue, 12 Sep 2017 15:02:42 GMT Таки точно 294, привет :-)<br> https://opennet.me/openforum/vsluhforumID3/112163.html#142 Tue, 12 Sep 2017 14:39:37 GMT &gt; Это известная бага (фича?) БТРа: до 50% - все хорошо, от 50% <br>&gt; до 80% - в зависимости от данных, после 80% - тормоза! <br><br>Ты удивишься, но в best practices ZFS'а тоже говорится про 80%. Это любого CoW касается, из соображений пространства для маневра для укладывания фрагментов при записи целиком. А так изена спроси насколько можно zfs ушатать, у него в этом экспертиза.<br><br>Кстати ушатанный btrfs можно дефрагментнуть накрайняк. А zfs - там дефраг сделали? Или предлагается разобрать и пересоздать весь пул заново?<br> https://opennet.me/openforum/vsluhforumID3/112163.html#141 Tue, 12 Sep 2017 14:14:40 GMT &gt; стесняюсь спросить - вы оба ее вообще видели?<br><br>Нене, тут только надутые гуси. Но если посмотришь в хексэдиторе как скомпонован партишн и FAT32 на флехах и SD - увидишь ERASE BLOCK. FTL не знает про FAT или партишн, поэтому если ты форматнешь сам - таблица разделов почти наверняка попадет в тот же erase block что FAT. Там часто делается Read-modify-write и есть шанс что однажды ты останешься без таблицы разделов. С битой копией FAT работать можно, а вот без разделов... Так что основная адаптация - правильно разложенная на фабрике ФС. Можно и самому разложить правильно, но проблема в том что размер ERASE BLOCK и PAGE получить стандартным способом нельзя. F2FS однако старается делать операции в виде не враждебном к такой структуре и там есть несколько настроек под размеры структур. У SSD более навернутые контроллеры, им менее критично, но все-таки, F2FS делает удобно и им. В бенчах за это воздается. Одно дело запись попавшая в ERASE BLOCK целиком и другое - канитель с RMW.<br><br>&gt; Или только "да ее ж использует https://opennet.me/openforum/vsluhforumID3/112163.html#140 Tue, 12 Sep 2017 13:11:38 GMT &gt; При этом железо - _знает_ о внутреннем устройстве exfat/ntfs/fat32, <br><br>Ничего оно не знает. Там просто flash translation layer, GC и wear leveling в фирмвари. Но поскольку флэш сам по себе крупноблочный - ему удобнее всего если записи идут большими кусками и желательно в разные места (делает жизнь упрощенных FTLов проще). Судя по бенчам F2FS самсунгу удалось сделать жизнь флеша проще. И на SD картах, и на флешках, и на SSD.<br>