The OpenNET Project / Index page

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



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

Оглавление

В ветку ядра Linux-next добавлена реализация ФС Bcachefs, opennews (??), 20-Сен-23, (0) [смотреть все]

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


200. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от Аноним (200), 21-Сен-23, 17:41 
> Особенностью Bcachefs является поддержка многослойного подключения накопителей, при котором хранилище компонуется из нескольких слоёв - к нижнему слою подключаются наиболее быстрые накопители (SSD), которые используются для кэширования часто используемых данных, а верхний слой образуют более ёмкие и дешёвые диски, обеспечивающие хранение менее востребованных данных.

Вот уж реально киллер фича, но в комментах почему-то спорят о совсем другом

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

209. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  –1 +/
Сообщение от Аноним (209), 21-Сен-23, 19:42 
ZFS такую "особенность" имеет с рождения
Ответить | Правка | Наверх | Cообщить модератору

213. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от пох. (?), 21-Сен-23, 20:33 
> ZFS такую "особенность" имеет с рождения

отродясь не имел.

тут layered storage а не т-пой да еще и де-факто неработающий кэш только на чтение.

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

223. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (-), 21-Сен-23, 21:56 
> тут layered storage а не т-пой да еще и де-факто неработающий кэш
> только на чтение.

Ну да. В общем то Кент достаточно забавно понял как еще можно с write-anywhere развернуться, учитыая свойства девайсов.

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

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

256. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (209), 22-Сен-23, 23:07 
> отродясь не имел.

Подождите минуточку, давайте посмотрим на второй абзац новости:
> Целью разработки Bcachefs является достижение [...],
> предоставляя при этом дополнительные возможности, свойственные Btrfs и ZFS, такие как
> включение в раздел нескольких устройств,
> многослойные раскладки накопителей,
> кэширование,
> прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), срезы состояния (снапшоты), верификация целостности по контрольным суммам

К пулу ZFS при желании может быть присоединен слой (кэш) на быстрых дисках, который, понятно, заполнится "часто используемыми данными". Т.е особенностью Bcachefs это не является, хотя понятно, что наука ушла вперёд за время существования ZFS, и реализация кэша в ней может быть очень умной. Это, кстати, отражено и её названии :)
С другой стороны,"автоматическая миграция данных" как-то настораживает.

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

263. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (-), 23-Сен-23, 02:42 
> К пулу ZFS при желании может быть присоединен слой (кэш) на быстрых
> дисках, который, понятно, заполнится "часто используемыми данными". Т.е особенностью
> Bcachefs это не является, хотя понятно, что наука ушла вперёд за
> время существования ZFS, и реализация кэша в ней может быть очень
> умной. Это, кстати, отражено и её названии :)
> С другой стороны,"автоматическая миграция данных" как-то настораживает.

Может вас еще и авто-репайр битой копии с исправной настораживать станет? Хорошие штуки так то необслуживаемы и не требуют к себе внимания.

А цимес в том что все вон то по задумке должно продолжать обеспечивать запрошенные гарантии. Если скажем RAID1 и оно запромотилось в кеш, все равно должно выжить даже если "кешовый" девайс дуба дал. Это как раз упражнения на тему интеграции кеша и write-anywhere CoW типа btrfs'а. Весьма забавный фокус так то.

Как это на практике будет? Нечто из разряда не попробуешь - не узнаешь.

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

222. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (-), 21-Сен-23, 21:53 
> Вот уж реально киллер фича, но в комментах почему-то спорят о совсем другом

Видимо не всем столько счастья надо и не все понимают что вообще можно вытворять с улучшенным вариантом гипердрайва Mk II :)

Дла этого надо все же немного войти во вкус и познать вещи за пределами EXT4, блин.

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

234. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (66), 22-Сен-23, 07:15 
Устарело, нынче модно всё на ssd или nvme
Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

245. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Kuromi (ok), 22-Сен-23, 14:05 
> Устарело, нынче модно всё на ssd или nvme

Хранить жирные рипы и прочие медиафайлы на SSD все еще не особо модно. Записываешь раз, читаешь кусками, 7 гигабайт в секунду чтения (PCIE4) тут не нужны вообще.

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

246. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от пох. (?), 22-Сен-23, 15:36 
причем записываешь тоже не из мегаскоростного источника, откуда бы ему такому взяться.

Остается только проверить - а сработает ли моднявый bcache правильно в таком формате - или таки будет переписывать этот рип с hdd на ssd layer чтобы потом отдавать в секунду не гигабайты а 7 килобит да и те не факт.

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

257. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Kuromi (ok), 22-Сен-23, 23:30 
> причем записываешь тоже не из мегаскоростного источника, откуда бы ему такому взяться.
> Остается только проверить - а сработает ли моднявый bcache правильно в таком
> формате - или таки будет переписывать этот рип с hdd на
> ssd layer чтобы потом отдавать в секунду не гигабайты а 7
> килобит да и те не факт.

Теоретически модный bcache при записи должен пихнуть рип на SSD, потом потихоньку в фоне перенести его в на HDD, а дальше смотреть как часто дергают данный файл. Если это что-то активно используемое, то держать на SSD, если нет, то нет. Тут все упирается в то насколько умная эвристика.

