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

"В Bcachefs реализована возможность самовосстановления ФС из избыточных кодов"	+/–
Сообщение от opennews (??), 18-Июл-24, 14:37
Кент Оверстрит (Kent Overstreet), разработчик ФС Bcachefs, предложил для включение в состав ядра Linux 6.11 изменение с реализацией в ФС Bcachefs возможности автоматического прозрачного восстановления проблемных данных, используя сохраняемые избыточные коды восстановления ошибок. Логика работы предложенной функциональности напоминает реализацию подобной функции в Btrfs: если при чтении возникает ошибка ввода/вывода или вычислено не соответствие контрольной суммы, проблемный блок данных будет автоматически перезаписан заново, при наличии избыточности для его восстановления... Подробнее: https://www.opennet.me/opennews/art.shtml?num=61570
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 18-Июл-24, 14:37	+/–
Гиперкомпенсация за предыдущую эпичную ошибку с порчей ФС?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #8

2. Сообщение от Аноним (2), 18-Июл-24, 14:37	–3 +/–
автоматизация и чёрный ящик это плохо, пнятненько? при каких условиях автор видит восстановимое повреждение?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #14

3. Сообщение от Аноним (3), 18-Июл-24, 14:44	–9 +/–
это не гиперкомпенсация, а бред, который сведёт всю производительность к нулю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #13

4. Сообщение от Аноним (4), 18-Июл-24, 14:52	–3 +/–
Драйвер Bcachefs восстановится из избыточного кода, если даже её удалить? Прямо как вирус, который удаляешь из Windows XP, а он непонятно откуда снова вылазит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #15

5. Сообщение от Аноним (5), 18-Июл-24, 15:02	+5 +/–
Как говорят пользователи ZFS, производительность не важна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #21

6. Сообщение от Аноним (5), 18-Июл-24, 15:03	–1 +/–
Почему это непонятно? Windows — это distributed replicated virus storage.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #9

7. Сообщение от Аноним (5), 18-Июл-24, 15:04	+2 +/–
> автоматизация и чёрный ящик это плохо, пнятненько? Окей, надо сказать раработчикам рейда, чтобы при каждой ошибке чтения-записи каждого блока пользователя спрашивали, что делать и какое устройство использовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10, #78

8. Сообщение от Аноним (8), 18-Июл-24, 15:04	+1 +/–
Гиперкомпенсация это когда компенсация много затратнеё чем то что она компенсирует. В данном же случае это даже не компенсация, а очередное нате на лопате.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

9. Сообщение от Аноним (8), 18-Июл-24, 15:06	+/–
На Линуксе же со всеми его npm и pypi вирусов нет (есть)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #19

10. Сообщение от Аноним (2), 18-Июл-24, 15:35	–1 +/–
>какое устройство использовать Что сказать то хотел? Или ты разницы не видишь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #12

12. Сообщение от Аноним (12), 18-Июл-24, 15:44	+/–
Я не тот аноним что выше. Но железные рейды да и софтовые типа zfs точно так же восстанавливают и перезаписывают битые данные (при условии что оставшейся избыточности для этого хватает). Такой функцией даже периодически проходятся по массиву (patrol / scrub). Непонятно почему bcachefs этого раньше не делала - типа нашла ошибку, радостно отрапортовала и оставила как есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #17

13. Сообщение от Аноним (-), 18-Июл-24, 16:03	+2 +/–
>  это не гиперкомпенсация, а бред, который сведёт всю производительность к нулю Это не бред, а косплей куска логики btrfs'а. И вы уж простите но если нечто не прочлось - вопрос не о производительности уже, а о том чтобы не продолбать данные. И в этом смысле self-repair битой копии из исправной прям по факту обнаружения, на лету - это очень круто придумано и отлично работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #18

14. Сообщение от Аноним (-), 18-Июл-24, 16:07	+/–
> автоматизация и чёрный ящик это плохо, пнятненько? при каких условиях автор видит > восстановимое повреждение? На обычном RAID вы вообще данные продолбаете. Вот видите вы на RAID1 что 2 копии не сошлись - и дальше что?! Файлуха с чексумами - по чексумам видит где правильный блок а где левак и может ре-репликацию сделать по мере обнаружения проблем. А обладатели более классических райдов, с учетом емкости современных сторажей и их хлипкости довольно часто огребают тыкву, когда оказывается что там уже факапище так то был. Отлично, кстати, работает на практике. В btrfs во всяком случае. Редкие сбойные сектора заруливает на ура. Теперь и этот так же сможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #30, #119

15. Сообщение от Аноним (-), 18-Июл-24, 16:09	–2 +/–
> Драйвер Bcachefs восстановится из избыточного кода, если даже её удалить? Если у вас системный стораж с избыточностью - то таки да. А чем он такой особенный то? А GRUB например умеет грузиться с альтернативного снапшота btrfs при желании. И вот вы вроде вон там драйвер снесли. Но это нелинейный менеджмент систем. У нас несколько таймлайнов, которые развивались side by side. И вот тут - драйвер еще был. Как и кернел например. Да, можно даже снос кернела обыграть одним только бутлоадером. Добро пожаловать в нелинейный менеджмент систем в стиле виртуалок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

17. Сообщение от Аноним (2), 18-Июл-24, 16:12	+/–
Zfs не рейд и по понятным причинам не пользуется поулярностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #22

18. Сообщение от Аноним (18), 18-Июл-24, 16:15	+/–
Придумано круто, ну вот как работает, будем посмотреть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #20

19. Сообщение от Аноним (18), 18-Июл-24, 16:22	–1 +/–
Они могут самораспространяться, заражая исполняемые файлы? Не могут. Значит, это не вирусы, а нечто другое: бекдоры, устанвливаемые социнженерным подходом; руткиты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #31, #86

20. Сообщение от Аноним (-), 18-Июл-24, 16:40	+1 +/–
> Придумано круто, ну вот как работает, будем посмотреть. В btrfs зашибись работает. Ничего этакого особо не делает при чтении кроме счета чекскм. А вот если не совпало или IO Error - тогда перезапись битой копии из исправной. Если это единичный редкий бэд - ну, он просто парируется в фоне. Раз в дохрена это обычное дело для современных сторажей. Если же это начинает лезть более часто - окей, вам пора поменять проблемный девайс. Ну и сабж постепенно допилит это дело. Ессно по началу возможны отклонения от идеала, но Кент весьма серьезно настроен держать марку "wont eat your data" и мне этот настрой - нравится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #33

21. Сообщение от Аноним (-), 18-Июл-24, 16:41	+/–
> Как говорят пользователи ZFS, производительность не важна. Это и повышает популярность btrfs и сабжа. Должен же кто-то энтерпрайзным утюгам мастеркласс показывать?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #23, #26

22. Сообщение от Аноним (-), 18-Июл-24, 16:44	+3 +/–
> Zfs не рейд и по понятным причинам не пользуется поулярностью. Он в том числе и это. А не пользуется популярностью потому что - махровая энтерпрайзятина, с ломовым жором ресурсов, неудобным менеджментом и специфичными допущениями. Сабж и btrfs с самого начала задуманы быть более универсальными и менее ушибленными на 1 конкретном кейсе энтерпрайзных NAS в ущерб всему остальному. Например даже при использовани RAID схем там не требуется выравнивать девайсы, можно подоткнуть любое что есть, лишь бы constraints схемы хранения можно было обеспечить. Хоть каким-то комбо свободного места на всех девайсах в ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #25

23. Сообщение от _ (??), 18-Июл-24, 17:47	+5 +/–
У бытыэра было сколько? 15 лет? чтобы это сделать и как то ... ну не шмогла :))) NOTE: Я про хранилище дикпиков на мордакниге слышал. Это можно и в /dev/null хранить - разницы никто не заметит :) bcachefs - выглядит заманчиво, впрочем все они выглядят заманчиво вначале :) Но конкретно у этой есть опупенное преимущество - еЯ практически в одно рыло тянет _вменяемый_ перец ... Ни те согласований CoC-a, ни те кода для розовых поней, встроенного вебсервера и генератора QR- кодов ... Даже не верится что до сих пор не придушили :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29, #68

24. Сообщение от Аноним (24), 18-Июл-24, 17:51	+/–
> Линус Торвальдс отложил приём данного изменения в ядро 6.11 из-за проблем с оформлением патчей (был выполнен "git rebase" на новую ветку, что не нужно было делать) Занятно выходит, создатель VCS не умеет пользоваться своей же VCS, занимается фетишизмом c зарослей из заплесневелых веток
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #79, #126

25. Сообщение от _ (??), 18-Июл-24, 17:58	+2 +/–
Как это не пользуется популярностью?!?!? Если сторидж не от первой HW 10-ки, то он на 100500% сделан на ZFS-e! Нихрена себе не пользуется 8-/ "Вы слишком много кушать!"(С) Кста - в РФ вообще будет лидер рынка, какой нить отечественный "ЯФС" :-)))) А а вот на ваших десЪктопах стоип то что инсталлер по-дефолту ставит :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #73, #139

26. Сообщение от Assssss (-), 18-Июл-24, 18:02	+/–
btrfs не пригодня для SSD, у неё write pressure (запись метаданных на единицу полезных данных) примерно в 30 больше чем у zfs. Т.е. btrfs SSD быстро приводит к концу ресурса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #36

27. Сообщение от Assssss (-), 18-Июл-24, 18:03	+/–
>был выполнен "git rebase" на новую ветку, что не нужно было делать Вот на этом моменте поподробнее плиз, чем  чревато?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

28. Сообщение от Assssss (-), 18-Июл-24, 18:06	+/–
Избыточные коды в файловой системе без ECC оперативной памяти лишены смысла. Сбойнёт память и файловая система этого никак не обнаружит и запишет сбойные данные.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #37, #43, #75

29. Сообщение от Assssss (-), 18-Июл-24, 18:08	+/–
Ахаха, очень вменяемый, особенно вменяемый он был когда в рассылке своей файловой системе послал чувака вот так - "fuck you", вместо того чтобы ответить по сути выявленых недоработок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #69, #100

30. Сообщение от _ (??), 18-Июл-24, 18:11	–2 +/–
А про RAID 3|5|6  у вас в Верхних Высерках вообще не в курсе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #41, #49, #74

31. Сообщение от _ (??), 18-Июл-24, 18:13	+2 +/–
Могут. Смотри в базы антивирей и удивляйся. Другое дело что масштаб этого смешной ... ну дык - 1%
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

32. Сообщение от _ (??), 18-Июл-24, 18:18	–1 +/–
Ну таки да - сильно ECC рекомендуется, но тут такое дело - ны Ынтрерпрайзном железе оно само-собой установленно, а васянам такое ставить - дорого. Ну и ... По любасу если ты из двух проблем хотябы с одной справился - это лучше чем иметь обе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #34, #44

33. Сообщение от Аноним (33), 18-Июл-24, 18:20	+/–
> перезапись битой копии из исправной Откуда берётся исправная копия? Речь про raid? Или эта фича работает и без raid? Работает благодаря CoW? Могут ли восстановиться старые данные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #40, #71

34. Сообщение от Assssss (-), 18-Июл-24, 18:34	+/–
Без ECC RAM в случае любого сбоя оперативки файловая система с избыточными кодами будет упорно восстанавливать сбойные данные считая их верными. Хотели добавить защиту _от_ сбоев в файловой системе, а добавили поддержку и потворствование на уровне FS _для_ сбоев в RAM. Начинать нужно с ECC RAM и только потом добавлять избыточные коды в FS иначе результат будет строго противоположный предполагаемому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #38

35. Сообщение от Не пытайтесь напугать меня пивом (?), 18-Июл-24, 19:35	+/–
вот тут большой документ, на который ссылается автор https://www.kernel.org/doc/Documentation/maintainer/rebasing... но там не по-русски чё-то написано
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #51

36. Сообщение от ананим.orig (?), 18-Июл-24, 20:25	+/–
Пруф?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #50, #52

37. Сообщение от Аноним (37), 18-Июл-24, 21:14	–1 +/–
DDR5 уже с ЕСС из коробки. Так что обновляйте свои коры дуба.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #46

38. Сообщение от Аноним (38), 18-Июл-24, 21:16	+/–
Развей, пожалуйста, свою мысль. Как сбой в RAM приводит к тому, что ФС будет пытаться восстановить не те данные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #47

40. Сообщение от Аноним (40), 18-Июл-24, 21:22	+/–
Про RAID.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

41. Сообщение от Аноним (40), 18-Июл-24, 21:25	+/–
А вы про RAID(0,1,10), видимо, не в курсе. Если вам кажется, что все вокруг вас дураки, то вам это только кажется, и главный дурак тут — вы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

42. Сообщение от Аноним (42), 18-Июл-24, 21:26	+/–
Кто-то уже ставил себе на локалхост?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #77

43. Сообщение от Аноним (40), 18-Июл-24, 21:31	+1 +/–
А ещё всё лишено смысла без автоматической системы пожаротушения, комплекса противовоздушной обороны, герметизации от воды, двойного резервирования энерговвода, и всего остального, что вообще когда-либо придумали в мире обработки данных. Научись уже различать разные угрозы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #48

44. Сообщение от Ivan_83 (ok), 18-Июл-24, 21:32	+/–
Не сильно дороже. На райзенах оно работает, а сама память не значительно дороже. Я уже года 4 как перешёл дома на ECC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #76, #105

45. Сообщение от Аноним (40), 18-Июл-24, 21:32	+/–
На домашнем насе под торрентами живёт великолепно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

46. Сообщение от Ivan_83 (ok), 18-Июл-24, 21:34	+/–
Это не совсем так, рекомендую вам читать больше по теме. На практике в DDR5 ECC внедрили на уровне чипов, чтобы хоть как то повысить выход годных чипов. На уровне же всей планки памяти ECC всё ещё делается установкой дополнительного чипа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #107

47. Сообщение от Ivan_83 (ok), 18-Июл-24, 21:37	+/–
Легко. ОС засылает DMA запрос на чтение с диска, контроллер поднимает данные, кладёт в память и нотифицирует ОС что готово, ОС отдаёт этот кусок памяти драйверу ФС, он чекает хэши/суммы и понимает что данные битые. Они побились уже после чтения в самой памяти. Дальше или паника или попытка драйвера ФС починить побитые данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #53, #55

48. Сообщение от Ivan_83 (ok), 18-Июл-24, 21:37	+/–
Аноним выше прав, я видел как ОС сама себя убила на сбойной памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

49. Сообщение от Be My Baby (?), 18-Июл-24, 22:25	+/–
А в Ваших пенатах в курсе, что для разных видов нагрузки - разные виды RAID? У вас базы данных на RAID5/6?  Сочувствую вашим пользователям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

50. Сообщение от Assss (?), 18-Июл-24, 23:30	–2 +/–
Пруф в гугле по запросу - btrfs write amplification
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #54

51. Сообщение от Assss (?), 18-Июл-24, 23:32	+1 +/–
Да это понятно, вопрос был почему в этом конкретном случае Линус не смог патч замёрджить. Никаких тех.проблем там нету, просто снобизм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

52. Сообщение от Аноним (54), 18-Июл-24, 23:45	+/–
Судя по тому, что он write amplification перепутал с write pressure, он мог ошибиться ещё раз и иметь в виду эту хабростатью[1], в которой есть числа около 30 (таблица в конце), но ничего нет о ZFS. [1] https://habr.com/ru/articles/476414/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #58, #117

53. Сообщение от Assss (?), 18-Июл-24, 23:48	+/–
>Дальше или паника или попытка драйвера ФС починить побитые данные. 1. ECC память, может один битый бит на байт пофиксить и больше 1 битого бита задетектить. 2. Больше 1 битого бита на байт у нормальной памяти крайне маловероятно - "A system on Earth, at sea level, with 4 GB of RAM has a 96% percent chance of having a bit error in three days without ECC RAM. With ECC RAM, that goes down to 1.67e-10 or about one chance in six billions." 3. Вы всё верно написали, хочу немного дополнить: в 99,9999...% в случае ECC памяти исправление ошибки будет происходить автоматом, а паника в меньше чем 1% в силу пункта 2 при этом битые данные на FS записаны не будут. В случае не ECC памяти любой битый бит приведёт к перезаписи блока на FS битыми данными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

54. Сообщение от Аноним (54), 18-Июл-24, 23:50	+/–
Демагогия, нужно "btrfs vs zfs write amplification", а таких сравнений нет или ищи сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #57

55. Сообщение от Аноним (38), 18-Июл-24, 23:53	+1 +/–
Так это однократная ошибка, не циклическая. В случае, если у нас есть другой источник для тех же данных, где сошлись контрольные суммы, мы берем данные из него и радостно пишем. Где повреждение данных, где циклическая перезапись? Допустим, что данные повредились в RAM перед самой записью в ФС, какие тогда вопросы к ФС могут быть? Что дали, то и записали, то и прочитаем в следующий раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #56

56. Сообщение от Assss (?), 19-Июл-24, 00:00	+/–
>Так это однократная ошибка, не циклическая Может новость прочитаешь? >В случае, если у нас есть другой источник для тех же данных, где сошлись контрольные суммы, мы берем данные из него и радостно пишем Предлагаешь всегда сверяться с бекапом? Очень забавно. >Где повреждение данных, где циклическая перезапись? Данные всегда читаются в диска и всегда их избыточные коды проверяются и далее перезаписываются. >Допустим, что данные повредились в RAM перед самой записью в ФС, какие тогда вопросы к ФС могут быть? Новость прочитай, если у прочитанных данных не сошлись избыточные коды то они автоматом фиксятся и сразу перезаписывают блок на диске. Если всё сошлось никакой перезаписи НЕ происходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #59, #66

57. Сообщение от Assss (?), 19-Июл-24, 00:02	+/–
Есть, лично видел на форме какой-то известной фирмы производящей NAS. Что-то типа TrueNAS или типа того.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #61, #70

58. Сообщение от Assss (?), 19-Июл-24, 00:04	+/–
1. Читать хабр это моветон. 2. В нормальных интернетах pressure и amplification используют взаимозаменяемо - https://www.reddit.com/r/btrfs/comments/12yespx/btrfs_write_.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #60

59. Сообщение от Assss (?), 19-Июл-24, 00:06	+/–
>Какие-то данные всегда читаются в диска и всегда их избыточные коды проверяются и далее фиксятся и перезаписываются в случае ошибки fixed
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

60. Сообщение от Аноним (54), 19-Июл-24, 00:16	+/–
1. числа-то из научной статьи на arxiv'е > 2. В нормальных интернетах pressure и amplification используют взаимозаменяемо - https://www.reddit.com/r/btrfs/comments/12yespx/btrfs_write_.../ Так теперь тебе совсем никто не поверит. "greater write amplification killing SSDs and compression making it even worse, is that true?". Он про включение сжатия файлов, слова pressure вообще нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #62, #72

61. Сообщение от Аноним (54), 19-Июл-24, 00:16	+1 +/–
Вот тогда и приходите
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #63

62. Сообщение от Assss (?), 19-Июл-24, 00:20	+/–
Тебе сказали, что amplification и pressure в нормальных интернетах взаимозаменяемы. Саму статью читать не нужно, ссылка приведена только ради заголовка. Нужно всё таки учить английский язык и не позориться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #64

63. Сообщение от Assss (?), 19-Июл-24, 00:21	+/–
Тебе в этой жизни никто ничего не должен, захочешь сам нагуглишь. Все явки и позывные тебе были слиты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

64. Сообщение от Аноним (54), 19-Июл-24, 00:27	+/–
Так я тебе и объяснил, что заголовок означает. Ты совсем того?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #65

65. Сообщение от Assss (?), 19-Июл-24, 00:31	+/–
Сорян, не ту ссылку запостил, сейчас правильную поищу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

66. Сообщение от Аноним (38), 19-Июл-24, 00:47	+/–
Новость конечно же не читал, а вот так пишут в оригинале: - Self healing on read IO/checksum error data is now automatically rewritten if we get a read error and then a successful retry > Новость прочитай, если у прочитанных данных не сошлись избыточные коды то они автоматом фиксятся и сразу перезаписывают блок на диске. Откуда мы берем данные для перезаписи, если не сошлись контрольные суммы? Из головы? Подбираем чтобы сошлись?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #67, #81

67. Сообщение от Assss (?), 19-Июл-24, 01:38	+/–
>Откуда мы берем данные для перезаписи, если не сошлись контрольные суммы? Из головы? Подбираем чтобы сошлись? Может тебе почитать, как работает ECC память и перенести это на случай прочитанным блоком с FS?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #80

68. Сообщение от Аноним (-), 19-Июл-24, 03:15	+1 +/–
> У бытыэра было сколько? 15 лет? чтобы это сделать и как то > ... ну не шмогла :))) Что - не шмогла? Ей можно нормально пользоваться на одноплатниках, ноутах, мелких VM и проч без гигазов рамы для подпора антикварного тормозного дизайна. В отличие от. Даже масдайцы растащили на цитаты. ZFS - для покусаных энтерпрайзными NAS любителями переростков. Btrfs и bcachefs - general purpose (next gen edition). До кучи можно попытаться из них и хранилки, у сабжа даже есть забавная идея иерархии кеширования на SSD, по наследству от bcache. Но это 1 из кейсов а не центр вселенной, так намного прикольнее. > NOTE: Я про хранилище дикпиков на мордакниге слышал. Это можно и в > /dev/null хранить - разницы никто не заметит :) А еще я слышал что ZFS пытался рефлинки сделать цать лет - и все равно феерично облажались, редиректя файло игогошников в /dev/null. А у сабжа, для сравнения, рефлинки с самого мержа в майнлайн. А когда случайно редирект вышел, кент в темпе вальса ребилд метаданных накидал и отыграл назад. А те лабухи с рефлинками, кажется, так и оставили обещания - обещаниями. > bcachefs - выглядит заманчиво, впрочем все они выглядят заманчиво вначале :) Это следующий логичный шаг, next gen next gen'а. Кент посмотрел на эксплуатационные проблемы btrfs, что ему не нравится, и смог твик/редизайн ряда структур и алго чтобы было как бы примерно такое же, но без вон тех недостатков. Поэтому интересно посмотреть что у него выйдет. > Но конкретно у этой есть опупенное преимущество - еЯ практически в одно > рыло тянет _вменяемый_ перец ... Они все в начале маленкие и простые. Btrfs тоже в 1 рыло сначала Cris Mason core дизайна накидал. Но по мере роста фич и оптимизаций... даже EXT4 это вам уже не клон фс minix'а, ага. > Ни те согласований CoC-a, ни те кода для розовых поней, встроенного > вебсервера и генератора QR- кодов ... Я б сказал что btrfs'ники этим всем - заморачиваются даже меньше Кента. Они просто работают работы. > Даже не верится что до сих пор не придушили :) Технически невозможно. Кент постепенно "притирается" к стилю разработки майнлайна, смотрит как делают другие, начинает действовать примерно так же, с теми же таймингами и свойствами пуллреквестов. Процесс налаживается. Да, первые пару релизов ядра Торвальдсу пришлось пинков давать для вправления мозга. Сейчас эта фаза уже в целом пройдена и начались нормальные работчие процессы. Тесты. Фиксы. Рутина. Но несколько лет именно этого и превращают лабораторный прототип в продакшновый дизайн.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #101

