The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Утверждён переход Fedora Desktop на Btrfs и замена редактора vi на nano, opennews (??), 16-Июл-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


79. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (27), 16-Июл-20, 15:22 
Смеешься? У нее 32x write amplification, ты эти "издержки контрольных сумм" на таком фоне - в микроскоп не разглядишь.

С другой стороны, безусловно, это далеко не всем нужная фича - кому и 32x норм. А кто вообще своих котиков только читает.

Ответить | Правка | Наверх | Cообщить модератору

82. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  –1 +/
Сообщение от Аноним (76), 16-Июл-20, 15:27 
btrfs медленнее ext4, однако. Однако! это не отнимает её прочие преимущества по надёжности по сравнению с ext4.  
Ответить | Правка | Наверх | Cообщить модератору

93. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от DrDiablo (ok), 16-Июл-20, 15:58 
Пруфы в студию!
Ответить | Правка | Наверх | Cообщить модератору

201. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 16-Июл-20, 21:26 
> Пруфы в студию!

Чисто логически, счет чексум - некое дополнительное действо. И на него ессно уходит время и системные ресурсы. Однако это все же лучше чем ВНЕЗАПНО обнаружить через пару лет такого факапища что у вас тут битая оперативочка была, система глючнела и дурела и половина файлов сейчас вообще труха, а то и вообще файлуха монтироваться перестала.

Ответить | Правка | Наверх | Cообщить модератору

307. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от VINRARUS (ok), 17-Июл-20, 23:24 
Чисто логически COW быстрее.
Ответить | Правка | Наверх | Cообщить модератору

318. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (27), 18-Июл-20, 02:07 
У вас явные проблемы с логикой.

Наоборот, перезаписать только данные прямо поверх старых - "чисто логически" быстрее, чем создать новую копию и перезаписывать еще и миллион мета-указателей на указатели, непременно синхронно, иначе все развалится.

Ответить | Правка | Наверх | Cообщить модератору

323. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от VINRARUS (ok), 18-Июл-20, 03:23 
> У вас явные проблемы с логикой.
> Наоборот, перезаписать только данные прямо поверх старых - "чисто логически" быстрее, чем
> создать новую копию и перезаписывать еще и миллион мета-указателей на указатели,
> непременно синхронно, иначе все развалится.

єто если не нада искать чистіьй блок

Ответить | Правка | Наверх | Cообщить модератору

330. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 18-Июл-20, 06:35 
> єто если не нада искать чистіьй блок

Вот тут я не особо понял. Мысль что лукапнуть размещение файла и его in-place блоки быстрее или медленнее чем лукапнуть свободное место для того же самого .. наверное надо бы как-то обосновать, чтоли, при том для разных ФС эти соотношения еще и разными могут быть, пожалуй. Откуда у народа такие универсальные выводы, безаппеляционно и в ту или иную сторону?

Ответить | Правка | Наверх | Cообщить модератору

331. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от VINRARUS (ok), 18-Июл-20, 11:03 
>> єто если не нада искать чистіьй блок
> Вот тут я не особо понял. Мысль что лукапнуть размещение файла и
> его in-place блоки быстрее или медленнее чем лукапнуть свободное место для
> того же самого .. наверное надо бы как-то обосновать, чтоли, при
> том для разных ФС эти соотношения еще и разными могут быть,
> пожалуй. Откуда у народа такие универсальные выводы, безаппеляционно и в ту
> или иную сторону?

Всё дело в фрагментацыи, ведь линейная запись/чтение всегда быстрее (конешно всё отностительно).
Разве главная цель COW это не борьба з фрагментацыей?

Ответить | Правка | Наверх | Cообщить модератору

342. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (342), 19-Июл-20, 01:19 
> Всё дело в фрагментацыи, ведь линейная запись/чтение всегда быстрее (конешно всё
> отностительно).

Паттерны доступа разные бывают. То что в свободном месте удастся накопать непрерывный экстент желаемого размера 1 махом - ниоткуда не следует. Скорость лукапа этого опять же интересный вопрос, с рядом факторов.

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

> Разве главная цель COW это не борьба з фрагментацыей?

Самым ключевым достоинством CoW я бы назвал все же
1) Некий эквивалент полного журналирования без двойной записи.
2) Неразрушающую запись.
3) "Халявные" снапшоты.

Насколько оно (не) фрагментируется под той или иной нагрузкой, как это соотнесется с классическими ФС и проч - зависит от дохрена факторов. Забитость тома, характер нагрузки и проч. Универсальных серебряных пуль нет.

