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

"Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, приводящей к повреждению файлов"	+/–
Сообщение от opennews (??), 01-Дек-23, 09:14
Сформированы корректирующие выпуски проекта OpenZFS 2.1.14 и 2.2.2, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. В обновлениях устранена проблема в коде проверки согласованности кэша dnode, приводящая к повреждению данных в файлах, содержавших пустые области, при их копировании после внесения изменений... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60212
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 01-Дек-23, 09:14	+/–
Живём!
Ответить | Правка | Наверх | Cообщить модератору

2. Сообщение от КриоМух (?), 01-Дек-23, 09:22	+18 +/–
Чётенько описали подробности проблемы. Спасибо!
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от bOOster (ok), 01-Дек-23, 09:22	–9 +/–
Объясните мне - зачем cp лезет в структуру файловой структуры нарушая уровни абстракции? Ну понятно что для убогих ufs, ext и т.п. это необходимо - но ZFS абсолютно другой класс ФС.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #65, #122, #156

6. Сообщение от Аноним (6), 01-Дек-23, 09:43	+8 +/–
Странно, что до сих пор нет исправления ошибки, приводящей к появлению файлов.
Ответить | Правка | Наверх | Cообщить модератору

7. Сообщение от Шарп (ok), 01-Дек-23, 09:48	–9 +/–
>return (B_TRUE); Над сишниками смеются, что они переизобретают строки. Но ситуация ещё хуже: они даже bool переизобретают. Скобочки ещё какие-то поставили при возвращении. Это бездна.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #51, #63, #70

8. Сообщение от Аноним (1), 01-Дек-23, 09:50	+2 +/–
Разве BTRFS не является переработанной и улучшенной версией ZFS?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #50, #85, #110, #129, #172, #317

9. Сообщение от Аноним (9), 01-Дек-23, 09:57	+4 +/–
Если это троллинг то только для тех кто не знает Си хотя бы на начальном уровне. Если нет - учите язык перед тем как писать подобное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #56

11. Сообщение от DEF (?), 01-Дек-23, 10:13	–5 +/–
Сижу на BTRFS с 2012 года и не потерял ни единого бита информации. А на ZFS постоянно жалуются на потерю данных. И баги у этой ФС соотвествующие. Кто вообще запустил миф, что ZFS - надежная ФС? :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #13, #28, #43, #48, #61, #72, #112, #136, #154

12. Сообщение от Аноним (1), 01-Дек-23, 10:17	–1 +/–
Расскажи это Шишкину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #14, #99, #174

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

14. Сообщение от DEF (?), 01-Дек-23, 10:22	–1 +/–
Какому Шишкину? Не тому ли, который грозился выпустить Reiser5, но так и забросил ее, не осилив ее разработку? Мнение теоретиков и прочих Шишкиных меня не интерсует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18

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

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

18. Сообщение от Аноним (1), 01-Дек-23, 10:32	–5 +/–
Да просто Шишкин понял что с такими токсичными людьми как Линукс Торвальдс нельзя иметь никаких дел. Всё равно не оценят, что бы ты ни сделал. Не писать же ещё и своё ядро в дополнение к ФС...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #26, #69

19. Сообщение от Аноним (19), 01-Дек-23, 10:36	+6 +/–
UFS норм FS. Третий день использую,никаких косяков нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #27, #155

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

21. Сообщение от Аноним (21), 01-Дек-23, 10:42	–7 +/–
Чем проще ФС тем надёжней, целостность данных должны обеспечивать аппаратные контроллеры, а то сидят болваны и трясутся чтобы файлы не пропадали, зато с чексуммами всё ок, хаха.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

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

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

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

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

26. Сообщение от DEF (?), 01-Дек-23, 11:01	–2 +/–
Чего? Шишкин - сам токсичен, дозиметр аж зашкаливает при его появлении. Кстати, когда он Reiser5 релизнет, а то перестал коммитить аж 2020 году.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #37

27. Сообщение от нах. (?), 01-Дек-23, 11:02	–1 +/–
mksnap_ffs /home/.snap/delme как, все еще - нет косяков?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #38

28. Сообщение от User (??), 01-Дек-23, 11:02	+/–
Ну я ни на ext2, ни на ext3 данные не терял - какие выводы необходимо сделать из этого факта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #32, #67, #213

29. Сообщение от Аноним (79), 01-Дек-23, 11:04	+8 +/–
они "аппаратные" просто из-за наличия своего процессора, а так тама унутре софт, только поправить его Вы не сможете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #31, #59

30. Сообщение от нах. (?), 01-Дек-23, 11:06	+1 +/–
нееее, это так не работает. Их надо подключить ДО того как понадобилось место в пуле. Иначе не хватит места для добавления места. Оно ТАК работаит. (подозреваю что костылик с zpool attach тоже может слегка побаливать этой же болячкой, но он таки во-первых костылик и ему можно, во-вторых к этому моменту все будет уже давно плохо и в общем-то кто не почесался вовремя - сам виноват)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #190

31. Сообщение от нах. (?), 01-Дек-23, 11:10	+3 +/–
Причем там почти наверняка linoops с mdraid. Т.е. без структурной целостности, с write hole и ресканом всего массива если неудачно выключили. По крайней мере для контроллеров areca это было доказано. Нет, разумеется, исходники этого линукса тебе никто не даст. А ты думал, в сказку попал, и у изготовителей контроллеров какая-то своя, особая магия, а не сп-женый "6ешплатновзятьвзятьвзять" код линукса? Причем самый примитивный и дрянной из возможных, потому что внутри контроллера особо не развернешься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #36, #39, #308

32. Сообщение от менеджер отдела везения (?), 01-Дек-23, 11:10	+2 +/–
вы наняты!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #35, #58

35. Сообщение от Аноним (6), 01-Дек-23, 11:16	+/–
просто дай мильён баксов, а то опять работать заставляешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от Аноним (6), 01-Дек-23, 11:17	+/–
зачем ты выключаешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

37. Сообщение от Аноним (1), 01-Дек-23, 11:19	+/–
Шишкин в отличие от некоторых не имеет привычки показывать средние пальцы и оскорблять всех без разбору. А у вашего божка все плохие, один он белый и пушистый. Нашкрябал кое как своё кривое ядро и ходит тридцать лет короной звенит...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #54, #74, #177

38. Сообщение от Дилетант (?), 01-Дек-23, 11:23	+4 +/–
не знаю, мне больше по душе Flatpak
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