69. Сообщение от Аноним (-), 19-Июл-24, 03:16	+3 +/–
> Ахаха, очень вменяемый, особенно вменяемый он был когда в рассылке своей файловой > системе послал чувака вот так - "fuck you", вместо того чтобы > ответить по сути выявленых недоработок. Вот он, будущий Торвальдс - 2.0 :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

70. Сообщение от Аноним (-), 19-Июл-24, 03:17	+/–
> Есть, лично видел на форме какой-то известной фирмы производящей NAS. Что-то типа > TrueNAS или типа того. Это те которые с фряхи как раз свалили недавно? Ахаха! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #83, #102

71. Сообщение от Аноним (71), 19-Июл-24, 04:37	+1 +/–
>> перезапись битой копии из исправной > Откуда берётся исправная копия? Речь про raid? Чудес не бывает и чтобы урытую копию восстановить - избыточность должна быть! У btrfs на этот случай есть режим DUP, если 1 накопитель, а дохнуть от 1 бэда не хочется, можно так: 2 копии в разные локации девайса. От полного отказа не спасет, места половина, записей в 2 раза больше, но иногда - вариант. При том довольно живучий. Скажем я сыпучую флеху с 32 гиг до 16 ополовинил. EXT4 за месяц на ней - в труху! Btrfs в DUP орет, пищит, но живет. Теорвер в дуругую сторону: надо чтобы (редкие) ошибки чтения вынесли СРАЗУ ОБЕ копии в РАЗНЫХ локациях. Такая лотерея намного веселее чем проигрыш при первом же бэде. Конечно, если девайс чаще чем раз в несколько месяцев бэды кидает - его заменить надо, а это утрированный экспериментальный сетап, удобный чтобы смотреть как ФС на вон то реагируют в реалистичном виде. Есть компромисс - DUP только метаданных, улучшает выживаемость и минимизирует урон (сейчас это по дефолту на 1-девайсных конфигах). Так соотношения лучше, но фэйл в регионе данных конечно попортит затронутое файло. Но массовый рассыпон ФС от кончины блока метаданных все же не случится. Преимущество относительно RAID? Несколко улучшает свойства 1-дисковой конфиги. И zero conf по сути. Никакой канители с выравниваниями, разделами, девайсами. Одну команду въ...ть. Или 0 если только метаданные ОК. > Или эта фича работает и без raid? У конкретно Кента еще есть Erasure Coding. Я так понимаю что в полной версии это сможет даже получше DUP, записывая коды коррекции, а при факапе - высчитывая недостающее по избыточности. Но это пока в сабже злостный WIP, я туда сильно не лазил. > Работает благодаря CoW? Могут ли восстановиться старые данные? Насчет cow кстати забавная идея. Не думаю что кто-то всерьез ЭТО исследовал. Наиболее очевидные траблы: 1) если cow сделал новый выносок, очевидно, он отличался от старого и вот так изначально - не очень подходит. Однако некая избыточность и правда некоторое время есть и то что вообще совсем нельзя отковырять контент именно нужного сектора в блоке - ниоткуда не следует. 2) GC обычно асинхронен относительно основной логики ФС, и все это соответственно без гарантий и эфемерно. Ну то-есть сколько уже ненужный cow выносок живет - весьма зависит от и не особо гарантированая величина. Но если у вас CoW дизайн, и лыжи крепко встали на асфальт, вы правильно поняли: попытаться зацепиться за немного более старое состояние, в надежде что там еще все было ОК - и бэд ЭТО еще не накрывал - валидный курс "advanced recovery", если вы понимаете что делаете. У обычных ФС с in-place перезаписью ессно нет такой опции. Там если данные или метаданные профаканы перезаписью, сие "окончательно". Никакая магия не вернет перезаписаный поверх себя файл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

72. Сообщение от Аноним (-), 19-Июл-24, 04:46	+/–
> 1. числа-то из научной статьи на arxiv'е ...которая так то суть синтетическая фигня у очередных академов, имеющая крайне мало с многими типовыми нагрузками у народа. Поэтому тратить свое время на чтение таких статеек это себя не уважать. Просто вода, для очередного мастер тезиса или что там у кого из академов было. > Так теперь тебе совсем никто не поверит. "greater write amplification killing SSDs > and compression making it even worse, is that true?". А реально - можно вместо слушания анонимов просто взять, инстальнуть это дело на свои SSDшники да помониторить статистику, вон там на хабре как раз расписано как это. И далее посмотреть как кому эволюция статистики VS гарантии. Скажем если у меня вон там за 5 лет протерлось аж целые 5% ресурса... окей, меня устроит ожидаемое время жизни в век. Это добро вероятно будет заменено быстрее. Это намного более прагматичный подход чем слушать анонов с опеннета и читать абстрактные пасквили. Которые к тому же писаны N лет назад, не трекали актуальное состояние дел и могут запросто протухнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #103

73. Сообщение от Аноним (-), 19-Июл-24, 05:25	+/–
> Как это не пользуется популярностью?!?!? Давать мастеркласс на тему популярности будет миллиард юзеров Facebook, например. > Если сторидж не от первой HW 10-ки, то он на 100500% сделан > на ZFS-e! Нихрена себе не пользуется 8-/ "Вы слишком много кушать!"(С) Ну а сабж и btrfs - general purpose, а не (нишевые и малоштучные) энтерпрайз хранилки. Чем и интересны. Мне вообще вот именно энтерпрайзные NAS не очень интересно. > Кста - в РФ вообще будет лидер рынка, какой нить отечественный "ЯФС" :-)))) Это вы там сами разбирайтесь, мне это не интересно. > А а вот на ваших десЪктопах стоип то что инсталлер по-дефолту ставит :) А на этих моих десктопах, виртуалках, одноплатниках и проч - чертова куча btrfs-ов в каждом закоулке. А вот вы столько хранилок напихать уже явно поднапряжетесь. Ну вот и поговорили про - популярность. Мне не надо ваш pie in the sky "где-то в энтерпрайзе". Мне надо современные продвинутые технологии улучшающие мою эффективность или свойства моих проектов - у вполне конкретного меня. Это доступно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #104

74. Сообщение от Аноним (-), 19-Июл-24, 05:35	+2 +/–
> А про RAID 3|5|6  у вас в Верхних Высерках вообще не в курсе? На RAID5 вы тоже продолбаете данные. Потому что если вы видите что (для простоты 3 девайса взято): (block 1) XOR (block 2) != parity окей, и какой из этого вывод?! :) Который из трех - кривой?! Ну так, вопрос на засыпку эксперту из Нижних Высерок. А btrfs в той же ситуации (его RAID56 не рекомендуется, но все же) - с чексумами, видите ли, и будет еще сбоку держать чексумы block 1 и block 2, и так тут уже понятнее где факап. Либо битый блок будет запален чексумой, либо это парити кривое. Ага? А вот попробуйте этот фортель без чексумм блоков?! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

75. Сообщение от Аноним (-), 19-Июл-24, 05:45	+/–
> Избыточные коды в файловой системе без ECC оперативной памяти лишены смысла. Очередной булшит от экспертов которые это все даже на картинке не видели. Кроме всего прочего, на практике чексумы ФС еще и сыпучую память и глюкавые процы хайлайтят в логах на раз - от этого всего там как правило знатный вой в логах поднимается, с воплями на csum error. Если то такие вопли в логи игнорит - им всяко мало что поможет: они узнают о проблемах лишь когда все фатально и окончательно фигакнется. Так бывает, но после этого вы уже пойдете в лабу к экспертам и узнаете сколько это стоит. И вам что-то не понравится. Ну, если те данные были нужны, конечно. > Сбойнёт память и файловая система этого никак не обнаружит и запишет сбойные данные. Вообще-то оно в таких ситуациях как правило массово орет про несовпадение чексум, мистер эксперт. Ну так, небольшое уточнение для теоретиков от практиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #85

76. Сообщение от Аноним (76), 19-Июл-24, 05:49	+/–
> Не сильно дороже. > На райзенах оно работает, а сама память не значительно дороже. > Я уже года 4 как перешёл дома на ECC. Даже без ECC если проц или память кривые, это как правило вызывает bit flip в данных - и чексуммы в ФС это дело радостно ловят, и ора в логах - немеряно. Так что это в каком-то роде подрабатывает таким себе scrubber'ом железа, чекающим что железо работает корректно, end to end. В какой-то момент конечно можно и записать что-то левое, но логи обычно завалены ором про сбой чексум задолго до. Да, а кроме сбоев RAM бывают и глючные процы например. Я вот поймал 1 засранца который изредка битики где-то флипал после прогрева. Btrfs'ом, угу. Ну, вот, брелочек в коллекцию. Или еще можно подарить врагу, если он не юзает фс с чексумами, пусть гадает в чем прикол, после узнает :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #106, #157

77. Сообщение от Аноним (-), 19-Июл-24, 05:53	+/–
> Кто-то уже ставил себе на локалхост? Ну я на эн виртуалок распихал. В принципе пашет, если без каких-то сильных извратов. Сильно ценные данные класть, конечно, туда пока не стоит. Но посмотреть на будущее уже сегодня - можно. А если у этого звездолета хвост отваливается в атмосфере - окей, вот как раз и напишите багу. Вас же предупредили что экспериментальное, так что план на такой случай на вашей совести :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #87

78. Сообщение от Аноним (-), 19-Июл-24, 06:19	+1 +/–
>> автоматизация и чёрный ящик это плохо, пнятненько? > Окей, надо сказать раработчикам рейда, чтобы при каждой ошибке чтения-записи каждого блока > пользователя спрашивали, что делать и какое устройство использовать. Круто же когда ваш прод будет затыкаться, остановив обслуживание юзерей, чтобы админа спросить что ему делать, да? :) Еще круче если так бортовой комп какой-нибудь так откаблучит. Вот прям спросить пилота посреди полета - мужик, тебе первый блок, или второй?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

79. Сообщение от Аноним (-), 19-Июл-24, 06:32	+/–
> Занятно выходит, создатель VCS не умеет пользоваться своей же VCS, занимается фетишизмом > c зарослей из заплесневелых веток Немного не так. Есть конкретные workflow, им просят следовать. И это так не только в Linux. Потому что разгребать за каждым косячным долбоклюем - в большом проекте может и подзадолбать. Воооон там лично меня бортанули с примерно такой же предъвой, и были по своему правы. Мержеры обычно очень нагруженные чуваки, и валить им с лопаты на голову еще работы на ровном месте очень нехорошо со стороны комитера. Если кто это случайно пробакланил, ему вежливо объяснят. Если кто это в принципе не понимает - разговор будет более другой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #114

80. Сообщение от Аноним (-), 19-Июл-24, 06:35	+/–
> Может тебе почитать, как работает ECC память и перенести это на случай > прочитанным блоком с FS? Этого недостаточно. Надо еще понять как чексумы ФС взаимодействуют с (битым) железом. И таки - обычно там и без ECC ора хватает и как минимум проблемы будет видно при первом намеке на нее. поэтому сках что ECC необходим - это булшит бинго. Но, конечно, с ним - лучше чем без него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #84

81. Сообщение от Аноним (-), 19-Июл-24, 06:52	+/–
> Откуда мы берем данные для перезаписи, если не сошлись контрольные суммы? Из > головы? Подбираем чтобы сошлись? Лол. Из другой копии, прежде всего. Или как вариант - erasure coding в сабже в принципе мог бы и на тот же девайс свою избыточность заскладировать. В btrfs еще схема DUP на эту тему есть, логика похожа на RAID1 но с 1 девайсом: 2 копии идут в разные физические смещения девайса. И если одна из них осыпалась - ну, вторая то есть. А это, вот, кент ту же самую логику запилил. Когда файлуха сама self heal редких факапов делает, прямо по ходу пьесы, если было из чего - это хорошо и правильно. Это снижает требуемую обслугу компьютерных систем и уменьшает число факапов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #82

82. Сообщение от Assssss (?), 19-Июл-24, 11:28	+/–
>Лол. Из другой копии, прежде всего А сколько копий достаточно поддерживать в оперативном режиме, дай угадаю, две? А почему не три или 4? >2 копии идут в разные физические смещения девайса. 1. Если копий только две то как определить какая из них верная? Та у которой прочитанные избыточные коды совпадают с расчётными? А кто сказал, что расчитанны будут верные избыточные коды? Они ведь считаются в RAM, а RAM не ECC. 2. Может быть ситуация, что с диска из копии 1 прочитаны битые данные и FS это определила, а из копии 2 прочитаны верные данные, но при расчёте избыточных кодов сбойнула RAM и были расчитаны неверные избыточные коды. С точки зрения FS обе копии неверные. Что делать? Использовать три копии? В этом случае три копии не помогут. Ты сам пишешь, что HDD может посыпаться и допустим hdd посыпался у копии 3 получается нужно минимум четыре копии. Или перечитать заново обе/все копии? Допустим это сработает в ситуации наличия хотя бы одной верной копии. 3. Теперь допустим HDD посыпался и вторая копия (первая изначально была неверной) стала неверной. Что делать, использовать три копии? А если при чтении копии три повторится ситуация из пункта 2? Использовать четыре копии или пять или заново перечитывать с диска данные? 4. А если нету верных копий? Например ещё до записи на устройства нескольких копий данных эти самые данные сбойнули и при вызове сискола write был передан указатель на битые данные, FS рассчитает избыточные коды для битых данных и будет упорно считать их верными. FS тебе никак в этом случае не поможет. Поможет только перепроверка в самом user space процессе записанных данных. Получается, что FS с избыточнымии кодами непригодна для использования без ECC помяти т.к. всё равно придётся перепроверять самому процессу который отправил данные на запись иначе FS будет упорно сберегать битые данные. И это далеко не все проблемы которые могут быть. >И если одна из них осыпалась - ну, вторая то есть. Речь шла о том, что не ECC RAM 100% угробит данные в конечном итоге. Я ранее цитировал hackernews где сказано что с вероятностью 96% в течении трёх дней не ECC память сбойнёт, для ECC памяти такая вероятность 1.67e-10 т.е. никогда, раньше солнце превратитьс я в белого карлика. Без ECC RAM памяти, если ты что-то типа СберБанка, тебе придётся поддерживать минимум 4-ре копии данных + будут частые перечитывания данных и это только на вскидку. Нерешаемость проблемы понятна без ECC RAM памяти?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #90, #156

83. Сообщение от Assssss (?), 19-Июл-24, 11:40	+/–
Сейчас перепроверил, кажется это не они, по цветовой расцветки которую я помню скорее всего это было где-то здесь - https://arstechnica.com/civis/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #88

84. Сообщение от Assssss (?), 19-Июл-24, 11:43	+/–
Процитирую самого себя: я ранее цитировал hackernews где сказано что с вероятностью 96% в течении трёх дней не ECC память сбойнёт, для ECC памяти такая вероятность 1.67e-10 т.е. никогда, раньше солнце превратиться в белого карлика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #89

85. Сообщение от Assssss (?), 19-Июл-24, 11:48	+/–
>Вообще-то оно в таких ситуациях как правило массово орет про несовпадение чексум, мистер эксперт. Ну так, небольшое уточнение для теоретиков от практиков. Скоро тебе в школу, готовься. Для остальных процитирую себя: Например ещё до записи на устройства нескольких копий данных эти самые данные сбойнули и при вызове сискола write был передан указатель на битые данные, FS рассчитает избыточные коды для битых данных и будет упорно считать их верными. FS тебе никак в этом случае не поможет. Поможет только перепроверка в самом user space процессе записаных данных. Получается, что FS с избыточнымии кодами непригодна для использования без ECC помяти т.к. всё равно придётся перепроверять самому процессу который отправил данные на запись иначе FS будет упорно сберегать битые данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #91

86. Сообщение от Аноним (8), 19-Июл-24, 12:28	+1 +/–
Сам придумал чего они не могут и сам в безопасности? Шапочку из фольги поправьте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

87. Сообщение от Аноним (8), 19-Июл-24, 12:30	+1 +/–
Что звездолету делать в атмосфере это его нетипичное использование. Как микроскопом забивать гвозди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #92, #93

88. Сообщение от Аноним (-), 19-Июл-24, 12:31	+/–
> Сейчас перепроверил, кажется это не они, по цветовой расцветки которую я помню > скорее всего это было где-то здесь - https://arstechnica.com/civis/ iXsystems - разве не за ними стоит? Они недавно как раз вариант на фряхе задвинули куда подальше, в глубокий майнтенанс, в пользу активного развития "такое же, но на дебиане". При чем тут какая-то arstechnica - я понятия не имею. Но тематичная новость была по моему даже на опеннете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

89. Сообщение от Аноним (-), 19-Июл-24, 12:59	+/–
> Процитирую самого себя: я ранее цитировал hackernews где сказано что с вероятностью > 96% в течении трёх дней не ECC память сбойнёт, для ECC > памяти такая вероятность 1.67e-10 т.е. никогда, раньше солнце превратиться в белого карлика. У меня так то есть ECC в ряде конфиг, но - как именно обязательное требование это неудобно. А вероятность зависит от частоты событий. Новая память тоньше, быстрее, вольтажи ниже и в целом все сильно хлипче. Там это соотношение вероятно уже хуже. А на практике - даже если RAM обычный, не ECC, но - кривой, ФС с чексумами при активном счете чексум будет довольно часто отхватывать несовпадение чексума с желаемым, словив битфлип прямо в буфере куда читалось, и истошно верещать в логи. Если логи не игнорить, проблему можно заметить и заменить/перенастроить проблемный компонент задолго до того как это превратится в реальную проблему. Это - опыт практической эксплуатации фичи с btrfs. Это просто факты. Спорить с ними или цитировать по этому поводу хакерньюс - странная идея.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

90. Сообщение от Аноним (90), 19-Июл-24, 13:35	+/–
> А сколько копий достаточно поддерживать в оперативном режиме, дай угадаю, две? А > почему не три или 4? Это можно! В btrfs такая схема обозвана RAID1C3/RAID1C4. И конечно имеет смысл только на многодевайсных высоконадежных конфигах. На однодевайсной смысла мало - девайс может умереть целиком. Не выйдет контроллер SSD/HDD на режим - и радости с 4 копий за ним? ;) У сабжа - можно запрашивать N реплик. Если вам надо 4 - окей, запросите 4. Будет то же самое по смыслу. Но тогда и остальное железо под стать налр. Т.е. память с ECC, надежные девайсины энтерпрайзного класса, резервированые фирменные питальники, вот это все. А то радости с 4 копий, если китайское питало выжжет все 4 за присест, сэкономив на защитах? :) Есть и другой путь. Можно купить хлам, и использовать распределенную инфраструктуру, на манер гугли. Даже если пару хлам-серваков выгорит - и что, избыточность была на уровне разных нод, структура в целом - самопочинится раскидав выпавшие реплики на соседей. А админам надо только серваки менять периодически. Но это для тех кто может себе это позволить. > 1. Если копий только две то как определить какая из них верная? По чексумам, внезапно. Блок с чексумами - отдельно, в метаданных. Их, кстати, тоже - 2 копии, так что если не сойдется чексум уже блока метаданных, нет, левака в чексумах не будет, блок метаданных будет просто взят из другой копии. > Та у которой прочитанные избыточные коды совпадают с расчётными? Ну как бы в общем случае мы хотим - совпадение чексумы. Где совпало там и ОК. > А кто сказал, что расчитанны будут верные избыточные коды? Они ведь считаются в > RAM, а RAM не ECC. Такая возможность - есть. Поэтому не следует игнорить такие вопли ФС на RAM без ECC, проблему надо - починить и быстро. Но это end to end валидация корректной работы железа, неплохо ловит крап на практике. Так что обычно если логи читают - до того не успевает дойти, к тому моменту воя ФС о несовпадении чексум - более чем. Например, надо прочитать целую ОС при загрузке. Еще до того как вы записывать что-то сможете по крупному. Ага? > 2. Может быть ситуация, что с диска из копии 1 прочитаны битые > данные и FS это определила, а из копии 2 прочитаны верные > данные, но при расчёте избыточных кодов сбойнула RAM и были расчитаны > неверные избыточные коды. С точки зрения FS обе копии неверные. Может быть много чего. Вопрос в вероятности. Если сбои редкие - так что их сразу не заметили - такое сочетание это произведение нескольких мелких вероятностей и поэтому крайне маловероятно на практике. Так то, теоретически, все молекулы воздуха могут улететь из вашей комнату в соседнюю, оставив вас в вакууме. Практически - попробуйте дожить до этого момента. > Что делать? Использовать три копии? В этом случае три копии не помогут. Использовать нормальное железо и не игнорить логи с воплями ФС годами, например. > Ты сам пишешь, что HDD может посыпаться и допустим hdd посыпался > у копии 3 получается нужно минимум четыре копии. См. выше, для эстетов есть и такие режимы. Если, конечно, они понимают что делают и готовы оплачивать такой банкет. > Или перечитать заново обе/все копии? Допустим это сработает в ситуации наличия хотя > бы одной верной копии. На практике даже с 2 копиями при сбое чтения 1 копии (с вероятностью 1/N) вероятность что и вторая не прочтется тоже 1/N он чтобы было оба сразу это уже (1/N^2) и дожить до такого совпадения при редких сбоях будет довольно сложно. Реально в логах будет немеряно воя задолго до того как это эскалирует в более крутые проблемы. > стала неверной. Что делать, использовать три копии? А если при чтении > копии три повторится ситуация из пункта 2? Да хоть 4, если жаба не душит! :) > 4. А если нету верных копий? Например ещё до записи на устройства > нескольких копий данных эти самые данные сбойнули и при вызове сискола Ну вот тут - упс. Это "uncorrectable". Запроектная авария. И вы таки - приплыли. Это сломаная система/ФС, она потребует к себе мануального внимания в общем случае для восстановления работы или вытаскивания данных, и вон то - не обязано быть lossless при этом раскладе. Но если у вас такие требования - вы наверное хотели так то распределенные структуры уже, они это иначе делают. Раскидывают эн реплик на кучу серваков по сети, по какой там причине i'й сервак сдох (отгружает битые блоки или ушел в даун) вообще не интересно, просто перераскидать реплик того что там было на другие, восстановив уровень избыточности до номинала. > FS тебе никак в этом случае не поможет. Поможет только перепроверка в > самом user space процессе записанных данных. И все прекрасно кроме того что программы это - не делают в большинстве случаев. И кстати по этому поводу какой-нибудь торент клиент заодно еще и неплохой тест end to end работы железа опять же. По примерно тем же причинам. Но вы ж не будете повседневные файлы типа офисного документа так? > Речь шла о том, что не ECC RAM 100% угробит данные в конечном итоге. Если не тупить и заметив вой в логах устранить проблему - все нормалек. А если тупить - тогда можно и приплыть однажды. > памяти такая вероятность 1.67e-10 т.е. никогда, раньше солнце превратитьс я в > белого карлика. Это все прекрасно. И никто не спорит что при высоких требованиях с ECC куда лучше. Но на практике польща от чексум есть и без ECC - проверяет end to end работу железа и быстро замечает что что-то не так. > Нерешаемость проблемы понятна без ECC RAM памяти? Теоретики такие теоретики... а на практике нормальный человек получив вопли в dmesg пойдет да заменит/перенастроит глючную железку. И тогда его ФС будет мягкой и шелковистой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #94