У пресловутого F2FS для этого есть категоризация файлов на холодные и горячие данные (по расширению файла). Задумано это больше под зонированные устройсва (вроде SMR), где есть быстрая и медленная зона, но логика та же.

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

264. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (-), 23-Сен-23, 02:49 
> У пресловутого F2FS для этого есть категоризация файлов на холодные и горячие
> данные (по расширению файла). Задумано это больше под зонированные устройсва (вроде
> SMR), где есть быстрая и медленная зона, но логика та же.

Это под гибриды где HDD и SSD в одном девайсе. Зонирование - немного не про то. Оно про управление зонами с хоста и работу с ними по определенным правилам, когда только дозапись, но перезаписывать можно только после очистки.

И кстати zoned это как черепица может быть так и - тадам - скоростные SSD, потому что вон те правила очень хорошо описывают идею работы флеша с eraseblock. И для SSD это позволяет заметно упростить и ускорить транслятор, заодно сделав ему удобнее и потому быстрее.

...в этом месте и btrfs с zoned оказывается такой себе "почти файлухой для флеша". По сути это часть FTL передвинута в ФС из фирмвари давая больше контроля как и что. Для флеша это более удачная семантика чем потуги с trim и ЭМУЛЯЦИЕЙ мелкоблочного стоража здоровой фирмварой.

Так что грань кто там флешовая ФС и проч - начинает немного стираться. Поразвели вот всяких гибридных решений.

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

267. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от пох. (?), 23-Сен-23, 09:13 
> Теоретически модный bcache при записи должен пихнуть рип на SSD

ага. Напоминаю - откуда он взялся-то? Правильна - либо с флэшки, либо с интернета, и скорость поступления этих данных не то что для ssd, а для mfm hdd вполне посильна.

Поэтому мы просто даром тратим ресурс.

Теперь мы его начинаем "активно использовать". Т.е. смотрим и подр..4иваем. Он, напоминаю - бааааальшоой. Поэтому места для всяких любимых тут некоторыми "/build" немножко перестает хватать и они идут нахрен писаться на медленный уровень. (хуже вариант - пишутся таки на ssd потому что он в приоритете, а потом переписываются потому что рип все еще читается - снова зря тратим ресурсы) Чтение идет со скоростью аж 8 килобит в секунду (что по-моему даже перебор для прона, чего там прыщи на п-де разглядывать-то) - опять справился бы древний диск.

В пресловутом zfs ARC очень старались не допустить вымывания кэшей линейными медленными чтениями и разовыми доступами к ненужно-данным. С arc2 по разным причинам получилось не очень по несвязанным с этими причинам (в основном потому что компьютеры были большими, а с тех пор никто этим не занимался нормально, нет ресурсов и туалетной бумаги).

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

287. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (-), 25-Сен-23, 16:13 
> Теперь мы его начинаем "активно использовать". Т.е. смотрим и подр..4иваем. Он, напоминаю
> - бааааальшоой. Поэтому места для всяких любимых тут некоторыми "/build" немножко
> перестает хватать и они идут нахрен писаться на медленный уровень.

Если кэш не совсем тупой он статистику вести будет - и забуферит даже не весь build а то что часто гоняют. А редкое - и хрен с ним. А если ты на огроменное порево так часто наяривать удумал, тебя, наверное, мозоли начнут больше напрягать. И не факт что только на руках :))). При этом как мне кажется тебе уже не до проблем SSD будет. "Козел у вас конечно задр@ченный, но жить будет" (c) анекдот.

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

296. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Kuromi (ok), 27-Сен-23, 16:14 
>> Теоретически модный bcache при записи должен пихнуть рип на SSD
> ага. Напоминаю - откуда он взялся-то? Правильна - либо с флэшки, либо
> с интернета, и скорость поступления этих данных не то что для
> ssd, а для mfm hdd вполне посильна.
> Поэтому мы просто даром тратим ресурс.

Ну так для тех же быстрых NVME даже в тестах данные льются чтобы скорость проверить - с другого такого же NVME, иначе откуда еще? Самый быстрый SATA SSD не загрузит на полную даже PCI-E 3 диск стоящий во втором слоте с двумя линиями PCI-E.

С другой стороны там только в кэше такая скорсоть, так что...

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

244. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Kuromi (ok), 22-Сен-23, 14:03 
>> Особенностью Bcachefs является поддержка многослойного подключения накопителей, при котором хранилище компонуется из нескольких слоёв - к нижнему слою подключаются наиболее быстрые накопители (SSD), которые используются для кэширования часто используемых данных, а верхний слой образуют более ёмкие и дешёвые диски, обеспечивающие хранение менее востребованных данных.
> Вот уж реально киллер фича, но в комментах почему-то спорят о совсем
> другом

Так это наследие от Bcache, который собственно это и делал - кэшировал HDD на SSD. Много лет уже доступно, а раньше SHDD тоже самое делали только сами.

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

292. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от rinat85 (ok), 26-Сен-23, 23:29 
то, как в первых имплементациях было реализовано, было напрямую взято из bcache, но позже всё переделали для именно файловой системы
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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