>Это как минимум перенос проекта и сетап рабочего окружения заново. Не то чтобы велкам. Я не знаю, с чем вы работаете и какие у вас сроки поднятия из бэкапа. Мне нужно убдет отойти на 10-15 минут и я потеряю максимум час работы. Не смертельно, но неприятно. Ну и я не пользуюсь всякими хитрыми фичами. Т.е. вероятность проблем - приемлемая для меня ).
>Вообще кентушка заморочился low overhead. Правда с тех пор и btrfs'ники - заморочились :)
Да все равно мы упираемся в сырую производительность носителей... Тут уже никуда не денешься, CoW - значит фрагментация, больше оверхеда и т.п. Понятное дело, что чем больше фич, тем медленнее - вон, fat12 так вообще шустрый был... Да, то, что он заморачивается - это хорошо, конечно.
>Скажем FUSE реализация - вообще труп по сути.
Не тыкал, не знаю, мне не нужно, я в этом конкретно вопросе не копенгаген, могу говорить только за то, что трогал :)
>когда SSD на который оно кешило затирается, это имеет тенденцию гробить подкешированую ФС наповал.
Падажжи. Если SSD затирается - он уходит в RO, либо отваливается совсем, либо не отдает прочитанные данные, так как чексуммы не совпадают и ECC не может уже их поднять у диска. А перед этим начинает сыпать в смарте проблемами... Т.е. в нормальном случае носитель должен быть заменен до того, как начнет отдавать мусор вместо данных. А вот если у нас writeback кэш и, как у меня, скажем, метаданные лежат ТОЛЬКО на SSD - то как он у меня умрет - умрут вместе с этим SSD и все данные, что лежат в background hdd. Тут все от сетапа зависит. Но если я увижу ошибки в smart (а я его контролирую) - возможно, я успею выставить durability=0 носителю и он превратится в writethrough и я спокойно смогу дожить до магазина ;).
>Даже вот отловить косяки - тоже способ сказать спасибо.
Чем и занимался, так-то. Просто при моем сетапе косяков не возникло а те, что есть - складируются и потом либо буду багрепортить, либо сам поправлю (хочу сам, например, баг со временем поправить).