Под некоторые нагрузки CoW ложится хорошо. Под некоторые - плохо. Скажем БД делает много мелких записей, журналит сама, и делалась под in-place патчинг если не raw разделы (оптимальнее, но неудобно). Если БД и журнал как есть вывалить на cow, модификации будут кучей дозаписей в сторону. Это может и не было бы хуже иных вариантов, но это как минимум создаст множество метаданных для описания "хвостов" и фрагментирует свободное место. По поводу чего в btrfs и оставили на такие случаи возможность CoW отклчить. Если БД хочет вот так - пусть будет так. При этом btrfs не сможет это "журналить", снапшотить и проч - но БД этим сами заведуют, а снапшотирование баз вообще чревато, особенно реплицируемых по сети, потуги так делать требуют отличного знания своей БД, ФС и как оно используется.

На забитом томе опять же будут проблемы с тем что выкроить непрерывный экстент для записи может не выйти. Это проблемя для любой ФС, но для CoW особенно чувствительно из-за того что он in-place ничего не меняет. Если этот процесс долговременно предоставить себе, на сильно забитом томе и то и другое придет к состоянию вермишели, но cow имхо дойдет туда раньше. На такие случаи, если это механические винчи и все совсем плохо стало, сейчас и у btrfs и у ext4 один фиг дефрагеры есть. Реально дефрагер ессно нужен только если совсем уж идиотничать, как iZEN, забивший до отказа торентами свой ZFS, так что тот забился фрагментами как черти что и красавец понтовался аж 18 мегов в секунду. С трех дисков, хоть и ноутбучных (у него, кстати, дефрагера в zfs таки еще и нет, хаха).

В конечном итоге CoW и классические ФС ... довольно разные по свойствам. Из-за довольно разной механики. Впрочем, если не хардкорить, забивая все под завязку или гоняя БД, и не заметить особых отличий. На каком-нить системном ssd в крейсерском режиме btrfs и ext4 по ощущениям будут однохренствены и вообще узнать что там за ФС можно только если специально это позырить.

Ответить | Правка | Наверх | Cообщить модератору

352. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от VINRARUS (ok), 19-Июл-20, 22:17 
> Насколько оно (не) фрагментируется под той или иной нагрузкой, как это соотнесется
> с классическими ФС и проч - зависит от дохрена факторов. Забитость
> тома, характер нагрузки и проч. Универсальных серебряных пуль нет.

Есть — 3D структура памяти без ячеистой привязки, правда она пока токо под черепушкой водится. :)

> Под некоторые нагрузки CoW ложится хорошо. Под некоторые - плохо. Скажем БД
> делает много мелких записей, журналит сама, и делалась под in-place патчинг
> если не raw разделы (оптимальнее, но неудобно). Если БД и журнал
> как есть вывалить на cow, модификации будут кучей дозаписей в сторону.

Да, COW лучше работает со "статичными" даными, по этому у меня /home c No_COW с этих же соображений (к стати, блин, нада каталогу steam включить COW).

> Это может и не было бы хуже иных вариантов, но это
> как минимум создаст множество метаданных для описания "хвостов" и фрагментирует свободное
> место. По поводу чего в btrfs и оставили на такие случаи
> возможность CoW отклчить. Если БД хочет вот так - пусть будет
> так. При этом btrfs не сможет это "журналить", снапшотить и проч
> - но БД этим сами заведуют, а снапшотирование баз вообще чревато,
> особенно реплицируемых по сети, потуги так делать требуют отличного знания своей
> БД, ФС и как оно используется.

Поправочка: снапшотить в btrfs можна и с No_COW, так сказать одиночный акт COW.

> Реально дефрагер ессно нужен только если
> совсем уж идиотничать, как iZEN, забивший до отказа торентами свой ZFS,
> так что тот забился фрагментами как черти что и красавец понтовался
> аж 18 мегов в секунду. С трех дисков, хоть и ноутбучных
> (у него, кстати, дефрагера в zfs таки еще и нет, хаха).

:D

> В конечном итоге CoW и классические ФС ... довольно разные по свойствам.

Если выборочный No_COW есть то ФС становится универсальой в умелых руках, по моему, в сpавнении з "класическим" EXT4.

Ответить | Правка | Наверх | Cообщить модератору

353. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (353), 20-Июл-20, 06:23 
> под черепушкой водится. :)

И таки временами нехило тормозит и глючит. Достаточно на опеннет посмотреть! Да и мувики хранит очень своеобразно и с жутким коэффициентом сжатия.

> Да, COW лучше работает со "статичными" даными, по этому у меня /home
> c No_COW с этих же соображений (к стати, блин, нада каталогу steam включить COW).

