The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, приводящей к повреждению файлов, opennews (??), 01-Дек-23, (0) [смотреть все]

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


13. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +3 +/–
Сообщение от Ананий (?), 01-Дек-23, 10:18 
Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных. И баги у этой ФС соотвествующие. Кто вообще запустил миф, что BTRFS - ФС?
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

16. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –2 +/–
Сообщение от Аноним (1), 01-Дек-23, 10:23 
У btrfs нет багов. Баги -- это когда ФС в целом надёжна, но иногда в коде обнаруживаются ошибки. А btrfs это одна сплошная ошибка, которая разваливается от любого неосторожного движения как трухлявое дерево.
Ответить | Правка | Наверх | Cообщить модератору

17. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –2 +/–
Сообщение от DEF (?), 01-Дек-23, 10:28 
Трухлявое дерево - это твое протухшее глючное железо. Железо замени на надежное. Ну и руки свои выпрями.
Ответить | Правка | Наверх | Cообщить модератору

20. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (1), 01-Дек-23, 10:38 
А вот ZFS прекрасно работает на любом железе, для неё не надо создавать тепличные условия. В этом кстати главная проблема btrfs -- в том что она хорошо работает только на бумаге и в стерильных лабораторных условиях.
Ответить | Правка | Наверх | Cообщить модератору

22. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от DEF (?), 01-Дек-23, 10:43 
Наглое вранье. Ни одна ФС не спасет от повреждения данных, которое происходит из-за глючного железа. У тебя проблемы с причинно-следственными связями.
Ответить | Правка | Наверх | Cообщить модератору

24. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от Аноним (24), 01-Дек-23, 10:58 
Бтрфс кстати спасает, но, до тех пор, пока всё складывается удачно. Это могут быть и годы, и неделя. Зависит от характера повреждений опять же. Но главное, она просигнализирует о проблемах задолго до того, как ситуация пример необратимый характер.
Ответить | Правка | Наверх | Cообщить модератору

25. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (1), 01-Дек-23, 11:01 
Главное не забыть докупить дисков чтобы можно было освободить место в пуле ))
Ответить | Правка | Наверх | Cообщить модератору

30. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/–
Сообщение от нах. (?), 01-Дек-23, 11:06 
нееее, это так не работает. Их надо подключить ДО того как понадобилось место в пуле. Иначе не хватит места для добавления места. Оно ТАК работаит.

(подозреваю что костылик с zpool attach тоже может слегка побаливать этой же болячкой, но он таки во-первых костылик и ему можно, во-вторых к этому моменту все будет уже давно плохо и в общем-то кто не почесался вовремя - сам виноват)

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

190. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 02-Дек-23, 09:46 
> нееее, это так не работает. Их надо подключить ДО того как понадобилось
> место в пуле. Иначе не хватит места для добавления места. Оно
> ТАК работаит.

Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень хорошо :)

> (подозреваю что костылик с zpool attach тоже может слегка побаливать этой же
> болячкой, но он таки во-первых костылик и ему можно, во-вторых к
> этому моменту все будет уже давно плохо и в общем-то кто
> не почесался вовремя - сам виноват)

Ну а btrfs'ники свои проблемы решили, как обычно. И кент конечно тоже стырил решение. Довольно предсказуемо, я б сказал.

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

220. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от нах. (?), 02-Дек-23, 17:47 
> Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем
> никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень

а если уже взяло? Потом еще разок взяло... а потом почему-то в доме у кролика вообще ничего не осталось.

И вот шансов на то что застрявший медведь схуднет через пару недель - не очень.

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

324. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 07:36 
>> Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем
>> никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень
> а если уже взяло? Потом еще разок взяло... а потом почему-то в
> доме у кролика вообще ничего не осталось.

Если оно это на актуальных версиях ядер делает - навесить баг, имхо. Но у них там так то для тестов целый книгоморд был - и они как раз подобные приколы гасили энное время назад. В обычной ситуации на ЭТО с современными ядрами вообще нарваться малореально - надо нечто супернагруженное, как у мордокниги, тогда под ломовой нагрузкой, на нескольких тазиках из всего парка, за недели-месяцы, может и получится. Но после тех фиксов уже вроде и там не получается, при том что нагрузки фэйсбука -

> И вот шансов на то что застрявший медведь схуднет через пару недель - не очень.

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

А так как видишь, свои приколы есть у всех. Кент глядя на это завел какой-то радикально более толстый резерв сразу, чтоб на уже известные грабли не вставать. Удобно же когда граблю nextgen дизайна до тебя любезно оттоптали, можно - вот - немного переиграть :). Круто конечно все заранее знать и заранее предусматривать - но так не бывает.

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

116. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (110), 01-Дек-23, 16:37 
Как и превосходное железо на глючной FS.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

23. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –5 +/–
Сообщение от Аноним (24), 01-Дек-23, 10:54 
Вообще-то только btrfs обкатана всеми и везде где только можно и зфс никто не использует в адеквате (потому что не предоставляет сколько-нибудь значимых преимуществ и потом приходится ныть на форумах).
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

41. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (41), 01-Дек-23, 11:31 
расскажи это пользователям TrueNAS, TrueNAS или OMV
Ответить | Правка | Наверх | Cообщить модератору

42. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (41), 01-Дек-23, 11:32 
*FreeNAS
Ответить | Правка | Наверх | Cообщить модератору

55. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от Аноним (24), 01-Дек-23, 11:49 
Лохи они и в Африке лохи, на то они и лохи.
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

77. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от DEF (?), 01-Дек-23, 13:20 
Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем, Red Hat (Все из Федоры идет в RHEL после обкатки).
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

130. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (130), 01-Дек-23, 18:26 
rhelovskiy сектант все с тобой понятно) жуй свой интырпрайз и не мешай крутить другим педали своих велосипедов
Ответить | Правка | Наверх | Cообщить модератору

191. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 02-Дек-23, 09:50 
> Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs
> в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем,
> Red Hat (Все из Федоры идет в RHEL после обкатки).

Что, редхат таки устал пыжиться прикрутить эрзац-подобие scrub к XFS? Там где-то в процессе аж майнтайнер слинял. Вооооон там, с btrfs'никами отвисает теперь. Популярное направление стало - почему-то из редхата все блочники-файлушники куда-то в сторону btrfs драпают. Тенденция, однако!

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

269. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от edo (ok), 04-Дек-23, 10:04 
> Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs
> в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем,
> Red Hat (Все из Федоры идет в RHEL после обкатки).

Facebook строит отказоустойчивую систему, так что пример не очень удачный, для них потеря данных на отдельном сервере/стойке или даже ДЦ не критична.
Synology — совсем уж entry-level, так что тоже не очень удачный пример.
RH активно продвигал xfs, не слышал, чтобы они отказались.
Остаётся разве что Fedora, понаблюдаем.
Но у меня пока ощущение, что скорее bcachefs допилят до готовности к проду в многодисковых конфигах, чем btrfs.

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

325. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 07:53 
> RH активно продвигал xfs, не слышал, чтобы они отказались.

0) Из RH удрапало дофига блочников и файлушников. Воооон там вокруг btrfs теперь тусят, лол.
1) Btrfs в федору втянули.
2) XFS - такая сова на глобус что там аж майнтайнер удрапал в панике не так давно. Его роботы багами засыпали в хламину, он и промямлил - мол XFSv4 код дидов такой крап что когданить потом пофиксим его, путем дропа, останется только v5. Но впрочем даже это будут пытаться другие.
2.1) И да, они там героически упираются хотя-бы аналог scrub запилить. При том уже несколько лет. Видимо идея делать вот именно fsck, именно при загрузке, вообще легаси пованивает с одной стороны, а проверять состояние данных в рантайм с другой стороны - как-то более актуально, ибо какие-нибудь серваки и что там еще могут ребутать не очень то и часто, да и время этой операции по всей площади - изрядное. Одно дело фоновое чтение с idle приоритетом, другое - что-то там чекать при загрузке и проч.
3) Пойнт вон той камасутры для меня загадка. Сколько это УГ не гальванизируй, btrfs/bcachefs по управлению из ЭТОГО не получится. А все эти сратисы с пыхтонрасом и этажеркой LVM/MD/DM/... - могу себе представить как это будет работать. Особенно если в процессе менеджмент операции питание слетит или там что еще.

Говоря за себя - меня тот блевотный менеджмент который редхат пытался сватать - вообще совсем не устроит после того как я Btrfs попробовал. Вот эти сделали управление файлухой и пространством так как это и должно было быть на самом деле.

> Остаётся разве что Fedora, понаблюдаем.
> Но у меня пока ощущение, что скорее bcachefs допилят до готовности к
> проду в многодисковых конфигах, чем btrfs.

Ну вот в данный момент времени я btrfs использую в вполне "продакшновых" сценариях, а bcachefs - ну я там уже пару багов отхватил. Но его только комитнули и это нормально.

И да, если кто думает что Кент все идеально предусмотрел... вон там уже блаблабла на тему того что надо б инверсные индексы на манер btrfs'ных backrefs, а то скорость операций менеджмента что-то дескать "не очень". При том этого еще нету на уровне структур и проч даже. У него еще есть прикольная штука - erasure coding. Но и это WIP жесточайший.

Btrfs-ники так то тоже свое дело делают. Недавно запилили bg_tree с которым btrfs маунтится аж быстрее ext4 (и bcachefs). На механике, VM или медленных флехах бывает довольно заметно. И какие-то расширения RAID56 пилят в фоне, дабы write hole более радикально заделать. Но у них core дизайна куда стабильнее если RAID56 не надо, имхо. Это уже продакшновый дизайн, видавший ломовые нагрузки уровня FB и проч. И основные самые жирные баги в нем - уже отловлены. В отличие от вон того - там поток багов такой что Kent почти каждый -rc прилично фиксов насыпает. Но это нормально в данный момент времени.

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

314. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Stellarwind (?), 05-Дек-23, 17:51 
Оно же было в RHEL 6/7 как Tech preview, а потом эту каку выкинули..

The Btrfs file system has been removed in Red Hat Enterprise Linux 8.
You can no longer create, mount, or install on Btrfs file systems in Red Hat Enterprise Linux 8. The Anaconda installer and the Kickstart commands no longer support Btrfs.

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

326. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 08:20 
> Оно же было в RHEL 6/7 как Tech preview, а потом эту каку выкинули..