39. Сообщение от crypt (ok), 01-Дек-23, 11:28	+/–
жаль, что фряха перешла на кодовую базу от этих криво-лапковых > Изначально проблему попытались устранить в версии 2.2.1, но исправление оказалось неэффективно. ну что это такое?:(((
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #47, #102, #238

40. Сообщение от crypt (ok), 01-Дек-23, 11:29	+1 +/–
> Изначально проблему попытались устранить в версии 2.2.1, но исправление оказалось неэффективно. все, что нужно знать об опенсорсных авторах этого проекта:((( linux-way all the way^(((
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53

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

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

43. Сообщение от Аноним34 (?), 01-Дек-23, 11:32	–1 +/–
ZFS надежная как скала. OpenZFS не особо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #79

44. Сообщение от penetrator (?), 01-Дек-23, 11:33	+/–
нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

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

46. Сообщение от penetrator (?), 01-Дек-23, 11:37	–1 +/–
это "трухлявое дерево" спасло массив на 40 тб после добавления ошибки в драйвере в ядре, недопустив повреждения данных и отключив массив так что на личном опыте использования могу сказать что ты звездишь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #57, #151

47. Сообщение от нах. (?), 01-Дек-23, 11:41	+/–
> жаль, что фряха перешла на кодовую базу от этих криво-лапковых Да, потому что в ней скорее всего ТОЖЕ есть эта проблема - но патч от open не подойдет, этот кусок кода даже в файле другом. Внешне - похож, так что скорее всего таки да. Внезапно, этот кот - кого нада кот. Либо из самого сана пришел, либо жертва давней-давней переделки parallel zfs (гуглите, не обещаю что найдете) > ну что это такое? не угадали источник, со сложными тяжело воспроизводимыми проблемами это бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

48. Сообщение от КО (?), 01-Дек-23, 11:44	+/–
Ну так поставь на битый HDD всё сразу и потеряешь, лмао
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

49. Сообщение от нах. (?), 01-Дек-23, 11:45	+2 +/–
> ZFS делали серьезные дяденьки для серьезных целей (Конкретно Solaris). Она там обкатана, > все у нее в жизни прекрасно и детских болезней в ней > нет. эммм... но это неточно. > А вот OpenZFS делали другие по другому и с другим подходом. пока не доказано что этот баг не притащен именно из швятаго соляриса. от сирьозных дядек на сириозных щщах Во всяком случае он есть в illumos.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

50. Сообщение от Минона (ok), 01-Дек-23, 11:45	+/–
бтр это недозфс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

51. Сообщение от nox. (?), 01-Дек-23, 11:45	–2 +/–
> Скобочки ещё какие-то поставили при возвращении. Это бездна. Уберите скобочки - можно новую версию анонсировать. Правда, ничего в логике не поменялось, что кто-то при деле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

53. Сообщение от nox. (?), 01-Дек-23, 11:48	+2 +/–
Как будто у ваших авторов хот-фиксы к патчам к исправлениям каждый вторник исправлений эффективны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #103

54. Сообщение от Аноним (54), 01-Дек-23, 11:48	–1 +/–
Судишь по обложке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

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

56. Сообщение от Аноним (-), 01-Дек-23, 11:49	–2 +/–
СИ настолько качественно продуманный язык, что stdbool.h в стандартной библиотеке появился в версии стандарта C99. Т.е через 10 лет после выпуска первого стандарта C89. (Ну... а фигли торопиться)) И примерно через 21 год после выпуска "не-стандарта" K&R.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #60, #92, #98

57. Сообщение от Минона (ok), 01-Дек-23, 11:49	+/–
Сказки опеннета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #62

58. Сообщение от User (??), 01-Дек-23, 11:53	+/–
> вы наняты! Или я просто звИзд0б0л. Или этих данных у меня было 2,5 байта - поставил на виртуалку, выключил\включил - ничего и не потерялось. Или... да много чего "или". Абсолютизировать свой, скорее всего, нерепрезентативный личный опыт - невеликого ума занятие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #73

59. Сообщение от Аноним (21), 01-Дек-23, 12:26	+1 +/–
> они "аппаратные" просто из-за наличия своего процессора, а так тама унутре софт который решает одну задачу но хорошо. А у вас комбайн сиськид это плохо а комбайн зоофс хорошо - это другое, там пингвинами не пахнет! ну кушайте не подавитесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #68, #132, #186

60. Сообщение от Аноним (60), 01-Дек-23, 12:39	+3 +/–
У него по крайней мере есть стандарт :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

61. Сообщение от Аноним (61), 01-Дек-23, 12:41	+/–
Какое количество резервных копий на других физических устройствах с другими файловым системами вы использовали, чтобы не потерять свои данные на btrfs? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #71

62. Сообщение от 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ообщить модератору
Родитель: #57 Ответы: #86

63. Сообщение от Аноним (60), 01-Дек-23, 12:48	–3 +/–
Скобки могли оставить для соблюдения единообразия кода. У Си и так простой и чистый синтаксис, а соблюдение единого стиля кода делает его вообще идеальным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #167

64. Сообщение от Аноним (60), 01-Дек-23, 12:53	+/–
Ну вот, взяли и оперативно исправили, а столько вони было.
Ответить | Правка | Наверх | Cообщить модератору

65. Сообщение от ананим.orig (?), 01-Дек-23, 13:00	–3 +/–
не правильно понимаете сабж > Проблема проявляется при использовании утилит копирования файлов, умеющих определять и оптимизировать пустые области в файлах. умеющих ПРАВИЛЬНО определять в общем и целом новость такая - zfs  НЕ использует внутренние структуры ядра (vfs/итд), а тянет свои ( ещё солярную spl/итд) Но иногда очень хочется использовать удобные новые возможности ядра: > … OpenZFS, начиная с выпуска 0.6.2, поддерживает операции SEEK_HOLE и SEEK_DATA … но не всегда получается кусочно-разрывная интеграция ежа с ужом. как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #76

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

67. Сообщение от DEF (?), 01-Дек-23, 13:03	–1 +/–
Выводы таковы, что ты дилетант. ext2/3/4 могут молча хавать битые данные и продолжать как-бы "работать". Потому что у нех нет механизмов проверки целостности данных (cow, checksums, etc). Данные повреждены, а ФС работает. Надо же какое счастье для тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #75, #83, #159

68. Сообщение от нах. (?), 01-Дек-23, 13:04	–1 +/–
> который решает одну задачу но хорошо. тоже нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

69. Сообщение от 123 (??), 01-Дек-23, 13:05	+/–
А в чём проблема, ZFS вроде как тоже нет в ядре, что ему мешает дорабатывать ReiserFS без включения в ядро?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #101

70. Сообщение от Пряник (?), 01-Дек-23, 13:06	+/–
Хочешь пиши 0 и 1 вместо fal$e/TrUe. А потом мы посмеемся над твоими макросами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

71. Сообщение от DEF (?), 01-Дек-23, 13:06	+/–
Резервные копии на 2 отдельных отсоединяемых HDD и тоже на Btrfs. Дальше что? Делать резервные копии ты должен в любой случае, какая бы супер-пупер надежная ФС ни была бы. Малоли, какой-нибудь клоун внесет в нее какой-нибудь коммит с багами и тю-тю твои данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #105

72. Сообщение от Пряник (?), 01-Дек-23, 13:09	+/–
Сижу на ZFS с 2012 года и не потерял ни единого бита информации. А на btrfs постоянно жалуются на потерю данных. И баги у этой ФС соотвествующие. Кто вообще запустил миф, что btrfs - надежная ФС? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #108

73. Сообщение от Аноним (24), 01-Дек-23, 13:14	–1 +/–
Ну почему же, просто не стоит говорить за всех. Это невеликого ума занятие. Вот лично я испытал куда больше повреждений ext4, чем 100% прочих пользователей ext4. И в процессе экспериментов, и в процессе тестирования, и в процессе использования в самых разных условиях. Даже обнаружил, что существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала, при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт достаточно много времени (ещё и несколько раз перезапустится в процессе). А вот с xfs у меня терялись данные, например, хотя большинство её поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #80

74. Сообщение от DEF (?), 01-Дек-23, 13:15	–1 +/–
Ты от темы не уходи. Шишкин обещал выпустить Reiser5, поливая фекалиями остальные ФС. В итоге слился как позорник, забросив разработку Reiser5 в 2020 году. Сдулся твой Шишкин.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #128, #139

75. Сообщение от Аноним (24), 01-Дек-23, 13:15	–1 +/–
О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя. Так что, идея хешировать только метаинфу вполне здравая. А если данные повредятся по причине неисправности железа, никакие проверки тебе не помогут в итоге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #78, #184, #271

76. Сообщение от ананим.orig (?), 01-Дек-23, 13:19	–1 +/–
в общем интересующимся - `man 2 lseek` > Since Linux 3.1, Linux supports the following additional values for whence: >       SEEK_DATA > … >       SEEK_HOLE > …
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

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

78. Сообщение от DEF (?), 01-Дек-23, 13:25	+/–
Прошивка носителя ничего не знает ни о ФС, ни о данных, ни о метаданных. Это днище. Если на Btrfs данные окажутся битыми, об этом разу будет известно. А ext4/XFS при рассыпании носителя, молча схавают это и дальше молча продолжат работать, как ни в чем ни бывало (silent data corruption). Данные тоже должны хешироваться, что есть в Btrfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #81

79. Сообщение от Аноним (79), 01-Дек-23, 13:27	+1 +/–
И как в скале хранятся данные? Высекаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #104

80. Сообщение от User (??), 01-Дек-23, 13:38	–1 +/–
>[оверквотинг удален] > и в процессе использования в самых разных условиях. Даже обнаружил, что > существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но > потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за > новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала, > при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт > достаточно много времени (ещё и несколько раз перезапустится в процессе). А > вот с xfs у меня терялись данные, например, хотя большинство её > поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся > ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не > стоит. Уф. Оценить "репрезентативность выборки" и "релевантность условий" на основании собственного опыта примерно "нельзя". Как соотносятся "надежность ФС" на физическом сервере в кладовке под нагрузкой "аждымицца!" и надежность той же самой ФС на виртуалке в ЦОДе в составе LB-кластера с автомасштабированием? Да никак не соотносится - в одном случае может регулярно сыпаться с последствиями, в другом - стабильно работать годами. В общем случае - "надежность работы ФС" оказывает не то, чтобы большое влияние на надежность хорошо спроектированной _системы_. Ну вот заглючил на СХД два месяца назад FC-порт - расфигачило SQL-сервер с 10 Тб данных - повлияло это на работу системы? Да нет, автоматом переключилось на другую геореплику, пересоздали виртуалку, залили бэкап, догнали лог - и даже не уверен, переключили ли нагрузку обратно. Чем\как бы тут помогла btrfs, fsck или другая абэвэгэдэ? Не то, чтобы мне было "совсем пофиг" на "надежность ФС" при проектировании ИС - но "примерно пофиг", да. Даже в отдельную строчку модели угроз не выделяем идет в составе "вероятность выхода из строя узла" или как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #82

81. Сообщение от Аноним (24), 01-Дек-23, 13:40	+1 +/–
Только silent data corruption не имеет ровно никакого отношения к повреждению носителя. Которое прошивка замечательно обнаружит после цикла самодиагностики (или даже сразу при обращении). Гораздо большая проблема это повреждение данных в процессе их записи, консистентность обеспечить может быть трудно даже при при наличии политики безумных повторных проверок. И файловые системы с нездоровым оверхэдом тут не особо помогут (а при совмещении с "лучшими практиками" ситуация становится ещё более абсурдной). Способность бтрфс сдохнуть и невозможность восстановления хоть чего-нибудь при серьёзных повреждениях, фактически множит на нет все её преимущества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #95

82. Сообщение от Аноним (24), 01-Дек-23, 13:44	+1 +/–
Я конечно понимаю желание отдельных индивидов игнорировать проблемы, заваливая их деньгами (и резервированием), но, что случится, когда автоматика подведёт? А это произойдёт, рано или поздно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #84

83. Сообщение от User (??), 01-Дек-23, 13:52	+1 +/–
> Выводы таковы, что ты дилетант. ext2/3/4 могут молча хавать битые данные и > продолжать как-бы "работать". Потому что у нех нет механизмов проверки целостности > данных (cow, checksums, etc). Данные повреждены, а ФС работает. Надо же > какое счастье для тебя. Да нет, это вы на локалхосте не подозреваете, что data integrity может контролироваться как на уровне выше, так и ниже ФС. Объясните, нахрена мне например развертывать ноды кассандры поверх btrfs с её мейджик чексуммами, м? Вот чтобы что? А кластеризованный postgres развернутый поверх raid6 в btrfs нуждается? Ох, бида - бегу переделывать. Заодним на бэкапах сэкономлю! Счастье то какое! Спасибо, друк!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #97, #273

84. Сообщение от User (??), 01-Дек-23, 13:55	+/–
> Я конечно понимаю желание отдельных индивидов игнорировать проблемы, заваливая их деньгами > (и резервированием), но, что случится, когда автоматика подведёт? А это произойдёт, > рано или поздно. Ну, примерно то же, что и в этом тредике с ZFS и чексуммами, которые вот беда-то! Внизапна! нипамагли, хотя казалось бы. Пойду бэкап поднимать - а вам с верой в "надежные-фс-и-чексуммы" ну... удачи, что ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #87, #270

85. Сообщение от Шарп (ok), 01-Дек-23, 13:58	+/–
> Разве BTRFS не является переработанной и улучшенной версией ZFS? Является. Но файнбои зфс не унимаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #311

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

87. Сообщение от Аноним (24), 01-Дек-23, 14:12	+/–
Бтрфс всё же имеет определённые преимущества. Если говорить о хешировании, то это незначительный сайд-эффект, однако, именно он позволяет обнаружить проблему раньше конкурентов (и во многих случаях избежать потери данных). Могут быть даже ситуации, когда при разрушении проедет гораздо дольше конкурентов (сохраняя фактическую исправность). До тех пор, пока по какой-либо причине не посыпется сама фс, тут уже как повезёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #94

88. Сообщение от Аноним (227), 01-Дек-23, 14:15	+/–
0.6.2 -- это порядка 10 (десяти) лет назад. Поймали на Gentoo, потому что там любят крутить все ручки сразу -- это к вопросу "зачем нужна Gentoo, когда есть RHEL, Debian и болгеносы на любой вкус?" Как быть с ответом на вопрос "сколько ещё осталось подобных неполных проверок?" (и не только в ZFS) -- не понятно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #123

90. Сообщение от Tron is Whistling (?), 01-Дек-23, 14:24	+1 +/–
Сквозная(с) целостность(tm). Сначала побьёт данные, потом запишет. С зияющей целостностью. С чем всех фанатиков и поздравляю.
Ответить | Правка | Наверх | Cообщить модератору

91. Сообщение от penetrator (?), 01-Дек-23, 14:31	–1 +/–
именно оно и спасло, при загрузке старого ядра данные остаются целыми, но если произвести модификацию данных на новом ядре, то портятся, все ext4 разделы побились, а BTRFS не дал этого сделать, проверив чексумы, сохранив свою целостность так что давай дальше БибаБоба смеши людей
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #96, #152, #180, #318

92. Сообщение от Big Robert TheTables (?), 01-Дек-23, 14:42	+2 +/–
С это и есть программирование в чистом виде - все эти параметры на стеке, условные переходы, всё это и есть разработка без уровня абстракций. То, что тебе понадобилось побитово делать маркеры успеха в виде булевских переменных, да и еще под это почему-то затребован отдельный тип данных - это уже абстракция, пандус у входа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #227

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

94. Сообщение от User (??), 01-Дек-23, 14:59	+/–
> Бтрфс всё же имеет определённые преимущества. Если говорить о хешировании, то это > незначительный сайд-эффект, однако, именно он позволяет обнаружить проблему раньше конкурентов > (и во многих случаях избежать потери данных). Могут быть даже ситуации, > когда при разрушении проедет гораздо дольше конкурентов (сохраняя фактическую исправность). > До тех пор, пока по какой-либо причине не посыпется сама фс, > тут уже как повезёт. Да - но так же и определенные недостатки в виде пригодности COW-семантики к ряду нагрузок. Плюс, если говорить за энтерпрайз и коммерческий саппорт - то тут будут играть роль дефолты базовой ОС и непосредственные рекомендации вендора ПО. Опять же, общий дизайн системы... я более, чем уверен, что facebook сделал правильный выбор... для facebook'а, и совершенно убежден, что пытаться повторять куски его технических решений у себя мне не следует :). Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #214

95. Сообщение от DEF (?), 01-Дек-23, 15:05	+/–
Поврежденные данные должны чекаться на уровне ФС. При записи должна быть сгенерирована хэш-сумма и потом периодически эта хэш-сумма должна сравниваться со сгенерированной хэш-суммой при скрабе. Прошивка тут ничем не поможет. Она не знает ни о ФС и тем более не имеет к внутренностям ФС. Btrfs давным-давно надежно и не дохнет на нормально работающем железе. А если и сдохнет, то данные восстанавливаются из бэкапа. Бэкапы надо делать в любом случае, даже если создадут супер-пупер надежную ФС. Эта ФС не спасет от пожара в хате или от сдохшего БП, который пропустит 220 вольт и сожгет все носители.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #113

96. Сообщение от Минона (ok), 01-Дек-23, 15:07	+1 +/–
> а BTRFS не дал этого сделать, проверив чексумы, сохранив > свою целостность А ранее ты писал: > недопустив повреждения данных и отключив массив Ы? > так что давай дальше БибаБоба смеши людей Аха, давай смеши дальше, сказочник опеннета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #137

97. Сообщение от DEF (?), 01-Дек-23, 15:11	+/–
То что выше - костыли. То что ниже - не data integrity, а дно, ибо аппаратура не имеет доступа к внутенним кишкам ФС и ее структурам данных. Ты тут ляпнул про PostgreSQL (которая, у меня крутится на Btrfs с отключенным COW). Ну так вот, в БД целостность данных контролируется и обеспечивается этой же самой БД, а не делегируется ФС и еще каким-нибудь днищенским сервисам. По такому принципу должна наботать и ФС, ибо она по сути тоже БД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #114, #143

98. Сообщение от анон (?), 01-Дек-23, 15:29	+/–
Че там по расту? Уже придумали и описали единственную имплементацию и реализацию вектора? Нет? Т.е. очередная обнова сине-розовых ленточных должна сломать поддержку в RO прошивке нескольких лямов готовых модемов у увожаемых партнеров в костюмах от гуччи? Покормил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

99. Сообщение от Аноним (106), 01-Дек-23, 15:33	+/–
Шишкин, как раз, сомневается в её надёжности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

100. Сообщение от Аноним (106), 01-Дек-23, 15:36	–1 +/–
>Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных. А, ясно, жалуются фрибздуны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #168, #335

101. Сообщение от Sw00p aka Jerom (?), 01-Дек-23, 15:38	+/–
>А в чём проблема басня Крылова - Л,ЩиРак :) пс: "а возу все нет ходу!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #106

102. Сообщение от Аноним (106), 01-Дек-23, 15:40	+/–
Котиков?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

103. Сообщение от Tron is Whistling (?), 01-Дек-23, 15:41	+/–
Там даже хуже - вообще не поглядеть, чего в очередной раз нафиксили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #125, #185

104. Сообщение от Аноним (106), 01-Дек-23, 15:41	+/–
Надёжная только в режиме использования, как ПЗУ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

105. Сообщение от Аноним (24), 01-Дек-23, 15:42	+/–
Вот это >2 отдельных отсоединяемых HDD и тоже на Btrfs называется "держать все яйца в 1 корзине". и фактически их нет, зао ты успешно тратишь время ну глупости. Толку от тех копий, если они рассыпаться будут при подключении, например? Не надо тут утверждать, что этого не случится. Чтобы этого не случилось, надо хотя бы знать основы криминалистической работы с данными, и регулярно их практиковать. Но только когда у тебя на руках десятки терабайт данных, которые срочно надо восстановить и привести в норму, на заботы о безопасности в любом случае просто нет времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #118

106. Сообщение от Аноним (106), 01-Дек-23, 15:44	+/–
А кто там в разные стороны тянет? Там только Шишкин с помошниками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #107

107. Сообщение от Sw00p aka Jerom (?), 01-Дек-23, 16:00	+/–
> А кто там в разные стороны тянет? Там только Шишкин с помошниками. мораль сего комента такова, что согласованность в разработке должна быть, выше кто-то там жаловался, почему "поделие" (опензфс) нарушает уровни абстракции и т.д., а все почему? -> "вроде как тоже нет в ядре"! пс: ток не будем раздувать холивар про "кто, под чью дудку плясать должен" - мораль -> "когда в товарищах согласья нет"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

108. Сообщение от Ананий (?), 01-Дек-23, 16:01	+/–
не трать время на срывателя покровов, он так и не понял, что ошибка выжившего распространяется на обе стороны и с упорством кра5ногла3ика продолжает хвалить свое болото.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #119

109. Сообщение от Аноним (-), 01-Дек-23, 16:03	–2 +/–
Прекрасный пример того, что бывает когда гнутики пытаются скопировать что-то рабочее. И оно "как-то" даже работает. Но не всегда и не у всех. А если именно у тебя не работает, то УМВР и иди "пердолься с конфигами"(с) Так и со всем остальным. Ну вроде скопировали, но то тут косяк, то там косяк.
Ответить | Правка | Наверх | Cообщить модератору

110. Сообщение от Аноним (110), 01-Дек-23, 16:17	+1 +/–
Не шутите так. Даже близко нет!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

112. Сообщение от Аноним (110), 01-Дек-23, 16:21	+/–
Вы не теряли, а я терял. Даже трижды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

113. Сообщение от Аноним (24), 01-Дек-23, 16:24	+/–
Кроме как добавить энтропии во вселенной этот подход ничего не несёт. Бесполезные операции ради бесполезных операций. Хотя, если нет возможности задействовать самодиагностику дисков (к примеру, при подключении через китайский переходник), то, может быть. >на нормально работающем железе на нормально работающем железе никогда не понадобится ничего сложнее ext4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #134, #358

114. Сообщение от Аноним (110), 01-Дек-23, 16:28	+/–
Сейчас бы крутить PostgreSQL на BTRFS...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

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

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

118. Сообщение от DEF (?), 01-Дек-23, 16:48	+/–
У меня Btrfs уже 11 лет не сыпается ни разу, с какой стати она должна рассыпаться сразу на всех 3 копиях одновременно? :) Типо, если у меня каждая копия будет с разными ФС, это спасет от рассыпания? Диверсификция - это дно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #121

119. Сообщение от DEF (?), 01-Дек-23, 16:50	–2 +/–
Про ошибку выжившего иди Фейсбуку (миллионы серваков на Btrfs) рассказывай, а в будущем и Red Hat, когда на RHEL будет Btrfs по-умолчанию. Сейчас Btrfs по-умолчанию в Федоре. Ты в курсе, что это значит? Бгг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #272

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

121. Сообщение от Аноним (24), 01-Дек-23, 16:54	+/–
Спасёт, если причина в баге ядра или в баге специфического юзеспейса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #140

122. Сообщение от all_glory_to_the_hypnotoad (ok), 01-Дек-23, 17:17	+/–
Ну ты бы прежде чем писать заумную ерунду посмотрел бы что написано в тексте новости, а из него догадался бы сходить в man lseek чтобы понять куда конкретно лезет cp. По крайней мере ддя ценителей уровней абстракции эта операция должна быть посильной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

123. Сообщение от all_glory_to_the_hypnotoad (ok), 01-Дек-23, 17:33	+2 +/–
Gentoo нужнен хотя бы чтобы не тащить весь крап, который понапихали в дистрибутивы симулянты бурной деятельности из RH и сказочники из Debian
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #124

124. Сообщение от нах. (?), 01-Дек-23, 17:35	+/–
а чтобы без конца пересобирать go
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

125. Сообщение от пох. (?), 01-Дек-23, 17:36	+/–
Ты не захочешь это увидеть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #146

126. Сообщение от EuPhobos (ok), 01-Дек-23, 18:06	+/–
Ого, так скоро вторая новость про повреждение данных в ZFS
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #127, #141

127. Сообщение от Аноним (-), 01-Дек-23, 18:19	+/–
Не в ZFS, а в OpenZFS. Это очень важная разница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #147

128. Сообщение от Аноним (128), 01-Дек-23, 18:20	–1 +/–
Он не сдулся, у него саббатикал. Понимаешь, устал он очень. Сперва писал код, потом давал интервью, потом думал много. Потом времени не было. Ну и утомился в конце концов. Но ты погоди немного, вот отдохнёт и всем покажет! Если время будет, конечно. Сам знаешь как оно бывает со всеми этими интервью, славой, известностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

129. Сообщение от лютый арчешкольник... (?), 01-Дек-23, 18:21	–1 +/–
>Разве BTRFS не является переработанной и улучшенной версией ZFS? улучшенной нет. в бтре нет шифроавния и рэйды 5-6 итд кривые. но если ничего из этого тебе не нужно, то бтрфс конечно тортее. особенно на oracle linux (у дебианов-бубунтофф понятное дело экспертизы нет)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #176

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

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

132. Сообщение от Аноним (128), 01-Дек-23, 18:28	+/–
> который решает Нет > одну задачу Тоже нет > но хорошо И снова нет. Я понимаю, конечно, что на локалхосте с LA 0.0 не повозишься особо с такими контроллерами, но в интернете-то хотя бы почитать или старших товарищей спросить не судьба?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

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

134. Сообщение от Аноним (134), 01-Дек-23, 18:38	+/–
На большом масштабе подход с чексуммами срабатывает: https://www.cs.toronto.edu/~bianca/papers/fast08.pdf https://indico.cern.ch/event/13797/contributions/1362288/att... Вопрос в оправданности в конкретном случае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

136. Сообщение от Аноним (136), 01-Дек-23, 18:53	+/–
Противоположнпая ситуауия: потерял целый раздел на бтрфс, с тех пор не пользуюсь, а на зфс все хорошо. Хорошо что тебе повезло
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

137. Сообщение от penetrator (?), 01-Дек-23, 18:58	+/–
массив был перемантирован в режиме для чтения, потому что операции записи были невозможны и это все было выполненно ядром и BTRFS автоматически так что не так, Куклачев?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #158

139. Сообщение от Аноним (1), 01-Дек-23, 19:12	+1 +/–
Возможно Шишкину просто надоело заниматься альтруизмом и он предпочёл посвятить себя чему-то более полезному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #175

140. Сообщение от DEF (?), 01-Дек-23, 19:20	+/–
Я не говорил, что буду бэкап подключать на том же ядре, на котором крякнулся основной носитель)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #142

141. Сообщение от Аноним (1), 01-Дек-23, 19:21	+/–
Обе новости касаются одного и того же бага, так что не считается. Баг можно исправить, а вот архитектурную ущербность btfrs уже ничем не вылечить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

142. Сообщение от Аноним (24), 01-Дек-23, 19:39	+/–
Слишком много "если" и никаких гарантий, что на другом ядре и ОС этого не случится. Даже если это старое ядро, новую проблему легко портируют и на него. Вон в ext4 баги десятилетиями никто не исправляет https://github.com/torvalds/linux/commit/b1489186cc8391e0c1e...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #338

143. Сообщение от User (??), 01-Дек-23, 20:21	+/–
> То что выше - костыли. То что ниже - не data integrity, > а дно, ибо аппаратура не имеет доступа к внутенним кишкам ФС > и ее структурам данных. Ты тут ляпнул про PostgreSQL (которая, у > меня крутится на Btrfs с отключенным COW). Ну так вот, в > БД целостность данных контролируется и обеспечивается этой же самой БД, а > не делегируется ФС и еще каким-нибудь днищенским сервисам. По такому принципу > должна наботать и ФС, ибо она по сути тоже БД. Ага. То, что выше - костыли, postgres - выше ФС, postgres это хорошо, по этому ФС должна быть как postgres. "Л" - логика! Я понял. Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что в postgresql чексумминг на уровне страниц надо включать отдельно? Впрочем, о чем это я, право слово. "Поздравляю тебя, Шарик - ты..."(ц) Вопросы _когда именно_ проверяются включенные чексуммы в postgresql, что происходит при выполнении резервного копирования (С мастера, кстати - или с реплики?), поддерживается ли этот сетап энтепрайз-бэкапилками и тэ дэ - оставляю для самостоятельного изучения. Рекомендую провести его ДО факапа, а не после - но тут уж хум хау.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #359

146. Сообщение от Tron is Whistling (?), 01-Дек-23, 20:43	+/–
После полистывания утекших исходников - ну, да видимо. Не, там есть интересное, но в общем и целом у меня во-первых это жизни разобрать не хватит, во-вторых после потребуется бригада психиатров...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

147. Сообщение от Tron is Whistling (?), 01-Дек-23, 20:44	–1 +/–
Так а первый по факту мёртв.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

150. Сообщение от Аноним (151), 01-Дек-23, 20:49	–1 +/–
Может тут кто мне объяснит, зачем нужен zfs в проде? А то в прошлом треде было "у меня торрентокачалка на zfs, поэтому это продакшон!!!111"
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #153, #206

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

152. Сообщение от Аноньимъ (ok), 01-Дек-23, 20:53	–1 +/–
> все ext4 разделы побились, а BTRFS не дал этого сделать BTRFS спас EXT4 разделы? Что я читаю?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

153. Сообщение от Аноньимъ (ok), 01-Дек-23, 21:01	–1 +/–
За шкафом? Зачем система хранения данных с управлением томами защитой от битрота и вот этим вот всем для хрениния данных? Ну хрен его знает. Дай подумаю. Ну может чтобы хранить данные и управлять этим всем ну там целостность тома вот это всё. Блин. Подожди. Я понял. Чтобы хранить данные! Для этого нужна система хранения! Или нет? Я запутался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #160, #161

154. Сообщение от Элита_Южного_Бутово (?), 01-Дек-23, 21:29	+/–
Выбор мужчин в свитере: кора дуба и ext4. Хватит лить смузи в монитор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

155. Сообщение от Аноним (-), 01-Дек-23, 21:36	–1 +/–
> UFS норм FS. Третий день использую,никаких косяков нет. Ну тогда bcachefs просто эталон стабильности. Уже неделю работает и никаких особых траблов вроде. Только еще умеет сильно поболее этого unknown flying sh...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #163

156. Сообщение от Аноним (-), 01-Дек-23, 21:38	+/–
> Объясните мне - зачем cp лезет в структуру файловой структуры нарушая уровни абстракции? > Ну понятно что для убогих ufs, ext и т.п. это необходимо - но ZFS абсолютно другой класс ФС. А она - не лезет. И лишь взаимодействует через апи файловых операций. Со временем и вот такие, для оптимизация операций появились. А ZFS и лоханулся в их реализации. Заметив сильно опосля, когда это coreutils в массы принесли. Так все просто и банально. Но вы там не расслябляйтесь, кроме coreutils есть и другие программы - вот теперь и гадайте у кого из вас данные побитые. Хотя там детектор есть, но его методы работы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #316

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

158. Сообщение от Tron is Whistling (?), 01-Дек-23, 21:51	+/–
> массив был перемантирован в режиме для чтения, потому что операции записи были > невозможны > и это все было выполненно ядром и BTRFS автоматически > так что не так, Куклачев? И давно errors=remount-ro отменили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #195

159. Сообщение от Tron is Whistling (?), 01-Дек-23, 21:54	+/–
Ну вот ZFS нули в файлах не хавала, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

160. Сообщение от Tron is Whistling (?), 01-Дек-23, 21:57	+/–
> Зачем система хранения данных с управлением томами защитой от битрота и вот > этим вот всем для хрениния данных? Не бывает в современных системах битврота. Бывают куда более масштабные повреждения, и тут уже что ZFS, что чёрт лысый - всё равно идти за бэкапом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #169, #173, #192, #203, #247

161. Сообщение от Аноним (161), 01-Дек-23, 22:07	–1 +/–
Я с тобой говорить не собираюсь, ты профан и на этом сайте все это знают. СХД - это не ФС и никакого отношения не имеет. Зачем ты лезешь в диалог, если не разбираешься?? Белый шум какой-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #162, #170

162. Сообщение от Аноним (161), 01-Дек-23, 22:09	+/–
Сорян, реально бесят такие люди, в каждой бочке затычка. Ну не разбираешься - ну помолчи. Нет, надо сказать какую-то ересь. Зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

163. Сообщение от Tron is Whistling (?), 01-Дек-23, 22:19	+2 +/–
/dev/null - недостижимый идеал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #171

167. Сообщение от Аноним (167), 01-Дек-23, 22:56	–2 +/–
> Скобки могли оставить для соблюдения единообразия кода. У Си и так простой > и чистый синтаксис, а соблюдение единого стиля кода делает его вообще > идеальным. #define MAP_LIST(f, ...) EVAL(MAP_LIST1(f, __VA_ARGS__, ()()(), ()()(), ()()(), 0)) ... volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #241

168. Сообщение от Аноним (167), 01-Дек-23, 23:02	+/–
>>> Сижу на BTRFS с 2012 года и не потерял ни единого бита информации. А на ZFS постоянно жалуются на потерю данных. >>Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. А на BTRFS остоянно жалуются на потерю данных. > А, ясно, жалуются фрибздуны. А, ясно, опять нам пишут Этодругое-ниды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

169. Сообщение от Аноним (169), 01-Дек-23, 23:07	+/–
Как еще бывают. Вот я на днях словил. samsung evo 870 выпуска 2021 года, как оказалось, имеет серьезные проблемы качества. В смарте неожиданно выплывают битые блоки, и это на практически неюзанном ссд. Хорошо zfs пожаловался при очередном скрубе, ну и подправил заодно. Но ссд менять все равно конечно. Вроде пишут что самсунг охотно меняет их по гарантии, без особой огласки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

170. Сообщение от Аноньимъ (ok), 02-Дек-23, 00:11	+1 +/–
> СХД - это не ФС и никакого отношения От оно как. Оказывается для хранения данных никаких ФС ненужно, и к хранению данных Файловые Системы никакого отношения не имеют. Аноним, ты сегодня на коне! ZFS, кстати, это не только лишь ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #193, #205

171. Сообщение от Аноним (-), 02-Дек-23, 00:14	+2 +/–
> /dev/null - недостижимый идеал Ну, блин, с него виртуалка не хочет грузиться что-то. И с /dev/urandom кстати тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

172. Сообщение от Аноним (-), 02-Дек-23, 00:15	+1 +/–
> Разве BTRFS не является переработанной и улучшенной версией ZFS? Это вообще совсем разные кодовые базы - и структуры ФС имеют мало общего. Единственное что хоть как-то пересекается это общая идея CoW.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

173. Сообщение от Аноньимъ (ok), 02-Дек-23, 00:19	+/–
Бывает. Не настолько хороши алгоритмы коррекции в дисках. Не говоря уже что там ошибка может много где залезть, в том числе в ОЗУ системы. Диск вполне себе может выдать неконкретный блок. И это случается даже на небольших объёмах. А когда у вас петабайты данных, то вероятность словить такое 100%. Ну и вообще чексуммы не только от этого защищают. Между единичным бит ротом и смертью половины дисков в пуле - есть много промежуточных состояний.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #187

174. Сообщение от Аноним (-), 02-Дек-23, 00:19	+/–
> Расскажи это Шишкину. Ну так пользуйтесь ФС от Шишкина, если это для вас лучше работает. Но reiser3 из майнлайна кажется скоро вылетит как заброшенный код, reiser4 там никогда и не было, а reiser5 это вообще vaporware какое-то где господа лучше всех знают как надо, но - толком не могут определиться как же это - так что оно вообще что-то этакое, существующее в основном на бумаге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #188

175. Сообщение от Аноним (-), 02-Дек-23, 00:23	–1 +/–
> Возможно Шишкину просто надоело заниматься альтруизмом и он предпочёл посвятить себя чему-то > более полезному. Поэтому будущее и будет принадлежать упрямому Кенту. А этот господин займется очередной НЕХ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

176. Сообщение от Аноним (-), 02-Дек-23, 00:29	–2 +/–
>>Разве BTRFS не является переработанной и улучшенной версией ZFS? > улучшенной нет. в бтре нет шифроавния и рэйды 5-6 итд кривые. но > если ничего из этого тебе не нужно, то бтрфс конечно тортее. У него менеджмент гораздо круче. Ну так, мелочи какие. Можно перегриать почти все. На ходу. И это даже относительно безопасно в силу природы CoW. И непозорно работает даже без подпора гигазами рамы, в отличие от ZFSа - который сам по себе редкостный тормоз без ломовых кешей в оперативе. И вообще - btrfs намного универсальнее и не такой энтерпрайзный пережорок как ZFS. Может DUP на ноутбучном диске например, переживая бэды, и при этом снапшотя систему и не выжирая гигазы на кеши. А с ZFS что в таких конфигах ловить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

177. Сообщение от Аноним (-), 02-Дек-23, 00:39	+/–
> Шишкин в отличие от некоторых не имеет привычки показывать средние пальцы и > оскорблять всех без разбору. А у вашего божка все плохие, один > он белый и пушистый. Нашкрябал кое как своё кривое ядро и > ходит тридцать лет короной звенит... В отличие от шишкина он то на гора результат выдает, каждые несколько месяцев, оправдывая ожидания всех кто ему и делегировал звон короной, совершенно добровольно. За это его звон короной можно и потерпеть - в отличие от всякого пустозвонства БЕЗ релизов чего-то полезного и юзабельного как итог. В конечном итоге засчитывается результат. И у шишкина результаты его жизнедеятельности - они в чем проявляются? И почему это круто, хорошо и правильно? Впрочем если вдруг - вы в вашем праве использовать его ФС, разумеется. Кто же вам это запретит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

178. Сообщение от Аноним (-), 02-Дек-23, 00:51	–4 +/–
> Чё там, на 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ообщить модератору
Родитель: #157 Ответы: #179, #181

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

180. Сообщение от Аноним (-), 02-Дек-23, 00:55	+1 +/–
> именно оно и спасло, при загрузке старого ядра данные остаются целыми, но > если произвести модификацию данных на новом ядре, то портятся, все ext4 > разделы побились, а BTRFS не дал этого сделать, проверив чексумы, сохранив > свою целостность > так что давай дальше БибаБоба смеши людей Чексумы забавная штука - они "до кучи" зарубают множество багов железа и софта. А фаны EXT4 - предпочитают следствия из законов Мерфи - как то: "если вам кажется что дела идут хорошо, возможно вы просто чего-то не заметили".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #182, #183

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

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

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

184. Сообщение от Аноним (-), 02-Дек-23, 01:07	+/–
> О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя. ...которая у SSDшников, флешек, sd карт и прочей флешатины зачастую совсем не прочь отгрузить какую-то левую труху, особенно при приближении к лимиту записей. Очень доставляет любителям bcache (не путать с bcachefs), которые это юзают в нагруженых конфигах ради перфоманса - и потому нередко приближаются к лимиту записей даже с энтерпрайзными девайсами. После чего - ну, btrfs то красиво орет в логи на csum failed заранее, они вылезают с вопросами, и если не очень тупят - успевают заменить девайс(ы) ДО того как все разлетится окончательно. И по крайней мере не могут сказать что их не предупреждали о факапах их хардвара. А вот фанов EXT4 и прочих XFS в этом месте по сценарию ВНЕЗАПНО зашибает роялем. И они вылезая из дырки удивленно - что за фигня? Где мои данные?! А там раз - труха на половине файлухи уже. > Так что, идея хешировать только метаинфу вполне здравая. Ну может тогда данные и хранить не стоит? Раз уж они не нужны. Ext4 все равно о их сохранности не парится, особенно без полного журнала (который тормозной как улитка из-за дублирования записей). > А если данные повредятся по причине неисправности железа, никакие проверки > тебе не помогут в итоге. 1) Таки помогают. 2) Прекрасно чинят битую копию из избыточной. 3) Это еще и дружественно к ремапу сбойных секторов фирмварой накопителя. А ext4 будет насиловать нечитаемый сектор до упора. Данные же хочется, больше взять неоткуда, а запись в этот сектор чтобы его еще и ремапнуть - можно не дождаться. Скорее, если не повезет - можно искусственно догнать read error rate до потолка, накопитель решит что ему плохо, уйдет в safe mode - и вот тут вам уже СЮРПРИЗ! И да, все это шоу - из-за 1 гребаного бэда который можно было ремапнуть и забыть о нем. И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. И чего? Какая правильная в результате? С чексумами то ответ тривиальный. А сделать из EXT4 райд с чексумами ну не то что совсем нельзя, но админ предпочтет застрелиться при нужде это менеджить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #245

185. Сообщение от Аноним (-), 02-Дек-23, 01:11	+/–
> Там даже хуже - вообще не поглядеть, чего в очередной раз нафиксили. Зато фороникс развлекается бенчами - и в очередном из убунта делает 11 на 20% в среднем. Хотя если бенчить файлухи, с пристрастием - там наверное и 200% можно получить. Если не 300%. Конечно не в пользу виндов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

186. Сообщение от Аноним (-), 02-Дек-23, 01:17	+/–
>> они "аппаратные" просто из-за наличия своего процессора, а так тама унутре софт > который решает одну задачу но хорошо. Мне как-то виндочка драйверок обновила на таком. Заодно и фирмвару рефлешнуло, чего теряться?! А весь массив на этой чуде каааак дал дуба! Вечер вторника сразу перестал быть томным...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #309

187. Сообщение от Аноним (21), 02-Дек-23, 02:51	–2 +/–
> Не настолько хороши алгоритмы коррекции в дисках. Не говоря уже что там ошибка может много где залезть, в том числе в ОЗУ системы. > Ну и вообще чексуммы не только от этого защищают. диски не с помойки, PCIe c FEC, кэши и ОЗУ с ECC - вот это защищает, а от зоофс с чексуммами пользы не больше чем от бесконтактного ушу, только нервы успокаивает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #194, #208

188. Сообщение от Аноним (1), 02-Дек-23, 08:12	+/–
Когда выйдет reiser5, тогда и буду смотреть что это такое, а пока меня и ZFS устраивает. Лучше ещё ничего не придумали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #189

189. Сообщение от Аноним (-), 02-Дек-23, 09:43	+/–
> Когда выйдет reiser5, тогда и буду смотреть что это такое, а пока > меня и ZFS устраивает. Лучше ещё ничего не придумали. Не хочу показаться скептиком, но по моему Шишкин лучше всего умеет рассказывать как (не)надо. А вот создавать себе команды или релизить файлухи в юзабельном виде - кажется, не его. Так что вот, доморощенный Кент сделал академика как с куста. Как и предсказывалось сколько там времени назад. Приятно быть провидцем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

190. Сообщение от Аноним (-), 02-Дек-23, 09:46	+/–
> нееее, это так не работает. Их надо подключить ДО того как понадобилось > место в пуле. Иначе не хватит места для добавления места. Оно > ТАК работаит. Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень хорошо :) > (подозреваю что костылик с zpool attach тоже может слегка побаливать этой же > болячкой, но он таки во-первых костылик и ему можно, во-вторых к > этому моменту все будет уже давно плохо и в общем-то кто > не почесался вовремя - сам виноват) Ну а btrfs'ники свои проблемы решили, как обычно. И кент конечно тоже стырил решение. Довольно предсказуемо, я б сказал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #220

191. Сообщение от Аноним (-), 02-Дек-23, 09:50	+/–
> Расскажи это Facebook (крутит Btrfs на миллионах серваков 24/7), Synology (юзает Btrfs > в своих NAS), Fedora (Btrfs по умолчанию) ну и в будущем, > Red Hat (Все из Федоры идет в RHEL после обкатки). Что, редхат таки устал пыжиться прикрутить эрзац-подобие scrub к XFS? Там где-то в процессе аж майнтайнер слинял. Вооооон там, с btrfs'никами отвисает теперь. Популярное направление стало - почему-то из редхата все блочники-файлушники куда-то в сторону btrfs драпают. Тенденция, однако!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

192. Сообщение от пох. (?), 02-Дек-23, 11:34	+3 +/–
> Не бывает в современных системах битврота. тем не менее - дефективные диски и контроллеры - еще как бывают. И лучше иметь возможность узнать об этом вовремя и выбросить без потерь, чем узнать когда чудо-ext4 заявит что журнальчик того-сего и неплохо бы тебе, васян, ручками полезть в консольку. Мне вот буквально на днях казалось бы супернадежное ентер-прайсное сочетание хитачивской схд и вмвари так принесло пое6аться. Как тебе полсотенки (к счастью отвалилась только пара сторов а не все сразу) систем вывалившихся в у кого бизибокс, у кого просто рак, потомушта "нишмалгла я тут твою ext4, какие-то там orphan nodes, потрахайся-ка ты вручную мальчик? Вместо утренней рюмки портвейна,блжад. А те у кого была zfs - после ресета поворчали и сами поднялись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #198

193. Сообщение от пох. (?), 02-Дек-23, 11:37	+1 +/–
ну volume management в linoopsе у нее своеобразный. Я не проверял свежие версии, но то что я прочитал по поводу неработы zpool -e меня слегка расстроило. А когда я увидел КАК они это полезли чинить - мне что-то и вовсе расхотелось дальше копать. resize2fs тем временем - never fails.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

194. Сообщение от Аноним (194), 02-Дек-23, 12:20	+/–
Какие вы диски используете и какой у них заявленный BER?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #196

195. Сообщение от penetrator (?), 02-Дек-23, 12:23	+/–
>> массив был перемантирован в режиме для чтения, потому что операции записи были >> невозможны >> и это все было выполненно ядром и BTRFS автоматически >> так что не так, Куклачев? > И давно errors=remount-ro отменили? так EXT4 думал что у него все хорошо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #199, #332

196. Сообщение от Аноним (21), 02-Дек-23, 12:47	+/–
> Какие вы диски используете и какой у них заявленный BER? странно что вас BER интересует а не UBER, стандарт допускает 1 некорректируемую ошибку на ~1.1 петабайт для SSD корпоративного класса, к слову для домашних дисков на которых вы храните свою критически важную порнуху UBER допускается в 10 раз хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

198. Сообщение от Tron is Whistling (?), 02-Дек-23, 13:34	+/–
> А те у кого была zfs - после ресета поворчали и сами поднялись. Конечно поднялись, там кроме ZFS вообще что-то было, учитывая, как оно с памятью работает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #204

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

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

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

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

203. Сообщение от Аноним (110), 02-Дек-23, 14:09	+/–
Неужели так нравится позориться? Боже, мой Господь Бог...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #235

204. Сообщение от нах. (?), 02-Дек-23, 14:30	+1 +/–
например там база заббикса была (далеко не оптимальная задачка для zfs). И никаких ручных действий не потребовала. Но поскольку убунту трагически сложно ухитриться целиком взгромоздить на zfs- ее системный диск был ext4. И его потребовалсь пнуть вручную чтобы хотя бы загрузиться дальше (rescue) - не смотря на чудо-журнал и прочие модные подпорки под идеей сталетней давности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #211, #212

205. Сообщение от all_glory_to_the_hypnotoad (ok), 02-Дек-23, 14:43	+/–
Вообще да, к СХД имеет отдалённое отношение. И ZFS местами используют для этих целей не как ФС, потому что это нечто не только ФС
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

206. Сообщение от all_glory_to_the_hypnotoad (ok), 02-Дек-23, 14:44	+/–
Это же зависит от вида прода. Для некоторого прода, например, нужны только сырые обычные диски
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #221

208. Сообщение от Аноньимъ (ok), 02-Дек-23, 14:49	+/–
ECC не защищает 100%, а только минимизирует до терпимого. > а от зоофс с чексуммами пользы не больше чем от бесконтактного ушу, только нервы успокаивает. Люди скрупулёзно считали математику и внедряли необходимые решения, а у вас пользы нет. Ну нет так нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #268

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

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

211. Сообщение от Аноним (110), 02-Дек-23, 15:17	+/–
А в чем сложность?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #218

212. Сообщение от Tron is Whistling (?), 02-Дек-23, 15:43	+/–
Трёхтерабайтная база заббиха живёт уже лет 10 на ext4, и ни разу не чихнула.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #219

213. Сообщение от Аноним (110), 02-Дек-23, 15:54	+/–
Допустим, полностью вы их не теряли. Но частично - наверняка! Правда, выяснить это без csum никак нельзя. Разве что на фотографиях или аудиозаписях. Так что csum - это необходимость, а не чей-то каприз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #217

214. Сообщение от Аноним (110), 02-Дек-23, 16:30	–1 +/–
Ну что вы, черт побери, такое несете?! Если Facebook использует BTRFS у себя в проде - это высокая гарантия качества этой файловой системы при любом применении и нагрузках! В самом деле, как дети...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #216

216. Сообщение от User (??), 02-Дек-23, 17:27	+1 +/–
> Ну что вы, черт побери, такое несете?! Если Facebook использует BTRFS у > себя в проде - это высокая гарантия качества этой файловой системы > при любом применении и нагрузках! В самом деле, как дети... Охтыж. Знаменитая "экспертиза opennet" in action. Или система спроектирована таким образом, что на сохранность данных каждой конкретной ноды настолько "пофиг", что просто "пофиг" - а вот дедуп экономит вполне реальные деньги. Пуркуа бы не па...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214 Ответы: #226

217. Сообщение от User (??), 02-Дек-23, 17:29	+/–
> Допустим, полностью вы их не теряли. Но частично - наверняка! Правда, выяснить > это без csum никак нельзя. Разве что на фотографиях или аудиозаписях. > Так что csum - это необходимость, а не чей-то каприз. Чем ситуация "я никогда не терял данные" отличается от ситуации "данные потерялись, но НИКТО НИКОГДА об этом не узнал"? А если нет никакой разницы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #224

218. Сообщение от нах. (?), 02-Дек-23, 17:42	+/–
> А в чем сложность? myisam в общем-то противопоказана жизнь на cow fs. Особенно такой как у жабикса, где бесконечные инсерты и такие же бесконечные удаления. Фрагментация действительно это подтверждает. Но железо справляется, поэтому переделывать никто не будет. Скорее уж целиком запихаю на zfs чтоб не как в прошлый раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211 Ответы: #225, #228

219. Сообщение от нах. (?), 02-Дек-23, 17:44	+/–
> Трёхтерабайтная база заббиха живёт уже лет 10 на ext4, и ни разу > не чихнула. держи в курсе нам очень интересно (нет). А вот что будет если на ходу выдернуть sata шлейфик? (примерный аналог того что случилось с SAN у нашего)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #222, #223

220. Сообщение от нах. (?), 02-Дек-23, 17:47	+/–
> Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем > никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень а если уже взяло? Потом еще разок взяло... а потом почему-то в доме у кролика вообще ничего не осталось. И вот шансов на то что застрявший медведь схуднет через пару недель - не очень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #324

221. Сообщение от нах. (?), 02-Дек-23, 17:54	+1 +/–
> Это же зависит от вида прода. Для некоторого прода, например, нужны только > сырые обычные диски какой у тебя фуфуфу немодный прод. У правильного прода только block storage, только S3 ! А все остальное надо выбросить как нимодна, нималадежна и ни атвичаит современным тенденциям!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

222. Сообщение от Tron is Whistling (?), 02-Дек-23, 23:01	+/–
[рвёт на голове волосы] Там нет SATA-шлейфика...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219

223. Сообщение от Tron is Whistling (?), 02-Дек-23, 23:02	+/–
На самом деле - ничего не случится. Выпадет накопитель с рейда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219 Ответы: #229

224. Сообщение от Аноним (110), 03-Дек-23, 03:27	+/–
Вы и сами ответили на свой вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #240

225. Сообщение от Аноним (110), 03-Дек-23, 03:31	+/–
А если использовать SLOG?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218 Ответы: #230

226. Сообщение от Аноним (110), 03-Дек-23, 03:33	+/–
Мне следовало добавить плашку "Сарказм"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216 Ответы: #239

227. Сообщение от Аноним (227), 03-Дек-23, 04:48	+/–
Забыли про флаги, от которых абстрагировались в Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

228. Сообщение от Аноним (110), 03-Дек-23, 07:06	+/–
Продолжу мысль, если использовать SLOG, то можно задраться commit до вполне себе космических величин - что отлично поможет в борьбе с фрагментацией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

229. Сообщение от нах. (?), 03-Дек-23, 09:24	+/–
Ну тогда все может быть гораздо интереснее. В эпоху когда рейды были не адской редкостью или атрибутом подвальных, а банально в каждом серваке - совершенно не было необычным в массовой эксплуатации за ночь получить пару алертов, утром поменять две сгоревшие платы и обнаружить что вторая оказалась чуточку не той ревизии и...вотЪ... А при отключении питания в DC как все интересно (нет, bbu не помогают)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223 Ответы: #231

230. Сообщение от нах. (?), 03-Дек-23, 09:30	+/–
ничем особо не поможет. Там есть особенности, отключать которые опасно (никто не понимает как это работает а вот подтвержденные случаи потери баз - были) а если не отключать оно тормозит что с выделенным zil, что без. zil это не writeback кэш, это double buffer. И отдельно - сбой slog device - это "unable to import pool" - 100% надежный способ пойти за бэкапом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #297

231. Сообщение от Tron is Whistling (?), 03-Дек-23, 09:57	+/–
При отключении питания в DC веселье в основном в том, что часть систем надо перезапускать в другом DC. Кластеры разбираются сами, у них есть третья или пятая сторона, многосервиски с балансировщиками тоже, а вот менее критичные некластеризованные вещи да, может случаться и руками переносить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #232

232. Сообщение от Tron is Whistling (?), 03-Дек-23, 09:59	+/–
В основном из-за того, что некластеризованные системы не любят сплитбрейнов, и перед переносом желательно удостовериться, что отказавший DC действительно лежит, а не связь с ним пропала временно. Если не удостовериться - да, можно и веселье с множественным доступом к LUN получить, тут уже никакая ZFS не спасёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231

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

235. Сообщение от Tron is Whistling (?), 03-Дек-23, 10:12	+/–
Не нравится - не позорься. А суть в том, что ZFS для ФС - монструозна, и это далеко не последняя подобного рода проблема в ней. Плюс то, как она вообще из палок на колене слеплена (её с системным кешем не просто так не удаётся интегрировать) - опять же не улыбает. Прикладная мерфология фанатикам таковой не прилететь не могла - и в этот раз прилетела аж до визга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

236. Сообщение от Tron is Whistling (?), 03-Дек-23, 10:15	+/–
Бгг. "So your best bet is if you have a known good source copy or hash from one, to compare your stuff against that. Anything else is going to be a heuristic with false positives and negatives." Сквозная(c) целостность(tm) с хешами(r) внезапно потребовала ещё этих вкусных хешей.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #237

237. Сообщение от Tron is Whistling (?), 03-Дек-23, 10:17	+/–
Причём баг жил аж с 2013 года... Сколько фанатиков за это время приобрели никак не замеченные нули в файлах - ну, можно прикинуть. Впрочем, там рядовая практика была "ой, чёт пул слетел, надо переставлять", поэтоу есть мысль, что хранились на этом в лучшем случае торренты, поэтому особо никто и не замечал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236 Ответы: #250

238. Сообщение от Tron is Whistling (?), 03-Дек-23, 10:38	+/–
Исходный баг присутствует и во фряхе тоже, не парьтесь. Оно очень древнее. Народ подозревает, что аж с 2006 года ещё от санок, но подтвердить не может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

239. Сообщение от User (??), 03-Дек-23, 12:10	+/–
Капсом. И джва раза - для тех, которые "Я" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #243

240. Сообщение от User (??), 03-Дек-23, 12:13	+/–
> Вы и сами ответили на свой вопрос. Доказательство наличия битов шредингера (Зависят от ФС наблюдателя - у btrfs все потеряно, но нашлось и даже восстановилось (но это не точно - см. казус с ZFS) - у любителей xfs ничего и не терялось - но несомненно ВСЬО пропало) через "аксиому суслика" - никто его не видел, но все знают, что он - ЕСТЬ. Кэк-спертиза opennet as is.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

241. Сообщение от шкаф (?), 03-Дек-23, 12:44	–1 +/–
Это лишь доказывает, что и тридцать ключевых слов -- дело тяжелое, ты вот даже не осилил нечто корректное написать, но мнение имеешь. Тьфу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #246

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

243. Сообщение от Аноним (110), 03-Дек-23, 13:45	+/–
Каюсь. Не распознал... видимо, из-за того, что крепко-крепко приболел. Так себе "отмазка", но хотя бы является правдой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

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

245. Сообщение от Хм (?), 03-Дек-23, 15:56	+/–
> А ext4 будет насиловать нечитаемый сектор до упора. ... > И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. И чего? Какая правильная в результате? А разве не очевидно, что правильная та, которую один из накопителей прочитал без ошибок? Вроде об этом было исходное утверждение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #337

246. Сообщение от Аноним (167), 03-Дек-23, 16:05	+2 +/–
> Это лишь доказывает, что и тридцать ключевых слов -- дело тяжелое, ты > вот даже не осилил нечто корректное написать, но мнение имеешь. Тьфу. Очередной кек-сперд опеннета опять пишет о себе в третьем лице? https://github.com/swansontec/map-macro/blob/master/map.h /** * Applies the function macro `f` to each of the remaining parameters. */ #define MAP(f, ...) EVAL(MAP1(f, __VA_ARGS__, ()()(), ()()(), ()()(), 0)) cat hello2.c && gcc -Wall -Wextra hello2.c && ./a.out #include <stdio.h> int main( void ) {     volatile const static signed long int* const restrict borsch = {(const volatile void*)0};     printf("Hello borsch %p", borsch);     return  0; } hello2.c: In function 'main': hello2.c:4:5: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]     4 |     volatile const static signed long int* const restrict borsch = {(const volatile void*)0};       |     ^~~~~~~~ Hello borsch 0x0%
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241 Ответы: #248

247. Сообщение от edo (ok), 03-Дек-23, 17:08	+1 +/–
> Не бывает в современных системах битврота Вас обманули. Из последнего подтверждённого (благодаря zfs, кстати): на паре hdd 16ТБ почти синхронно попортились данные в нескольких секторах. После перезаписи исправлялось, потом опять, в тех же секторах. При этом сами диски никаких ошибок не выдавали, просто чексуммы в zfs не сходились. Через некоторое время до дисков «дошло», и они начали выдавать ошибки чтения (и были заменены по гарантии).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #253, #254, #261

248. Сообщение от шкаф (?), 03-Дек-23, 17:20	–3 +/–
так а где корректность-то? в чем смысл того, что ты тут выдал? "а вот так вот можно написать и скомпилеца, ыхых, сишка, диды, дырени" -- это твое показательное выступление? Озвучь в паре предложений, что ты хотел проиллюстрировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #249

249. Сообщение от Аноним (167), 03-Дек-23, 18:23	+1 +/–
> У Си и так простой и чистый синтаксис, ... > так а где корректность-то? в чем смысл того, что ты тут выдал? Причем тут "корректность"-то? В чем смысл того, что ты тут выдал, спрыгнув с темы (ну или как обычно - вообще не читав обсуждение, просто нафантазировав себе что-то)? > "а вот так вот можно написать и скомпилеца, ыхых, сишка, диды, дырени" -- это твое показательное выступление? А это твой показательный слив, с унылыми передергами и откровенными приписками из собственных фантазий? Уныленько, че.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #251

250. Сообщение от нах. (?), 03-Дек-23, 18:34	+2 +/–
> Причём баг жил аж с 2013 года... Сколько фанатиков за это время > приобрели никак не замеченные нули в файлах - ну, можно прикинуть. Э... ноль? Часто у тебя возникает идея скопировать только что скопированный файл (причем именно копию, а не еще раз оригинал) ? Ну и еще надо было иметь очень оптимизированную систему, чтобы успеть это сделать до момента, когда уже будет поздно и он банально и неинтересно скопируется. И очень интересный софт, умеющий в поиск holes. И это до недавнего времени был ни разу не cp. > Впрочем, там рядовая практика была "ой, чёт пул слетел, надо переставлять", Зачем ты транслируешь fud? Рядовая практика там - пи3данулось - да и х-й с ним. Вот только что после недели переговоров с хостером заменил совсем уже развалившийся диск. Ничего не пострадало, кроме моих нервов (он как-то плохо сдох, подвесив заодно и оставшийся рабочий, диски в недосерверах такое любят, нас...ть на шину так что вся ata встает колом) Что забавно - это уже третий в той коробке (где их физически всего два) идущий нах..й за два года. Ну и ладушки, +терабайт свободного места (таких которые там изначально стояли, больше не делают, и очень хорошо что не) > поэтоу есть мысль, что хранились на этом в лучшем случае торренты, > поэтому особо никто и не замечал. торренты имеют собственный контроль целостности, поэтому еще как заметили бы. Но у тех кто там такое хранит - ничего не ломалось. Вот у каждодневых пересобирателей go - бываит. Им за эту ненужную деятельность - большое человеческое спасибо, отлично помогли найти сложный в обнаружении баг. Xyета Хрюндберг правда недовольна, но ей не до того - вчера жырные м-ки на хороших зарплатах не долетели из Мюнхена в Дубай на конференцию по глобальному потеплению. Их бизнес-джет примерз ж0пой к полосе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237 Ответы: #252

251. Сообщение от шкаф (?), 03-Дек-23, 19:24	–1 +/–
ну, насколько вижу, ты привел примеры какой-то фигни в ответ на "скобки могли оставить для соблюдения единообразия кода. У Си и так простой и чистый синтаксис, а соблюдение единого стиля кода делает его вообще идеальным." только ты решил, что взять хитрожопые трюки с ПРЕПРОЦЕССОРОМ (ого, препроцессор, который просто s/x/y/, на этом его работа всё, и который не си); что взять нагромождение слов, которые сканпеляюца, но не несут никакой смысловой нагрузки -- это разбить в пух и прах аргумент выше? Ну так ты выдал шизофазию, которая и не опровергает ничего, и не доказывает. Ну, кроме того, что "и так можно". Что ты сказать-то хотел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #256

252. Сообщение от Tron is Whistling (?), 03-Дек-23, 21:03	–1 +/–
Там речь не о копировании любого только что скопированного файла. Там речь о попытке чтения из бывшей write hole после записи в таковую. Ну я ATA не использую, только SAS, там всё попроще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #257

253. Сообщение от Tron is Whistling (?), 03-Дек-23, 21:04	+/–
> Из последнего подтверждённого (благодаря zfs, кстати): на паре hdd 16ТБ почти синхронно > попортились данные в нескольких секторах. После перезаписи исправлялось, потом опять, > в тех же секторах. При этом сами диски никаких ошибок не выдавали, просто чексуммы в zfs не сходились. Ищите проблему в платформе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #255

254. Сообщение от Tron is Whistling (?), 03-Дек-23, 21:05	+/–
Вообще - честно - за 30 лет опыта все эти сказки про "потом вот нате развалилось" - вообще не умиляют. Потому что всё это скорее для красного словца, а ситуация - индикация проблем совершенно в другом месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #262

255. Сообщение от edo (ok), 03-Дек-23, 21:19	+/–
> Ищите проблему в платформе. Гхм, в том же массиве ещё 11 точно таких дисков, с ними проблем нет. Сейчас глянул, аптайм дисков 4 года. И с теми, что поставили на замену этим двум с бэдами, тоже проблем нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #259

256. Сообщение от Аноним (167), 04-Дек-23, 00:02	+2 +/–
> ну, насколько вижу, ты привел примеры какой-то фигни в ответ на "скобки > могли оставить для соблюдения единообразия кода. У Си и так простой > и чистый синтаксис, а соблюдение единого стиля кода делает его вообще > идеальным." Теперь поподробнее, какие буквы в "Си и так простой и чистый синтаксис" тебе не понятны и с каких пор используемый реально (вот этот вот MAPLIST в разных вариациях встречается только так) стал "фигней"? > только ты решил, что взять хитрожопые трюки с ПРЕПРОЦЕССОРОМ (ого, препроцессор, который > просто s/x/y/, на этом его работа всё, и который не си); Прероцессор "не си"? Надеюсь, это такая унылая демагогия, иначе на этом можно и закончить обсуждение с очередным кекс-пертом. >> "У Си и так простой и чистый синтаксис" > что взять нагромождение слов, которые сканпеляюца, но не несут никакой смысловой > нагрузки -- это разбить в пух и прах аргумент выше? Ну > так ты выдал шизофазию, которая и не опровергает ничего, и не > доказывает. Ну, кроме того, что "и так можно". > Что ты сказать-то хотел? Поясни, это из раздела "Папа, где море?" или "нищитаица!" Ну и да, "шизофазия" это для только для кекспертов опеннета, так-то применение единичного, константно-волатильного указателя на какой нидь int - вполне встречается для общения с железками (пусть там обычно и не signed long int) ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

257. Сообщение от нах. (?), 04-Дек-23, 00:15	+/–
> Там речь не о копировании любого только что скопированного файла. > Там речь о попытке чтения из бывшей write hole после записи в таковую. ДО записи. Попробуй это воспроизвести в реальной жизни. Не пересобирая игого. sas дохнет ничуть не хуже sata, всем бэкплейном сразу, не надо мне сказок про суперуникальные ентер-прайс решения, я на них не одну крысу съел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252 Ответы: #258, #263

258. Сообщение от Tron is Whistling (?), 04-Дек-23, 09:31	+/–
Судя по количеству визга в треде в issues - воспроизвелось на отличненько.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257 Ответы: #260

259. Сообщение от Tron is Whistling (?), 04-Дек-23, 09:34	+/–
Поделитесь моделью дисков плиз, по крайней мере буду знать, с чем не связываться. Хотя вряд ли я с этим конечно свяжусь просто по факту - скорее всего будет отсечено по другим критериям. Сейчас стоит далеко не один массив с разными дисками. Есть место, где у флеша общий налёт 5 лет. Есть место, где у оставшихся HDD уже десятка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #264

260. Сообщение от нах. (?), 04-Дек-23, 09:37	+2 +/–
> Судя по количеству визга в треде в issues воспроизвелось у трех человек помимо пересобирателей игогошечки, причем они постарались воспроизвести, внезапно (и это хорошо, что такие вообще еще остались). И даже у пересобирателей через раз, понадобился скрипт чтобы воспроизводимость была хотя бы на уровне, позволяющем проверить баг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258

261. Сообщение от нах. (?), 04-Дек-23, 09:39	+/–
> Из последнего подтверждённого (благодаря zfs, кстати): на паре hdd 16ТБ почти синхронно > попортились данные в нескольких секторах. После перезаписи исправлялось, потом опять, да, можно модельку? Добавить в черный списочек. Я за всю жизнь с такой х-ней ни разу не сталкивался, почему-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #287

262. Сообщение от нах. (?), 04-Дек-23, 09:41	+/–
> Вообще - честно - за 30 лет опыта все эти сказки про > "потом вот нате развалилось" - вообще не умиляют. вообще-то совершенно типично для твоих любимых аппаратных рейдов. Сперва начинаются дикие тормоза, и ты ищешь причину где ни попадя, пока не догадываешься посмотреть на чтение с дисков. А после пары-тройки ребутов - внезапно рейд спохватывается и сообщает тебе что один из дисков всьо (хорошо если один а не сразу два в raid5). До этого момента причем не всегда даже можно угадать, какой именно - наружу тебе ничего не сообщают, просто тупят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254 Ответы: #266, #267

263. Сообщение от Tron is Whistling (?), 04-Дек-23, 09:42	+/–
Не ДО записи. После записи и ДО сброса на диск.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257

264. Сообщение от edo (ok), 04-Дек-23, 09:48	+/–
ST16000NM002G Вообще дисков на 10+ у меня за сотню, есть и sata, и sas; по производителям — сигейт и hgst/wd. Проблемы вылезли только на этих двух накопителях; но, конечно, количество накопителей недостаточное чтобы делать какие-то выводы о надёжности конкретных моделей. Всё, что я знаю — это то, что silent data corruption случается. Да, скорее всего, речь о банальном баге в прошивке, но от этого не легче. Кстати, автор vitastor'а тоже долго не верил в необходимость чексумм, потом столкнулся с порчей данных на ST8000NM0055
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259 Ответы: #274, #275, #276

266. Сообщение от Tron is Whistling (?), 04-Дек-23, 09:53	+/–
Дай угадаю, диски из ближайшего шопа? "RAID-optimized" диски как раз и отличаются тем, что мгновенно сообщают об uncorrectables, не пытаясь их мучительно читать. Причём разница в ценнике ныне может быть не заметной, отличие только в фирмвари.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #283

267. Сообщение от edo (ok), 04-Дек-23, 09:54	+/–
> До этого момента причем не всегда даже можно угадать, какой именно - > наружу тебе ничего не сообщают, просто тупят. В этом плане меня приятно удивляли рейды от hp — они просили поменять работающие диски. И несколько раз действительно угадывали (диск не меняли, а спустя какое-то время он уходил в ошибку). Читал исследование, в котором для предсказания выхода из строя анализировались задержки дисков; не знаю, это да используется у hpe, или что-то другое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #284

268. Сообщение от Tron is Whistling (?), 04-Дек-23, 09:55	–1 +/–
Когда добавляли в диски ECC - да, люди скрупулёзно считали математику и внедряли необходимые решения. А у вас оно только "минимизирует до терпимого". Ну и ладно, кто ж вас заставляет-то. Продолжайте юзать монструозный комбайн сверху, в котором вот это вот обсуждаемое - далеко не последнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

269. Сообщение от 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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #325

270. Сообщение от edo (ok), 04-Дек-23, 10:11	+/–
> Ну, примерно то же, что и в этом тредике с ZFS и > чексуммами, которые вот беда-то! Внизапна! нипамагли, хотя казалось бы. А что тут странного? Чексуммы — не серебряная пуля, ошибки в реализации фс они, очевидно, не могут исправить. Зато ошибки в железе/прошивках они обнаруживают, а зачастую и дают исправить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #336

271. Сообщение от edo (ok), 04-Дек-23, 10:14	+/–
> О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя. Или не прекрасно, личный пример факапа я уже размещал в этом обсуждении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

272. Сообщение от Ананий (?), 04-Дек-23, 10:17	+/–
>по-умолчанию в Федоре. Ты в курсе, что это значит? Что федорка снова стала полигоном для RHEL? Как и раньше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

273. Сообщение от edo (ok), 04-Дек-23, 10:19	+/–
> Да нет, это вы на локалхосте не подозреваете, что data integrity может > контролироваться как на уровне выше, так и ниже ФС. На уровне ниже фс, внезапно, случаются факапы. На уровне выше фс тоже не всё так просто, обычно софт ожидает консистентность от фс (например, что версия файлов данных бд соответствует версии wal).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #288

274. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:19	+/–
Вообще у этих дисков так-то T10-PI есть. Так что либо кто-то что-то, либо просто используется что-то эдакое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #281

275. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:20	+/–
Ну вот сейчас часть ребят с TrueNAS'ом резко перестали верить в волшебность чексумм :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #285

276. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:37	+/–
А так - да, в последнее время с сигейта ушли на hgst, сигейт достал падучестью. Silent data corruption действительно случается, его и обсуждаем. Вообще сами по себе лишние чексуммы - безусловное добро. Зло - это монстр, которого ради него пытаются втюхать в нагрузку. Я вот в этом плане думаю, может просто через dm блочный слой чексумм присобачить...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #277, #279, #280

277. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:38	+/–
(правда hgst wd теперь, но не суть)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276

278. Сообщение от edo (ok), 04-Дек-23, 10:42	+/–
у меня есть массивы и побольше. почему zfs — в первую очередь потому что чексуммы + merkle tree (плюс это всё работает в связке с raidz/raidz). также востребованы снапшоты, возможность выносить метаданные на ssd в отосительно свежих версиях; возможность сделать большой размер записи; дедупликация. мои варианты использования: - тупая файлохранилка, отдача по http/smb/nfs/… куча hdd, метаинформация на ssd, снапшоты; - то же самое для бэкапов образов виртуалок/физических хостов аналогично, плюс дедупликация; - хранилище в проксмоксе ssd, zvol (блочные устройства для гостевых систем, к которым применимы все гарантии целостности и конситентности zfs).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

279. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:43	+/–
Так-то LVM с dm-integrity вполне себе, и не нужно никаких ZFS'ов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276 Ответы: #341

280. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:49	+/–
Другое дело, что экспириенс показывает, что это всё на практике не нужно, но вот на бэкапный сервер почему бы и нет, там как раз вероятность ошибки в долго живущих данных максимальна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276

281. Сообщение от edo (ok), 04-Дек-23, 10:56	+/–
не уверен, что есть (но не проверял). даже если и есть, t10 pi сам по себе ничего не делает, нужно переформатировать диски на нестандартный размер сектора + нужен софт, который умеет с этим работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274 Ответы: #282

282. Сообщение от Tron is Whistling (?), 04-Дек-23, 10:59	+/–
Зачем софт? Выносные RAID-контроллеры вполне себе умеют. Те же перки с 9 начиная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281 Ответы: #289

283. Сообщение от нах. (?), 04-Дек-23, 11:19	+/–
> Дай угадаю, диски из ближайшего шопа? ты точно работаешь с рейдами, или все же - знания из реддита и википедии? Так ведут себя штатные рейды в увешанном сертификатами и флажками лезвии IBM, например. Где IBM покупала эти диски - спрашивай у нее, они все в наклейках в три слоя, если хоть один оторвать, хрен тебе а не обслуживание. (это еще именно IBM, впрочем, в леново такая же хрень только рейд другой и наклейки, само собой, другие. Диски, вполне вероятно, из той же помойки.) > Причём разница в ценнике ныне может быть не заметной, отличие только потому что в розницу их никто тебе не продаст. И даже не скажет что это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266

284. Сообщение от нах. (?), 04-Дек-23, 11:21	+/–
> В этом плане меня приятно удивляли рейды от hp — они просили видимо, везло. Вообще-то они могут и на самом деле уметь что-то помимо стандартного dumb-smart Я-то полагал что перепрошивка там в основном s/seagate/hpe/g но возможно и не только (поскольку если ЭТИ вежливо попросят - им-то отдадут исходники и инструменты и еще благодарить будут).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #290

285. Сообщение от нах. (?), 04-Дек-23, 11:24	+/–
> Ну вот сейчас часть ребят с TrueNAS'ом резко перестали верить в волшебность > чексумм :D у этих ребят все тихо - не представляю себе use pattern позволяющий на NAS напороться на этот баг. Там просто нет такого софта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #275 Ответы: #299, #300

286. Сообщение от Аноним (286), 04-Дек-23, 11:47	+/–
Круто. Лучшая файловая система стала ещё лучше.
Ответить | Правка | Наверх | Cообщить модератору

287. Сообщение от edo (ok), 04-Дек-23, 12:47	+/–
> да, можно модельку? Добавить в черный списочек. https://www.opennet.dev/openforum/vsluhforumID3/132224.html#264 > Я за всю жизнь с такой х-ней ни разу не сталкивался, почему-то точно подтверждённый случай вины диска у меня тоже один (ну два, если считать по накопителям). а с порчей данных на накопителях сталкивался неоднократно, только на 100% вина накопителя была не доказана.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #292

288. Сообщение от User (??), 04-Дек-23, 12:49	+/–
>> Да нет, это вы на локалхосте не подозреваете, что data integrity может >> контролироваться как на уровне выше, так и ниже ФС. > На уровне ниже фс, внезапно, случаются факапы. > На уровне выше фс тоже не всё так просто, обычно софт ожидает > консистентность от фс (например, что версия файлов данных бд соответствует версии > wal). Да. И уровень ФС, как мы видим, от факапов нифига не застрахован. Более того, лишнаяя сложность не бесплатна и сама по себе повышает вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не работают в три раза лучше одного, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #291

289. Сообщение от edo (ok), 04-Дек-23, 12:51	+/–
> Зачем софт? Выносные RAID-контроллеры вполне себе умеют. Те же перки с 9 > начиная. не пробовал, не скажу. в люблю случае,  доверия к zfs у меня куда больше, чем к некоторому пропиетарному контроллеру (да ещё и заточенному под определённого производителя серверов). и да, за счёт использования merkle tree у zfs чексуммы гарантируют консистентность фс даже если накопители врут, сомневаюсь, что perk предлагает что-то подобное ну а то, что для этого функционала не требуется нестандартный формат — ещё один плюс zfs (да, с заменой по гарантии была долгая история, мы заменили эти накопители на то, что было под рукой, как бы не sata)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282 Ответы: #298

290. Сообщение от edo (ok), 04-Дек-23, 12:54	+/–
идея контроля таймингов операций была как раз независимая от вендора и не требующая дополнительных атрибутов smart. не удивлюсь, если она и с ssd сработает )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284 Ответы: #293