91. Сообщение от Аноним (-), 19-Июл-24, 13:47	+/–
> Скоро тебе в школу, готовься. Лол. По себе других не судят. > Для остальных процитирую себя: Я лишь скажу для экспертов от теоретицизма что на практике - ор в логах про сбои чексум нормальные юзеря ФС с чексумами замечают задолго до того как проблема эскалирует во что-то более крупное. Это спасает их от дофига траблов. И например один из вараинтов как нвидия была поймана на разрушении памяти своим модулем - это, внезапно, ор файлух на сбои чексум. Заметили пиплы корреляцию - ор csum error <-> модуль нвидии в списке. А без него - ор пропадает. Ну вот так вот. Заметьте, ECC в это уравнение вообще не входит. На ECC такой факап тоже прекрасно работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #95

92. Сообщение от Аноним (-), 19-Июл-24, 13:51	+/–
> Что звездолету делать в атмосфере это его нетипичное использование. Как микроскопом забивать гвозди. Вообще, хороший дизайн должен быть универсален - и может и вон там припарковаться для удобства владельца, и взлететь откуда попало, и приземлиться в свободном месте. Чтоб не заниматься всякими сложностями, ритуалами, инфраструктурой, костылями, тратами времени на хз что и проч. То-есть жить без этого при сильном желании можно. Да что там, можно даже на FAT свои данне хранить. Но это такая себе радость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

93. Сообщение от a (??), 19-Июл-24, 13:58	+/–
Хороший звездолет должен либо продолжить работать в атмосфере пускай с деградацией характеристик, либо отказаться входить в атмосферу и предоставить большую красную кнопку, снимающую все гарантии и таки выполняющую вход в атмосферу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

94. Сообщение от Assssss (?), 19-Июл-24, 15:30	+/–
>Если не тупить и заметив вой в логах устранить проблему - все нормалек. В логах НЕ БУДЕТ воя если вновь записываемые данные были подпорчены до вызова сискола write. Сколько мне ещё раз это написать, чтобы ты понял? >Но на практике польща от чексум есть и без ECC - проверяет end to end работу железа и быстро замечает что что-то не так. Без ECC RAM ты не сможешь проверить работу end2end потому, что ещё до вызова write у тебя уже битые данные и FS никак не сможет это определить. Более того !!!!!!FS будет всячески бороться за эти битые данные считая их верными!!!!!!!!!!!!. Более на этот бред отвечать не буду, этот аноним не спомобен понять очевидны вещи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #96

95. Сообщение от Assssss (?), 19-Июл-24, 15:34	+/–
>Я лишь скажу для экспертов от теоретицизма что на практике - ор в логах про сбои чексум нормальные юзеря ФС с чексумами замечают задолго до НЕ БУДЕТ НИКАКОГО ОРА В ЛОГАХ ЕСЛИ ВНОВЬ ЗАПИСЫВАЕМЫЕ ДАННЫЕ БЫЛИ ИСПОРЧЕНЫ ЕЩЁ ДО ВЫЗОВА СИСКОЛА WRITE!!!!!!!!!!!!!!!! Для FS такие данные будут верными потому, что сама FS будет для этих данных перед записью расчитывать избыточные коды. На этом всё, финиш, с глупыми людьми не люблю общаться. Буду игнорировать тупые сообщения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #98

96. Сообщение от Аноним (-), 19-Июл-24, 16:39	+/–
> В логах НЕ БУДЕТ воя если вновь записываемые данные были подпорчены до > вызова сискола write. Сколько мне ещё раз это написать, чтобы ты понял? Слышь, теоретик, чтоб ты понял: в логах при битой RAM или проце - от btrfs обычно немеряно воя при чтении. Это - результат практических наблюдений "а как оно" на проблемном железе. С последующей починкой или заменой, ессно. Этого более чем достаточно чтобы заметить проблемы, до того как урон примет катастрофический характер (e.g. труха в метаданных). Но можно конечно фигачить и как те фаны XFS/EXT4 с нвидией (да, чексумы поймают и разрушение памяти через DMA или левые записи ядра, какая им разница): в какой-то момент файлуха резко и внезапно делает фигакс - у юзера падает челюсть на пол - fsck это не чинит - о, добро пожаловать в дата рекавери лабу, приготовьте-ка ваш кошелек. Тоже опция, но довольно гиморная, долгая и - дорогая. > Без ECC RAM ты не сможешь проверить работу end2end потому, что ещё > до вызова write у тебя уже битые данные и FS никак Будет немеряно случаев когда записалось правильно - прочлось неправильно - и в логах вой. Это - цук - проверено практикой. А если какая-то теория наблюдаемый факт не объясняет, это хреновая теория и ее место в мусорке. Конец истории.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #97

97. Сообщение от Assssss (?), 19-Июл-24, 17:07	+/–
>Слышь, теоретик, чтоб ты понял: Слыш ты будешь говорить своим друзьям гопникам >в логах при битой RAM Только глупый человек может считать, что битые данные в не ECC RAM это потому что сама RAM битая. Иди учи мат.часть - данные в не ECC RAM могут быть испорчены из-за солнечной/космической радиации и при этом сама не ECC RAM будет абсолютно рабочей. >Это - результат практических наблюдений "а как оно" на проблемном железе Я тебе ещё раз повторяю - ЖЕЛЕЗО НЕ ПРОБЛЕМНОЕ, ЖЕЛЕЗО РАБОЧЕЕ И КАЧЕСТВЕННОЕ, НО БЕЗ ECC RAM ОНО НЕ ЗАЩИЩАЕТ ОТ СБОЕВ ИЗ-ЗА КОСМИЧЕСКОЙ РАДИАЦИИ И ДАЖЕ НЕ ДЕТЕКТИТ ТАКИЕ СБОИ. Дальше можно не комментировать, очевидно что этот аноним вообще не в курсе космической радиации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #108

98. Сообщение от Аноним (-), 19-Июл-24, 17:16	+/–
> НЕ БУДЕТ НИКАКОГО ОРА В ЛОГАХ ЕСЛИ ВНОВЬ ЗАПИСЫВАЕМЫЕ ДАННЫЕ БЫЛИ ИСПОРЧЕНЫ > ЕЩЁ ДО ВЫЗОВА СИСКОЛА WRITE!!!!!!!!!!!!!!!! Это - мягко говоря не единственная возможная ситуация в системе. Поэтому на практике прекрасно орет от дущи и много. Задолго до эскалации проблемы в дестрой метаданных и прочие нездоровые вещи с массивным уроном. И юзерь зачастую успевает приползти с вопросами и устранить проблему до того как его постигнет волшебный хренакс. Поэтому де факто это end to end checker железа бонусом. Типовой тематичный чатик обычно как-то так: - Подскажите, "csum error" - это баг btrfs? - Нет, чел, это у тебя кривая RAM/сыпется стораж/драйвер нвидии/что там еще. Чини ASAP!! > Для FS такие данные будут верными потому, что сама FS будет для > этих данных перед записью расчитывать избыточные коды. Бла-бла-бла. Теоретики они такие. И, конечно, предмет обсуждения не юзали - никогда. > На этом всё, финиш, с глупыми людьми не люблю общаться. Буду игнорировать тупые сообщения. Я не позволю постить технически некорректную дезу в МОЕЙ новости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #99

99. Сообщение от Assssss (?), 19-Июл-24, 17:26	+/–
>Это - мягко говоря не единственная возможная ситуация в системе. А я говорю об этой конкретной ситуции которая не зависит от качества НЕ ECC RAM и с которой FS без ECC RAM не сможет справиться в принципе. И никаких предупреждений в логах FS не будет. Поэтому твой понос про другие ситуции не рассматриваю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #109

100. Сообщение от _ (??), 19-Июл-24, 17:39	+4 +/–
>послал чувака вот так - "fuck you" Всё - перехожу на Bcachefs! Наш чел :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #120

101. Сообщение от _ (??), 19-Июл-24, 18:01	+/–
> У бытыэра было сколько? 15 лет? чтобы это сделать и как то ... ну не шмогла :))) > Что - не шмогла? Того что ты требовал выше :) > Ей можно нормально пользоваться на одноплатниках, ноутах, мелких VM и проч без гигазов рамы для подпора антикварного тормозного дизайна. Но не используют! А так то я вот могу и на Ferrari ездить, но езжу ... :) > ZFS - для покусаных энтерпрайзными NAS любителями переростков. Ну ... пусть будет так, ОК. Но! > Btrfs и bcachefs - general purpose (next gen edition). Вообще ни для чего. Для чего не примени - всегда есть что то лучше. Карма :) Причём бтр - уже понятно что та же песня как у языГа "D" :), а bcachefs только в начале пути, всяко может выйти ... > А еще я слышал что ZFS пытался рефлинки сделать цать лет - и все равно феерично облажались, Дык это же живая система, там архитектурные недостатки плавно перетекают в косяки реализации :) Дедуп например, до сих пор - для сильных духом :) Но ... еЯ всётаки широко используют в "кровавом", а бтр - нет. ТЧК.(С) >> bcachefs - выглядит заманчиво, впрочем все они выглядят заманчиво вначале :) > Это следующий логичный шаг, next gen next gen'а. Кент посмотрел на эксплуатационные проблемы btrfs, Ну надо же! А он сам __немного__ по другому рассказывал! :) > Поэтому интересно посмотреть что у него выйдет. Это - да. Без всяких пошутилок. > Они все в начале маленкие и простые. Ага, я и не обольшаюсь :) >> Даже не верится что до сих пор не придушили :) > Технически невозможно. Мне б твою уверенность. Я за годы в ойте и не такое видел :(  Вот прям соседний стул - райзен. > Но несколько лет именно этого и превращают лабораторный прототип в продакшновый дизайн. Ну скрестил пальцы на ногах, вот от всей оставшейся души - удачи ему! Пора, пора уже "вот это вот всё" и чтоб как с ext4 - которая в головах норота "точно работает"(С)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #122

102. Сообщение от _ (??), 19-Июл-24, 18:08	+/–
Да, причём после того как разработка ZFS уехала на линукс они ещё долго фряшный вариант тянули... Осторожничали? А теперь то чего, один фиг единственная ZFS которая есть - с линукса. Ну и дропнули фряшный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

103. Сообщение от _ (??), 19-Июл-24, 18:16	+1 +/–
> И далее посмотреть как кому эволюция статистики VS гарантии. Скажем если у меня вон там за 5 лет протерлось аж целые 5% ресурса... окей, меня устроит ожидаемое время жизни в век. Дитё. Ты считаешь что оно дегрэйдится линейно? Человекам так не везёт(С) Но и при этом всё же, если SSD выживет лет 15 ... я его пожалуй беру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #123

104. Сообщение от _ (??), 19-Июл-24, 19:12	+/–
>> Как это не пользуется популярностью?!?!? >Давать мастеркласс на тему популярности будет миллиард юзеров Facebook, например. Это мне не интересно, это всё в RAM-FS хранить можно с потерей всего по поверсайклингу, всем пох :) Но вот покажи хоть один банк, иншуранс, клинику\госпиталь ... а нету, от слова НАПРОЧЬ!(С) :) Ибо спички - детям не игрушка! > Ну а сабж и btrfs - general purpose, а не (нишевые и малоштучные) энтерпрайз хранилки. Чем и интересны. С улыбкой про "нишевые и малоштучные энтерпрайз хранилки" :) - но принято. Если вытеснит ext4 - респект и уважуха. Будем посмотреть(С). > Мне вообще вот именно энтерпрайзные NAS не очень интересно. Дык в Ытерпрайзе не только NAS есть, обычным серверам тоже FS нужна. Впрочем фиксируем разницу интересов ==> разницу как оно [для меня] выглядит. >> А а вот на ваших десЪктопах стоип то что инсталлер по-дефолту ставит :) > А на этих моих десктопах, виртуалках, одноплатниках и проч - чертова куча btrfs-ов в каждом закоулке. > А вот вы столько хранилок напихать уже явно поднапряжетесь. Ну вот и поговорили про - популярность. А у меня в (авторский CnP) моих десктопах, виртуалках, одноплатниках и проч - чертова куча NTFS и ext4 соответственно. И в других лавках. И у других дома. Что ты там про популярность? :-D > Мне не надо ваш pie in the sky "где-то в энтерпрайзе". Мне надо современные продвинутые технологии улучшающие мою эффективность или свойства моих проектов - у вполне конкретного меня. Это доступно? Вполне. И даже от всего сердца, без подЪЁ - желаю удачи! Но когда ты снова придёшь сюда врать про "бтр готова для продаГжОна" - я снова тебя буду макать(С) :) Это доступно?(C) ононим
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #121

105. Сообщение от _ (??), 19-Июл-24, 19:27	+/–
>Я уже года 4 как перешёл дома на ECC. Я с 17 года :) Не от того что умный как тутошние ононимы конечно, а просто железо такое купил по случаю :) Dell Precision с Xeon-ами и ECC RAM считай за коньяк :) HDD-RAID уже выкинул, но гудит эта падла всё равно знатно! Не альфасервер конечно, но всё же :) Выкинуть жаль. Если зомбоапокалипсис - я им отбиваться буду! :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #152

106. Сообщение от _ (??), 19-Июл-24, 19:28	+/–
> Я вот поймал 1 засранца который изредка битики где-то флипал после прогрева. А имьЯ его сестра!(С) Ну чтобы тоже не вляпаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #151

107. Сообщение от _ (??), 19-Июл-24, 19:37	+1 +/–
Они больше озабочены RGB- подсветкой на чипах, вот это действительно важно, а не ECC там какоето! :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

108. Сообщение от Аноним (-), 19-Июл-24, 19:58	+/–
> Слыш ты будешь говорить своим друзьям гопникам Большего с вашим сочетанием квалификации и апломба вы не заслуживаете. Вот реально уровень гопника и спамера. > Только глупый человек может считать, что битые данные в не ECC RAM > это потому что сама RAM битая. Для тех кто в танке повторяю еще раз. На практике при хардварных сбоях RAM или CPU btrfs шикарно орет в логи на тему csum failed. Это просто факты которые я наблюдал лично. Если какие-то измышлизмы какого-то упертого типа в них не укладываются - это хреновые теории, которые должны быть списаны в утиль. Потому что теории должны описывать наблюдаемые факты. > Иди учи мат.часть - данные в не ECC RAM могут быть испорчены Идите бамбук курить с вашими неработоспособными теориями, имхо. > КАЧЕСТВЕННОЕ, НО БЕЗ ECC RAM ОНО НЕ ЗАЩИЩАЕТ ОТ СБОЕВ ИЗ-ЗА > КОСМИЧЕСКОЙ РАДИАЦИИ И ДАЖЕ НЕ ДЕТЕКТИТ ТАКИЕ СБОИ. Сбои от вот именно космической радиации - явление довольно редкое. А я про именно настоящие сбои железа, когда например тайминги модуля "на грани" и после прогрева он начинает периодически флипать битик-другой. Такое добро великолепно отсвечивает в логи. > Дальше можно не комментировать, очевидно что этот аноним вообще не в курсе > космической радиации. Это не есть какая-то сильно крутая и массовая проблема. Как обладатель ECC оперативы - с настроенным логгингом этсамого - говорю. Более того - если это вот реально штучная проблема такого плана и избыточность есть - btrfs ее "починит" по ошибке чексум вон тем механизмом - вероятность что и при этом вторую копию частица побьет понятно какая - и в целом станет лучше. Конечно, данные на стораже и так исправны были, зато - восстановило нормальные данные в кеше. И в целом self heal все же имеет некий эффект. Да, не полный. Да, без гарантий. Но таки - до некоторой степени может потрепыхаться даже так. Но основная ценность - в детектировании сбойного железа. А вон те, с фс без чексум - получают при случае разлет в вермишель и долго думают "какого хрена?!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #110

109. Сообщение от Аноним (-), 19-Июл-24, 20:03	+/–
> А я говорю об этой конкретной ситуции которая не зависит от качества > НЕ ECC RAM и с которой FS без ECC RAM не > сможет справиться в принципе. И никаких предупреждений в логах FS не будет. А какой смысл фиксации на 1 конкретном узком кейсе если мы обсуждаем ФС вообще и их фэйлы в частности? С пеной у рта доказать что с ECC лучше? А с этим никто и не спорил. Отличная война с ветряными мельницами получалась. Но. Даже на системе без ECC чексумы вполне себе могут быть полезны. > Поэтому твой понос про другие ситуции не рассматриваю. Взаимно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #112

110. Сообщение от Assssss (?), 19-Июл-24, 20:07	+/–
>На практике при хардварных сбоях RAM или CPU btrfs шикарно орет в логи Охохохо, вот это имбицил. Ему говорят, что порча данных в НЕ ECC RAM это не сбой железа, а он этого понять не может или делает вид что не понимает. >Сбои от вот именно космической радиации - явление довольно редкое Ага понял если редкое значит этого нет. Вот только вероятность сбоев 96% раз в три дня у НЕ ECC RAM. >Как обладатель ECC оперативы - с настроенным логгингом этсамого - говорю Великое достижение. У меня три системника с катайской б/у ECC RAM 2400 Ghz если что. На этом стоп, с имбицилами глупо спорить и вообще общаться. Больше в ветку где обитает имбицил не зайду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #111, #131, #132, #150

111. Сообщение от Assssss (?), 19-Июл-24, 20:09	+/–
>Ему говорят, что порча данных в НЕ ECC RAM это не сбой железа Речь конечно же шла о порче данных от космической/солнечной радиации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

112. Сообщение от Assssss (?), 19-Июл-24, 20:14	+/–
>А какой смысл фиксации на 1 конкретном узком кейсе если мы обсуждаем ФС вообще и их фэйлы в частности Смысл в том, что этот 1 конкретный кейс невозможно победить без ECC RAM и FS в случае порчи вновь записываемых данных от солнечной радиации будет считать эти испорченные данные истинно верными и всячески бороться за испорченные данные. Я это уже 100 раз написал, но ты им6ицил этого не понимаешь поэтому в игнор тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #113, #133

113. Сообщение от Qq (?), 19-Июл-24, 20:31	+/–
А тебе неоднократно написали, что: fs без чексумм < fs с чексуммами при любом раскладе солнечной радиации и наличия/отсутствия ECC RAM, и что? Разве помогло? И это я даже не говорю про наличие коррекции каким- либо механизмом ошибки отловленной на уровне ФС
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

114. Сообщение от Аноним (24), 19-Июл-24, 20:55	+2 +/–
Т.е. если основные моменты своих фетишей записать на бумажке и обозвать workflow-ом, то фетиши перестают быть фетишами и превращаются в рационально обоснованные требования. Ну да, вполне логично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

115. Сообщение от Аноним (115), 19-Июл-24, 21:05	+/–
В ZFS 100 лет как self-healing
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #127, #158

116. Сообщение от AKTEON (?), 20-Июл-24, 02:01	+/–
Наконец-то ! Дождались !!
Ответить | Правка | Наверх | Cообщить модератору

117. Сообщение от нах. (?), 20-Июл-24, 08:17	+/–
write amplification когда-то какой-то неплохой инженер - _мерял_. Не по косвенным признакам или ковырянием в носу, а просто взял и снял счетчики - бо в виртуалке это элементарно. У него вышло примерно одинаково, 64x у обоих. (не делайте такие большие глаза - у ext4 - 8x. write amplification есть ВСЕГДА, кроме разьве что магнитной ленты с линейной записью. Но не всегда в 64 раза все же.) Мне там не нравится другое - отсутствие tx ring приводит к тому, что запись одного байта финиширует в суперблоке. Который физически прибит к конкретному сектору диска. Т.е. на любое самое элементарное действие - оно трахает суперблок (помимо, разумеется, миллиона блоков дальше вниз по иерархии), причем там нет и не может быть отложенной записи и тем более кэша. Боюсь это п-ц не ssd а как раз spinning rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #128

