> О том и речь. CoW исключает частичную запись. Блок либо запишется полностью
> и валидно, либо не запишется совсем, среднего не дано. В этом
> суть самой технологии.Этот фокус позволяет ему делать вещи от которых остальные в штаны бы обгадились. Типа, вот, неспешно конвертировать в другую схему RAID. А если покрешится в процессе - так и черт с ним, после перезапуска сможет продолжить это занятие без каких-то особых проблем. В силу вон той механики - на файлах сие не скажется. А на уровне аллокатора оно ок с смесью block group разных типов. Есть дефолтные с которым новые данные и метаданные пишутся, но смесь типов block group вполне рабочий сценарий.
> Если трогать большой файл частичными перезаписями - да. Особенно страдают вещи типа
> образов виртуальных машин и прочие базы данных.
Просто надо сделать только 1 CoW. И снапшоты либо ФС - либо виртуализатором. А вот cow диск на cow файлухе - это уже довольно неудачная идея. Если уж хочется cow диск, логично его nocow сделать при большой нагрузке.
>> На самом деле, конечно, главный довод против бтрфс -- это необходимость
>> регулярной ребалансировки деревьев.
> Сколько лет с ней живу, ни разу не приходилось.
Удваиваю. Ребаланс реально нужен если девайсами маневрировать, типа убрали-добавили. В старых ядрах - еще если соотношение метаданных и данных радикаьлно изменилось. В новых - оно почти пустые block group само научилось в фоне подгребать и в этом месте конвергенция идей с сабжем стала просматриваться еще сильнее. Это такая часть логики рюхания buckets от Кента. Хоть и иная в деталях. А что, идеи можно таскать и в обе стороны :)