291. Сообщение от edo (ok), 04-Дек-23, 12:58	+/–
> Да. И уровень ФС, как мы видим, от факапов нифига не застрахован. > Более того, лишнаяя сложность не бесплатна и сама по себе повышает > вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не > работают в три раза лучше одного, да? с моей точки зрения, обеспечение консистентности — это совсем не лишняя функциональность у фс. а факапы с потерей данных были с у ext4, и у xfs, про btrfs я вообще молчу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #296

292. Сообщение от нах. (?), 04-Дек-23, 13:27	+/–
>> да, можно модельку? Добавить в черный списочек. > https://www.opennet.dev/openforum/vsluhforumID3/132224.html#264 блин, то есть все exos? Ну ооок...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #322

293. Сообщение от нах. (?), 04-Дек-23, 13:31	+/–
> идея контроля таймингов операций была как раз независимая от вендора и не ну это странная идея - они у разных дисков могут быть разные и их надо мерять, где-то хранить, в общем не для прошивки занятие. Скорее всего что-то более простое у того хепе, тем более они могут себе позволить false alarms, потом у себя перепроверят, пятый слой наклеек налепят и можно еще кому-то поменять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290 Ответы: #294

294. Сообщение от edo (ok), 04-Дек-23, 13:45	+/–
> ну это странная идея - они у разных дисков могут быть разные > и их надо мерять, где-то хранить, в общем не для прошивки > занятие. так важно не абсолютное значение, а изменение. собирать статистику по нескольким ключевым таймингам на каждый используемый накопитель — не выглядит сложной задачей. поднимать аларм если вдруг какой-то процент обращений существенно выходит за пределы средних значений — тоже. сходу самое сложное на мой взгляд — это увязать всё это с глубиной очереди (отключать механизм при наличии очереди?).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #293 Ответы: #295