119. Сообщение от Tron is Whistling (?), 20-Июл-24, 10:50	+/–
"2 копии не сошлись" - это очень редкий случай в реальном мире. Потому что у носителей есть свои ECC, причём чем энтерпрайзнее носитель - тем более суровые, и в случае ошибки декодирования они выплюнут в сторону рейда ошибкой, а не битыми данными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #124

120. Сообщение от Аноним (120), 20-Июл-24, 12:00    Скрыто ботом-модератором	+1 +/–
fuck you
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

121. Сообщение от Аноним (-), 20-Июл-24, 13:57	+/–
> Это мне не интересно, это всё в RAM-FS хранить можно с потерей > всего по поверсайклингу, всем пох :) Мы про популярность говорили. С ней - вот так. > Но вот покажи хоть один банк, иншуранс, клинику\госпиталь ... а нету, от слова НАПРОЧЬ!(С) :) Они не отчитываются мне о используемых ФС, а вместе взятые не переплюнут тех. > Ибо спички - детям не игрушка! Забойный аргумент ФСостроения. > С улыбкой про "нишевые и малоштучные энтерпрайз хранилки" :) - но принято. Это и правда нишевые штучные вещи. У вас же не найдется хранилок на все мои кучи VM, и выводки по сотне мелких железок и проч? :) > Если вытеснит ext4 - респект и уважуха. Будем посмотреть(С). EXT4 почти не развивается, выжали почти все на что он годился, пытаться расширять ЭТО - нафиг надо, когда btrfs и сабж показали как это уже можно и нужно на самом деле. Теперь будущее это вот так. А то легаси, архитектура из прошлого века. Врядли кто будет новые дизайны ТАК делать уже. > Впрочем фиксируем разницу интересов ==> разницу как оно [для меня] выглядит. Когда в руках молоток - все вокруг кажется гвоздями... > А у меня в (авторский CnP) моих десктопах, виртуалках, одноплатниках и проч > - чертова куча NTFS и ext4 соответственно. И в других лавках. Ну я рад за вас, только их фичесет и рядом не стоял. А btrfs таки довольно попсовая штука в плане объемов использования. Лично мне технологии лохматых 90х уже как-то не того. И линейное управление системами без снапшотов и возможности БЫСТРО отыграть - тоже. > И у других дома. Что ты там про популярность? :-D Ну, тогда (ex)FAT на зиллионах карточек и флех - может много кому мастеркласс дать. Можете пользоваться. Я не настаивал что btrfs "самый популярный в мире" но таки довольно распостраненный. > Но когда ты снова придёшь сюда врать про "бтр готова для продаГжОна" > - я снова тебя буду макать(С) :) > Это доступно?(C) ононим Дык вы там известные спиди гонщики. И у всяких маздайцев и прочих околобсдшников с дуалбутами вечно подгорает с того что в линухе приличные ФС есть а у них - только античный треш да махровая энтерпрайзятина. В общем то так вам и надо, сапожники без сапог, можете NTFS и EXT4 юзать. А я как-то хочу снапшоты на моих системах как часть менеджмент операций. Меня ваш менеджмент из 90х не устраивает уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

122. Сообщение от Аноним (-), 20-Июл-24, 14:15	+/–
> Того что ты требовал выше :) Я бы сказал что вполне. Не во всех номинациях? Может быть. Но рож с откровенно энтерпрайзными SSD с этой штукой - весьма даже есть. > Но не используют! А так то я вот могу и на Ferrari ездить, но езжу ... :) Это вранье. Я буду конкретным пруфом что - используют, и 1 контрпримера достаточно для пруфа что тезис вранье. Сами так поставили вопрос, сами виноваты, враль! > Ну ... пусть будет так, ОК. Но! Лично мне - все равно что случится с тем внемайнлайн выкидышем. Но достаточно не все равно что случится с этой парочкой. И только. Пруф? Допустим, эта новость. > Вообще ни для чего. Для чего не примени - всегда есть что то лучше. Карма :) Я совсем не против чтоб вы с вашей кармой юзали EXT4, NTFS и подобный хлам вечно. Это прикольно, правильно и одобряемо с моей стороны, как раз то что вы заслуживаете. Сам я, конечно, так делать не буду. > Причём бтр - уже понятно что та же песня как у языГа > "D" :), а bcachefs только в начале пути, всяко может выйти Что-то не помню чтобы на D прогали чего-нибудь для миллиарда фэйсбучных клиентов. > Дык это же живая система, там архитектурные недостатки плавно перетекают в косяки реализации :) А я то думал что там разработчики долбоклюи, которые не тестированую фичу по дефолту врубили, для начала. О том что фичи в ФС неплохо бы еще и тестить до релиза там и вообще упоминать неудобно. Энтерпрайз который вы заслужили. > Дедуп например, до сих пор - для сильных духом :) А в btrfs у меня вполне себе работает. Конечно в виде рефлинков или офлайновым дедубликатором, видал я гигазы рамы и проца жрать на кучу хешей в памяти. > Но ... еЯ всётаки широко используют в "кровавом", а бтр - нет. ТЧК.(С) Удачи в повторении мантр. > Ну надо же! А он сам __немного__ по другому рассказывал! :) А таки я вижу что у дизайнов много общих решений. Да, местами они несколько отличаются - но общая логика конвергирует к примерно одной и той же точке, немного с разных сторон. И идеи они друг у друга таскают на ура. > Мне б твою уверенность. Я за годы в ойте и не такое видел :(  Вот прям соседний > стул - райзен. За годы айти я усвоил 1 вещь. Упрямый тип свое - отспорит. > с ext4 - которая в головах норота "точно работает"(С) Ну мне проблемы колхозников и некромантов так то не очень интересны. Меня такой уровень менеджмента ос не устроит уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

123. Сообщение от Аноним (-), 20-Июл-24, 14:20	+/–
> Дитё. Ты считаешь что оно дегрэйдится линейно? Человекам так не везёт(С) Повылезло тут всяких, из которых уже песок сыпется, с высокоинновационными технологиями из прошлого века. Вы ж понимаете что у меня совсем другие тайминги системных операций и принципы менеджмента ОС и ФС? Потому что долго и канительно возитсья с окаменелыми какахами мамонта - это для вас. > Но и при этом всё же, если SSD выживет лет 15 ... я его пожалуй беру. Как музейный экспонат, чтоли? :) Ну тоже вариант. А я как-то не готов 15 лет относительно state of art лагать. Ибо не маклауд и хочу насладиться чем-то хорошим сейчас. А моему скелету в могиле SSD уже, наверное, будет ни к чему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

124. Сообщение от Аноним (-), 20-Июл-24, 14:26	+1 +/–
> "2 копии не сошлись" - это очень редкий случай в реальном мире. Вполне распостраненный и частый случай. Сторажи, что SSD что HDD стали емче, хлипче, и в погоне за дешевизной - глючнее и стремнее. > Потому что у носителей есть свои ECC, Который часто на минималках - места эвон как жрет, а цифирь на этикетку не добавляет. > причём чем энтерпрайзнее носитель - ...тем дороже! И тем удивленнее вопли его юзерей :) > тем более суровые, и в случае ошибки декодирования они выплюнут в > сторону рейда ошибкой, а не битыми данными. Прикольно так за все заскоки всех железки с всеми версиями фирмварей расписываться, хорошо что вы ФС не делаете. А вот разработчики ФС и датареки почему-то иного мнения на тему как оно бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #125

125. Сообщение от Tron is Whistling (?), 20-Июл-24, 17:34	+/–
> Вполне распостраненный и частый случай. Просто не берите вот эти вот смарт*** и прочее аналогичное. >> Потому что у носителей есть свои ECC, > Который часто на минималках - места эвон как жрет, а цифирь на этикетку не добавляет. И снова п.выше. >> причём чем энтерпрайзнее носитель - > ...тем дороже! И тем удивленнее вопли его юзерей :) Тем дороже, да. Гонитесь за дешевизной - тогда да, понимаю, частый и распространённый случай. Мне чуть проще - ни одного "несхождения" рейдов за 20 лет истории с кучей сторейджа я так и не встретил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #129

126. Сообщение от нах. (?), 20-Июл-24, 19:10	+/–
чувак, ты реально опоздал родиться. Этот "создатель" НИКОГДА не умел пользоваться vcs, не понимал зачем они ему нужны, ведь так прекрасны "новая-папка-1.3.103", и мешал пользоваться другим. (Отдельные команды, например net3, пользовались внутри себя cvs, но доведя дело до уже готового оттестированного кода - вынуждены были разбирать его обратно на отдельные мелкие патчи чтоб божеству "в экран влазило" и переподавать с прогибом. В результате иногда что-то и теряли, и оно потом не работало как надо.) А потом пришел Larry McVoy - и, хороший, с-ко, был менеджер! УБЕДИЛ божество что cvsы с svnами и правда дрянь, а вот его поделка идеально ложится в б-жественно корявый "воркфлоу" с порежьте помельче и пришлите в рассылку. Причем там, кажется, прям на ходу допиливались какие-то мелкие детальки, чтоб получше угодить (ну еще бы - "линукс использует нашу поделку!" - какая реклама-то). Ну а что оно диффы не показывало, пока денег не заплатишь (да, да - это была коммерческая поделка с полностью закрытым и кодом и внутренней структурой) - божество не напрягало, оно никогда не смотрит древние диффы. (и только когда хороший менеджер куда-то пропал, возможно - продав шефа налоговой, секретаршу в публичный дом, ибо хороший же, с-ка, был менеджер - новые владельцы все же умудрились поссориться с божком. И тот натяпляпал себе шва6одное подобие как умел. В основном скопировав логику биткипера - так как сам ее понимал. И оно по сей день автоматизирует именно тот корявый ворквфлоу с новой папкой и порежьте-перепошлите в рассылку.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #130

127. Сообщение от нах. (?), 20-Июл-24, 19:11	+/–
а, кстати, кто проверял? (в бырбыр-подобной конфигурации, разумеется, понятно что с raidz все в порядке)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

128. Сообщение от Аноним (128), 21-Июл-24, 03:28	+/–
> write amplification когда-то какой-то неплохой инженер - _мерял_. Не по косвенным признакам > или ковырянием в носу, а просто взял и снял счетчики - Когда-то и какой-то - в это то вся проблема. Во первых, смотреть надо здесь и сейчас ибо код не выбит в камне и меняется между версиями ядер. Во вторых смотреть надо кейсы которые волнуют себя любимого. Зачем вам Васян и его проблематика? И почему вы думаете что у вас всенепременно точно так же будет? > бо в виртуалке это элементарно. У него вышло примерно одинаково, 64x у обоих. Это и на реальных железках не так уж сложно. Вон там на линке хабры мастеркласс небольшой на тему как оно делается. Изучайте, эксперты от сохи^W линуха, фигли. Сможете сами мерять в реальном сценарии, вместо выслушивания измышлизмов на опеннете. Это намного лучше работает. > (не делайте такие большие глаза - у ext4 - 8x. write amplification > есть ВСЕГДА, кроме разьве что магнитной ленты с линейной записью. Но > не всегда в 64 раза все же.) Лично я просто мониторю параметры SSD - и там неплохо видно зачастую, сколько этой кукушке лет жить. Точность конечно плюс-минус лапоть, ну так и нефиг играть "на грани фола".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #135

129. Сообщение от Аноним (-), 21-Июл-24, 03:40	+/–
>> Вполне распостраненный и частый случай. > Просто не берите вот эти вот смарт*** и прочее аналогичное. Откуда вы такие теоретики лезете? С вон той проблемой периодически высовываются даже энтерпрайзники с архидорогими SSD. Так что гуляйте уж с вашими теориями не от мира сего, надоели. Небось у вас еще и ФС без чексум, так что о проблеме такие кадры узнают - последними. >> Который часто на минималках - места эвон как жрет, а цифирь на этикетку не добавляет. > И снова п.выше. Ну как бы корпы - штука такая, продать г за много денег у них никогда не ржавело. Это как раз оптимальный вариант если удастся избежать резкого слива репутации. > Тем дороже, да. Гонитесь за дешевизной - тогда да, понимаю, частый и > распространённый случай. Да вон там господа с пафосными энтерпрайзными модельками - тоже вопросики то задают. Топовым моделькам и нагрузку так то топовую могут еще и вкатить. Сюрприз! > Мне чуть проще - ни одного "несхождения" рейдов за 20 лет истории > с кучей сторейджа я так и не встретил. А вы это еще и проверяли? Да и кто вас там знает что за инсталляции и сколько их? Может там малонагруженное нечто с ломовым запасом, или просто повезло с ревизиями железок, фирмварей и проч. А вон там - некто с дорогими энтерпрайзнми SSD вопросики - задают. И я это вижу. Но вы мне можете рассказать как этого не бывает. Хороший способ чтобы я вас считал позером и клоуном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #136, #137

130. Сообщение от Аноним (-), 21-Июл-24, 03:46	+/–
> Этот "создатель" НИКОГДА не умел пользоваться vcs, не понимал зачем они ему > нужны, ведь так прекрасны "новая-папка-1.3.103", и мешал пользоваться другим. (Отдельные > команды, например net3, пользовались внутри себя cvs, Ну да, только тот создатель - git напрогал, и чего-то теперь этот ваш CVS уже даже лопатой по сопатке в могилу не заталкивают, ибо уже и сам не лезет оттуда. Даже, вон, некромансеры из опенбсд какую-то пародию на гит уже накорябали, частично-совместимо. > отдельные мелкие патчи чтоб божеству "в экран влазило" и переподавать с > прогибом. В результате иногда что-то и теряли, и оно потом не > работало как надо.) Ну ты можешь вкатывать что попало с лопаты, посмотрим что с твоим проектом будет. А на данный момент - для РЯДА случаев с относительно одупляемыми майнтайнерами, которые исторически не делали явно идиотских вещей - можно pull request кинуть. Но там тоже могут дать лопатой по роже, как Кенту недавно. Впрочем, кажется, тот починил предъявы в темпе вальса и судя по git log - это pull'нули. ... > (и только когда хороший менеджер куда-то пропал, возможно - продав шефа налоговой, > секретаршу в публичный дом, ибо хороший же, с-ка, был менеджер - > новые владельцы все же умудрились поссориться с божком. И тот натяпляпал > себе шва6одное подобие как умел. А самое унизительное для тебя - что ты тепенрь будешь пользоваться ЭТИМ. Ибо сам не можешь даже и так. Ну или взаимодействуй сам с собой, во!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #134

131. Сообщение от Аноним (131), 21-Июл-24, 03:54	+/–
> Охохохо, вот это имбицил. Ему говорят, что порча данных в НЕ ECC > RAM это не сбой железа, а он этого понять не может > или делает вид что не понимает. Это крайне редкие события и софт на них сам по себе - не рассчитан. И дальше уже каждый длля себя решает - окей он с некоторой ненулевой вероятностью падения на него рояла или таки нет. > Ага понял если редкое значит этого нет. Вот только вероятность сбоев 96% > раз в три дня у НЕ ECC RAM. Где же тогда спам от ECC correctable ошибками раз в три дня? :) > Великое достижение. У меня три системника с катайской б/у ECC RAM 2400 Ghz если что. А у меня еще и с нормальной к тому же. С китайской про 96% за 3 дня я пожалуй даже поверю. > На этом стоп, с имбицилами глупо спорить и вообще общаться. Больше в > ветку где обитает имбицил не зайду. Вот и отлично. Не будет в тредже некомептентных бакланов рассказывающих о бесполезности чексум. Ибо я видел немеряно кейсов когда чексумы ловили битое железо, включая и кривые модули RAM, без всякой ECC. Так что вашим теоретизмам грош цена в базарный день, если на практике вот так. Более того - оно даже "софтварные" и "DMAшные" разрушения памяти при случае хайлайтит только в путь. От чего вообще никакой ECC не помогает. А чексумы предмет простой - не сошлось, оно и орет. По какому поводу буфер испортился им не интересно, это уже админ изучать должен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

132. Сообщение от Аноним (132), 21-Июл-24, 03:59	+/–
> RAM это не сбой железа, а он этого понять не может > или делает вид что не понимает. Это редкие события, софт на них сам по себе - не рассчитан. И дальше уже каждый решает - окей он с ненулевой вероятностью падения на него рояла или нет. > Ага понял если редкое значит этого нет. Вот только вероятность сбоев 96% > раз в три дня у НЕ ECC RAM. Где тогда спам от ECC correctable ошибками раз в три дня? Теории должны подтверждаться практикой ;) > Великое достижение. У меня три системника с катайской б/у ECC RAM 2400 Ghz если что. А у меня еще и с нормальной к тому же. С китайской про 96% за 3 дня пожалуй поверю. Только вот для вероятности влета частиц это как-то перебор. > не зайду. Вот и отлично. Не будет фигни о бесполезности чексум в треде. Реально они полезны и на железе без ECC, ловя чертову кучу кривых ситуаций, от кривых модулей RAM до заскоков DMA, и это уже прерогатива админа разбираться с конкретикой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

133. Сообщение от Аноним (-), 21-Июл-24, 04:07	+/–
> Смысл в том, что этот 1 конкретный кейс невозможно победить без ECC > RAM и FS в случае порчи вновь записываемых данных от солнечной > радиации будет считать эти испорченные данные истинно верными Во первых, даже в подобных сценариях есть отличная от ноля вероятность что чексумы заметят разрушение буфера по несовпадению чексум и восстановят если было откуда. И апликухи лишний раз не скушают труху. Во вторых, буфер с данными в RAM между апликухой и фактической записью "dirty" на перманентный стораж живет довольно ограниченное время, так что вероятность что испортит именно его, в именно этот довольно узкий интервал - микроскопическая. Какое-то исключение разве что нечто типа больших высоконагруженных помоек, где жирный буфер ФС может быть "всегда" но тогда уже вопросы к админам почему у них ЭТО - без ECC. В третьих, в этом мире кроме этого конкретного кейса есть еще более 9000 других, в которых чексуммы отлично работают. Это идет вразрез с тезисом о бесполезности чексум. > и всячески бороться за испорченные данные. Ну извините, если у вас данные испортились еще до записи - ФС вообще не знает что оно как-то иначе задумано было. Это же касается и сбоев уровня ядра и DMA. Там тоже без гарантий. Но реально - таки, орет. Оптом. Поэтому обычно юзеры btrfs успевают заметить проблему до того как она станет фатальной. А вот юзеры какого-нибудь EXT4 в такой ситуации получают ВНЕЗАПНУЮ вермишель, и обнаруживают что накопившийся урон fsck уже починить не могет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

134. Сообщение от нах. (?), 21-Июл-24, 07:21	+/–
> Ну да, только тот создатель - git напрогал, и чего-то теперь этот а программисты не умеют учиться, сюрприз. "мне некогда читать документацию"(с)генитальный разработчик Поэтому и побеждает каждый раз самая омерзительная, зато распиаренная технология. К ее качеству это ни малейшего отношения не имеет. Перечитай все истории с заменой нормальных vcs на этого уродца - "ах, бедняжечкам вчера-родившимся так сложно из-за этого заслать нам свой ценнейший патчик к README.md" > лопатой по роже, как Кенту недавно. Впрочем, кажется, тот починил предъявы > в темпе вальса и судя по git log - это pull'нули. ну некоторым нравится работка в режиме лизания царских сандалей. Этому не впервой. > А самое унизительное для тебя - что ты тепенрь будешь пользоваться ЭТИМ. Мне - и в голову не придет. > Ибо сам не можешь даже и так. Ну или взаимодействуй сам конечно. мне ж не платит по миллиону долларов в месяц Трансмета, приходится работать. > с собой, во! ну не с тобой же, в самом деле. Ты ж ничего не можешь за пределами своих ворот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #148

135. Сообщение от нах. (?), 21-Июл-24, 07:31	+/–
> Во первых, смотреть надо здесь и сейчас ну посмотри. Ах, да, ты ж дерьмовый инженер и не сможешь. > Это и на реальных железках не так уж сложно. Вон там на линке хабры мастеркласс небольшой на тему > как оно делается. там куча каких-то невнятных заклинаний. Вот так оно инженерами и НЕ делается. Потому что там каждый пункт перепроверять надо. И совершенно непонятно, зачем. Собственно, это и подтверждает - из тебя инженер как из навоза пуля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #141

136. Сообщение от Tron is Whistling (?), 21-Июл-24, 09:17	+1 +/–
> что за инсталляции и сколько их? Может там малонагруженное нечто с > ломовым запасом, или просто повезло с ревизиями железок, фирмварей и проч. И вот так 20 лет везёт, прикиньте. С виртуализацией, непредсказуемыми впсами, шаредхостингами, базами данных на терабайты, и прочим-прочим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #143

137. Сообщение от Tron is Whistling (?), 21-Июл-24, 09:25	–1 +/–
Всё это время есть несколько простых правил: - Никаких софтварных рейдов - Накопители должны быть RAID-оптимизированы (НЕ "SAN", именно энтерпрайзные варианты под RAID) - Никаких "дешёвых" вендоров. HDD - Seagate/WD/IBM, SSD - только Samsung. Рейды - в основном LSI(Avago)-based, была пара адаптеков в своё время, но не зашли. И вот что с HDD, что вот теперь уже лет 5 как SSD-only - никаких проблем с несхождением рейды не выдавали. Тут конечно может сказываться то, что уже 10 лет избыточности менее RAID6 нет, но и раньше те же RAID1 жили и не плакали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #138, #144

138. Сообщение от Хрю (?), 21-Июл-24, 11:17	+/–
Классическое правило - чем круче джип, тем дальше переться за трактором. Всё самое навароченное и крутое зачастую не оттестированно массами и в специфических случаях может вести себя не как ожидается. И ручками там ничего ни сделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #140

