The OpenNET Project / Index page

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



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

Оглавление

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

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


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
Добавить, Поддержать, Вебмастеру