295. Сообщение от нах. (?), 04-Дек-23, 14:05	+/–
Именно. А для статистики - маленький такой эластик с прометеусом и все это конечно же внутри прошивки. Неее, это так не работает. Там что-то совсем простое у них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #345

296. Сообщение от User (??), 04-Дек-23, 16:01	+1 +/–
>> Да. И уровень ФС, как мы видим, от факапов нифига не застрахован. >> Более того, лишнаяя сложность не бесплатна и сама по себе повышает >> вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не >> работают в три раза лучше одного, да? > с моей точки зрения, обеспечение консистентности — это совсем не лишняя функциональность > у фс. > а факапы с потерей данных были с у ext4, и у xfs, > про btrfs я вообще молчу Ну, теоретически - если "забесплатно" или "очень-очень-дешево", то конечно "ДА!!!". Если дорого, сложно и с COW в нагрузку - то уже ХЗ. Хватит ли чексуммы метаданных в качестве компромисса - тоже вопрос. Ответ на это все - varies от системы к системе. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291

297. Сообщение от Аноним (297), 04-Дек-23, 16:35	+/–
Происходит аккумуляция и агрегация до сброса на пул. Между интервалами commit данные могут многократно изменяться, но запишутся только самые последние изменения, что помогает заметно снизить темпы фрагментации. Преимуществ масса! Как вариант, можно установит commit=1,2... и sync=disabled - что поможет заметно улучшить агрегацию данных, с риском потери данных 1,2...секунд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230

298. Сообщение от Tron is Whistling (?), 04-Дек-23, 20:38	+/–
Вообще убедили, пожалуй попробую собрать dm-integrity там, где может прилететь с накопителя. Но ради этого неадекватной сложности комбайн ZFS - это как 14 гвозди башенным краном забивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289

299. Сообщение от Tron is Whistling (?), 04-Дек-23, 20:39	+/–
Там уже подтвердили, что напоролись, вроде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #285

300. Сообщение от Tron is Whistling (?), 04-Дек-23, 20:39	+/–
Тем более что в режиме SAN почти наверняка для дискарда write hole во все поля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #285 Ответы: #301

301. Сообщение от Tron is Whistling (?), 04-Дек-23, 20:40	+/–
А записать задискарденный блок и сразу попробовать его прочитать - это вообще норма жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300 Ответы: #302

302. Сообщение от нах. (?), 04-Дек-23, 23:35	+/–
> А записать задискарденный блок и сразу попробовать его прочитать - это вообще > норма жизни. так он прочитается. Проблема только при поиске пропущенных блоков, совершенно не понимаю зачем это SAN
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301 Ответы: #303

303. Сообщение от Tron is Whistling (?), 05-Дек-23, 00:06	+/–
В том-то и дело, что там как раз таки возможен рейс при котором он не прочитается. Нет, не только при поиске. Вообще идентификация. Т.е. читнёт нули как раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302 Ответы: #304