139. Сообщение от нах. (?), 21-Июл-24, 23:40	+/–
> Как это не пользуется популярностью?!?!? > Если сторидж не от первой HW 10-ки, вполне возможно и там внутри слегка модифицированная zfs но тебе об этом предпочтут не рассказывать (привет, netapp) > Кста - в РФ вообще будет лидер рынка, какой нить отечественный "ЯФС" не, не будет. на бырбырах скорее уж соберут. В РФ почти не осталось людей, способных на нетривиальную техподдержку - т.е. не просто next-next, а разобраться почему оно у клиента сдохло и как починить, а не вешать ему лапшу на уши "просто удалите пул и пересоздайте". Т.е. разбирающихся в коде и внутренней структуре и умеющих при случае что-то поправить. Так что в лучшем случае сп-ят типовое редхатовское решение с lvm + xfs. Когда навернется - повесят тикет через фирму-прокладку в Казахстане и будут ждать от индуса на лопате.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #142

140. Сообщение от Tron is Whistling (?), 22-Июл-24, 10:26	+/–
Понимаешь, в чём дело - если у меня система начнёт выкидывать фортели вроде тех, "от которых" позиционируются все эти ZFS ("несхождение" рейда, проходящие ECC битовые ошибки) - это повод данную систему выкинуть и больше не использовать. Три указанных выше правила - не панацея, но 20 лет спокойной жизни они дали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #145

141. Сообщение от Аноним (141), 23-Июл-24, 09:19	+/–
> ну посмотри. Ах, да, ты ж дерьмовый инженер и не сможешь. Не стоит судить по себе. Я никогда не испытывал с этим проблем - поэтому и могу постебаться над бредом теоретиков. Например на обычном десктопе - объемы записей вообще сравнимы с EXT4, плюс-минус. Особенно если commit=N прибавить (больше 300 не стоит). > там куча каких-то невнятных заклинаний. Вот так оно инженерами и НЕ делается. > Потому что там каждый пункт перепроверять надо. Нормальный инженер - из этих заклинаний возьмет общую идею, главное не облажаться в каких юнитах статистика оперирует, по разному бывает. > И совершенно непонятно, зачем. Изучение эволюции статистики накопителя по времени - и окей ли они с этим. Так просто и банально. > Собственно, это и подтверждает - из тебя инженер как из навоза пуля. Да уж кто бы говорил, в нубских заклинаниях нихрена не понять - это уж совсем позор. Более того - амплификация сильно зависит от характера нагрузки. Если ты 100500 гигз фот котят скопируешь отсюда сюда и быстро, амплификация будет около 1, а откуда ей другой быть? А если это какой-нибудь постгр основной нагрузкой, то конечно все иначе. Но у btrfs на этот случай nocow есть. В отличие от ZFS. Да, снапшотов, конечно, не будет, но то что некто хотел вот именно снапшоты, именно БД, особенно не дай боже реплицируемой - это еще большой вопрос. А теоретики выдающие универсальные цифири на все - это пять, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #147

142. Сообщение от Аноним (142), 23-Июл-24, 09:28	+/–
> вполне возможно и там внутри слегка модифицированная zfs но тебе об этом > предпочтут не рассказывать (привет, netapp) Ну так иначе клиент начнет задавать вопросы всяикие - мол, а что мне самому так же мешает, чтоб дохраналион вот этим не платить?! Так что по итогам квартала этот чувак себе яхту не прикупит, а тот попроще без канар останется, что ж поделать. > не, не будет. на бырбырах скорее уж соберут. Что, донкихотство в острой форме попустило наконец? Не будет никаких шишкинфсов, захочется что-то работающее и чтоб с ноля и самим все не фигачить как идиотам? Да ладно, так бывает?! > пул и пересоздайте". Т.е. разбирающихся в коде и внутренней структуре и > умеющих при случае что-то поправить. А они когда-то были? Конечно было полтора землекопа в Namesys но их прожект менеджер не смог отменеджить даже - себя, женившись на какой-то б, потом ее грохнув, и засев пожизненно в итоге. С таким decisionmaking фирмой управлять.. ну даже не знаю, в йемене каком разве что. > Так что в лучшем случае сп-ят типовое редхатовское решение с lvm + > xfs. Когда навернется - повесят тикет через фирму-прокладку в Казахстане и > будут ждать от индуса на лопате. А клиент покурит полгодика бамбук с дохлым продом пока распасы идут. Ему полезно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #146

143. Сообщение от Аноним (-), 23-Июл-24, 09:33	–1 +/–
> И вот так 20 лет везёт, прикиньте. Ну я рад за вас. Правда не понимаю как вы без чексум определяли что везет. По технологии страуса чтоли? Типа, если не вижу проблему - то ее нет? > С виртуализацией, непредсказуемыми впсами, шаредхостингами, базами данных на терабайты, > и прочим-прочим. Теперь еще расскажите как вы свое везение без чексум измеряли. По офигенному принципу "на авось", типа, вроде, ничего так откровенно не глючит? Да, и это не ваш шаред хостинг с битыми картинками случайно был? У них вот тоже видимо "все работает", клиенты давно не смотрят что там, а забредшший народ удивляется - чойта половина картинки грузится а дальше "decode error" какой-то. И труха в файле с этого места. Но, технически, файло же с диска как-то грузится, видимо с точки хрения хостера все "збс" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

144. Сообщение от Аноним (-), 23-Июл-24, 09:38	–1 +/–
> Всё это время есть несколько простых правил: ...позволяющих крепко поставить фирму на бабки и вендорлок, а потом в случае чего еще поиметь море enterprise grade гимора с складированием запасов этого архидорого крапа на складе. > SSD-only - никаких проблем с несхождением рейды не выдавали. А вы это проверяли вообще? Полный scrub от и до - делали? Или как это без чексус? > Тут конечно может сказываться то, что уже 10 лет избыточности менее RAID6 нет, Ну да, то-есть менее 4 девайсов вообще не человек. А теперь эксперт может с знанием дела рассказать что у него на ноуте, десктопе и проч, и можно будет посмотреть как его супер-технологии работают хотя-бы для его собственной ж@пы, например. В этом месте он и ему подобные возможно начнут подозревать что нам и btrfs и сабже нравится. Кажется, в мой ноут некуда RAID6 впихать. А юзать архаику умиращую от 1 бэда общесистемно наповал, без снапшотов и чексум, так что еще и о проблемах железа узнать - последним, когда все уже фигакнулось это конечно хитрый план. Или как обычно сапожник без сапог окажется. А мне вот вломы таким сапожником быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #155, #159

145. Сообщение от Аноним (-), 23-Июл-24, 09:39	–2 +/–
> не использовать. Три указанных выше правила - не панацея, но 20 > лет спокойной жизни они дали. Да, расскажи как это у тебя на компе работает. Скажем на системном стораже. Мистер враль и лицемер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #153, #154

146. Сообщение от нах. (?), 23-Июл-24, 11:09	+/–
> Ну так иначе клиент начнет задавать вопросы всяикие - мол, а что мне самому так же мешает, ну вперед - нанимаешь последних уцелевших программистов, а не фуллшмяков, причем умеющих и в сложные системы и в первом приближении хотя бы понимающих проблемы bare metal, осталось их таких очень немного, они там пол-года копаются чтобы в общих чертах только начать понимать проект. Я вот знал одного клиента подобного рода - желавшего дешево и сердито. (И таки да - он нанял такого разработчика на фултайм). Кончилось все как-то несчастливо. Одновременно заказываешь корпуса (металлопрокат, штамповка, иногда - еще и фрезерные работы - т.е. три совершенно отдельных производства требующие прямых рук и инженерного присмотра), проектируешь или ищешь готовой baseboard (у тебя даже в кастомном корпусе серьезные проблемы с охлаждением и cable management, поэтому первый попавшийся в руки хлам с али работать не будет... точнее недолго и несчастливо), hba (тоже беда), коннекторы и блоки питания. Это если именно "так же" - готовое к монтажу в стойку серийно производимое решение, а не один раз из г-на и палок как-то собрали и потом запчастей не найти. > А они когда-то были? стойки с нетапами гудят и дымят 24/7 В отличие от импортозамещенного хлама из бырбыр недоделков, который используют только под дулом товарщимайорского пистолета и в интересах товарищмайоров (поэтому то что оно там может периодически дохнуть - тебе никто не расскажет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #161

147. Сообщение от нах. (?), 23-Июл-24, 11:17	+/–
> Я никогда не испытывал с этим проблем - поэтому и могу постебаться над бредом теоретиков. потому что тебе никогда не давали лопатой по горбу за бездоказательные выдумки. > Например на обычном десктопе - объемы записей вообще сравнимы с EXT4, плюс-минус. пааанятна. Проблем нет. Измерений тоже нет - он опрашивал, а не мерял. > Нормальный инженер - из этих заклинаний возьмет общую идею нормальному инженеру очевидно что там нет никакой идеи - только бессмысленное шаманство. > Изучение эволюции статистики накопителя по времени что это за чушь? > Более того - амплификация сильно зависит от характера нагрузки. чо? Обосновать это ты конечно же даже не попытаешься. Доказать измерениями - тем более. > амплификация будет около 1, а откуда ей другой быть? опять он опрашивал...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #160

148. Сообщение от Аноним (-), 23-Июл-24, 14:31	+/–
> а программисты не умеют учиться, сюрприз. "мне некогда читать документацию" Не любая документация достойна чтения. Убивать время на освоение централизованого крапа типа CVS/SVN это себя не уважать. Торвальдс смог в более крутую штуку - распределенный воркфлоу. > Поэтому и побеждает каждый раз самая омерзительная, зато распиаренная технология. К ее > качеству это ни малейшего отношения не имеет. 1) Изначально он так то BitBaker выбрал или как там его, но увы он пропертарный да еще владелец удумал залупаться. 2) Внутренний дизайн гита чем-то напоминает файлуху, это приветы господам которые грили что линух так сам не может. Да вот даже при нужде послать залупившегося проприетария смогли. 3) А что на этом глобусе так уж прям сильно качественнее? И ничего что качество интегральная оценка? Если у энной штуки проприетарий в комплекте и он залупается, общая оценка фиговины начинает пробивать пол. > Перечитай все истории с заменой нормальных vcs на этого уродца - Нормальные это всякий окаменелый кал мамонта который жрать готовы только всякие дино? Вот уж чего не жалко. >> в темпе вальса и судя по git log - это pull'нули. > ну некоторым нравится работка в режиме лизания царских сандалей. Этому не впервой. Просто нормальные люди в рабочих процессах найдут устраивающие компромиссы - и перейдут к Getting Things Done. Такие как ты будут лепить отмазы на тему почему - обом, почему г так и задумано и проч. Как будто это кого-то интересует. Нормальных людей интересует - GTD. > Мне - и в голову не придет. Это к счастью не мои проблемы и никогда таковыми не будет. > конечно. мне ж не платит по миллиону долларов в месяц Трансмета, приходится работать. Потому что ты из себя ничего такого на миллион не представляешь. В отличие от. Когда сможешь агрегировать проект такого масштаба в хоть там чем, мы поговорим о более крутых и правильных подходах и инструментах. До тех пор - булшит бинго. > ну не с тобой же, в самом деле. Ты ж ничего не можешь за пределами своих ворот. Да вот только вчера дюжину комитов гражданам навесил, они довольны были. И мне гит как-то отлично, интуитивно понятен. И все ключевые операции интуативны, шустры, работают даже локаьлно если сети нет. Можно по версиям мотаться шустро, bisect делать и проч. А что мне еще от DVCS надо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #149

149. Сообщение от нах. (?), 23-Июл-24, 14:44	+/–
> Убивать время на освоение централизованого крапа то есть пользоваться ты не умеешь, но "централизованный крап". Все что надо знать о тебе и твоих фантазиях. > Торвальдс смог в более крутую штуку - распределенный воркфлоу. нет там никакого распределенного воркфлоу, нечитателям документаций про него брехай. Порежьте помельче и перепошлите в рассылку. Причем непременно диффами к сегодня объявленной правильной версии. Кто посмел rebase сделать - того нахрен с пляжа! > Изначально он так то BitBaker выбрал или как там его, но увы он пропертарный изначально ему _впарили_. С энергией которую б в мирных целях, но куда там... И кстати божеству пять лет было наплевать что он проприетарный. Вот когда его от кормушки отлучили и бесплатно полную версию перестали выдавать - оно обидевшись. > А что на этом глобусе так уж прям сильно качественнее? Спрашивает наш нечитатель документации и ниасилятор ничего кроме единственноверной технологии одобренной божком. Впрочем скорее всего ты и ее не осиливал никогда. Дай угадаю - что такое и какой хтонью порожден pwclient - ты без понятия? > Просто нормальные люди в рабочих процессах найдут устраивающие компромиссы нет. Нормальные люди уйдут из е..нутых проектов. Останутся любители лизать чужие пятки и переподавать по двести раз с прогибом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #165

150. Сообщение от нах. (?), 23-Июл-24, 16:27	+/–
> Ага понял если редкое значит этого нет. Вот только вероятность сбоев 96% > раз в три дня у НЕ ECC RAM. и с какого же потолка эта цифирь тобой взята? >>Как обладатель ECC оперативы - с настроенным логгингом этсамого - говорю у человека - логи. У тебя - фантазия. > Великое достижение. У меня три системника с катайской б/у ECC RAM 2400 не хочу тебя огорчать, но если это X99 - ecc линии там не распаяны. Никакого ECC по факту у тебя - нет. В смысле лишние чипы на планках есть, но они ничего не могут ни проверять ни исправлять. А у тех у кого есть - есть логи ошибок. И там либо пусто, либо почти пусто, либо надо срочно менять модуль, он банально дефективный. > На этом стоп, с имбицилами глупо спорить и вообще общаться. Больше в это вот да. Не заходи сюда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #166

151. Сообщение от нах. (?), 23-Июл-24, 16:28	+/–
>> Я вот поймал 1 засранца который изредка битики где-то флипал после прогрева. > А имьЯ его сестра!(С) > Ну чтобы тоже не вляпаться. да опять какой-нибудь китайский одноразовый мусор, нам с тобой это имя и не скажет ничего. Примерно из того же источника что и битые флэшки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #167

152. Сообщение от нах. (?), 23-Июл-24, 16:30	+/–
>>Я уже года 4 как перешёл дома на ECC. > Я с 17 года :) > Не от того что умный как тутошние ононимы конечно, а просто железо > такое купил по случаю :) "купившие ЭТО так же покупали:" - шесть баннеров с затычками для ушей и два с наушниками для стрельбы. > Dell Precision с Xeon-ами и ECC RAM считай за коньяк :) HDD-RAID коньяку за вывоз этого антитехнологического мусора я потребую примерно ведро. (там же когда навернется что-то, хотя бы даже вентилятор - ты замену не найдешь нигде и ни за какие деньги)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

153. Сообщение от Tron is Whistling (?), 23-Июл-24, 21:12	+1 +/–
На локалхостике у меня внезапно обычное коммодити, потому что требования к локалхостику другие. Конфигурация локалхостика такая: Системный сторейдж - вообще без рейда, оно мне там просто не упёрлось, винду перенакатить займёт в случае чего менее дня. Для данных и тестовых виртуалок - внезапно софтовый внезапно виндовый RAID 1 (Storage Spaces), тут вам уже не энтерпрайз. Раньше кстати вместо виндового рейда по привычным правилам стоял LSI 9260-4i и внезапно RAID 6 на младших энтерпрайзных HDD, но в итоге в новую систему решил всё это не тянуть, локалхост он и есть локалхост. Для исключения сюрпризов на локалхостике у меня тоже есть своя пара правил: - Всё ценное должно быть продублировано наружу (нет, не в публичные облачка, к ним у меня личная неприязнь) - Память с ECC (в моём случае - только Samsung, ога) - И снова - никаких **ка китайских дешёвых драйвов, нет, энтерпрайзные SSD я в локалхостик ставить ещё не долбанулся, стоят обычные коммодити SSD от того же самсунга --- И вот внезапно - ни одного несхождения рейдов (потерь данных) аналогично пока не случалось. Тут - да, тут я уже верю, что вот один раз в тысячелетие (если я конечно доживу до этого момента) у меня может проскочить через всю цепочку ECC неожиданный битврот, который обязательно убьёт мне очень ценную информацию - например сейвы игрух, которые в стиме хранятся. Или даже запорет целый MKV из сезона анимехи. Их я, так и быть, перекачаю заново - раз в тысячелетие могу себе позволить. А вот всё ценное на случай отказа двух драйвов из рейда сразу или вот этого вот гипотетического схождения целого созвездия для появления битврота - дублируется снаружи, и тут мне тоже собственно плевать, битвротнется оно в один момент или нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #162

154. Сообщение от Tron is Whistling (?), 23-Июл-24, 21:16	+/–
И да, у меня ещё и несколько огнетушителей по квартире раскидано, прикинь :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

155. Сообщение от Tron is Whistling (?), 23-Июл-24, 21:24	+/–
> ...позволяющих крепко поставить фирму на бабки и вендорлок, а потом в случае > чего еще поиметь море enterprise grade гимора с складированием запасов этого > архидорого крапа на складе. Вендорлок есть, факт. Крап афтер юзе, если до совсем уже EoВСЁ не эксплуатировать, легко продаётся секондхендерам. Суммы конечно не те, но лучше, чем ничего. >> SSD-only - никаких проблем с несхождением рейды не выдавали. > А вы это проверяли вообще? Полный scrub от и до - делали? Понимаешь, в чём дело, RAID 6 - он и при обычном policy read вполне себе сообщает о проблемах, когда они есть. Ну дык вот - вот просто несхождения я не видел никогда. Отвалы чтения секторов у вращающихся болванок видел, отвалы твёрдых, как он самый, накопителей - видел. Отвала вот именно вот прямо вот чтобы ECC в 6 рейде (проскочившую через ECC накопителей ошибку) - за все эти годы - не видел ни одного раза. > Ну да, то-есть менее 4 девайсов вообще не человек. Ну то есть да - вот так и живём. Кроме шуток. R6/2+2 - это вообще мелкосервер, где нужен локальный сторейдж, к счастью, таких осталось полторы штуки, малоэффективная конфигурация. RAID60/Nx6+2+spare или RAID60/Nx8+2+spare - уже конфигурация поинтереснее с той же т.з. производительности. А для остального есть iSCSI SAN, у которого там свой хитрый распределённый энтерпрайзный RAID 6. С вендорлоком и свистелками, куда ж без них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #163

156. Сообщение от Tron is Whistling (?), 23-Июл-24, 21:28	+/–
Всё ещё хуже. Не-ECC память угробит данные ещё до записи. И они во все десять копий запишутся угробленными :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #183

157. Сообщение от Tron is Whistling (?), 23-Июл-24, 21:30	+1 +/–
Поверь, если у тебя проц вызывает битфлип в данных - ты это заметишь очень быстро через вставание системы раком. И вот тут уже никакая мегадублированная ФС тебе не поможет, потому что данные с большой долей вероятности уйдут на чексумминг и запись уже битыми. При этом чексумма будет посчитана корректно, но от битых данных. Такое встречал, ну, не в личной практике, но встречал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #184

158. Сообщение от Tron is Whistling (?), 23-Июл-24, 21:31	+/–
Самый хороший селф-х**линг всплывал недавно - данные в ноль, и сделали вид, что так и было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

159. Сообщение от нах. (?), 24-Июл-24, 11:05	+/–
>> SSD-only - никаких проблем с несхождением рейды не выдавали. > А вы это проверяли вообще? Полный scrub от и до - делали? внезапно, hardware raid умеют в полный. Но современные умеют и в неполный, с контролем при чтении. > Или как это без чексус? внезапно, для контроля они не нужны, рейд обладает избыточностью. >> Тут конечно может сказываться то, что уже 10 лет избыточности менее RAID6 нет, > Ну да, то-есть менее 4 девайсов вообще не человек. Это не человек, это локалхостик. С которого таки да - надо просто копировать на другой локалхостик все что тебе жалко. Потому что твой единственный дивайс от помойного китайца в один непрекрасный день просто перестанет видеться системой, вообще. И без каких-либо предупреждающих событий, раз - и нет его. А для современного рейда всего 4 - это вообще заявка на премию дарвина. Учитывая объемы современных дисков - ты его не восстановишь. У тебя просто навернется второй еще до того как ты первый заменишь. Сейчас конфигурации меньше чем 6+2 или 3x2 рассматривать - это либо локалхост либо тебе те данные и нафиг были не нужны. > ноуте, десктопе и проч, и можно будет посмотреть как его супер-технологии > работают хотя-бы для его собственной ж@пы, например. В этом месте он > и ему подобные возможно начнут подозревать что нам и btrfs и на ноуте, десктопе и прочем где нет даже второго диска, а первый меняют вместе с ноутом? Да, безусловно это самое место для бырбыров и прочего недоотлаженного и толком никем не тестированного трэшачка. > А юзать архаику умиращую от 1 бэда общесистемно наповал, без снапшотов и ох уж эти сказочки, ох уж эти сказочники...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #164

160. Сообщение от Аноним (-), 24-Июл-24, 17:10	–1 +/–
> потому что тебе никогда не давали лопатой по горбу за бездоказательные выдумки. И тебе видимо тоже. А следовало бы, за блистание высокоиннвоационными знаниями 2010 года свежести и неумение мониторить даже вон то, на уровне юзеров хабры - но при этом хватает наглости пытаться косить под эксперта в лине. Но усы безжалостно отклеиваются в каждом первом треде. > Проблем нет. Измерений тоже нет - он опрашивал, а не мерял. Я статистику смотрел с нескольких штук с SSD. В том числе своих. И как она эволюционирует по времени. Ради интереса. Хоть как. И да, вон те господа на хабре расписали азы того на что смотреть. > нормальному инженеру очевидно что там нет никакой идеи - только бессмысленное шаманство. Чего такого шаманского в изучении числа записанных секторов накопителем? Хотя для таких как ты это магия, конечно. Вот ежели вместо статистик накопителя на какой-то левый туалетный пэйпер кивать, это да, не то что статистика накопителя! > что это за чушь? Это ну чушь а посмотреть сколько примерно на накопитель пишется скажем с EXT4 а потом - BTRFS при более-менее прочих равных. > Обосновать это ты конечно же даже не попытаешься. Доказать измерениями - тем более. Это почему же? В случае вон того - фоточки и видики сильно жирнее метаданных вообще, и в целом пишутся в новую локацию как выноски cow, 1 раз. И вот откуда при копировании 50 гиг этого добра возьмется амплификация? Это лучше ты обоснуй - где она в таком сценарии случается, и почему скорость работы ФС не валится в эти 64 раза при записи. >> амплификация будет около 1, а откуда ей другой быть? > опять он опрашивал... Затвердила сорока Якова одно про всякого. Кто этому гражданину зеркало подсунул?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