Если весь home так сделать то и снапшоты на нем не получатся. Насколько это плохо - кому как. Я туда адские терабайты мелкими фрагментами не пишу, поэтому оставил и юзаю там снапшоты. Грубо говоря, есть 2 subvolume - "system" и "userdata". Идея изначально стырена у убунт, вроде логично придумали. И "один уровень вверх" который в нормальной ситуации не видно - начало иерархии btrfs никуда не замонтировано, только пара subvolumes с него как / и /home.

> Поправочка: снапшотить в btrfs можна и с No_COW, так сказать одиночный акт COW.

А вот это кстати интересно. А дальше какая участь постигнет эти экстенты по мере накопления отличий? И будет ли аплаится CoW к кому-то из копий далее? oO Чисто теоретически это как бы 2 как бы nocow файла, которые должны быть независимы. Но я искренне сомневаюсь что в этот момент их полностью разделят в отдельные блоки которые можно патчить in-place.

> Если выборочный No_COW есть то ФС становится универсальой в умелых руках, по
> моему, в сpавнении з "класическим" EXT4.

Собссно systemd например своим бинарным логам пытается +C на диру сделать. Вот как раз чтобы быстрее работало и не фрагментилось. И какой-то пойнт в этом есть. Да и мысль именно снапшотить именно логи 50/50, то что админ хотел при откате и логи профукать - не факт.

Ответить | Правка | Наверх | Cообщить модератору

327. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (327), 18-Июл-20, 05:26 
> Наоборот, перезаписать только данные прямо поверх старых - "чисто логически" быстрее,

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

А если DATA журналить - а вот тут уже и поговорим про скорость! Ведь записать надо 2 раза - сперва в журнал, потом в основную область. CoW же - нечто типа одного сплошного журнала, поэтому ему не требуется та вторая запись. Реально чуть хитрее, но чит довольно забавен в своей наглости. И вообще - работает. Хоть и приносит свои особенности.

> чем создать новую копию и перезаписывать еще и миллион мета-указателей на указатели,
> непременно синхронно, иначе все развалится.

Зато если все фигакнулось, достаточно переключить по сути указатели на более старые блоки (которые никуда не делись) - и рекавери завершен. Это состояние вполне валидно и консистентно, и по данным и по метаданным. И при том почти нахаляву. А бонусом еще и снапшоты всякие довольно халявно получаются. По сути зафиксировать набор указателей, чтоб GC не подгреб - и готово. Поэтому снапшот случается ... да мгновенно с точки зрения человека. А заодно можно сослаться на блоки и несколько раз.

Ответить | Правка | К родителю #318 | Наверх | Cообщить модератору

178. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (257), 16-Июл-20, 19:13 
> прочие преимущества по надёжности по сравнению с ext4.

Шта?

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

265. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +3 +/
Сообщение от анонимомус (?), 17-Июл-20, 11:59 
У меня btrfs надежно становилась RO, когда "заканчивалось" место.
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

328. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (327), 18-Июл-20, 05:27 
> У меня btrfs надежно становилась RO, когда "заканчивалось" место.

Сейчас там достаточно просто стереть что-нибудь. Метаданные от этого пойдут в "золотой резерв", номер прокатит - и собссно появится свободное место. Извините, а сколько лет назад вы это пробовали? Этот механизм вроде довольно давно сделали уже? :)

Ответить | Правка | Наверх | Cообщить модератору

119. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (60), 16-Июл-20, 16:55 
> 32x write amplification

Это при каком характере использования?

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

172. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 16-Июл-20, 18:49 
> Это при каком характере использования?

"Шишкин делает бенчмарк" :D

Ответить | Правка | Наверх | Cообщить модератору

174. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (27), 16-Июл-20, 18:57 
Afair, там была синтетика, из нескольких небольших linear write и небольших модификаций, но мог уже подзабыть детали или смешать в памяти несколько тестов разных людей (но вроде там симуляция именно девелоперской машины, где пачка компиляторов что-то крупное компилит, ну и по мелочи кто-то что-то пописывает при этом, а не базы данных. При этом сравнивались цифры записанного с реальными счетчиками физически записанного, а не "ощущения" анонима).

Гуглите, полагаю, оно сравнительно легко находится, если вас интересует разобраться в вопросе, а не святая вера в непогрешимость.

Если что, у ext4 было 4x, у xfs то ли 4, то ли 8 - то есть оно не в 32, а всего лишь в 8 раз тормознее ;-)

По факту, хомячки со своими домашними ssd ничего не заметят, ну так они и нагрузки от подсчета контрольных сумм не заметят тем более, это для владельцев массивов nvme и быстрых сетевух возможная проблема, у них процессор и так занят.

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

147. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  –1 +/
Сообщение от Аноним (-), 16-Июл-20, 17:46 
> Смеешься? У нее 32x write amplification,

