> За глаза я считаю затею делать снапшоты на блочном уровне тухлой идеейэто да, лучше каждый свой велосипед будет придумывать.
> Ты как замшелый ретроград снапшотами поди просто не пользуешься
> совсем и именно тебе поэтому пофиг как оно работает.
и ты таки угадал: я в них не вижу особого смысла. нет у меня привычки сначала приводить систему в состояние жопы, а потом радостно откатываться на старый снапшот. мне и LVM хватает.
> А как по мне так это попытка приделать деревянному биплану крыло
> с изменяемой геометрией. Как-то летать, конечно, будет. А зачем мне "как-то"?
> Мне надо best of the best.
оно и видно, да. crc32 в качестве хэш-функции — это бэст, не поспоришь. общий бэкграунд авторов в CS показывает очень наглядно.
>> что значит «медленно»? по сравнению с чем?
> Да хоть с экст4 элементарным.
ты ещё с прямой записью сравни, ага — где сразу через DMA на диск фигачит в известные области.
> Продуть xfs в плане работы с кучей мелочи
а зачем ты xfs так используешь? не надо. у тебя вообще большинство проблем от того, что ты инструменты не по назначению используешь.
>> нет, бтр не предлагать, оно нифига не стабильное ещё.
> Эксперименты показали что в целом он вполне себе работает.
спасибо, когда у меня появятся ненужные файлы… нет, и даже их я не буду на бтр класть, я их просто сотру: они ненужные. я и к ext4 насторожено отношусь, а она более вылизана, чем бтр.
> кого-нибудь кто делает full журналирование данных+метаданных и сделает это быстрее.
а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать это путём создания нового и атомарного rename. а если файл большой — то это, обычно, какая-нибудь БД, и пусть журналом сама БД и занимается: она лучше знает, как со своими файлами работать.
ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно призвано не твои файлы спасать, а FS: чтобы FS после крэша была в консистентном состоянии. это, кстати, не только твоя беда: очень много людей отчего-то считают, что журналирование должно их файлы спасать. это не так; спасение файлов — задача программы, которая с этими файлами работает. а задача FS — не вставать раком, если вдруг что.
>> вот как стабилизируется — тогда и посмотрим.
> Как по мне так это от уровней требований зависит.
требование простое: не терять мои файлы. пока что raiser3, jfs и xfs с этим справляются. судя по интернетам, бтр справляется не всегда. будем подождать.
>> что это и зачем оно надо?
> А затем что мне не очевидно что у меня все файлы с
> одинаковой ценностью. И мне возможность заказать файлухе как мне размещать файло
> видится большим шагом вперед над классическими дубовыми схемами raid ориентированными
> на сферический мир в вакууме, где у файлов одинаковая ценность, у
> дисков одинаковый объем, а уж переиграть конфигурацию и вовсе никогда не
> хочется. Ибо разбирать большой райд - удовольствие ниже среднего.
пиши разные файлы на разные рэйды. объединяй оверлейной FS. в чём проблемы-то? опять ты инструменты не туда и не так.
>> всегда было интересно, чем «журналирование просто данных» отличается от «записываем
>> данные на диск», и как это должно работать вообще.
> В случае классики типа xfs/ext4/... - тем что файлуху не парит вопрос
> консистентности данных.
и это правильно. см. выше.
> Ну ездийте на бричках. Только нефиг нам в спину шипеть, когда мы
> трансокеанские рейсы делаем.
пока что я наблюдаю, как вы весело бегаете кругами, периодически собирая свой развалившийся на части мегаболид. а потом ещё: «ой! тут пассажир был! где пассажир? никто пассажира не видел?!»
безумству храбрых, конечно, и всё такое. но я лучше пока что на «бричке» доеду. пока ваш болид круги описывает и проверяет носом стены на прочность.
p.s. претензии, если что, не к тому, что болид разваливается, а к тому, что это выдают за «стабильное состояние, готовое к повседневному применению». нет, не готово пока.