304. Сообщение от нах. (?), 05-Дек-23, 00:27	+/–
там исправляли только и исключительно поиск нулей. И ничего больше. (причем все исправление - если нам надо проверить (а не прочитать) нули - дергаем flush и сидим тихо пока не сольется)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #303

307. Сообщение от Аноньимъ (ok), 05-Дек-23, 13:09	+/–
> ZFS плоха в частности именно этим монотонным унылым пиаром - на уровне > пониже начинают верить, что оно действительно волшебное. А с технической стороны > - пока оно с системным кешем не интегрируется, для обычного юза > непригодно, разве что для выделенных NAS. Просто ненужно его юзать с линуксом. И будет всё отлично. В родной иллюмус нет проблем с интеграцией кеша.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183

308. Сообщение от voiceofreason (?), 05-Дек-23, 17:26	+/–
md уже научился на горячую диски менять? а дешёвые LSI - запросто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #312

309. Сообщение от voiceofreason (?), 05-Дек-23, 17:28	+/–
Невыдуманные истории, о которых невозможно молчать(с) А потом такой ставишь md-какашку и харды разгоняются до топовых SSD :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #313, #340

311. Сообщение от Stellarwind (?), 05-Дек-23, 17:35	+/–
А ENOSPC при диске заполненном от силы наполовину с необходимостью ребалансировки постоянной это у бтр такая фича улучшенная по сравнению с зфс. И рейд5/6 недоделанный тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #339