С дуба упал? Хотя, конечно, если исключительно 100-байтовые файлы записывать, исключительно синхронно... но там вообще-то у всех будет это самое, потому что у нанда страница этак кило 4 и меньше адресовать оно принципиально не могет :)

> ты эти "издержки контрольных сумм" на таком фоне - в микроскоп не разглядишь.

Вообще-то разглядишь. Поэтому для тех кому важно - там теперь есть разные алгоритмы, включая xxhash для тех кому быстро.

> С другой стороны, безусловно, это далеко не всем нужная фича - кому
> и 32x норм. А кто вообще своих котиков только читает.

С другой стороны, вы вообще спиди-гонщик, сэр. Если взять обычный системный SSD и погонять на нем EXT4 и Btrfs, разница в объеме write при типовой эксплуатации - в пределах погрешности! О том чтобы SSD протирался в разы быстрее речь не идет в принципе. Btrfs даже достаточно сообразителен для того чтобы врубать ssd'шную эвристику по дефолту сам, если видит что это не "грампластинка".

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

164. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (27), 16-Июл-20, 18:31 
> С дуба упал?

Нашел тесты, имеющие внятное описание методики, использующие достоверные счетчики и use-patternы близкие к реальным. Ты тоже мог бы, если бы обладал умением пользоваться гуглем, а не только святой верой в прекрасную btrfs.

> Btrfs даже достаточно сообразителен для того чтобы врубать ssd'шную эвристику по дефолту сам

А еще от нее шрам от вскрытия рассосался.

Главное - верить!

Ответить | Правка | Наверх | Cообщить модератору

171. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  –2 +/
Сообщение от Аноним (-), 16-Июл-20, 18:46 
> пользоваться гуглем, а не только святой верой в прекрасную btrfs.

Лол, чувак! Я btrfs'ом таки пользуюсь для себя, довольно много где. И к дьяволу твой гугол, когда я могу сам статстику SMART позырить, вот прям счетчик записей. И сравнить с EXT4, который я тоже много где раньше использовал - и тоже мониторил счетчики записей.

В крейсерском режиме обычного системного SSD разница - маргинальная. Что с ext4 2% wear за 2 года, что c btrfs. А если нет принципиальной разницы, почему бы и не позволить себе немного удобства? Алсо, при проектируемом с такими темпами износа сроке жизни около века :) мне явно пригодятся чексумы под данными на случай если оно вдруг удумает начать массово осыпаться несколько раньше - чтобы я заметил граблину на подлете! :D

>> Btrfs даже достаточно сообразителен для того чтобы врубать ssd'шную эвристику по дефолту сам
> А еще от нее шрам от вскрытия рассосался.

Эксперт, вы походу форум перепутали.

> Главное - верить!

Я верю своему опыту эксплуатации. Это хорошая и прагматичная вера, которая меня не подводит.

Ответить | Правка | Наверх | Cообщить модератору

246. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от КО (?), 17-Июл-20, 08:11 
>что у нанда страница этак кило 4

В том то и дело, что уже 128, а то и больше.
4 - логический сектор.

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

306. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 17-Июл-20, 23:24 
> В том то и дело, что уже 128, а то и больше.

RTFM, >=128 - про ERASEBLOCK, вероятно. Или как максимум какой-нибудь юнит параллелизма контроллера с кучей interleaved чипов. Минимальный адресуемый юнит в пределах nand чипа - страница. Мельче этого юнита как правило технически нельзя оформить и при нужде сделать так контроллером будет сделан read-modify-write, претендующий на то что он и правда смог запатчить 10 байтов в середине страницы. Потеря питания в этот момент ни к чему хорошему разумеется не ведет и может превзойти допущения ФС относительно характера разрушений.

> 4 - логический сектор.

У флеша на самом деле 2 сущности - "page" (юнит операции PROGRAM) и "eraseblock" (юнит операции ERASE). Программирование возможно только для ранее стертых блоков, но не каждый program ведет к erase: если в eraseblock есть не прописанные страницы, можно стирание не гонять и запрограмить те страницы.

Страницы - "несколько кб" (порядка 4). Их не делают большими - огромный *минимальный* юнит обращения сильно все заякорит. Erase block - от сотен кило в старых до мегабайтов в новых. Контроллеры используют еще понятие ERASE GROUP, т.к. предпочитают работать сразу с N чипов параллельно, если ситуация к тому располагает. Это уже бывает десятки мегабайтов, зачастую кратно двойке. Наиболее удобное IO кратно этому размеру, но это очень теоретически и в допущении что это выровнено на размер erase group, о чем софт не парится.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру