> ну вот такую хрень и именно для этой цели - множить диски
> виртуалок - в refs завезли

Ну ты ж рассказывал что NTFS хватит всем, работать надо, блаблаблабла. Я и привел тебе пример когда работинг сильно эффективнее с более продвинутыми технологиями.

А так что лексус что лада приора - машины. Вот только в лекс плюхнуться комфортно, рулить удобно, и вообще. И когда тебе вместо него приору подсунут - это конечно тоже авто, тоже ездит, но есть определенные нюансы. Вот btrfs - просто комфортная штука. Мелкие факапы чинит сам не требуя внимания. Варнинги можно заранее получить. Можно подоткнуть девайсов. Или даже вынуть их. Совершенно не напрягаясь. Да даже схему хранения на ходу сменить.

> (вроде бы даже в дисяточную но это неточно.

Ты такой эксперт по фиче что ни разу ей не пользовался? Ну а меня вот эффективность моего работинга и взаимодействия с компьютером еще и интересует. И я не готов гробить в 10 раз больше времени на тривиальные операции. И учитывая сколько я образов и виртуалок ворочаю, без рефлинков у меня место бы наверное давно кончилось. А так, вот, злостный overprovisioning. А чего, вон те железки и виртуалки отлчиаются друг от друга достаточно маргинально, только кастомизацией под их задачу. А core технологии - одно и то же. Добро пожаловать в мир вертикального масштабироания, реюза знаний и экономии себе времени и сил. Здесь тебе не 1980 и даже не 1990 и твой NTFS для меня уже давно не последний писк а исторический экспонат.

> cp не завезли, за нее товарищмайор п-дют и в чвк отправляют-с,

Ух блин это не тот cp - майор будет немало разочарован.

> дикими потерями производительности если на самом деле нам это сейчас не
> требуется, а мы в этот раз будем по одному и тому же сектору елозить двадцать раз

Не будем насколько я помню. И просадки там скорее будут если слишклм дофига референсов на блок, за сам факт что кучу референсов надо жевать. Ну тут извините, вы хотели 100500 раз на блок сослаться и потом эти метаданные не разгребать? На этот счет автор bcachefs сильно заморочился, по итогам. Но задним числом все умные. Дизайнить новый фс когда до тебя граблю другие оттоптали - проще.

> - просто двадцать раз перезапишет этот один, а не будет создавать двадцать
> транзакций каскадно обновляя все метаданные с самого верху до самого низу
> и еще и блок данных напоследок.

В большинстве практических сценариев я не заметил никаких особых проблем. В том числе и в статистике флешовых накопителей. Ну да, мне было бы интересно посмотреть что сможет bcachefs. Btrfs дизайнили под более классические реалии когда IO еще не был сверхскоростным. Сейчас его нехило оптимизят (последний писк: +10% к скорости scrub) но дизайн изначально не был параноидален насчет low overhead по счету метаданных.

> только линукс не умеет в инкременальный билд после смены настроек - поэтому
> никакого смысла в этом нет.

Ну во первых, есть неиллюзорная экономия на времени "копирования" и сжираемым месте. Во вторых, как минимум git'овые файлы остаются одни и те же а .git это добрая половина веса дерева. В третьих таки, зачастую вот именно ребилдится умеренное количество файлов и таки получается что-то типа инкрементального билда. Но ты конечно можешь рассказать мне как оно у меня не работает. Тебе то виднее. Ты когда кернел последний раз билдил, интересно? Я - сегодня. А ты?

> А для исходников задача решается обычным линком.

В этом случае пойнт в том что это как бы независимые копии которые я могу кантовать без урона остальным вариантам. И если я облажаюсь в вон том эксперименте - это не накроет десяток дир с более прод ориентироваными ядрами, зачем мне там такой сюрприз?

> (И да, patch писали для юникс-систем ...

Я вообще git apply пользуюсь обычно. И единственный файл это прекрасно но у меня может быть реально с десяток working dir с ядрами и последнее что мне хотелось бы это раздать кастомный патч специфичный для энной задачи на всех.

> если ты будешь такое дерево патчить, а создаст новый файл.)
> Никакой cow и его тормоза снова, оказывается, не нужен.

Да нет там никаких особых тормозов, представляешь? В винде твой NTFS без всяких коров на такой иерархии будет тормозить многократно злее.

> Все придумано еще тридцать лет назад (и да я этим пользовался в те далекие времена)

Я не собираюсь откатывать мою эффетивность на уровень 30-летней давности, освоив технологии я ими еще и пользоваться хочу, разгоняя свою эффективность. А ты можешь работать как 30 лет назад. С своими патчами и нтфс. Но мне кажется что я сильно обгоню по общей эффективности операций в результате. И по отсутствию глупых грабель тоже. Потому что вон та штука обеспечивает независимость дир друг от друга и даже если я вдрызг разнес кернел для экспериментальной виртуалки, это никак не обязывает поиметь какие-то проблемы где-то еще. И кастомные патчи мне надо было "на вон той железке" а не вообще везде, представляешь? В остальных местах от них только вред сплошной.

А еще - если не создавать себе предпосылок для прострела пяток, не придется корчиться в твоем стиле рассказывая как и что у меня не работает и какой линух плохой. Можно ссать против ветра. А можно посчитать ветер фичой и поставить турбину, электричество генерить. Ну вот и с CoW так же. Независимость дир спасает меня от множества прострелов пяток. Представляешь, с десятком деревьев линуха я могу и лохануться плотно трекать все мелкие изменения для воооон той платформы неуместные для вооооон этой. Помогать себе лохануться я уж точно не намерен.