312. Сообщение от нах. (?), 05-Дек-23, 17:48	+/–
> md уже научился на горячую диски менять? а дешёвые LSI - запросто. mdadm --replace существует по-моему с 90х годов прошлого века. А с дешевыми lsi можно очень недешево влететь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308 Ответы: #348

313. Сообщение от нах. (?), 05-Дек-23, 17:50	+1 +/–
> Невыдуманные истории, о которых невозможно молчать(с) > А потом такой ставишь md-какашку и харды разгоняются до топовых SSD :) внезапно, на заре опеннета пингвинятки во всю топырили гузки что их md недоразумение быстрее (дешевых и помойных) адаптеков. Правда начинали исходить на гуано, когда их тыкали клювиками в виндовый рейд (который таки был быстрее и адаптеков и md - тогда не умевшего даже параллелить чтение с зеркал. Не уверен что уже научился, они ж еще маленькие, всего 25й годок)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309

314. Сообщение от 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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #326

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

316. Сообщение от bOOster (ok), 05-Дек-23, 19:39	+/–
Нда, оголтелые в своем репертуаре. Кто нибудь из вас хоть исходники cp из coreutils видел?... Хотя о чем я спрашивают - понятно что нет. Бред то нести это не изучать вопрос перед ответом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #323

317. Сообщение от bOOster (ok), 05-Дек-23, 19:57	+/–
https://www.enterprisedb.com/blog/postgres-vs-file-systems-p... btrfs полный хлам в PostgreSQL применении...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

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

319. Сообщение от Аноним (319), 05-Дек-23, 21:47	+/–
task txg_sync blocked for more than 120 seconds ]:}
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #320

320. Сообщение от Минона (ok), 05-Дек-23, 22:01	+/–
> task txg_sync blocked for more than 120 seconds ]:} Что же они там такого накодили. Во фре и солярке такого не наблюдается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #319 Ответы: #346

321. Сообщение от Аноним (319), 05-Дек-23, 22:37	+/–
Хз, сегодня поймал от rsync локально на pool/ФС. На pool/zvol с ext4 внутри через virtio льет нормально с максимальной для источника скоростью (пул на nvram, источник hdd) Багу уже несколько лет https://github.com/openzfs/zfs/issues/9130
Ответить | Правка | Наверх | Cообщить модератору

322. Сообщение от Tron is Whistling (?), 06-Дек-23, 00:01	+/–
Ну гелиевые Exos на самом деле редкостная дрянь. Хуже были только VX.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292

323. Сообщение от Аноним (-), 06-Дек-23, 06:02	–1 +/–
> Нда, оголтелые в своем репертуаре. Кто нибудь из вас хоть исходники cp > из coreutils видел?... Хотя о чем я спрашивают - понятно что > нет. Бред то нести это не изучать вопрос перед ответом. 1) Да, я видел эти исходники. Покажи мне там "нарушение уровня абстракций", чудак. Если это про экстенты, программы всегда писали данные в файлы как (offset, len) и операция над "экстентом" мало чем отличаются, экстент это тоже (offset, len). Да, там предполагается продвинутая ФС которая понимает ряд расширенных запросов. Но как это внутри ФС сделано - программы не знают. Это абстрактный запрос в терминах операций над регионами. В ряде случаев ФС даже имеет право переиначить и выполнить "неточно", как умеет. Как минимум для "same extent" ioctl. 2) Судя по рейтингу твоего "умного" вопроса оголтелый был не я... 3) Расскажи как делать допустим офлайн дедуп или - вот - копирование-как-рефлинк по твоему суперценному мнению? 4) Если тебе интересно, я даже и ответку этих интерфейсов из 1) видел в btrfs и bcachefs. И нет, "онлайн дедуп" жрущий 100500 рам и проца - вообще совсем не эквивалент этих операций. Которые могут быть достаточно просты, дешевы (рефлинк вообще почти моментальная штука, только в метаданных пометить что те же блоки юзаются еще кем-то) или по крайней мере дефернуты по времени ("same extent" ioctl). Просто для понимания - btrfs делает рефлинк на 3-терабайтный образ винча создавая "типа копию" которая ведет себя как независимый файл за примерно секунду. А ты можешь, конечно, честно скопировать все 3 терабайта (не забудь засечь сколько займет) а потом по сути отменить это действо дедупом (тоже не забудь зесечь сколько это заняло). А при этом потребуется еще и +3 терабайта свободного места на такой "transient". А вон там оно с самого начала - "идеальный дедуп" и места не занимает, только то что изменится и закопировано в сторону CoW. И не уметь подобные интерфейсы для CoW системы вообще-то довольно глупо. В лине этому даже XFS каким-то чудом научился. Я не знаю как они сову на такой глобус натянули, но ZFSники сделали это сильно позже и когда non-cow дизайн получает cow фичу раньше чем cow-дизайн это полкило прикола! Bcachefs тоже это умеет с самого начала. Итого, на данный момент в клуб новых интерфейсов вступило минимум 4 файлухи: bcachefs, btrfs, xfs, zfs. И я нахожу умение в такие фичи логичным для next-gen CoW дизайнов, классическая семантика IO операций вообще - не про них, у них by design есть фичи которые классическими апями posix не описываются. p.s. а самое прикольное во всей этой истории что баг вообще к рефлинкам походу не относился, они "виноваты" только тем что позволили каким-то гентушникам активнее юзать вон тот кусок механики ФС, и там наконец что-то отвалилось под нагрузкой в каком-то древнем баге как воспроизводимая операция. При том отваливаться оно могло и без этого, просто ситуацию создать не очень просто - условия специфичные. По этой причине кого-то явно ждут "приятные" сюрпризы с корапченой файлухой, которую они не заметили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #316

324. Сообщение от Аноним (-), 06-Дек-23, 07:36	+/–
>> Там GlobalReserve уж сто лет есть на такие оказии. Если иначе совсем >> никак - возьмет из него. Кент, кстати, этот урок усвоил оооочень > а если уже взяло? Потом еще разок взяло... а потом почему-то в > доме у кролика вообще ничего не осталось. Если оно это на актуальных версиях ядер делает - навесить баг, имхо. Но у них там так то для тестов целый книгоморд был - и они как раз подобные приколы гасили энное время назад. В обычной ситуации на ЭТО с современными ядрами вообще нарваться малореально - надо нечто супернагруженное, как у мордокниги, тогда под ломовой нагрузкой, на нескольких тазиках из всего парка, за недели-месяцы, может и получится. Но после тех фиксов уже вроде и там не получается, при том что нагрузки фэйсбука - > И вот шансов на то что застрявший медведь схуднет через пару недель - не очень. В обычной жизни увидеть это - ну даже не знаю. Если у тебя свой книгомордий есть - можно попробовать, конечно. Ну или кернелы древние. А так как видишь, свои приколы есть у всех. Кент глядя на это завел какой-то радикально более толстый резерв сразу, чтоб на уже известные грабли не вставать. Удобно же когда граблю nextgen дизайна до тебя любезно оттоптали, можно - вот - немного переиграть :). Круто конечно все заранее знать и заранее предусматривать - но так не бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220

325. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #269

326. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #314

327. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #179

328. Сообщение от Аноним (-), 06-Дек-23, 09:06	+/–
> Вот кстати то самое место, где лучше чексумминг иметь, у старых SD-карт > ECC примерно около отсутствует. > Новые правда поинтереснее, они уже мало чем от SSD отличаются. Я бы не стал излишне обобщать. Девайсов, фирмварей и проч - дохрена, и постоянно новые появляются. Кто и что откаблучит - это всегда некое минное поле. Штуки типа DUP (или тем более RAID1, если было куда) + CSUM здорово улучшают вышиваемость файлухи при отклонениях от идеала. И что важнее, факапы можно заметить на подлете. Скажем учащаюшиеся битые блоки по "csum failed" станет видно ДО того как девайс по всей площади осыпется в труху. А на EXT4 каком это замечают когда там уже совсем фаталити, так что оно и не смогло работать дальше. Но там к тому моменту может такой трешовник быть - что чинить уже нечего и спасибо если хоть самое ценное хотя-бы частично восстановится. ФС с чексумами сильно улучшают диагностируемость железа и даже в общем то и глюков софта порой. Идея в том что что бы ни вызывало глюк, оно не знает как считать чексумы а то что оно вклинится в окно между формированием данных и счетом чексуммы - не так уж и вероятно и чаще всего чексумы смогут спалить даже и это тоже. Потому что отъедет. Не на 100% гарантия - так что обещание что данные не будут испочены может быть профукано. Но реально хайлайтит проблемные железки на ура.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #329, #331

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

330. Сообщение от Аноним (-), 06-Дек-23, 09:14	+/–
> WA да, у BTRFS действительно конский, проверено на SAN. Это на самом деле от ворклоадов зависит. Вы там что делали? Какой характер файлов и ворклоадов? > Ещё отдельная проблема с трекингом свободного места, но она хотя бы решаема > вариантом одна FS - один "раздел". Это расплата за продвинутый дизайн и удобный менеджмент, у медалей 2 стороны. Если у вас есть возможность сжатия, рефлинки, снапшоты, возможность сохранять в РАЗНЫЕ схемы избыточности и проч - ответ на вопрос "сколько места" становится ... значительно интереснее. Появляются забавные факторы. - Насколько сожмется? Вы это знаете заранее? - Насколько блоки совпадают - и будут совпадать далее? - В какой схеме в будущем запросят новые блоки? Это переключаемо в run time и ничем не грозит, можно даже не рестрайпить а заказать новые дефолты для НОВЫХ записей, тогда то что уже записано останется в той схеме как было. Это совершенно валидно в таком дизайне. Это же делает возможной конверсию типа RAID на ходу, по примерно той же технологии. С cow нет причин почему бы данные разрушились. Даже при крахе во время этого действа. И ему даже позицию конверсии трекать не надо при этом. - А также прочие приколы типа снапшотов, метаданных/tail packing (метаданные могут иметь иную схему хранения чем данные, "хвосты" или мелкие файлы - будут в этой схеме). Откуда заранее знать data/metadata ratio и проч?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #334

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

332. Сообщение от Аноним (-), 06-Дек-23, 09:16	+/–
>>> и это все было выполненно ядром и BTRFS автоматически >>> так что не так, Куклачев? >> И давно errors=remount-ro отменили? > так EXT4 думал что у него все хорошо Ну дык, он Титаника напоминает - до последнего оркестр играет и проч. Но потом все же может потонуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

333. Сообщение от Аноним (-), 06-Дек-23, 09:18	+/–
> ZFS плоха в частности именно этим монотонным унылым пиаром - Ну, блина, я его на Btrfs'е таки оценил - и могу подтвердить что чексумы способствуют отлову кривого железа. При том чаще всего ДО того как это в фатальные проблемы эскалирует. А что делать? Факты штука упрямая, мой опыт - вот такой. И чексумы в ФС делают минимум допущений о конфиге, чем оно и хорошо - работает везде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183

334. Сообщение от Tron is Whistling (?), 06-Дек-23, 09:20	+/–
>> WA да, у BTRFS действительно конский, проверено на SAN. > Это на самом деле от ворклоадов зависит. Вы там что делали? Какой характер файлов и ворклоадов? Смешанный. > Это расплата за продвинутый дизайн и удобный менеджмент Не знать, сколько _реально_ в FS осталось свободного места - это да, мегаудобнейший дизайн и наиэффективнейший менеджмент. Честно - одна из самых веских причин обходить стороной. Потому что внезапный отказ в записи - это почти гарантированно потеря данных с любым софтом ныне. > - Насколько сожмется? Вы это знаете заранее? > - Насколько блоки совпадают - и будут совпадать далее? Зачем? Достаточно знать, сколько там _реально_ ещё можно записать, без "сожмётся" и "совпадают". Если удастся записать больше - хорошо, но ни в коем случае не меньше. > С cow нет причин почему бы данные разрушились Конечно нет, ZFS не даст соврать. И ищи потом свищи, где у тебя в этой каше был оригинал данных, он там на весь диск разложен. Ещё одна прелесть не-CoW - данные фрагментируются не сильно, и можно хоть что-то выдернуть при 3.14це, который такого выдёргивания требует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330 Ответы: #354

335. Сообщение от Аноним (-), 06-Дек-23, 09:21	+/–
>> Сижу на ZFS с FreeBSD 7 и не потерял ни единого бита информации. >> А на BTRFS остоянно жалуются на потерю данных. > А, ясно, жалуются фрибздуны. Ты только сейчас это заметил? Ну понятно что им обидно - btrfs даже на маздайке уже есть, а у них только дырка от бублика^W файла какого-то, копированого дважды :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

336. Сообщение от Tron is Whistling (?), 06-Дек-23, 09:25	+/–
Ахтунг, чексуммы научились исправлять баги в прошивках!!!111
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270 Ответы: #342

337. Сообщение от Аноним (-), 06-Дек-23, 09:30	+/–
>> И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. >> И чего? Какая правильная в результате? > А разве не очевидно, что правильная та, которую один из накопителей прочитал > без ошибок? Вроде об этом было исходное утверждение. Так сложно понять что фирмвари (в основном у флешастых штук) в последнее время взяли моду возвращать при чтении какую-то труху - без отлупа IO error при этом? И вот у вас 2 разные копии - а теперь попробуйте угадать которая из них была правильная! С чексумами то это как 2 байта переслать - где совпало, тот девайс и нормальный. А вон тот, гамнюк, гонит, вот ему перезапись этого блока. А если такое часто - он, наверное протерся/сыпется/кривой и это вообще лучше заменить ASAP. При этом по крайней мере известно что проблема есть. А на какомнить EXT4 данные будут рандомно факапаться, никто ничего не заметит пока что-то не навернется как следует, в заметном виде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245