161. Сообщение от Аноним (161), 24-Июл-24, 17:24	–1 +/–
> ну вперед - нанимаешь последних уцелевших программистов, а не фуллшмяков, причем умеющих > и в сложные системы и в первом приближении хотя бы понимающих > проблемы bare metal, осталось их таких очень немного, они там пол-года > копаются чтобы в общих чертах только начать понимать проект. Ну, мне хватает обслуживать свои проблемы без всяких божков. На публику эти услуги предоставлять лично мне нафиг надо: нет у меня passion по части энтерпрайзов вообще и переросточных хранилок в частности. Я за глаза считаю что "большая хранилка == ошибки архитектуры". > (И таки да - он нанял такого разработчика на фултайм). Кончилось > все как-то несчастливо. Случаи разные бывают. Вон NYSE вообще тиму гентушников наняли. Видимо так можно было если сильно хочется. Им правда другое интересно. > присмотра), проектируешь или ищешь готовой baseboard (у тебя даже в кастомном > корпусе серьезные проблемы с охлаждением и cable management, Да, пох, не быть тебе инноватором. Так, глядя на то как мaйнepы сотни своего добра распихивают куда угодно не имея столь тупых проблем. Бывают и вполне себе с корпусами и - решив проблемы охлаждения. > а не один раз из г-на и палок как-то собрали и потом запчастей не найти. КМК ты теперь и к вон тем запчасти будешь искать так же. Есть такое подозрение. > стойки с нетапами гудят и дымят 24/7 А дымят то чего? Их уже посетил бобер чтоли? > В отличие от импортозамещенного хлама из бырбыр недоделков, который используют только под > дулом товарщимайорского пистолета и в интересах товарищмайоров (поэтому то что оно > там может периодически дохнуть - тебе никто не расскажет). Ну я от всего этого далек. Но в этом смысле майор по крайней мере догадывается что с запчастями будет, реально, ж@па. И если совсем ничего не делать - ок, айти в РФ в какой-то време просто встанет почти намертво. Он, вероятно и так встрянет, но потрепыхаться с имитацией бурной деятельности все ж надо, а то ж крайним можно оказаться!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #173

162. Сообщение от Аноним (162), 24-Июл-24, 17:41	+/–
> На локалхостике у меня внезапно обычное коммодити, потому что требования > к локалхостику другие. Видел я как мамонты с такими требованиями менеджат системы. Убивая полдня на реинсталл при малейшем отклонении от идеала. Не имея мозможность откатить факапы типа стертого системного файла или неудачного апдейта. И тому подобные характерные прелести. > Системный сторейдж - вообще без рейда, оно мне там просто не упёрлось, > винду перенакатить займёт в случае чего менее дня. А я в этом моем линухе даже стертый кернел - за пару минут назад отыграю. Как и неудачный апдейт. А каким-нить btrfs send я еще и виртуалку из ЭТОГО сделаю минут за 10 максимум. Видите, у нас сильно разные взгляды на системный менеждмент. Мой косплеит "энтерпрайз с виртуалками" даже на bare metal. А заодно чексумы в случае чего хайлайтят проблемы железа. > Для исключения сюрпризов на локалхостике у меня тоже есть своя пара правил: Лично мне не интересны танцы с бубном от маздайщиков, убивающих "менее дня" на реинстал оси. У меня сильно более другие подходы и времянки. Моя цель - показать ALL что так можно было, и почему именно таких мамонтов отправляют уже на пенсию. > И вот внезапно - ни одного несхождения рейдов (потерь данных) аналогично пока > не случалось. Еще раз: как это все проверялось? Обычный RAID без чексум спокойно вынет абы что с энной копии, он понятия не имеет правильное оно или нет. Если фирмварь+FEC дадут маху, ну, значит, со временем у вон того лабуха те или иные файлы станут как у вон того хостинга - когда до половины читается, а потом тынц, decode error "почему-то". > Их я, так и быть, перекачаю заново - раз в тысячелетие могу себе позволить. А у меня так то рабочие проекты. И если я настроился доделать вот этот проект, я уж точно не собираюсь "менее дня" всякие маздайки реинсталить. У меня таких времянок операций вообще нет. > - дублируется снаружи, и тут мне тоже собственно плевать, битвротнется оно > в один момент или нет. Одна из траблов битрота в том что его без чексум сложно заметить. А потом, i++ лет спустя, оказывается что вон та фоточка - до половины только декодируется. Почему-то. И вот это обидно бывает. Когда везде тишь и гладь, а оно вот так. И в бэкап уже - такое же уехало. В этом смысле чексумы ФС - дополнительный уровень на пути подобных раскладов, срабатывающий на более 9000 причин по которым это могло бы быть. А что EXT4 что NTFS это последний писк технологий хранения 1990х. Тридцатилетней давности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #171

163. Сообщение от Аноним (-), 24-Июл-24, 17:51	+/–
> Вендорлок есть, факт. Как и конские ценники. Так что в результате пригодно только для мегахранилок в пафосном энтерпрайзе. С характерным эксперименсом "наймите пару админов для менеджмента". Случай который мне - не интересен. И тут вы лезете такие "универсальные" советы давать. Во спасибо. > Понимаешь, в чём дело, RAID 6 - он и при обычном policy > read вполне себе сообщает о проблемах, Только вот он подразумевает МИНИМУМ 4 девайса, при эффективности 50%. А что-то менее масштабное соответственно в полном пролете. А если это еще делать как вон те - надо будет какие-нить однотипные девайсы, да еще заскладировать несколько таких про запас, вместе с архидорогим контроллером. Я со своей стороны считаю что такой системный менеджмент должен умереть. > секторов у вращающихся болванок видел, отвалы твёрдых, как он самый, накопителей - видел. А я видел и энтерпрайзные SSD выгружающие откровенный левак. Btrfs у народа начинает радостно выть про csum error - если юзер не баклан и спрашивает про это, ему и грят - меняй свой SSD ASAP: такое поведение характерно для девайсов на грани издыханяи. У меня много всяких (около)админствующих и проч на виду. По всему глобусу. И я прицельно мониторю траблы народа с btrfs поэтому, вот, набредал и на такое. Узнав что так бывает. > Ну то есть да - вот так и живём. Кроме шуток. R6/2+2 > - это вообще мелкосервер, где нужен локальный сторейдж, к счастью, таких > осталось полторы штуки, малоэффективная конфигурация. RAID60/Nx6+2+spare Угу, угу, а на десктопе/ноуте такого супер-спеца картина "сапожник без сапог" и "меньше дня реинсталла системы". Ну в пень такие технологии и инновации, сейчас уже и получше можно стало. А вы там переставляйте свою виндочку сутками, на двоих с похом. ...потом вы как-нибудь увидите как это все делают такие как я, будете долго делить на 0. Как борландпаскальские проги на слишком быстром компе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #170, #172

164. Сообщение от Аноним (-), 24-Июл-24, 17:58	+/–
> внезапно, для контроля они не нужны, рейд обладает избыточностью. Ну если с 6 - еще пожалуй. Но это не менее 4 девайсов с эффективностью 50% и много радости. > Это не человек, это локалхостик. С которого таки да - надо просто > копировать на другой локалхостик все что тебе жалко. И "переустанавливать минду менее суток" (c). Спасибо, но - такой системный менеджмент это для тебя и того юзера винды. И вот вы рассказываете как космические корабли бороздят просторы. Но сами ходите - пешком. > единственный дивайс от помойного китайца в один непрекрасный день просто перестанет > видеться системой, вообще. И без каких-либо предупреждающих событий, раз - и нет его. А у меня нет девайсов от помойных китайцев. Но csum error даже крутые энтерпрайзные SSD - умеют, оказывается. > А для современного рейда всего 4 - это вообще заявка на премию дарвина. Я уже понял что у тебя там гигантомания, а если не получилось воткнуть как минимум стойку, тогда на ноуте ты вообще без продвинутостей, с технологиями 90х. Мне такой подход кажется несбалансированым и я его практиковать не буду, предпочитая более гибкие и масштабируемые решения. > меняют вместе с ноутом? Да, безусловно это самое место для бырбыров > и прочего недоотлаженного и толком никем не тестированного трэшачка. То ли дело господа "переставляющие винду менее суток". Снапшотов системы ведь у них тоже не было как и чексум :). Бывает какой там маздайрекавери жрущий сотни места и вкалывающий полдня, но по сравнению с нормальными снапшотами... эээ... ну вот ВЫ этим и пользуйтесь :)) >> А юзать архаику умиращую от 1 бэда общесистемно наповал, без снапшотов и > ох уж эти сказочки, ох уж эти сказочники... Ага, блин, я как-то смотался в перди в авральном режиме, заменять одноплатник. Обидно было из-за 1 сцаного бэда то. С тех пор EXT4 у меня - phased out почти везде. В том числе и за такие приколы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #168

165. Сообщение от Аноним (-), 24-Июл-24, 18:09	+/–
> то есть пользоваться ты не умеешь, но "централизованный крап". То есть, git мне понравился намного большей симметричностью, возможностью полноценно мотаться по всем версиям без каких там супер-серверов и перекачки половины интернета по получасу, так что развлекуха типа git bisect катит даже на больших проектах. > Все что надо знать о тебе и твоих фантазиях. Кроме фантазий я еще комиты навешиваю в чертову кучу открытых проектов. > нет там никакого распределенного воркфлоу, нечитателям документаций про него брехай. Я так то видел как Торвальдс резко переключился на гитхаб, когда кернелорг ломанули. Потому что тот реп - ничем не хуже. В общем то вопрос в договоренности о точке обмена. Более того - моя репа ничем не хуже вон тех. И единственное отличие - не вывешено в инет и/или не используется толпой как "точка обмена". И только. > Порежьте помельче и перепошлите в рассылку. Причем непременно диффами к сегодня объявленной > правильной версии. Кто посмел rebase сделать - того нахрен с пляжа! Опять знания 2010 года на марше? Расскажи это Кенту, который pull request в рассылку запостил, ага? :) >> Изначально он так то BitBaker выбрал или как там его, но увы он пропертарный > изначально ему _впарили_. С энергией которую б в мирных целях, но куда > там... И кстати божеству пять лет было наплевать что он проприетарный. Божество - прагматик. Но когда проприетарий делом показал чем именно проприетара плоха, тот не только усвоил - но и задницу надрал по полной. Только так проприетарии и понимают, у меня с ними срамнимый опыт. > - оно обидевшись. Ну так проприетарии понимают только - лопатой по сопатке, да, не все и не всегда замечают это сразу, а cookies таки, вот, соблазнительные, вкусные бывают. > Спрашивает наш нечитатель документации и ниасилятор ничего кроме единственноверной А зачем мне осваивать окаменелый крап, недееспособный без перекачки половины интернета на каждый пшик или каких-то экзотов вида "ну тогда и ... сам с собой"? Какая практическая цель этого занятия могла бы быть? > Дай угадаю - что такое и какой хтонью порожден pwclient - ты без понятия? Абсолютно. У меня этого нет -> это ненужное мне знание. > нет. Нормальные люди уйдут из е..нутых проектов. Останутся любители лизать чужие пятки > и переподавать по двести раз с прогибом. Угу, и нормальность тех людей проявляется в... чем именно? Где их супер-проекты, с более удачными воркфлоу и идеями? Или нормально - нудеть на форуме да отмазываться на тему почему фигня - так и задумано? Да ну тя с такой нормальностью?! Тоже мне гении непризнанные :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #169

166. Сообщение от Аноним (-), 24-Июл-24, 18:20	+/–
> и с какого же потолка эта цифирь тобой взята? Может, у него вместе с тем исследователем модули с алиэкспресса? Или чувак мерял в поясе Ван Аллена. Ну там, заказчик статьи попросил выпятить нужность ECC, бывает и такое. > у человека - логи. У тебя - фантазия. Да кого волнует инженерный подход и измерения, если можно задвинуть красивую теорию?! Как говорит следствие из законов мерфи "если факты не подтверждают теорию, от них надо избавиться!". > не хочу тебя огорчать, но если это X99 - ecc линии там > не распаяны. Никакого ECC по факту у тебя - нет. Лол. Т.е. он в полной уверенности на тему ECC без его наличия? > А у тех у кого есть - есть логи ошибок. И там либо пусто, либо почти пусто, либо > надо срочно менять модуль, он банально дефективный. Вот я и не понимаю как тот экземпляр вон те сведения получил - и попытался меня ими накормить. У меня то линии ECC распаяны, и это реально работает. И там реально - вот так, если не жить в поясе Ван Аллена. А если жить, пользователь, пожалуй, быстрее скопытится. > это вот да. Не заходи сюда. Лол. Бывает так что пох может выдать дельную мысль. Походу на столь жесткий непрофессионализм даже у него аллергия. Но если хочешь поссыковать посмотри на BER новых PCIe с PAM4... :). Там, правда, тоже с горя FEC приделали, по тем же причинам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

167. Сообщение от Аноним (-), 24-Июл-24, 18:25	+/–
> да опять какой-нибудь китайский одноразовый мусор, нам с тобой это имя и > не скажет ничего. Примерно из того же источника что и битые флэшки. Да ну бросьте, какой-то атлон 64-битный старый. Нормальный вполне. Просто видимо - неудачный экземпляр. Вам не приходило в бошку что при производстве микросхем - они не одинаковые получаются? Есть разбросы процесса что куда осело. Какой-то левак может куда-то прилепиться. Толщина слоев не одинаковая по вафле. Вот это все. Так что после производства чипы так то тестируют, откровенно сбойные - в треш, потом - классифицируют по "запасу прочности" и то что с параметрами получше - маркируют частотами повыше. Похреновее - пониже. ...но вы же понимаете что ВСЕ проблемы физики в здоровом сложном чипе никакими фабричными тестами словить не получится? Особенно - если сейчас все работает, а, вот, через пару годков - после деградации - уже что-то где-то за margins выехало и де-стабилизировалось. Так что где-то как-то изредка левый логический уровень, вот, защелкивается - и нате вам сюрприз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

168. Сообщение от нах. (?), 24-Июл-24, 19:19	+/–
>> внезапно, для контроля они не нужны, рейд обладает избыточностью. > Ну если с 6 - еще пожалуй. для _контроля_ - ЛЮБОЙ. И да, даже совсем уж дешевые из приличных плат умеют такой контроль. (что потом делать с результатами - это уже отдельный вопрос. Но как минимум знать что что-то уже не в порядке.) > И "переустанавливать минду менее суток" (c). если у тебя в ноуте навернулся единственный модуль - то еще пол-дня ты будешь выбирать и покупать новый... ноут. А если ноут породистый - то может и неделю. На этом фоне переустановка - ну неприятно, но в общем уже мелочь. > А у меня нет девайсов от помойных китайцев. Но csum error даже крутые энтерпрайзные SSD - > умеют, оказывается. да полно заливать-то. Не видел ты их ни разу в жизни. Непомойных. Их на али не продают. > Я уже понял что у тебя там гигантомания, а если не получилось воткнуть как минимум стойку, 6+2 это все еще двухюнитовый корпус. Но да, такой лучше в стойке держать, он шумный. Меньше - стремная лотерея, потому что диски нынче - чорт бы их взял - большие. Додохнут последние мои 4T - что дальше - 20? Меньше-то уже либо хлам либо не купить либо хлам и не купить. 3way mirror разьве что. А остальное, извини уж - локалхосты. Им все это без надобности потому что ценность представляет (и навернется первым) целиком локалхост а не его единственный дисочек. Тот может даже и как новый, только запихать некуда. > То ли дело господа "переставляющие винду менее суток". Снапшотов системы ведь у них тоже не > было как и чексум какая польза от снапшота если физически поврежден диск - казалось бы ответ любому очевиден. Но не тебе. > Ага, блин, я как-то смотался в перди в авральном режиме, заменять одноплатник. это какие-то проблемы поделок с алиэкспресса в шибкоумных воротах гаражного мастера-самоучки без мотора, меня они совершенно не интересуют. Отдельный вопрос - почему эта проблема тебя волнует в ext4, а в бырбыре без конца перезаписывающем одни и те же секторы суперблоков - ты их в упор не хочешь замечать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #178

169. Сообщение от нах. (?), 24-Июл-24, 19:35	+/–
>> то есть пользоваться ты не умеешь, но "централизованный крап". > То есть, git мне понравился намного большей симметричностью, возможностью полноценно мотаться По сравнению с тем о чем ты даже не в курсе? > по всем версиям без каких там супер-серверов и перекачки половины интернета > по получасу, так что развлекуха типа git bisect катит даже на > больших проектах. развлекуха git bisect не катит потому что каждый тест на большом и сложном проекте - геморрой вовсе не на пару минут. А не потому что аж пятнадцать секунд понадобилось на svn switch >> Все что надо знать о тебе и твоих фантазиях. > Кроме фантазий я еще комиты навешиваю в чертову кучу открытых проектов. Я тебя спросил про инструмент, необходимый для... хм... комитов тоже в общем-то, в один хехе открытый проект. Не, не слышал. Ну а кто в теме, тот понял, чего ты стоишь со своей болтовней. >> нет там никакого распределенного воркфлоу, нечитателям документаций про него брехай. > Я так то видел как Торвальдс резко переключился на гитхаб, когда кернелорг > ломанули. Потому что тот реп - ничем не хуже. В общем именно потому что никакого "распределенного" там в помине нет. Иначе бы он был хуже на потерянную ту самую "распределенную" часть, сгинувшую в кернелорговском. Но ее там нет, и это НИЧЕМ не отличается от банальных svn mirrors. > то вопрос в договоренности о точке обмена. Более того - моя вообще-то смысл распределенных систем - в том что нет единой точки обмена. Но это не про kernel.org да и вообще не про любой нормальный проект. Т.е. git-то позволяет такое построить, но работать в таком режиме могут только полтора васяна. У него теоретически могло бы быть сугубо побочное и вне/сбоку проектов применение, но эта vcs настолько уродлива и убога, что так - не работает и я до сих пор не знаю никого кто бы всерьез этим пользовался. >> Порежьте помельче и перепошлите в рассылку. Причем непременно диффами к сегодня объявленной >> правильной версии. Кто посмел rebase сделать - того нахрен с пляжа! > Опять знания 2010 года на марше? Расскажи это Кенту, который pull request который только что пошел лесом потому что запостил без уважения? >> там... И кстати божеству пять лет было наплевать что он проприетарный. > Божество - прагматик. Но когда проприетарий делом показал чем именно проприетара плоха, все кто умели пользоваться - и так понимали. Но не божество. Которому ононенать. >> Спрашивает наш нечитатель документации и ниасилятор ничего кроме единственноверной > А зачем мне осваивать окаменелый крап, недееспособный без перекачки половины интернета хотя бы чтоб вот тут не нести чепуху. > на каждый пшик или каких-то экзотов вида "ну тогда и ... > сам с собой"? Какая практическая цель этого занятия могла бы быть? ты бы не выглядел в моих глазах полным дуpaком, ну, например. А там, глядишь, может чего и полезное бы извлек. >> Дай угадаю - что такое и какой хтонью порожден pwclient - ты без понятия? > Абсолютно. У меня этого нет -> это ненужное мне знание. все что требовалось знать о твоем "опыте" работы с технологиями lkml.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #179

170. Сообщение от Tron is Whistling (?), 24-Июл-24, 21:50	+/–
> Угу, угу, а на десктопе/ноуте такого супер-спеца картина "сапожник без сапог" и > "меньше дня реинсталла системы". Ну в пень такие технологии и инновации, Вот понимаешь в чём дело, раз в тысячелетие - могу себе позволить :D Пока не случалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #176

171. Сообщение от Tron is Whistling (?), 24-Июл-24, 21:51	+/–
> А я в этом моем линухе даже стертый кернел - за пару > минут назад отыграю. Как и неудачный апдейт. А каким-нить btrfs send > я еще и виртуалку из ЭТОГО сделаю минут за 10 максимум. Пфффт, и часто у вас это случается? Стёртые кёрнелы и неудачные апдейты? Ключевые слова тут во всём моём посте выше - это "раз в тысячелетие".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #175

172. Сообщение от Tron is Whistling (?), 24-Июл-24, 21:54	+/–
Что же до четырёх девайсов - ну, блин, ну вот меньше ныне на платформы с реальным сторейджем - это уже моветон. Меньше - где boot-only, там вообще может быть или RAID1 или безрейдовый бут, а всё остальное с SAN. PXE/iSCSI boot не юзаем по внутренним причинам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #177