Я б сказал что скорее блочники и файлушники - выкинулись из редхата, ну они и не смогли майнтайнить компонент. Не знаю что там случилось но вон те устроили практически исход из RHBM и часть скучковалась - вот - вокруг btrfs, уже под другими вывесками, видимо. Деталей не знаю.

Оракл смачно потролил это дело декларя "как редхат, но с этим". А RH видимо наняли по объявлению, закончилось что сбег (хайповатый так то) майнтайнер XFS-а и теперь отвисает где-то рядом с кентом и бтрфсниками, тенденция однако. Видимо гальванизация трупа шла тяжко.

> The Btrfs file system has been removed in Red Hat Enterprise Linux 8.

Пусть еще напишут что все известные файлушники и блочники из их dream team ремувнулись, и теперь XFSников обслуживают нонеймы. Даже хайповатый майнтайнер съ... по причине "боты завалили багами!!!111". Да, это вам не расскажет маркетинг в прессрелизе.

> You can no longer create, mount, or install on Btrfs file systems
> in Red Hat Enterprise Linux 8. The Anaconda installer and the
> Kickstart commands no longer support Btrfs.

На лично мое нескромное мнение у редхата что инсталер, что пакетник - лютое УГ. Теперь тренду последовало и управление ФС. Что они там делать будут - хз. Я б на их месте попытался кента перехватить (btrfs-ники уже все при деле). И сделать что-нибудь НОРМАЛЬНОЕ - а не тот #$%ный стыд! Но видимо будет как с пакетником, too little and too late.

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

315. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от bOOster (ok), 05-Дек-23, 19:37 
Да ладно, врать то. Enterprise Synology так же как и QNAP - ZFS с FreeBSD пользуют. А дурачкам отдают btrfs. Надо же как дифференцировать продукт. Btrfs для лохов под га..но. Под Enterprise ZFS.
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

45. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/–
Сообщение от Аноним34 (?), 01-Дек-23, 11:36 
ZFS делали серьезные дяденьки для серьезных целей (Конкретно Solaris). Она там обкатана, все у нее в жизни прекрасно и детских болезней в ней нет.
А вот OpenZFS делали другие по другому и с другим подходом.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

49. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +2 +/–
Сообщение от нах. (?), 01-Дек-23, 11:45 
> ZFS делали серьезные дяденьки для серьезных целей (Конкретно Solaris). Она там обкатана,
> все у нее в жизни прекрасно и детских болезней в ней
> нет.

эммм... но это неточно.

> А вот OpenZFS делали другие по другому и с другим подходом.

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


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

66. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –3 +/–
Сообщение от DEF (?), 01-Дек-23, 13:00 
Серьезные дяденьки из Sun? Sun - банкрот, Solaris - мертва. OracleZFS - тоже. Дяденьки разбежались, кто на пенсию, кто в другие шараги. OpenZFS - кривая поделка, которую пилит по сути один чувак. Какой-то лаборант.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

93. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +2 +/–
Сообщение от Аноним34 (?), 01-Дек-23, 14:50 
От того, что они на пенсии, мертвы и банкроты, менее серьезными они не стали
Ответить | Правка | Наверх | Cообщить модератору

115. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (110), 01-Дек-23, 16:34 
Что значит "не предостоставляет сколько-нибудь значимых преимуществ"? А можете озвучить краткий список возможностей как BTRFS, так и ZFS? Вместе сравним!
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

120. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –4 +/–
Сообщение от Аноним (24), 01-Дек-23, 16:50 
Так плюсов в наличии только что-то похожее на raid6 разве что. Зато из минусов для работы надо выделить минимум 2 гига памяти на каждый терабайт хранилища и памяти можно найти применение получше.
Ответить | Правка | Наверх | Cообщить модератору

131. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +2 +/–
Сообщение от Аноним (130), 01-Дек-23, 18:27 
крутится фряха с двумя гигами и винтом на 6тб как файлопомока скорость по гигабиту ~125МБ/c
Ответить | Правка | Наверх | Cообщить модератору

133. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –2 +/–
Сообщение от Аноним (24), 01-Дек-23, 18:29 
Как дедупликация поживает, сколько подключений, кстати, и вообще что там с параллельной нагрузкой?
Ответить | Правка | Наверх | Cообщить модератору

200. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/–
Сообщение от Аноним (110), 02-Дек-23, 14:02 
Ничего не скажешь, шикарные познания в ZFS. Даже о самом очевидном, изменяемом размере блока, не упомянул. А это, на минуточку, если вы на BTRFS не отключаете CoW, одна из самых важных штук. Просто повальная профанация в области файловых систем.
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

202. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –3 +/–
Сообщение от Аноним (24), 02-Дек-23, 14:07 
Так а толку возиться с ней, если она сасает на буквально любых применениях? Я не вижу ни одной причины трогать её даже 12 метровой палкой, и это отличает специалиста от аутиста.
Ответить | Правка | Наверх | Cообщить модератору

209. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +2 +/–
Сообщение от Аноним (110), 02-Дек-23, 14:58 
Сколько высокомерия и самонадеянности. На этом профессионализм и заканчивается. Как же все это глупо... будь оно так - с ZFS бы никто дел не имел и не тратил бы на нее столько времени и сил. Ну, удачи специалист!
Ответить | Правка | Наверх | Cообщить модератору

210. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –3 +/–
Сообщение от Аноним (24), 02-Дек-23, 15:13 
Так и никто и не тратит. Это чистое безумие, на неё завязываться. Даже не столько по причине технических недостатков.
Ответить | Правка | Наверх | Cообщить модератору

157. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 01-Дек-23, 21:50 
Чё там, на RPI Model A с 256M RAM будет работать?
Речь о работать, а не слоупочить.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

178. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –4 +/–
Сообщение от Аноним (-), 02-Дек-23, 00:51 
> Чё там, на RPI Model A с 256M RAM будет работать?
> Речь о работать, а не слоупочить.

Btrfs - норм работает на таком. Вообще на вид от EXT4 не отличишь особо. А с bg_tree новомодным - он еще и монтируется быстрее чем ext4, совсем уж прикол. Я его даже на роутере с 64 мегами цеплял, достаточно культурно в целом, btrfs (и bcachefs) на уровне структур не супертормоз как ZFS.

В отличие от - может например DUP на sd-карточке разложить что очень способствует тому чтобы система не сдохла от 1 рандомного бэда раз в дохреналион, например. И даже слет блока флеша при внезапном powerloss чаще всего переживает, при налете на это буркнет про csum failed в лог да починит. А ext4 в таком случае ловит шикарнейший фаталити и сразу наповал.

И fsck при старте не надо - что жирный плюс на управляющей штуке: кто там будет разгребать fsck и прочие lost+found? И эникей жать там некому, однако. Так что получает свой пойнт для необслуживаемых и малообслуживаемых систем имхо, делая их более устойчивыми и разворачивая теорвер в более интересную сторону. А заодно чаще всего хайлайтя явные проблемы железа ДО того как это трансформируется в реальные сбои. Узнать о потенциальной трабле из логов лучше чем когда уже отскребаешь управлялку от асфальта в режиме аврала.

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

179. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 02-Дек-23, 00:54 
Бутер будет. Ему правда будет очень кисло из-за тормознющей SD, но таки будет.
Но я на пост про ZFS отвечал.
Ответить | Правка | Наверх | Cообщить модератору

327. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 08:58 
> Бутер будет. Ему правда будет очень кисло из-за тормознющей SD, но таки будет.

Да нормально работает на самом деле. И флешу cow достаточно удобен на самом деле: in place патчинг для FTL означает крайне нетривиальные RMW+GC, ибо ну вот не умеет флеш на самом деле именно "in place patching" мелким блоком. На уровне его структуры и физики. CoW там лучше в целом. Btrfs к тому же умеет trim - и вон та идея с async trim круто на SD/eMMC @ mmc hci контроллер вписалась.

И между прочим - там еще сжатие есть. Если накопитель тормоз, ЭТО дает кроме всего прочего апгрейд скорости IO, система и проч - неплохо жмется, раза в 2-3.

> Но я на пост про ZFS отвечал.

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

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

181. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 02-Дек-23, 00:56 
Вот кстати то самое место, где лучше чексумминг иметь, у старых SD-карт ECC примерно около отсутствует.
Новые правда поинтереснее, они уже мало чем от SSD отличаются.
Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

328. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 09:06 
> Вот кстати то самое место, где лучше чексумминг иметь, у старых SD-карт
> ECC примерно около отсутствует.
> Новые правда поинтереснее, они уже мало чем от SSD отличаются.

Я бы не стал излишне обобщать. Девайсов, фирмварей и проч - дохрена, и постоянно новые появляются. Кто и что откаблучит - это всегда некое минное поле.

Штуки типа DUP (или тем более RAID1, если было куда) + CSUM здорово улучшают вышиваемость файлухи при отклонениях от идеала. И что важнее, факапы можно заметить на подлете. Скажем учащаюшиеся битые блоки по "csum failed" станет видно ДО того как девайс по всей площади осыпется в труху. А на EXT4 каком это замечают когда там уже совсем фаталити, так что оно и не смогло работать дальше. Но там к тому моменту может такой трешовник быть - что чинить уже нечего и спасибо если хоть самое ценное хотя-бы частично восстановится.

ФС с чексумами сильно улучшают диагностируемость железа и даже в общем то и глюков софта порой. Идея в том что что бы ни вызывало глюк, оно не знает как считать чексумы а то что оно вклинится в окно между формированием данных и счетом чексуммы - не так уж и вероятно и чаще всего чексумы смогут спалить даже и это тоже. Потому что отъедет. Не на 100% гарантия - так что обещание что данные не будут испочены может быть профукано. Но реально хайлайтит проблемные железки на ура.

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

329. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 06-Дек-23, 09:14 
Летом тоже с шипами на ботинках и в костюме химзащиты ходишь?
Ответить | Правка | Наверх | Cообщить модератору

344. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от edo (ok), 06-Дек-23, 11:21 
> Летом тоже с шипами на ботинках и в костюме химзащиты ходишь?

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

не потому, что ecc исправляет ошибки, это на самом деле не главное.
главное, что ecc детектит сбои, и можно отбраковать проблемные модули памяти до того, как это вызовет пробемы.

в сравнении со стандартным «что-то прога сегфолт выдала, может библиотека кривая, а может быть космические лучи, или всё-таки выключить комипьютер и на сутки запустить мемтест» это просто гигантский шаг вперёд.

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

349. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 07-Дек-23, 10:38 
Э, да у вас проблемы с надёжностью.
У меня десктоп с ECC-памятью лет 8 уже как.
Может поэтому мне никакие ZFS и не упёрлись :)
Ответить | Правка | Наверх | Cообщить модератору

353. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 08-Дек-23, 14:43 
> Э, да у вас проблемы с надёжностью.
> У меня десктоп с ECC-памятью лет 8 уже как.
> Может поэтому мне никакие ZFS и не упёрлись :)

А корректность работы проца, чипсета, шин, шнурков, накопителей и проч - гарантируется любимым российским методом - "на авось". Я все правильно понял в этой чудной схеме?

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

351. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 08-Дек-23, 13:35 
> Летом тоже с шипами на ботинках и в костюме химзащиты ходишь?

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

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

331. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 06-Дек-23, 09:15 
И да, при чём тут ФС с чексуммами - опять явная реклама.
dm-integrity мало?
Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

343. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от edo (ok), 06-Дек-23, 11:16 
> И да, при чём тут ФС с чексуммами - опять явная реклама.
> dm-integrity мало?

не смотрел внимательно, но обеспечивает ли dm-integrity консистентность данных?
случаи, когда накопитель сказал, что записал данные, а после отключения оказывается, что нет — он читает пусть и валидные, но данные прошлой версии — совсем не редки, увы. в многодисковых конфигурациях это может сделать больно. да и в однодисковых возможны сценарии потери данных.

zfs закрывает и этот случай тоже. ну и, как побочный эффект, raid5 write hole тоже закрывается.

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

347. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 06-Дек-23, 15:07 
Это да. Неказистый RAID5 write hole ловким движением превратился в элегантное read zero hole.

dm-integrity хранит журнал и метаданные отдельно от данных, так что должно быть ок.

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

352. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 08-Дек-23, 14:21 
> И да, при чём тут ФС с чексуммами - опять явная реклама.

Очень странно упоминать ФС с чексумами в топике про ФС с чексумами. Где чексумы одно из достоинств дизайна и аргумент "за".

> dm-integrity мало?

Файлухи с чексумами менеджить сильно удобнее чем этажерку из этих кусков крапа. А ты можешь на этих костылях прыгать если хочешь. Но без моего участия. Мне как-то device add/device remove - с прозрачным увеличением/уменьшением места по сути 1 командой - нравится сильно больше. Я хочу видеть управление вот так, а не вон тот кошмарик.

И да, снапшоты тоже полезны, например, для операционки, чтобы как в виртуалке - в случае факапа например апгрейда системы просто откатиться да попытаться еще раз. Без реинстала всей оси и проч на полдня. А у тебя вон то не получится. Можно конечно и это отрастить в той этажерке, но если захочется что-то переконфигурировать, скажем, размер ФС увеличить - не спятить при этом будет довольно тяжко. Наслаждайся этим сам, а я свой выбор сделал. И хотя это не ZFS, они были первыми кто это придумал - и у них был нефиговый пойнт.

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

201. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (110), 02-Дек-23, 14:07 
А вы, видно, неплохо так развлекаетесь. В таких условиях, даже BTRFS придется несладко.
Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

234. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 03-Дек-23, 10:09 
btrfs кстати кое-как работает... И учитывая что левелинг в старых SD надо искать, некоторый смысл имело.
То же самое с CF в совсем мелкой эмбедовке, которая ещё хуже распи. Но туда конечно и бтр уже не влезает, приходится делать слой левелинга на ubifs.
С другой стороны в новых самсунговских SDXC левелинг есть, и на новых RPi уже можно особо не заморачиваться.
Ответить | Правка | Наверх | Cообщить модератору

242. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (110), 03-Дек-23, 13:37 
Основная проблема в BTRFS - это просто конский WA. Причина того, почему ZFS будет работать плохо или не работать вообще - это ARC. С этим уже ничего не сделаешь.
Ответить | Правка | Наверх | Cообщить модератору

244. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 03-Дек-23, 13:55 
WA да, у BTRFS действительно конский, проверено на SAN.
Ещё отдельная проблема с трекингом свободного места, но она хотя бы решаема вариантом одна FS - один "раздел".
Ответить | Правка | Наверх | Cообщить модератору

330. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 09:14 
> WA да, у BTRFS действительно конский, проверено на SAN.

Это на самом деле от ворклоадов зависит. Вы там что делали? Какой характер файлов и ворклоадов?

> Ещё отдельная проблема с трекингом свободного места, но она хотя бы решаема
> вариантом одна FS - один "раздел".

Это расплата за продвинутый дизайн и удобный менеджмент, у медалей 2 стороны. Если у вас есть возможность сжатия, рефлинки, снапшоты, возможность сохранять в РАЗНЫЕ схемы избыточности и проч - ответ на вопрос "сколько места" становится ... значительно интереснее.