338. Сообщение от Аноним (-), 06-Дек-23, 09:41	+1 +/–
> Слишком много "если" и никаких гарантий, что на другом ядре и ОС > этого не случится. Даже если это старое ядро, новую проблему легко > портируют и на него. Вон в ext4 баги десятилетиями никто не > исправляет https://github.com/torvalds/linux/commit/b1489186cc8391e0c1e... У сабжа баг тоже на поверку оказался далеко не вчерашний так то. А то что новую фичу запилили, и она помогла спровоцировать это в более легко воспроизводимом виде - вообще совсем другая история. На память о которой у ряда счастливчиков думающих что все ЗБС в ФС будут битые файлы. А в силу меньшей вероятности - они как раз и не заметят факап. Это еще прикольнее, подождать пока по бэкапам разлетится, старые бэкапы подтереть, и тут однажды вдруг - обана! Оказывается что файл битый - и такой уже пару лет, так что и все бэкапы с ним такие же. А то что пару лет он не требовался... ну... мало ли чего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

339. Сообщение от Шарп (ok), 06-Дек-23, 09:52	+/–
> А ENOSPC при диске заполненном от силы наполовину с необходимостью ребалансировки постоянной Брехня. Как раз наоборот можно поймать исчерпание свободного пространства при балансировке или дефрагментации. Я два раза на такое попадал у себя. А если не лезть с ручным обслуживанием, то проблем не возникает. > рейд5/6 недоделанный тоже. Да. Но лично у меня только 0 и 1. Так что пофиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #311

340. Сообщение от Аноним (-), 06-Дек-23, 09:53	+/–
> Невыдуманные истории, о которых невозможно молчать(с) Что есть то есть - #$%ля с сервантом на ровном месте, с выкапыванием по помойкам старой фирмвари и рефлешем фирмвари вниз полуправдами, чтобы вернуть как было, вместо легкого апгрейда - это шикарно. Еще мне понравилось как интель на своих серваках делал дрова под конкретный SP - а если у вас не он ... упс ... вы обновили систему и райду - кабзда. При том если от накатки нового SP она гарантированная, то от вон тех KB - а вот попробуйте угадать, какой апдейт вам драйвер нагнет! Русская^W редмондская рулетка! В смысле райд то после вон того остается нормальный, только его драйвер более не работает, а на сайте интел мило так: "buy new server and press any key" - потому что поддержку вашей модели мы тут очень кстати дропнули месяц назад, так что ВОТ вам а не сервиспак! Все для удобства клиента! :))) > А потом такой ставишь md-какашку и харды разгоняются до топовых SSD :) Да упаси меня от этих феккальев после btrfs'а. Я скорее поверю что это для меня bcachefs смогет. У него к тому предпосылки есть, иерархический стораж это кент прикольно придумал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309

341. Сообщение от Аноним (-), 06-Дек-23, 09:58	–1 +/–
> Так-то LVM с dm-integrity вполне себе, и не нужно никаких ZFS'ов. Так то сделать эрзац btrfs/zfs можно и из той этажерки. Но вот когда захочется это еще и отменеджить и что-то переиграть - вот тут и вспоминаешь архитекта Криса Мэйсона, показавшего что это все может быть намного лучше чем вон тот истошный брейнфак. Который ты как-нибудь сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

342. Сообщение от edo (ok), 06-Дек-23, 11:10	+/–
> Ахтунг, чексуммы научились исправлять баги в прошивках!!!111 исправлять баги — нет, конечно. испралять data corruption, вызванные (в том числе и) багами в прошивке за счёт чексум и избыточности — да. и одной избыточности тут недостаточно, в случае с raid 1, например, мы можем только узнать что копии расходятся, но не можем сказать какая верная. то же самое и с raid 5. raid 6 теоретически может исправить ошибку, но только пока он не в degraded состоянии. у zfs таких ограничений нет, всегда можно сказать верна ли запись на конкретном диске или нет (и, более того, за счёт merkle tree можно сказать актуальная она или нет; если нет, то можно откатить фс в предыдущее консистентное состояние)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #336 Ответы: #356

343. Сообщение от edo (ok), 06-Дек-23, 11:16	+/–
> И да, при чём тут ФС с чексуммами - опять явная реклама. > dm-integrity мало? не смотрел внимательно, но обеспечивает ли dm-integrity консистентность данных? случаи, когда накопитель сказал, что записал данные, а после отключения оказывается, что нет — он читает пусть и валидные, но данные прошлой версии — совсем не редки, увы. в многодисковых конфигурациях это может сделать больно. да и в однодисковых возможны сценарии потери данных. zfs закрывает и этот случай тоже. ну и, как побочный эффект, raid5 write hole тоже закрывается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331 Ответы: #347

344. Сообщение от edo (ok), 06-Дек-23, 11:21	+/–
> Летом тоже с шипами на ботинках и в костюме химзащиты ходишь? нет. но сервера, например, без ecc не рассматриваю. и давно решил, что и домашний компьютер при следующем апгрейде будет с ecc памятью. не потому, что ecc исправляет ошибки, это на самом деле не главное. главное, что ecc детектит сбои, и можно отбраковать проблемные модули памяти до того, как это вызовет пробемы. в сравнении со стандартным «что-то прога сегфолт выдала, может библиотека кривая, а может быть космические лучи, или всё-таки выключить комипьютер и на сутки запустить мемтест» это просто гигантский шаг вперёд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329 Ответы: #349

345. Сообщение от edo (ok), 06-Дек-23, 11:29	+/–
> Именно. А для статистики - маленький такой эластик с прометеусом и все > это конечно же внутри прошивки. > Неее, это так не работает. Там что-то совсем простое у них. да не нужно там никакого прометея, буквально десяток-другой байт в постоянном хранилище и может сотня байт в ОЗУ. в общем, задача посильная для МК, что уж говорить о полноценных powerpc/arm  в рейд-контроллерах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #295

346. Сообщение от нах. (?), 06-Дек-23, 11:43	+/–
> Во фре и солярке такого не наблюдается. нет автообнаружения заблокировавшихся ядерных тредов, вот и не наблюдается. Я в такое вляпывался на пресловутой 11.1 Воспроизводимость в конкретно моей конфигурации - 100%, мертвое повисание системы на make world, вероятнее всего из-за нехватки памяти при попытке обработать нехватку памяти. (как у них обычно) К сожалению, пока я пытался донести эту информацию до тех кто мог бы что-то поправить, из той конторы уволился и ноут отобрали. А там и ZoF стала немодно. Попробуйте отключить abd scatter и arc compression - чем чорт не шутит, может это именно тот баг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #320

347. Сообщение от Tron is Whistling (?), 06-Дек-23, 15:07	+/–
Это да. Неказистый RAID5 write hole ловким движением превратился в элегантное read zero hole. dm-integrity хранит журнал и метаданные отдельно от данных, так что должно быть ок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343

348. Сообщение от voiceofreason (?), 06-Дек-23, 16:41	+/–
На горячую это когда не прикасаясь ни к какому софту вынимаешь диск из зеркала, вставляешь такой же новый и он сам инитится и встаёт в работу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312 Ответы: #350

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

350. Сообщение от нах. (?), 07-Дек-23, 23:16	+/–
А ты его вставил вообще-то в надежде хоть что-то вытащить с еще не до конца но вот-вот сыплющегося второго. Успех гарантирован. Нет, спасибо, именно из-за этого в моих собственных системах никогда не будет udisksов и тому подобного вредного г-на, лезущего к железу без явной моей команды. (я бы и udev отправил следом, но это уже нереально сделать)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #348

351. Сообщение от Аноним (-), 08-Дек-23, 13:35	+/–
> Летом тоже с шипами на ботинках и в костюме химзащиты ходишь? Представляешь, даже летом можно походить в горах - или даже сунуться в коллектор. Более того - учитывая хлипкость современного железа, где в погоне за скоростью и ценой профачили надежность и стабильность на всех мыслимых уровнях - ну ты еще скажи что страховочный трос на высоте "летом" ни к чему, и каску на стройке тоже одевать - это лишнее, под ней череп потеет. Видимо, будет намного лучше если с высоты какой-нибудь камешек его прошибет насквозь - зато, вот, не жарко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329

352. Сообщение от Аноним (-), 08-Дек-23, 14:21	+/–
> И да, при чём тут ФС с чексуммами - опять явная реклама. Очень странно упоминать ФС с чексумами в топике про ФС с чексумами. Где чексумы одно из достоинств дизайна и аргумент "за". > dm-integrity мало? Файлухи с чексумами менеджить сильно удобнее чем этажерку из этих кусков крапа. А ты можешь на этих костылях прыгать если хочешь. Но без моего участия. Мне как-то device add/device remove - с прозрачным увеличением/уменьшением места по сути 1 командой - нравится сильно больше. Я хочу видеть управление вот так, а не вон тот кошмарик. И да, снапшоты тоже полезны, например, для операционки, чтобы как в виртуалке - в случае факапа например апгрейда системы просто откатиться да попытаться еще раз. Без реинстала всей оси и проч на полдня. А у тебя вон то не получится. Можно конечно и это отрастить в той этажерке, но если захочется что-то переконфигурировать, скажем, размер ФС увеличить - не спятить при этом будет довольно тяжко. Наслаждайся этим сам, а я свой выбор сделал. И хотя это не ZFS, они были первыми кто это придумал - и у них был нефиговый пойнт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331

353. Сообщение от Аноним (-), 08-Дек-23, 14:43	+/–
> Э, да у вас проблемы с надёжностью. > У меня десктоп с ECC-памятью лет 8 уже как. > Может поэтому мне никакие ZFS и не упёрлись :) А корректность работы проца, чипсета, шин, шнурков, накопителей и проч - гарантируется любимым российским методом - "на авось". Я все правильно понял в этой чудной схеме?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #349

354. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #334 Ответы: #357

355. Сообщение от Аноним (-), 08-Дек-23, 15:19	+/–
> Например дырочку при чтении дырочки из файла. Субъективно - на 1 этот факап за всю жизнь я видел не менее ДЮЖИНЫ прецедентов выгрузки блочными девайсами какой-то трухи юзерам - и даже лично мне. Учитывая что для вот этого факапа надо было еще и извратиться, а вон то - вообще САМО разваливается, на флешатине просто за факт приближения к лимиту износа - ну, знаете, я предпочту знать истинное состояние дел с чексумами. И не, ваши dm, md, lvm и проч вы там сами и используйте, имхо. Если в zfs нужда в именно таком менеджменте девайсов еще притянута за уши, ибо ничего принципиально иного не делает, то вот btrfs и bcachefs попользовались на всю катушку возможностями которые это дает - и это было круто. А еще лично мне нравится как логика self heal в btrfs с ремапом взаимодействует: репайрит плохую копию из хорошей, что при io error что при отгрузке трухи. В любом случае проблема починена а этот факт залоггирован. А не вон тот позор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

356. Сообщение от Аноним (-), 08-Дек-23, 15:28	+/–
> в случае с raid 1, например, мы можем только узнать что > копии расходятся, но не можем сказать какая верная. то же самое > и с raid 5. raid 6 теоретически может исправить ошибку, но только пока он не в > degraded состоянии. Во, edo понял трабл - и чем райд+чексум лучше чем просто raid. Но в размазанном на layer'ы дизайне оно, вероятно, в self heal вообще не смогет. Инфо на стыке layer'ов потеряется - и упс, то что btrfs делает в крейсерском режиме, вообще не требуя конфигурации, вон там - жуткий рокетсайнс - если возможно вообще. Пусть этот свистун и пользуется такими технологиями сам. > можно сказать актуальная она или нет; если нет, то можно откатить > фс в предыдущее консистентное состояние) Btrfs для трека актуальности generation использует, но это в целом не мешает чексумам работать и делать - ну вот то что и должны. Так что наловилось некоторое количество кривых экспонатов. И при таких фактах свистящий трон выглядит хиловато...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #342

357. Сообщение от Tron is Whistling (?), 09-Дек-23, 11:43	+/–
> Ну да, ну да, в бак с топливом "боинга" на лету неудобно светить фонариком и оценивать на глаз Ну, знаешь, если в боингах будут такие же датчики, как в бтрзфсах, то я лучше на них летать перестану.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #354

358. Сообщение от Аноним (-), 10-Дек-23, 12:40	+/–
> Кроме как добавить энтропии во вселенной этот подход ничего не несёт. Бесполезные > операции ради бесполезных операций. Хотя, если нет возможности задействовать самодиагностику > дисков (к примеру, при подключении через китайский переходник), то, может быть. Это может сказать только человек не эксплуатировавший ФС с чексумами в достаточном объеме. А те кто это пробовал - таки, вот, наловили глюкавых железок и спасли немало фс от фатальных разлетов, срубив проблему на подлете - и считают иначе, соответственно. Хороший пример что незнание - сила. В плохом смысле слова. >>на нормально работающем железе > на нормально работающем железе никогда не понадобится ничего сложнее ext4. Осталось еще вселенную с этим нормальным железом найти. Потому что в этой вселенной - даже энтерпрайзные SSD осыпаются. Особенно если ими подпереть как кешом более медленные хранилки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #360

359. Сообщение от Аноним (-), 10-Дек-23, 12:47	+/–
> Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что > в postgresql чексумминг на уровне страниц надо включать отдельно? Базы априори пытаются делать большую часть работы ФС, начиная с журналирования. Плюс-минус еще и чексуммы - логичное продолжение банкета. А зачем считать чексумы дважды? Если кто хотел косплеить ФС - пусть и косплеит. Даже вот фича такая есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #361

360. Сообщение от Аноним (24), 10-Дек-23, 12:57	+/–
Упоминание ссд тут очень характерно и показательно на самом деле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358

361. Сообщение от User (??), 10-Дек-23, 14:16	+/–
>> Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что >> в postgresql чексумминг на уровне страниц надо включать отдельно? > Базы априори пытаются делать большую часть работы ФС, начиная с журналирования. Плюс-минус > еще и чексуммы - логичное продолжение банкета. А зачем считать чексумы > дважды? Если кто хотел косплеить ФС - пусть и косплеит. Даже > вот фича такая есть. И какое отношение этот спич имеет к истории Шарика выше, который вместе с COW, роняющей перформанс БД (mvcc субд + cow ФС, м-ммм!) отключил чексуммы на ФС, а в БД - внезапно - не включил, и рассказывает всем про супер-уровень-защиты-волосы-стали-длинными-и-шелковистыми, м? А если "никакого" - то может лучшие собаководы расскажут, куда в таком сетапе ставить btrfs (Или не btrfs?), где включать чексуммы, как с этим взаимодействует репликация (Streaming или logical? Или может вообще не включать - двух контрацептивов заглаза?), к чему цеплять EMC Avamar (Или не цеплять? Защищено ж все!) - ну и что сделать, чтобы этот чудо-сетап в реальной жизни отставал от mssql на фуууу! немодной ntfs хотя бы процентов на 20, а не каквсигда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359

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

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