173. Сообщение от нах. (?), 24-Июл-24, 22:48	+/–
> Ну, мне хватает обслуживать свои проблемы без всяких божков. На публику эти потому что твои проблемы с единственной битой флэшкой с али - гроша ломанного не стоят. > части энтерпрайзов вообще и переросточных хранилок в частности. Я за глаза > считаю что "большая хранилка == ошибки архитектуры". да знаем мы уже, выучили что ты не инженер. Всем наплевать что ты там считаешь. > Да, пох, не быть тебе инноватором. Так, глядя на то как мaйнepы Я инженер, да. > сотни своего добра распихивают куда угодно не имея столь тупых проблем. только потом никто не хочет покупать их "добро", потому что оно - вероятней всего - горелое. Потому что пихали куда-угодно, угодно было на от...сь, щас же намайним мульен и все это выкинем. > Бывают и вполне себе с корпусами и - решив проблемы охлаждения. может где-то и бывают, в одном уникальном экземпляре. Только коммерческие решения даже самых минимальных размеров потребуют десяток сейчас и быть готовым еще десяток через два месяца (а тех самых деталек на али - уже днем с огнем не найти) А для тех кому данные все же немножко важны - можешь почитать бравурные сказочки backblaze о том как они огого и агагага, они в свое время очень гордились своими наколеночными решениями и охотно делились подробностями. Как диски выковыривали из консумерских внешних корпусов, поды свои лепили чуть ли не на 3д принтере из навоза и т д. Оно у них в штатах до сих пор такое. А потом открывали новый ЦОД в европке (где надо еще и сертификации проходить а то в приличный-то tier не пустют) - посчитали...прослезились, и... и все эти самопалы пошли лесом, и купили обычные делловские полки. Оно так дешевле. И самоучки без мотора без надобности. > КМК ты теперь и к вон тем запчасти будешь искать так же. > Есть такое подозрение. в данном случае даже не опрашивал. Подозревает. Потому что и близко не подпустят самоучку без мотора к такому. Нет, все пока норм с запчастями. Денежки не пахнут. Это людишкам мы карточки заблокируем и через границу не пустим. А фура с эстоооонскими номерами едет себе и едет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #174

174. Сообщение от Аноним (-), 25-Июл-24, 18:22	+/–
> потому что твои проблемы с единственной битой флэшкой с али - гроша > ломанного не стоят. Ну как бы авторы btrfs и bcachefs считают иначе, в том смысле что у них именно general purpose FS, это находит мое самое теплое понимание. И уже мне решать какие кейсы мне актуальны а какие нет. Ну а ты можешь быть сапожником без сапог, с высокоинновационнм NTFS'ом, конечно. И так тебе и надо, имхо :) >> считаю что "большая хранилка == ошибки архитектуры". > да знаем мы уже, выучили что ты не инженер. Всем наплевать что ты там считаешь. Фокус в том что так считаю не только я :) > Я инженер, да. Неа. Вообще не похож. Похож на голимого теоретика, с протухшими знаниями от 2010 года. Хотя возможно у тебя такая помойка что и это - типа инженер, на безрыбье и сам раком станешь. > только потом никто не хочет покупать их "добро", потому что оно - > вероятней всего - горелое. Потому что пихали куда-угодно, угодно было на > от...сь, щас же намайним мульен и все это выкинем. То ли дело инженеры ставящие фирму на дохреналион, а сами вообще - без сапог. На виндочке с нтфсиком, крутые технологии, хыхы :). Но для себя на такое я уже не согласен, сорь. > может где-то и бывают, в одном уникальном экземпляре. Да ну брось - упомянутые в промышленных масштабах свое добро фигачат. > через два месяца (а тех самых деталек на али - уже днем с огнем не найти) Так то среди майнилок есть и те кто даже чипы сами разработали. Детальки можно и сделать если вопрос на миллион и - очень хочется. > чуть ли не на 3д принтере из навоза и т д. > Оно у них в штатах до сих пор такое. Ну так бизнес идет, и чего б им не? Только как я понимаю они в основном - для себя? > и все эти самопалы пошли лесом, и купили обычные делловские полки. > Оно так дешевле. И самоучки без мотора без надобности. Да не переживай ты так, граждане с мозгом без работы не останутся. А ты можешь себе деловскую полку домой вкатить конечно, с тебя станется. > в данном случае даже не опрашивал. Подозревает. Потому что и близко не > подпустят самоучку без мотора к такому. А я туда и сам не лезу, не моя область. Мне мелкая эмбедовка нравится. А деловская полка там... ну... ээээ ... как бы тебе сказать то? Немного избыточна, не, строить сразу и датацентр под шумок - в планы не входило, извини! :) > карточки заблокируем и через границу не пустим. А фура с эстоооонскими > номерами едет себе и едет. КМК это все же закончится. Будет COCOM. Или жестче чем он.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

175. Сообщение от Аноним (-), 25-Июл-24, 18:27	–1 +/–
> Пфффт, и часто у вас это случается? Стёртые кёрнелы и неудачные апдейты? Нет, но возможность сэкономить себе на такой оказии "меньше чем день" окупает все освоение (благо его немного) буквально на первом же взбрыке. Вы можете переставлять системы по дню. А я забыл как в дебиане инсталер выглядит. Ну вот практикую более крутые и эффективные способы деплоя и уже давно. > Ключевые слова тут во всём моём посте выше - это "раз в тысячелетие". Я еще всякие виртуалки и образа делаю под задачи, это где-то на стыке технологий, но тоже прикольно и эффективно. И кроме всего прочего - я с рефлинками целый флот влет подыму, и места сожрет почти как 1 изначально. А как это у вас - я представляю себе, и именно поэтому не буду вас слушать :). Потому что моя фамилия не МакЛауд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

176. Сообщение от Аноним (-), 25-Июл-24, 18:31	+/–
> Вот понимаешь в чём дело, раз в тысячелетие - могу себе позволить > :D Пока не случалось. А я могу не трястись над системой как кощей и сделать эксперименты где не уверен в результате. И отыграть взад если не понравилось. Пару раз такие привычки очень выручали. Скажем апгрейдил одним хомякам на старом компе демьян с 11 до 12, хорошо что я btrfs там поставил. Ибо 12-й ну не то что не работал, но вылез ряд косяков с именно вот той железкой. Ну я и вернул снапшотом за 2 минуты все как было. Не получилось так не получилось. А вы б отношались с реинсталом оси полдня. Мне вот оно надо? А, не, простите, дисковую полку от Dell туда пусть пох тащит, если хочет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

177. Сообщение от Аноним (-), 25-Июл-24, 18:34	+/–
> Что же до четырёх девайсов - ну, блин, ну вот меньше ныне > на платформы с реальным сторейджем - это уже моветон. > Меньше - где boot-only, там вообще может быть или RAID1 или безрейдовый > бут, а всё остальное с SAN. PXE/iSCSI boot не юзаем по > внутренним причинам. Ага. Бывают "унесенные ветром", а быают - "покусанные энтерпрайзом". Наверное, про вас таких можно уже даже фильм снять. А хорошо в этом всем то что btrfs и сабж - не настолько отшибленые и допускают мысль что есть и иные кейсы. Вместо сказа как мне выбирать между дисковыми полками Dell и NTFSом высокоинновационным :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172

178. Сообщение от Аноним (-), 25-Июл-24, 18:43	+/–
> для _контроля_ - ЛЮБОЙ. > И да, даже совсем уж дешевые из приличных плат умеют такой контроль. А все равно куча допущений о роялях в кустах. И если что отъедет, с такой штукой и проприетарным форматом метаданных в вон той лабе - вообще потом не расплатишься, даже если админов в рабство и на почки распродать. > (что потом делать с результатами - это уже отдельный вопрос. Но как > минимум знать что что-то уже не в порядке.) Это очень круто и полезно, но, вот, self heal меня - прикалывает. И можно даже совершенно нашару, из того что есть. Без вот этих вот загонов. А такой менеджмент систем как у вас - должен умереть. Вместе с его носителями. > если у тебя в ноуте навернулся единственный модуль - то еще пол-дня > ты будешь выбирать и покупать новый... ноут. А если ноут породистый > - то может и неделю. > На этом фоне переустановка - ну неприятно, но в общем уже мелочь. Так, черт, я забыл с кем болтаю. Пох всегда расскажет что всего 1 стрела в пятке - фигня! смотри как я могу! Обана - дикобраз! Да, это прикольно, конечно, ежели не у меня. > да полно заливать-то. Не видел ты их ни разу в жизни. Непомойных. > Их на али не продают. Ты еще не понял? Я отвисаю с толпой самого разного народа. У них есть полно всякого добра. Ну я и посмотрел на разные приколы. > 6+2 это все еще двухюнитовый корпус. Но да, такой лучше в стойке > держать, он шумный. У тебя соседи не удивляются "чего это он так пылесосить любит?!" :D > что ценность представляет (и навернется первым) целиком локалхост а не его > единственный дисочек. Тот может даже и как новый, только запихать некуда. Все эти теории не бьются с failure modes которые я видел в диком виде. А так все хорошо, прекрасная маркиза. > какая польза от снапшота если физически поврежден диск - казалось бы ответ > любому очевиден. Но не тебе. Если физически поврежден - но что-то еще читается - для датарека это так то может быть +1 шанс вынуть консистентное файло хоть в более старом виде. >> Ага, блин, я как-то смотался в перди в авральном режиме, заменять одноплатник. > это какие-то проблемы поделок с алиэкспресса в шибкоумных воротах гаражного мастера-самоучки Что-то пафосные самоучки с энтерпрайзными SSD под кеши то. Хрен его знает зачем воротам кеши такого плана. Но у поха что угодно бывает :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #181

179. Сообщение от Аноним (-), 25-Июл-24, 19:08	+/–
> По сравнению с тем о чем ты даже не в курсе? По сравнению с всякими cvs/svn и лабудой пытавшейся косплеить "более быстрых лошадей" с интерфейсом "зато привычные вожжи". Туда же идут экзоты голубых кровей от проприетариев, с кем там взаимодействовать то? > развлекуха git bisect не катит потому что каждый тест на большом и > сложном проекте - геморрой вовсе не на пару минут. Ну, для меня он прокатил - на проекте с линукскернел размером. И тесты я адресно на именно мои проблемы фигачил. Более жирных проектов у меня нет, так что мне нормуль было. Да, ребилд конечно что-то занимает, но на финальной итерации даже это относительно быстро, ибо несколько комитов и несколько файлов, так, релинк по сути. Зато можно выловить жирный факап будучи профаном в подсистеме, потыкать вон того @email.com'а носом - мол, косяк у тебя в рефакторе, он почертыхается - да починит за 10 минут. Вот это - работа над проблемой. Да что там, я сам себе так факап в програминге DMA отловил. Но ты то конечно придумаешь как извлечь с такого максимум удовольствия, растянув крузаду на полгодика. Меньше с вот именно таким багом наверне не получится, ведь никто заранее не скажет что DMA был виноват, а по эффектам это ессно не очевидно :) > А не потому что аж пятнадцать секунд понадобилось на svn switch Ну ты там сам с своим свином и возись. А я смог - вон то. И не только. Это позволило мне делать больше и быстрее. Значит хороший тул. > Я тебя спросил про инструмент, необходимый для... хм... комитов тоже в общем-то, > в один хехе открытый проект. Мало ли у кого какие причуды на этом глобусе бывают, я что все их знать должен, за все время существования разработки софта? > именно потому что никакого "распределенного" там в помине нет. Иначе бы он > был хуже на потерянную ту самую "распределенную" часть, сгинувшую в кернелорговском. Я прекрасно перекидываюсь git bundle с несколькими кексами через (распределенный же) месенжер. Зашло той тусовочке так, не любим мы HTTP. Ну и расскажи мне кто там центральная репа? :) Теоретически можно меня обозвать, ибо я агрегирую изменения, но де факто любой из - может так же, и это сугубо предпочтения господ делать через меня, а не соседа. Топологически же это P2P в чистом виде. Все репы равнозначны, и даже транспорт - p2p. > Но ее там нет, и это НИЧЕМ не отличается от банальных svn mirrors. Попробуй вон то своим свином окаменелым? Видишь, насколько мы отличаемся? Ты не можешь шагу без централизованых супербогов. А я могу и своим ходом уже на пантеон сходить. > вообще-то смысл распределенных систем - в том что нет единой точки обмена. Это convenience, не более. > нормальный проект. Т.е. git-то позволяет такое построить, но работать в таком > режиме могут только полтора васяна. И, кстати, ты встретил одного из них. Прикольно, да? А вот с свином ты так не смогешь :) > работает и я до сих пор не знаю никого кто бы всерьез этим пользовался. И ты покажешь решения лучше? Или свой свин еще более уродский расхвалишь? >> Опять знания 2010 года на марше? Расскажи это Кенту, который pull request > который только что пошел лесом потому что запостил без уважения? Судя по git log уже вернулся из кругосветки с новыми ништяками! :) > все кто умели пользоваться - и так понимали. Но не божество. Которому ононенать. Божество является таковым - потому что умеет в сбалансированное управление проектом. А ты это даже не нюхал. Такая разница. >> А зачем мне осваивать окаменелый крап, недееспособный без перекачки половины интернета > хотя бы чтоб вот тут не нести чепуху. Тебе это не очень помогает, насколько я вижу, так что рецепт сомнительный. > ты бы не выглядел в моих глазах полным дуpaком, ну, например. А > там, глядишь, может чего и полезное бы извлек. Да, спасибо, имхо, я с git намного больше для себя извлек пока-что. >> Абсолютно. У меня этого нет -> это ненужное мне знание. > все что требовалось знать о твоем "опыте" работы с технологиями lkml. Ты почему-то уверен что твой путь - единственно верный, а все что не соответствует ему, маздай. Это очень странная идея. Так, по жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #180

180. Сообщение от нах. (?), 25-Июл-24, 23:26	+/–
> По сравнению с всякими cvs/svn о которых ты ничего кроме названия не знаешь. > Ну, для меня он прокатил - на проекте с линукскернел размером. т.е. собирающемся по часу, с необходимостью ручного ковыряния, безусловно на таком проекте очень-очень важны те 15 секунд за которые делается switch > Ну ты там сам с своим свином и возись. А я смог - вон то. ты не смог банально в инженерное мышление, позволяющее отделять ерунду (секунды на свитч) от реальных затрат времени - пересборки и запуск сложной хрени, да еще так чтобы можно было считать это тестом, а не каждый раз по разному. Кому другому вешай на уши лапшу что ты что-то при этом смог. >> Я тебя спросил про инструмент, необходимый для... хм... комитов тоже в общем-то, >> в один хехе открытый проект. > Мало ли у кого какие причуды на этом глобусе бывают мы обсуждали "причуды" - твоего ложного божка с пальцем а не мало-кого. Теперь выясняется что ты вообще без понятия как и чем в линуксной разработке вынуждены пользоваться страдальцы, пытающиеся подлаживаться под его "воркфлоу" а на деле набор закостенелых привычек из 80х. > Я прекрасно перекидываюсь git bundle с несколькими кексами через (распределенный же) месенжер. вот п-ц-то... > Попробуй вон то своим свином окаменелым? чтобы потом никто уже не мог распутать эту вермишель после пары неудачных комитов не в ту веточку? Нет, спасибо, такой бред мне совершенно не нужен. Как и пересылать историю комитов бандлами через мессенджер, я не настолько йо...нутый. > И, кстати, ты встретил одного из них. нет, я встретил болтуна-неумешку. Который как выясняется, занят вообще каким-то чесанием левой ногой правого уха, никому кроме него ненужным. А к разработке того же линукса никаким боком, даже не наблюдатель, а так, мимокрокодил. > Божество является таковым - потому что умеет в сбалансированное управление проектом. нет. Потому что его невозможно оттереть от проекта, который загадил всю поляну. Единственное что он отлично сбалансировал - это потоки бабла платиновых спонсоров в свой карман. А работают за него другие, в основном забесплатно (а точнее вон вообще "for kicks").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #182

181. Сообщение от нах. (?), 25-Июл-24, 23:49	+/–
>> для _контроля_ - ЛЮБОЙ. >> И да, даже совсем уж дешевые из приличных плат умеют такой контроль. > А все равно куча допущений о роялях в кустах. понеслась бредятина... что тебе лапочка непонятно - любые рейды кроме совсем игрушечных умеют в контроль массива - сравнивают зеркала или пересчитывают и сравнивают сумму. И даже встроенный планировщик для этого бывает, внутри самой железки. Какие еще тебе мерещатся допущения и рояли? (про твой опыт работы с чем-то кроме битых флэшек - уже и так все понятно, раз ты этого не знаешь) > Это очень круто и полезно, но, вот, self heal меня - прикалывает. А меня нет. Потому что такое железо надо просто выбрасывать. К счастью, первый и последний раз я видел подобное лет пятнадцать назад на трэшовом сервере за 15 евро, ему можно было простить. (кстати, ни одного ценного байта он так и не потерял, пока его не угробили физически рукозадые админы - видимо с твоим примерно опытом и умениями) > Ты еще не понял? Я отвисаю с толпой самого разного народа. У них есть полно всякого добра. Так это - у них, а не у тебя. Видел, через плечо, ага. Но ценное мнение - выше гор. > Все эти теории не бьются с failure modes которые я видел в диком виде. потому что кроме своей дохлой флэшки ничего вообще не видел. > Если физически поврежден - но что-то еще читается - для датарека это так то может быть +1 > шанс вынуть консистентное файло хоть в более старом виде. А если не читается - как обычно бывает с ssd - то без шансов. А бэкапы ты не делал, потому что у тебя ж self-поxepинг и что-то там еще. Да и raid нормальный не для тебя, вот десять копий на одном и том же носителе - это твой способ. А если бы делал - то просто выбросил бы сдохший носитель или целиком ноут. Какой я там по счету диск меняю у хостера - я уже забыл давно. Начал сыпаться - в помойку. И умрет, я уверен, не от того что fs не та, а когда хостер спалит второй меняя первый. > Что-то пафосные самоучки с энтерпрайзными SSD под кеши то. что-то мне подсказывает что это не у тебя такое ни разу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #186

182. Сообщение от Аноним (-), 26-Июл-24, 11:37	+/–
> о которых ты ничего кроме названия не знаешь. Я в свое время рекатос таскал оными. И помню сколько апдейт по сети занимал, капец. Оно реально большую часть репы заново таскало на любой пшик. > т.е. собирающемся по часу, с необходимостью ручного ковыряния, Во первых кернелконф разные бывают, у меня и лайтовые есть ;) Во вторых не обязательно лично смотреть на билд. Пнул, прищел за результатом потом, прогнал тесты, goto 1. Ну потрачу я по 5, минут несколько раз в день, и?! В третьих, замахать нетривиальные баги за это время - недурно. Другими способами это может совсем другие времена требовать. В четвертых - сейчас у ядра есть и автоматический бот который бисекты делает для некоторых багов, ессно для того что он умеет репродусить на автомате. Прикольно со стороны выглядит, сам бисектит, сам пинает причастного - "вкалывают роботы" :) > безусловно на таком проекте очень-очень важны те 15 секунд за которые делается switch Сколько я себя помню - на штуке типа реактоса качало полинтернета минут по 20. Это даст фору иным ребилдам ряда моих ядерных конфиг. Более того - bisect полностью локальная операция, с 0 допущениями. Это позволяет сие в большем числе конфиг, с меньшими допущениями. А что там в твоем уютном энтеррпайзике где тебе админ развернул - мне похрен, я вообще такие воркфлоу не практикую. Для меня это означает что убить время на сетап сервака должен буду я сам. Оно мне надо по сравнению с "git init"? :) > ты не смог банально в инженерное мышление, позволяющее отделять ерунду (секунды на > свитч) от реальных затрат времени - пересборки и запуск сложной хрени, Я смог в инженерное мышление и понял что фигня с вожжами и сервером мне ни к чему, обоснование выше. И воркфлоу у меня уже не завязаны на какой-то корп который мне ЗБС сделает своимии админами. Это формат мамонтов. > да еще так чтобы можно было считать это тестом, а не > каждый раз по разному. Мои тесты прокатывали и я случайно заимел отношение к гасилову жирных багов в core подсистемах линя. Я не планировал это, но правильный тул сделал меня мощнее, достаточно чтобы это сделать в фоне. До кучи. Just because I can. Я такое еще в нескольких проектах войдя во вкус делал. Вызывает прикольные коменты "а что так можно было?!". Да! Опенсорс - "пришел, увидел, победил" в чистом виде. > Кому другому вешай на уши лапшу что ты что-то при этом смог. Бедный мамонт, настолько не стыкуется с его замшелой картиной мира что он поверить не может что такое уже возможно. Но спасибо, я смеялся. >> Мало ли у кого какие причуды на этом глобусе бывают > мы обсуждали "причуды" - твоего ложного божка с пальцем а не мало-кого. Его причуды обычно имеют рациональные обоснования. Чтобы их понимать - надо попробовать самому интегрять изменения в проект гитом для хотяб 5-10 кексов. Тогда все просто, логично и понятно и сам так же станешь делать. А без этого - рассказ неандертальцу о работе микроволновки получается. > Теперь выясняется что ты вообще без понятия как и чем в > линуксной разработке вынуждены пользоваться страдальцы, Я настолько "вынужден" пользоваться гитом, что добровольно, по моему выбору, трекаю им лично свои проекты. И да, я могу все это делать без корпорации за спиной и пары админов для майнтенанса суперсервера. Какой я несчастный. > пытающиеся подлаживаться под его "воркфлоу" а на деле набор закостенелых привычек из 80х. Я попробовал эти воркфлоу и стал косплеить их в своих проектах, это лучше работает чем высокоинновационные воркфлоу от фанов свина. > вот п-ц-то... Manageable :). Что, удивлен что кому-то и правда не нужны боги с их серверами? > чтобы потом никто уже не мог распутать эту вермишель после пары неудачных > комитов не в ту веточку? Жизнь без богов за спиной имеет особенности, подразумевая взрослых полноценных людей, понимающих что они делают, способных взять на себя часть ответственности и разрулить свои же факапы самостоятельно. Впрочем, при таком воркфлоу от факапа плохо в основном факапнувшемуся, заодно и поучится рулению гитом как раз при случае. Хороший стимул понимать что и зачем делаешь. > Нет, спасибо, такой бред мне совершенно не нужен. А тебе кто-то разве предлагал? > Как и пересылать историю комитов бандлами через мессенджер, я не настолько йо...нутый. Спасибо, я смеялся :). Распределенный месенжер, прошу заметить. Это немного эксперимент, посмотреть можно ли уже вообще совсем без божеств "благодетелей". > нет, я встретил болтуна-неумешку. Который как выясняется, занят вообще каким-то чесанием Точка зрения мамонта с свином очень важна в 2024 году. Эх, затыкают тебя палочками лысые абизяны, пушистик. > нет. Потому что его невозможно оттереть от проекта, который загадил всю поляну. > Единственное что он отлично сбалансировал - это потоки бабла платиновых спонсоров Завидуй уж молча, раб корпоративный. Ты ж без вон тех и их серваков - вообще никто. И это вовсе и не фича была, если подумать...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #185