Появляются забавные факторы.
- Насколько сожмется? Вы это знаете заранее?
- Насколько блоки совпадают - и будут совпадать далее?
- В какой схеме в будущем запросят новые блоки? Это переключаемо в run time и ничем не грозит, можно даже не рестрайпить а заказать новые дефолты для НОВЫХ записей, тогда то что уже записано останется в той схеме как было. Это совершенно валидно в таком дизайне. Это же делает возможной конверсию типа RAID на ходу, по примерно той же технологии. С cow нет причин почему бы данные разрушились. Даже при крахе во время этого действа. И ему даже позицию конверсии трекать не надо при этом.
- А также прочие приколы типа снапшотов, метаданных/tail packing (метаданные могут иметь иную схему хранения чем данные, "хвосты" или мелкие файлы - будут в этой схеме). Откуда заранее знать data/metadata ratio и проч?

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

334. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 06-Дек-23, 09:20 
>> WA да, у BTRFS действительно конский, проверено на SAN.
> Это на самом деле от ворклоадов зависит. Вы там что делали? Какой характер файлов и ворклоадов?

Смешанный.

> Это расплата за продвинутый дизайн и удобный менеджмент

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

> - Насколько сожмется? Вы это знаете заранее?
> - Насколько блоки совпадают - и будут совпадать далее?

Зачем? Достаточно знать, сколько там _реально_ ещё можно записать, без "сожмётся" и "совпадают".
Если удастся записать больше - хорошо, но ни в коем случае не меньше.

> С cow нет причин почему бы данные разрушились

Конечно нет, ZFS не даст соврать. И ищи потом свищи, где у тебя в этой каше был оригинал данных, он там на весь диск разложен. Ещё одна прелесть не-CoW - данные фрагментируются не сильно, и можно хоть что-то выдернуть при 3.14це, который такого выдёргивания требует.

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

354. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 08-Дек-23, 15:10 
> Смешанный.

Может означать все что угодно. Однако нехило бы описать что и как измерялось, по сравнению с чем, и указать какие-то детали.

>> Это расплата за продвинутый дизайн и удобный менеджмент
> Не знать, сколько _реально_ в FS осталось свободного места - это да,

Ды ты в современной системе и сколько RAM свободной - де факто не знаешь. Можешь посмотреть как в линухе аллокация памяти сделана по дефолту, с оверкомитом и проч. Идея кстати примерно та же самая. Но ты конечно можешь у себя отрубить оверкомит... только тогда сильно меньше программ сможешь запускать при прочих равных. Почему-то.

А прикинь, файлуха может не знать заранее что я рефлинкну вон тот 3-терабайтный образ. Смотри, мы начинаем с 3Тб файлом и 5Тб хранилкой. Вроде бы 2 Тб места примерно. Делаем пару рефлинканутых "копий". Опа, у нас как бы 9 терабайт - на 5 тер места. Реально конечно там 3 терабайта + отличия. Но де факто это оверкомит и "оверселл". И откуда б заранее знать насколько рефлинкнутые копии разъедутся? Захотят - станут независимые. Или останутся почти идентичными. С сжатием - аналогично. И так далее.

> мегаудобнейший дизайн и наиэффективнейший менеджмент. Честно - одна из самых веских
> причин обходить стороной.

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

Ващет файлухи на 100% забивать - не очень удачная идея в целом из-за жуткой фрагментации. Так что в нормальном случае это не проблема. При том если btrfs после этого можно попробовать отдефрагать, в случае сабжа - получится убер-тормозной пул с которым вообще хз что делать. Но вообще-то такая же фигня даже и из ext4 и xfs получается. У ext4 даже дефраг есть но он видите ли не умеет агрегацию свободного места и вообще базовый весьма.

А, да, EXT4 кстати - вообще идиотская ФС. Например совсем не умеет деаллокацию директорий. Если в дире одно время отращивалось 100500 файлов и дира вымахала до эн мегз - мало того что дира останется эн мегз навечно! Кроме этого - даже если там ща 100 файлов, операции с этой дирой тормозят как будто там все 100500 на месте. Такая вот скалабельная, крутая фс - которая даже деаллоккацию дир не могет. И которой цук номерков на иноды может не хватить. И эти люди тут еще юродствовать смеют на тему сабжа.

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

Как там поживает деаллокация дир в EXT4 или ограничение на число инодов? А, ничо, эти копролиты - нормуль, не жмут?

> Зачем? Достаточно знать, сколько там _реально_ ещё можно записать, без "сожмётся"
> и "совпадают". Если удастся записать больше - хорошо, но ни в коем случае
> не меньше.

Оно что-то такое видимо и выдает как оценку для доступного места. Но реально ессно возможны варианты. Кроме того...

...у ФС есть метаданные. Вот смотрите: кто-то даже делал супер-архивер, который попытался взять приз на конкурсе сжатия. Идея была простая:
- А можно сохранять в несколько файлов?!
- ОкеЙ, сохраняйте!

Ну чувак и читал данные исходного файла. Разложил прочитанные данные по именам файлов в дире. И вот - обана! - смотрите дети, идеальный архивер! Суммарный вес файлов - ноль! Данные же в именах хранятся, зачем в файл что-то писать. Сумма размеров файлов - вообше ноль.

Вот только приз ему кажется не дали. Да и вообще - если попробовать так архивировать, можно заметить что в принципе можно догнаться до точки когда формально на ФС аллоцировано 0 байтов в файлы, но записать почему-то не получается. А как вы собрались заранее оценивать размер метаданных и соотношение оного VS данные - кто б его знает. Для ФС с tail packing и inlining мелких файлов - это как бы аргумент.