183. Сообщение от Аноним (-), 26-Июл-24, 11:42	+/–
> Всё ещё хуже. > Не-ECC память угробит данные ещё до записи. > И они во все десять копий запишутся угробленными :D Только это все если и будет - то в 1 случае из дохреналиона. А еще дохреналион будет успешно запален чексумами, и если не нарываться и исправить проблемную ситуацию, то в целом все куда лучше чем если игнорить проблему до упора, прощелкав ее наличие без чексум. А вот когда такое долго игнорят - потом тома могут в вермишель развалиться и fsck совсем не обязан сильно загаженый том моунтабельным сделать, и тем более - lossless.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

184. Сообщение от Аноним (-), 26-Июл-24, 11:55	+/–
> Поверь, если у тебя проц вызывает битфлип в данных - ты это > заметишь очень быстро через вставание системы раком. Опять теоретики вылезли. Вы такое ловили хоть раз на практике чтобы лечить про это? Экземпляр это делал 1) редко 2) только после прогрева. Так что система могла спокойно пахать почти неограниченное время в крейсерском без постановки в позу. Ну может пару раз в неделю странности бывали, но кто на них обращает внимание в современных сложных системах? Но вот вой btrfs о чексумах - это повод расследовать проблемы железа. И вот тогда, после адресного тыкания палочкой, когда оказалось что scrub хаотично сыпется в разных участках без понятных паттернов, зато "через некоторое время от начала" - уже понятнее. Методом замены подозрения с RAM были cняты, и остался - вот - странный гаденыш. Реально подглюкивал изредка после прогрева. После его замены стало - ЗБС. > никакая мегадублированная ФС тебе не поможет, потому что данные с большой > долей вероятности уйдут на чексумминг и запись уже битыми. Эксперимент показл обратное: btrfs изумительно орет в логи в таком случае. Но я могу понять писки адептов нтфс, ибо парочку развермишеленых до совсем немонтируемого и нечинимого состояния ntfs'ов я вот именно после подобных факапов (пробакланеные сбои RAM) таки знакомым рекаверил, ога. Да, вам нечем такое крыть :) > При этом чексумма будет посчитана корректно, но от битых данных. Такое встречал, ну, > не в личной практике, но встречал. А я вот постепенно собрал мини-коллекцию глюкавых шнурков, сторажей, планок - и - даже - вот - проц. Благодаря чексумам, ога :). Но вы можете рассказать какие они бесполезные, лол.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #189

185. Сообщение от нах. (?), 26-Июл-24, 12:13	+/–
> Я в свое время рекатос таскал оными. И помню сколько апдейт по сети занимал, капец. Оно реально но разбираться в чем причина - конечно же не стал > большую часть репы заново таскало на любой пшик. оно никогда не таскает никакие части никакой репы. Сюрприз. Там все делается server-side. Твоя "квалификация" в очередной раз пробивает днище. На твоей стороне только трекинг ТВОИХ изменений, которых у тебя нет, по всей видимости, поэтому ты выбрал вообще не тот инструмент. Это гит имеет привычку таскать ненужную никому галиматью в сотни раз превышающую объем реального кода, только ради возможности посмотреть на дифф. Причем никакой распределенностью снова не пахнет, для сложного проекта только чтоб иметь счастье получить себе полную копию а не огрызок, нужны танцы с бубнами. > Во вторых не обязательно лично смотреть на билд. Пнул, прищел за результатом потом, прогнал > тесты, goto 1. Ну потрачу я по 5, минут несколько раз в день, и?! и если весь остальной день ничего не делаешь, то оно так работает. Наверное. Потому что обычно нужно двадцать раз все пересобирать только ради того чтоб быть уверенным что тест работает, ну или делать все вручную, подпирая на ходу. > Сколько я себя помню - на штуке типа реактоса качало полинтернета минут по 20. это что угодно но не свитч ветки. Если только ты не на модеме 9600 сидишь (ну или ректалос). В любом случае не с твоей квалификацией отличить одно от другого. > Для меня это означает что убить время на сетап сервака должен буду я сам. Оно мне надо по > сравнению с "git init"? :) и сразу ведь после git init у тебя свой гитляп с блэкджеком и стикерами (нет, у тебя кучка мусора на локалхосте). Признайся уже честно - и это ты тоже никогда не делал, за тебя все делали презираемые тобой админы. А твоего умения - кнопочка форк на гитхапе и гитляпе. (svnadmin create тоже выполняется мгновенно, сюрприз.) Причем svn для подкроватного сервера хорош еще и тем, что отредактировать следом две строчки в плэйнтексте даже ты мог бы осилить. И это сразу дает тебе работающий сервер, с авторизацией и разделением прав, а не git serve феерически бесполезный без костылей и подпорок в разы превышающих сложностью само это недоразумение. Квалификация-с, в очередной раз. > Я настолько "вынужден" пользоваться гитом, что добровольно, по моему выбору, трекаю им лично > свои проекты. потому что обезьянка погналась за модным калом, не разбираясь, не ее это, разбираться, что удивительного, она только ведро пересобирать кое-как обучена. >> пытающиеся подлаживаться под его "воркфлоу" а на деле набор закостенелых привычек из 80х. > Я попробовал эти воркфлоу и стал косплеить их в своих проектах, нет, ты не пробовал и не их косплеишь, ты какую-то вообще невероятную хрень на полутора секретных васяна нагородил (подозреваю оба твои тульпы), с бандлами своего ценного хеловрота через чятик, это вообще ж е..у даться. Когда тебя кнули носом именно в линуксо-специфичный воркфлоу - ты слился, как обычно, ты даже не слышал что это и для чего. Т.е. ты даже близко к линуксной разработке не стоял и не подходил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #187

186. Сообщение от Аноним (186), 26-Июл-24, 13:06	+/–
> что тебе лапочка непонятно - любые рейды кроме совсем игрушечных умеют в > контроль массива - сравнивают зеркала или пересчитывают и сравнивают сумму. И > даже встроенный планировщик для этого бывает, внутри самой железки. Какие еще > тебе мерещатся допущения и рояли? Ну вот эти. И да, именно благодаря характерному эксперименсу, ценнику и допущениям - я буду за штуки типа btrfs и bcachefs. Чтобы видеть ЭТО в более вменяемом вормате, с удобным управлением, и деланое человеками, для человеков. Когда можно подоткнуть +1 девайс из того что есть, не делая мозг, получить +N места, с минимумом side effects и considerations. И все это еще нашару, без вендорлоков, камасутр с выравниваниями, нужд типа склазирования зипов и прочего брейнфака, большим разнообразием поддерживаемых конфиг, вплоть до планов что делать при отклонении от идела на 1-девайсном конфиге, кроме как "помереть с позором". В общем вон то - сугубо для унесенных ветром^W^W покусанных энтерпрайзом. О том что кому-то может хотеться чего-то между таким брейнфаком и NTFS, бжаж, вы, видимо, не задумывались. > (про твой опыт работы с чем-то кроме битых флэшек - уже и > так все понятно, раз ты этого не знаешь) Как я уже сказал - у нас и правда разные хотелки. Пересекающиеся, скажем так, лишь местами. >> Это очень круто и полезно, но, вот, self heal меня - прикалывает. > А меня нет. Потому что такое железо надо просто выбрасывать. К счастью, Если 1 бэд/ошибка чтения раз в пару лет - а смысл? Это единичный upset, он ничего не означает. > первый и последний раз я видел подобное лет пятнадцать назад на > трэшовом сервере за 15 евро, А я видел с месяц назад когда какой-то юзер с топовым энтерпрайз SSD логи запостил и там csum error какие-то. В паре с счетчиками записей и статистикой (их такие под кеши bcache, не того который fs, сейчас модно пихать) понятно что девайсу просто недолго осталось, он - сыпется. > угробили физически рукозадые админы - видимо с твоим примерно опытом и умениями) Ну, я интересуясь топиком - посматриваю по сторонам. И иногда замечаю всякие вещи, типа вон того. На штуках типа EXT4/XFS юзерье часто совсем проклацывает разлет bcache - и там ФС обычно совсем в г@вно :) > Так это - у них, а не у тебя. Видел, через плечо, > ага. Но ценное мнение - выше гор. Ну мне как бы куска их сислогов и статистики вполне достаточно чтобы понять источник проблем. А если они еще и волшебное слово "bcache" произносят, то и вообще все сразу понятно. >> Все эти теории не бьются с failure modes которые я видел в диком виде. > потому что кроме своей дохлой флэшки ничего вообще не видел. См. выше, я ж грю - такое бывает и с откровенно энтерпрайзными девайсами. А протирают их вусмерть ессно засунув в bcache. >> Если физически поврежден - но что-то еще читается - для датарека это так то может быть +1 >> шанс вынуть консистентное файло хоть в более старом виде. > А если не читается - как обычно бывает с ssd - то без шансов. Если 1 блок не читается - это еще не значит что и другой тоже. А так отказов у флешатины много разных, на все вкусы. Если ты возомнил что видел все - try again. Продвинутые датареки, кстати, могут порой вынуть добро и программатором, откосплеив FTL самостоятельно, порой даже с частично-продолбаной трансляцией. Если в пересобраном с теми или иными потерями блочном образе будет >1 инкарнации файла за счет cow, шанс увидеть хоть 1 из версий в живом виде повышается. Сдерут за квест, конечно, немилосердно, такой ребилд - know how. А не нравится - ну попробуй сам такое, проприетарные форматы метаданных транслятора и там позволят познать все 33 удовольствия и почему те столько хотят :) > А бэкапы ты не делал, потому что у тебя ж self-поxepинг и что-то там еще. Бэкапы это бэкапы. У них сильно иное время восстановления и возня с этим всем. > Да и raid нормальный не для тебя, вот десять копий на одном и том же носителе > - это твой способ. Ну, ты можешь таскать дисковую полку за ноутом, например :) > А если бы делал - то просто выбросил бы сдохший носитель или целиком ноут. Ага! Потратить пару килобаксов и продолбать эн дней на unplanned трах, где вон то вообще только в лог пискнет да самопочинится, и если это разово, я просто забуду о проблему - блин, что же я выберу?! Не, прости, мазохистских наклонностей у меня нет :). Сам так прыгай из-за 1 случайного бэда. > когда хостер спалит второй меняя первый. >> Что-то пафосные самоучки с энтерпрайзными SSD под кеши то. > что-то мне подсказывает что это не у тебя такое ни разу. Это не мешает мне из-за интереса к топику посмотреть логи, статистику, и выдвинуть мое мнение - которое совпадает с другими тематическими рожами. Чаще всего такие приколы с bcache. Ну вот популярно нынче под такое энтерпрайзные девайсы втуливать. Собссно поэтому сабж и придумал вон то, с фронтом и бэком. Сможет как-то менее похабно на такие вещи реагировать постепенно, все же на уровне ФС ему будет виднее incoming осыпон девайса и оно сможет более осмысленную статистику факапов-по-накопителям накапливать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #188

187. Сообщение от Аноним (187), 26-Июл-24, 14:19	+/–
> но разбираться в чем причина - конечно же не стал Я и в тыкании копьем мамонта профан. > Там все делается server-side. Особенно билд кернела реактоса из актуального сорца на моей системе? :) > Твоя "квалификация" в очередной раз пробивает днище. А уж как меня стебли бы неандертальцы при походе на мамонта... > На твоей стороне только трекинг ТВОИХ изменений, которых у тебя нет, по > всей видимости, поэтому ты выбрал вообще не тот инструмент. Вот именно ВЫБРАЛ я для себя и правда - ДРУГОЙ инструмент. И не только я. Даже реактос, вроде, допер, хоть я и не слежу уже. > Это гит имеет привычку таскать ненужную никому галиматью Это про историю? Да, уж, кому с VCS придет в голову мотаться по версиям?! Но если мы про документацию, в эту игру могут играть и двое. Про clone --depth=1 ты, видимо, не в курсе? :) > и если весь остальной день ничего не делаешь, то оно так работает. Не понимаю как билд ядра мешает мне делать что-то еще. Я асинхронен относительно компов/vm/одноплатников и не обязан смотреть на билд лично. Если вопрос в том чтобы увести в даун основной комп - виртуалки, мелкие железки, второй комп, и проч - делают это все сильно менее интрузивным. Да, можно все делать долго, хреново, криво и сложно. Но зачем? Достаточно выйти за пределы привычного тебе линейного менеджмента систем и все станет намного проще, удобнее, логичнее и прикольнее. Открываются новые горизонты, и все намного проще и быстрее. > Наверное. Потому что обычно нужно двадцать раз все пересобирать Не стоит судить по себе. > это что угодно но не свитч ветки. Если только ты не на > модеме 9600 сидишь (ну или ректалос). Ну, э, гит при прочих равных все это сильно быстрее делает и это мой типовой сценарий. > В любом случае не с твоей квалификацией отличить одно от другого. А питекантропы засмеют мою квалификацию с копьем. Ужас. > и сразу ведь после git init у тебя свой гитляп с блэкджеком Есть и варианты и без этого, особенно для кучи гиков, как ты уже заметил. > все делали презираемые тобой админы. А твоего умения - кнопочка форк > на гитхапе и гитляпе. Я понимаю что иногда сложно поверить что большой белой птицей с турбинами^W громовым голосом управляют все же люди, а жрат можно готовить и в микроволновке, но у тебя, имхо, есть шанс это осознать. Я бы, имхо, не смог вон то - придумать. КМК у меня не настолько крутая фантазия. > (svnadmin create тоже выполняется мгновенно, сюрприз.) Ога, и сервак наверное сам сетапится. > Причем svn для подкроватного сервера хорош еще и тем, git хорош тем что - подкроватных серверов вообще не требует. > сразу дает тебе работающий сервер, с авторизацией и разделением прав, Мне с моей тягой к распределенным, более симметричным workflow, экспериментам с параллельными таймлайнами и проч - все это актуально как скилл тыкания мамонта копьем примерно. Это не мой формат. У меня нет такой нужды. Я не хочу никакие "серверы". И тем более трах с менеджментом праф. Git работает сильно иначе. И это решается сильно иначе - я или аплаю то что мне некто прислал/запросил, или нет. И весь ACL. > Квалификация-с, в очередной раз. Да вот черт, и в верховой езде я тоже не очень, да. > разбираться, что удивительного, она только ведро пересобирать кое-как обучена. Я обучился тому что мне было интересно, удобно и кайфово. Git 1 из таких штук. А свин мне для себя не надо. Да и все проекты которые меня как-то интересовали постепенно тоже на git ушли. > нет, ты не пробовал и не их косплеишь, ты какую-то вообще невероятную > хрень на полутора секретных васяна нагородил (подозреваю оба твои тульпы), Я есть и в ряде более классических проектов, но это не отменяет природы гита и того что я умею ей пользоваться. > с бандлами своего ценного хеловрота через чятик, это вообще ж е..у даться. Ну да, с SVN ты так, имхо, не сможешь :)). А гит так то довольно абстрактен относительно транспорта. Им можно даже pull с соеднего дерева этсамого в ФС сделать. Если это зачем-то надо. С суровым юзежом рефлинков даже может иметь некий смысл, хоть и странноватый способ. > Когда тебя кнули носом именно в линуксо-специфичный воркфлоу - ты слился, как > обычно, ты даже не слышал что это и для чего. > Т.е. ты даже близко к линуксной разработке не стоял и не подходил. Т.е. твои знания 2010 года и уверенность что это единственный вариант - как обычно сыграли с тобой дурную шутку. Интересно, сколько раз тебе надо обломаться одинаковым способом, чтобы сделать выводы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185

188. Сообщение от нах. (?), 26-Июл-24, 23:34	+/–
> Ну вот эти. И да, именно благодаря характерному эксперименсу, ценнику и допущениям которого у тебя - нет, как обычно. > В общем вон то - сугубо для унесенных ветром^W^W покусанных энтерпрайзом. О нет. Но не для невменозников талдычащих одни и те же бредовые мантры и отвергающих все что выходит за пределы их мирка. > Как я уже сказал - у нас и правда разные хотелки. Пересекающиеся, у нас разный опыт. У тебя его нет, у меня - есть, вот и вся разница. Там где у тебя мантры и религиозные верования и что-то как-то непонятно видел - у меня знания, как оно на самом деле, а не в фантазиях. > Если 1 бэд/ошибка чтения раз в пару лет - а смысл? Это я никогда не видел ошибок чтения раз в пару лет. Вероятно и не увижу. Ну, надеюсь. > единичный upset, он ничего не означает. нет, он означает что что-то серьезно поломалось, потому что в исправной системе этого быть не может. Нет там никаких ошибок чтения, кроме sector read error, resetting dma и так далее, привет диску. > А я видел с месяц назад когда какой-то юзер с топовым энтерпрайз > SSD логи запостил и там csum error какие-то. В паре с А у меня - сотни этих ssd и нет никаких "csum error", только дохлые ssd. В этом и заключается разница между слышал звон и знает как оно на самом деле. > который fs, сейчас модно пихать) понятно что девайсу просто недолго осталось, > он - сыпется. нет. Когда энтерпрайзному дивайсу "недолго осталось" - он встает в readonly, и продолжает читаться без всяких ошибок. (ну или совсем уже не читаться, если правда посыпалось) А у твоего дятла - дефективные кабели или полудохлый блок питания, вероятнее всего. Которыми он и угробит свой краденый ssd в ближайшее время. Обычная история. > Ну, я интересуясь топиком - посматриваю по сторонам. И иногда замечаю всякие Посматривание через плечо имеет один существенный недостаток - ты видишь таких же васянов-самоучек без мотора, с крайне странными поделками из дерьма и палок. ssd может и энтерпрайзный, но из мусорки ,вон наши же девают куда-то после загорания красных лампочек. Остальной комп - из дерьма, потому что таков путь. > вещи, типа вон того. На штуках типа EXT4/XFS юзерье часто совсем > проклацывает разлет bcache - и там ФС обычно совсем в г@вно Вероятно, и bcache - какой-то невменозный хлам. Собственно, я в этом почти и не сомневался. Понятия не имею кто и зачем его использует. > Ну мне как бы куска их сислогов и статистики вполне достаточно чтобы > понять источник проблем. А если они еще и волшебное слово "bcache" Очевидно, источник проблем - bcache. Потому что я среди своих сотен разномастых ext4 ничего подобного не получал. C xfs были интересные истории, кстати. Но всерьез - были давно. Говорят редгад ее с тех пор сильно попочинял. > См. выше, я ж грю - такое бывает и с откровенно энтерпрайзными > девайсами. А протирают их вусмерть ессно засунув в bcache. успехов им всяческих. >> А если не читается - как обычно бывает с ssd - то без шансов. > Если 1 блок не читается - это еще не значит что и > другой тоже. А так отказов у флешатины много разных, на все а у тебя на все один блок, забыл? Твои снапшоты - это тот же самый блок. Поэтому не читается ни текущий, ни снапшот. >> А бэкапы ты не делал, потому что у тебя ж self-поxepинг и что-то там еще. > Бэкапы это бэкапы. У них сильно иное время восстановления и возня с не делал. Так и запишем. > Ну, ты можешь таскать дисковую полку за ноутом, например :) У моего ноута есть бэкап. И крайне мало ценного непосредственно на ноуте. (по факту там кроме паролей в браузере вообще ничего нет) Я больше буду переживать что остался без рабочего инструмента где-то в ..нях. >> А если бы делал - то просто выбросил бы сдохший носитель или целиком ноут. > Ага! Потратить пару килобаксов и продолбать эн дней на unplanned трах, где не надо сказок. Ноут у тебя тоже с помойки, в ноутах за пару килобаксов нормальные ssd стоят. И тоже либо работают, либо сдохли окончательно. > я выберу?! Не, прости, мазохистских наклонностей у меня нет :). Сам > так прыгай из-за 1 случайного бэда. У меня нет случайных бэдов. Даже на дешевых китайских ноутах это как-то перебор. > Это не мешает мне из-за интереса к топику посмотреть логи, статистику, и > выдвинуть мое мнение - которое совпадает с другими тематическими рожами. Чаще > всего такие приколы с bcache. Ну вот популярно нынче под такое > энтерпрайзные девайсы втуливать. Собссно поэтому сабж и придумал вон то, с Среди таких вот дятлов - популярно. А у нормальных покупателей энтерпрайзных дивайсов - энтерпрайзная полка. И никакого bcache в ней нет (что там есть в гибридных полках - я хз, но они ничем особо не выделялись по отказам, а нынче и вовсе стали немодны и пропали из рекомендованных к продажам, мы их уже лет пять не берем). Диски дохнут, систематически, они всегда дохли - но для того и полка чтобы просто так же систематически их менять без разбора, что там случилось и почему пусть вендор разбирается. Вероятнее всего у вас в вашей поделке какой-то антипаттерн, на который эти диски не рассчитаны. Что странно, но я в вас верю, тут вы вполне успешны, и х-й сломать, и руки порезать, и гвоздь погнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

189. Сообщение от Tron is Whistling (?), 27-Июл-24, 10:52	+/–
Битых систем - к счастью, не у себя, а у разных любителей "подешевле" - я ловил в своей жизни предостаточно. Коллекцию не собирал, просто предлагал выкинуть и заменить на нормальное железо. И вот если начался тот самый массовый "вой о чексуммах" или появились рандомные падения с порчей структур FS / данных - всё, дальше только бэкапы "до события", потому что с вероятностью 99% часть данных прекрасно записалась битыми. Но тут уже каждый сам себе в свою меру злобный буратина. Всё это правда было задолго до того, как тот же zfs даже в проекте появился - я тогда подрабатывал консультацией всяких разных указанных любителей. А дальше всё это как-то уже прошло мимо меня - необходимости просто не возникало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

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

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