>> С cow нет причин почему бы данные разрушились
> Конечно нет, ZFS не даст соврать. И ищи потом свищи,

Ну, вообще, если попортилась копия, копии, да еще быстро упавшая лицом на тот кулак 2 раза подряд - это еще ухитриться надо. А с твоим EXT4 педальным ты и осыпон половины файлухи не заметишь. И таки глядя на коллекцию BadHardware отловленого btrfs я имею сказать что "it works!" и я буду предпочитать такую диагностирумеость и верификацию работы моих систем и далее. Это спасает от множества дурачких приключений и непоняток.

> где у тебя в этой каше был оригинал данных, он там на весь
> диск разложен. Ещё одна прелесть не-CoW - данные фрагментируются не сильно,

Ну вот вообще ниоткуда не следует. Если подзабить и активно поюзать даже тот же EXT4 - тупить он начнет весьма ощутимо, особенно на механике.

> и можно хоть что-то выдернуть при 3.14це, который такого выдёргивания требует.

Я и с btrfs'а вытащу, при том в отличие от твоего хексэдитора - прям встроеным альтернативным парсером. Да еще - имея под рукой ТРИ копии суперов, много разных точек входа в иерархию деревьев, ибо GC ж не прибивает более старый вид сразу и оно энное время живет. Это повышает шансы что основной объем метаданных зацепится без урона вообще. Особенно учитывая что хранится даже на 1-дисковом стораже с DUP, а на более приличной конфиге и как RAID1 (можно даже c3/c4, если девайсов много). Я как-то предпочту не натыкаться на мануальный парсинг данных, чем упражняться в нем, при прочих равных. И я это говорю как датарек-любитель, способный поболтать на равных с себе подобными. Вооон там в советах, я изобрел способ gumanzoy по ресету и рескану за несколько лет до него. Правда я скрипты не делал - тупо oneliner "по ситуации" на машине запускал.

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

357. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 09-Дек-23, 11:43 
> Ну да, ну да, в бак с топливом "боинга" на лету неудобно светить фонариком и оценивать на глаз

Ну, знаешь, если в боингах будут такие же датчики, как в бтрзфсах, то я лучше на них летать перестану.

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

46. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от penetrator (?), 01-Дек-23, 11:37 
это "трухлявое дерево" спасло массив на 40 тб после добавления ошибки в драйвере в ядре, недопустив повреждения данных и отключив массив

так что на личном опыте использования могу сказать что ты звездишь

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

57. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Минона (ok), 01-Дек-23, 11:49 
Сказки опеннета.
Ответить | Правка | Наверх | Cообщить модератору

62. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от penetrator (?), 01-Дек-23, 12:44 
loshok сходи на kernel.org

[  287.137901] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137909] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137912] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137914] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137916] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137919] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137921] aacraid: Host adapter abort request.
               aacraid: Outstanding commands on (10,0,0,0):
[  287.137924] aacraid: Host adapter abort request.

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

86. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Минона (ok), 01-Дек-23, 14:11 
Сказки тут:
> это "трухлявое дерево" спасло массив
Ответить | Правка | Наверх | Cообщить модератору

91. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от penetrator (?), 01-Дек-23, 14:31 
именно оно и спасло, при загрузке старого ядра данные остаются целыми, но если произвести модификацию данных на новом ядре, то портятся, все ext4 разделы побились, а BTRFS не дал этого сделать, проверив чексумы, сохранив свою целостность

так что давай дальше БибаБоба смеши людей

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

96. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/–
Сообщение от Минона (ok), 01-Дек-23, 15:07 
> а BTRFS не дал этого сделать, проверив чексумы, сохранив
> свою целостность

А ранее ты писал:
> недопустив повреждения данных и отключив массив

Ы?
> так что давай дальше БибаБоба смеши людей

Аха, давай смеши дальше, сказочник опеннета.

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

137. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от penetrator (?), 01-Дек-23, 18:58 
массив был перемантирован в режиме для чтения, потому что операции записи были невозможны

и это все было выполненно ядром и BTRFS автоматически

так что не так, Куклачев?

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

158. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 01-Дек-23, 21:51 
> массив был перемантирован в режиме для чтения, потому что операции записи были
> невозможны
> и это все было выполненно ядром и BTRFS автоматически
> так что не так, Куклачев?

И давно errors=remount-ro отменили?

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

195. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от penetrator (?), 02-Дек-23, 12:23 
>> массив был перемантирован в режиме для чтения, потому что операции записи были
>> невозможны
>> и это все было выполненно ядром и BTRFS автоматически
>> так что не так, Куклачев?
> И давно errors=remount-ro отменили?

так EXT4 думал что у него все хорошо

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

199. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 02-Дек-23, 13:35 
Чо? Ядро выплюнуло ошибки контроллера, ext4 там уже ничего думать не может.
Ответить | Правка | Наверх | Cообщить модератору

332. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 09:16 
>>> и это все было выполненно ядром и BTRFS автоматически
>>> так что не так, Куклачев?
>> И давно errors=remount-ro отменили?
> так EXT4 думал что у него все хорошо

Ну дык, он Титаника напоминает - до последнего оркестр играет и проч. Но потом все же может потонуть.

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

152. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от Аноньимъ (ok), 01-Дек-23, 20:53 
> все ext4 разделы побились, а BTRFS не дал этого сделать

BTRFS спас EXT4 разделы? Что я читаю?

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

180. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/–
Сообщение от Аноним (-), 02-Дек-23, 00:55 
> именно оно и спасло, при загрузке старого ядра данные остаются целыми, но
> если произвести модификацию данных на новом ядре, то портятся, все ext4
> разделы побились, а BTRFS не дал этого сделать, проверив чексумы, сохранив
> свою целостность
> так что давай дальше БибаБоба смеши людей

Чексумы забавная штука - они "до кучи" зарубают множество багов железа и софта. А фаны EXT4 - предпочитают следствия из законов Мерфи - как то: "если вам кажется что дела идут хорошо, возможно вы просто чего-то не заметили".

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

182. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Tron is Whistling (?), 02-Дек-23, 00:56 
Например дырочку при чтении дырочки из файла.
Ответить | Правка | Наверх | Cообщить модератору

355. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 08-Дек-23, 15:19 
> Например дырочку при чтении дырочки из файла.

Субъективно - на 1 этот факап за всю жизнь я видел не менее ДЮЖИНЫ прецедентов выгрузки блочными девайсами какой-то трухи юзерам - и даже лично мне.

Учитывая что для вот этого факапа надо было еще и извратиться, а вон то - вообще САМО разваливается, на флешатине просто за факт приближения к лимиту износа - ну, знаете, я предпочту знать истинное состояние дел с чексумами. И не, ваши dm, md, lvm и проч вы там сами и используйте, имхо. Если в zfs нужда в именно таком менеджменте девайсов еще притянута за уши, ибо ничего принципиально иного не делает, то вот btrfs и bcachefs попользовались на всю катушку возможностями которые это дает - и это было круто.

А еще лично мне нравится как логика self heal в btrfs с ремапом взаимодействует: репайрит плохую копию из хорошей, что при io error что при отгрузке трухи. В любом случае проблема починена а этот факт залоггирован. А не вон тот позор.

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

183. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от Tron is Whistling (?), 02-Дек-23, 00:58 
ZFS плоха в частности именно этим монотонным унылым пиаром - на уровне пониже начинают верить, что оно действительно волшебное. А с технической стороны - пока оно с системным кешем не интегрируется, для обычного юза непригодно, разве что для выделенных NAS.
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

307. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноньимъ (ok), 05-Дек-23, 13:09 
> ZFS плоха в частности именно этим монотонным унылым пиаром - на уровне
> пониже начинают верить, что оно действительно волшебное. А с технической стороны
> - пока оно с системным кешем не интегрируется, для обычного юза
> непригодно, разве что для выделенных NAS.

Просто ненужно его юзать с линуксом. И будет всё отлично. В родной иллюмус нет проблем с интеграцией кеша.

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

333. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 09:18 
> ZFS плоха в частности именно этим монотонным унылым пиаром -

Ну, блина, я его на Btrfs'е таки оценил - и могу подтвердить что чексумы способствуют отлову кривого железа. При том чаще всего ДО того как это в фатальные проблемы эскалирует. А что делать? Факты штука упрямая, мой опыт - вот такой. И чексумы в ФС делают минимум допущений о конфиге, чем оно и хорошо - работает везде.

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

318. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от bOOster (ok), 05-Дек-23, 20:02 
Врать не мешки ворочать... Ммм диски...
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

151. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (151), 01-Дек-23, 20:52 
О. а у тебя массив 40Тб на zfs? А зачем? Какая нагрузка? Что в прикладе? Почему zfs? А то твои коллеги так и не осилили ответить на эти вопросы.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

278. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от edo (ok), 04-Дек-23, 10:42 
у меня есть массивы и побольше.

почему zfs — в первую очередь потому что чексуммы + merkle tree (плюс это всё работает в связке с raidz/raidz). также востребованы снапшоты, возможность выносить метаданные на ssd в отосительно свежих версиях; возможность сделать большой размер записи; дедупликация.

мои варианты использования:
- тупая файлохранилка, отдача по http/smb/nfs/…
куча hdd, метаинформация на ssd, снапшоты;
- то же самое для бэкапов образов виртуалок/физических хостов
аналогично, плюс дедупликация;
- хранилище в проксмоксе
ssd, zvol (блочные устройства для гостевых систем, к которым применимы все гарантии целостности и конситентности zfs).

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

100. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/–
Сообщение от Аноним (106), 01-Дек-23, 15:36 
>Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных.

А, ясно, жалуются фрибздуны.

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

168. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (167), 01-Дек-23, 23:02 
>>> Сижу на BTRFS с 2012 года и не потерял ни единого бита информации. А на ZFS постоянно жалуются на потерю данных.
>>Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных.
> А, ясно, жалуются фрибздуны.

А, ясно, опять нам пишут Этодругое-ниды.


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

335. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/–
Сообщение от Аноним (-), 06-Дек-23, 09:21 
>> Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации.
>> А на BTRFS остоянно жалуются на потерю данных.
> А, ясно, жалуются фрибздуны.

Ты только сейчас это заметил? Ну понятно что им обидно - btrfs даже на маздайке уже есть, а у них только дырка от бублика^W файла какого-то, копированого дважды :)

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

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

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




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

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