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

"Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"	+/–
Сообщение от opennews (??), 07-Янв-21, 09:51
Доступен промежуточный выпуск проекта OpenZFS 2.0.1, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Проект получил известность как "ZFS on Linux" и ранее ограничивался разработкой модуля для ядра Linux, но после переноса поддержки FreeBSD был признан основной реализацией OpenZFS и был избавлен от упоминания Linux в названии. Работа OpenZFS проверена с ядрами Linux c 3.10 по 5.10 (в прошлом выпуске поддерживались ядра, начиная с 2.6.32) и ветками FreeBSD 12.2, stable/12 и 13.0 (HEAD). Код распространяется под свободной лицензией CDDL... Подробнее: https://www.opennet.me/opennews/art.shtml?num=54368
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 07-Янв-21, 09:51	–12 +/–
погодите-ка, так эта ФС используется в ядре или в пространстве пользователя??
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #5, #6, #7, #11

3. Сообщение от ИмяХ (?), 07-Янв-21, 10:06	–3 +/–
Это зависит только от тебя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от anonymous (??), 07-Янв-21, 10:06	+5 +/–
OpenZFS - в ядре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Аноним (5), 07-Янв-21, 10:08	–3 +/–
В ядре модуля
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

6. Сообщение от Аноним (6), 07-Янв-21, 10:51	+9 +/–
В пространстве ядра пользователя модуля
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #72

7. Сообщение от Аноним (7), 07-Янв-21, 11:26	+5 +/–
Да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10

8. Сообщение от Аноним (8), 07-Янв-21, 11:54	+5 +/–
Отличная файловая система. Она как запретный плод: один раз zfs - всегда zfs! ^_^
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #15

9. Сообщение от 5.6_4.2 (?), 07-Янв-21, 12:26	–6 +/–
Да особо ничего в ней хорошего нет вот если из формата zst сделают файловую систему это будет самая быстрая в мире фс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

10. Сообщение от Аноним (10), 07-Янв-21, 12:54	–1 +/–
Нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #18, #39

11. Сообщение от Ю.Т. (?), 07-Янв-21, 13:02	+3 +/–
Волновая функция схлопнется, когда откроют коробку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от Аноним (12), 07-Янв-21, 13:04	+1 +/–
Лучше про разницу между оригиналом и сабжем напишите)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98

13. Сообщение от Аноним (-), 07-Янв-21, 13:44	–7 +/–
Эх, жаль не на расте...
Ответить | Правка | Наверх | Cообщить модератору

14. Сообщение от 9nko (ok), 07-Янв-21, 14:05	–2 +/–
Как-то пробовал ZFS на собственном NAS поставить под FreeNAS ОС (который переодетый в веб-морду FreeBSD). Честно говоря столько гемора с этими пулами и постоянной слежкой за тем, чтобы при обновлениях ничего не слетело - есть пара моментов, где можно пальнуть себе в ногу, и прощай 10 терабайт целого диска данных. Вне дома вероятно хорошая вещь, но точно не для малого использования, где лучше Debian с лошадкой Ext4.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #32, #41, #44

15. Сообщение от Аноним (15), 07-Янв-21, 14:05	–1 +/–
zfs лучше ext4? Чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #16, #17, #19, #40, #81

16. Сообщение от анон (?), 07-Янв-21, 14:10	+4 +/–
снапшоты которые не уменьшаю производительность (в отличии от lvm2) и их можно передавать икрементально (только изменённые данные) по ssh (для обновления бэкапа), програмный raid (отказоустойчивость) который можно воткнуть в другой комп без проблем, сжатие файлов в самой системе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #21, #37, #71

17. Сообщение от анон (?), 07-Янв-21, 14:14	–5 +/–
но она хуже чем ext4 потому что zfs нельзя использовать на одном диске, если навернется часть данных - навернётся всё и полностью, а средств восстановления кроме бэкапа нет (никаких утилит для выколупывания файлов нет)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #23, #97

18. Сообщение от Аноним (18), 07-Янв-21, 14:34	+/–
Отнюдь не Анонима ответ!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

19. Сообщение от Аноним (8), 07-Янв-21, 15:00	+1 +/–
В двух словах и не расскажешь, но если сильно постараться - буквально всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

20. Сообщение от Док (?), 07-Янв-21, 15:07	–4 +/–
Кривое чудо. Добавил ssd в комп. Угадайте как на него перенести свою хоум папку? Спорю что не знаете. После этого еще пул начал периодически исчезать. Вылечил через import. После очередного обновления ZoL при загрузке вообще вывалился в черный экран с сообщением что импортировать нечего поэтому сами напишите мне в строке zfs import root и тд Н если это написать то ответ что импортировать нечего Зато если написать exit  то загрузка продолжится и все будет норм... но в zfs list  видно что все смонтировалось черте куда. Вобщем странная штука с отсутствующей поддержкой (ни форумов ни групп ни ответов на гитхабе). Работает нормально только в дефолтном варианте иначе хер разберешься
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #46, #73

21. Сообщение от Аноним (15), 07-Янв-21, 15:10	–2 +/–
А вот прям на домашнем компуктере обоснованно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #27, #111

22. Сообщение от Аноним (22), 07-Янв-21, 15:23	–6 +/–
Нечего особенного в ней нет, вернее "уже нет", на фоне btrfs. Жрёт очень много оперативки, медленнее btrfs, да и возможностей меньше.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #28, #34, #43

23. Сообщение от thiteigh (?), 07-Янв-21, 15:30	+1 +/–
Это в фантазиях, на деле с восстановлением данных уже беда. Нет бекапов — данные не нужны. zfs упрощает создание резервных копий и управление ими.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #45

25. Сообщение от Аноним (12), 07-Янв-21, 15:37	–1 +/–
Чего-то "особенного" в ФС мне совсем не нужно))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

26. Сообщение от thiteigh (?), 07-Янв-21, 15:45	+1 +/–
Пользовал zfs на бздах (fbsd9) с 2012-13 года в качестве домашней fs. Сейчас держу пул на deb (testing) c zol 0.8.6 c (0.6) на одном диске по `zpool history` созданным в марте 2018. репозитории с бекапами + под виртуалки + помойка. Где-то отваливался драйвер (какая-то 0.7), где-то текла, где-то тупила. Начиная 0.8 стабильность заметно возросла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #31, #42

27. Сообщение от OpenEcho (?), 07-Янв-21, 16:08	+6 +/–
А на домашнем компютере не хранятся налоговые отчеты, фотки и видео семьи,которые будет досадно потерять ??? Если нет, то вам даже fat32 подойдет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29

28. Сообщение от Djonson (?), 07-Янв-21, 16:09	+4 +/–
Ну про BTRFS Вы, очевидно, в теориях. Краха BTRFS никогда не было? Очень забавный и чувствительный момент. ZFS надежнее будет. И да, бэкапов никто не отменял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #104, #124

29. Сообщение от Аноним (15), 07-Янв-21, 16:16	+/–
Налогов, семьи, фоток нет. Никого из перечисленных потерять будет не досадно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #33, #113

31. Сообщение от Аноним (31), 07-Янв-21, 16:59	+1 +/–
Продакшон на лимоны IOPS. Резко всё стало идеально с ZoL 0.8.3/Ubuntu_20.04. Всё что раньше - теряло read-range locks, стопорило процессы в D-State.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #92, #157

32. Сообщение от OpenEcho (?), 07-Янв-21, 17:08	+/–
> есть пара моментов, где можно пальнуть себе в ногу А можно поподробней об этом? Не любопытсва ради спрашиваю и не с подколом, т.к. приходится присматривать за НАС-ми с 512 Тб данными
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #38, #94

33. Сообщение от OpenEcho (?), 07-Янв-21, 17:14	+4 +/–
> Налогов, семьи, фоток нет. Никого из перечисленных потерять будет не досадно. В таком случае проще держать bootable флешку с read-only swicth-em - и безопасно и нет зависимости от компов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от Аноним (34), 07-Янв-21, 17:25	+8 +/–
> Жрёт очень много оперативки, Типичный ответ опеннетного иксперда. Файловые системы (и ZFS тоже) оперативку не жрут, а используют по прямому назначению - кешируют содержимое диска.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #35, #48, #63

35. Сообщение от Аноним (35), 07-Янв-21, 17:43	+1 +/–
Вообще-то, жрут. И btrfs тоже (особенно бтрфс). Да и кэши кэшам рознь. Проверить не сложно. Значит, создаёте каталог с парой миллиардов файлов и открываете его в какой-нибудь программе, потом смотрите куда и сколько памяти уходит. Это были только иноды по-сути. Далее, используете дедупликацию/снапшоты/сжатие/шифрование/вотевер и скармливаете ей подготовленный датасет на пару миллиардов файлов (дубликаты, рандомные данные, текст, частичные дубликаты - будет идеально), протоколируете наблюдения. Удаляете данные, опять отмечаете результаты. Каждый шаг тестирования должен быть воспроизводимым, повторять 3-5 раз с перезагрузкой и всем остальным. Желательно поочерёдно перебирать все варианты. Взять среднее значение, если они не расходятся совсем уж очевидно, если расходятся - проанализировать по какой причине и отбросить некорректные данные. Естественно использоваться должна консистентная система, т.е. можно взять либо снапшоты поверх bare-metal гипервизора, либо необходимо убедиться в отсутствии вмешательства внешних факторов в процесс тестирования, а тестирование проводить на отдельном (исправном) диске.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #62, #125

36. Сообщение от Кир (?), 07-Янв-21, 17:44	–4 +/–
ZFS нужна ECC память для надежной работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #49, #74

37. Сообщение от Аноним (37), 07-Янв-21, 17:47	+1 +/–
Еще любителям экспериментов можно линукс, фрибсд и опенсолярисовские форки ставить на один диск, сделать просто несколько отдельных датасетов для рутовой фс каждой и все, даже не придется думать кому сколько отдать - свободное пространство будет общим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #78

38. Сообщение от Аноним (37), 07-Янв-21, 17:56	+1 +/–
Да преувеличивает человек. С ZFS нужно тщательно все спланировать перед тем как пул создавать, это да (потом поменять рейд-левел, например, невозможно). А дальше проблем никаких не должно быть, кроме теоретически возможных проблем с обновлением загрузчика системы, который может быть не совместим с версией пула.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

39. Сообщение от псевдонимус (?), 07-Янв-21, 17:56	+/–
Не пинди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

40. Сообщение от псевдонимус (?), 07-Янв-21, 17:58	–2 +/–
Какого овоща ты сравниваешь древний кал экст с современной файловой системой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #47

41. Сообщение от псевдонимус (?), 07-Янв-21, 18:00	–5 +/–
С полулошадьюполуптицей экст4, которая почти всем хуже нтфс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #95

42. Сообщение от псевдонимус (?), 07-Янв-21, 18:02	–3 +/–
>Держу пул на деб тестинг Безумству храбрых поем мы песню©
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #99

43. Сообщение от псевдонимус (?), 07-Янв-21, 18:05	+3 +/–
Бтрфс...лучше совсем не показывать этого калеча и никому о нем не говорить. Позорище позорное, неисправимое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #65, #102

44. Сообщение от zzz (??), 07-Янв-21, 18:46	+6 +/–
Какой там геморрой с пулами? Подцепил устройства, сделал zpool create pool mirror|raidz /dev/da1 /dev/da2 ..., и погнали. Сдох диск - zpool replace pool <A-Z0-9> /dev/da3. Как это можно променять на убожество ext4 - непонятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #89, #96

45. Сообщение от Онаним (?), 07-Янв-21, 18:46	–4 +/–
ZFS в подобных случаях упрощает полную потерю данных, факт. Даже если бэкапы есть - развёртывать бэкап из миллионов файлов на несколько Тб - ну так себе затея. Выковыривание останков с помощью fsck используется в частности для того, чтобы хотя бы частично перезапустить сервисы до момента, когда бэкап развернётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #51

46. Сообщение от zzz (??), 07-Янв-21, 18:47	+1 +/–
Линуксопроблемы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

47. Сообщение от Онаним (?), 07-Янв-21, 18:48	+/–
Сравнивать поезд с проходчиком тоннелей - так себе затея, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #52

48. Сообщение от Онаним (?), 07-Янв-21, 18:58	–1 +/–
Кеш ZFS, к сожалению - вещь в себе, которая именно что "жрёт память", потому что отдача памяти назад ОС при необходимости затруднена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #55

49. Сообщение от Онаним (?), 07-Янв-21, 19:00	+/–
ECC память, ECC на всех внутренних шинах и т.п. Сферическая ситуация в вакууме, для которой существует специальное железо. В общем же случае что ZFS, что RAID с чётностью - один фиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #50

50. Сообщение от Онаним (?), 07-Янв-21, 19:03	+2 +/–
Упреждая "онашазфстакаясквозноцелостная" - в 99% реальных случаев данные будут повреждены ещё _до_ записи. И запишутся уже повреждёнными. Со "сквозной целостностью", угу. А от повреждения данных на дисках и шинах к таковым RAID с двойной чётностью допустим страхует достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #123

51. Сообщение от zzz (??), 07-Янв-21, 19:11	+/–
Людей, умудряющихся угробить ZFS до состояния невосстановимости, надо выгонять из профессии с волчьим билетом дворы мести - в Москве, говорят, сейчас как раз дефицит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #53, #79

52. Сообщение от zzz (??), 07-Янв-21, 19:12	+/–
>проходчиком тоннелей Так ext4 еще никто не унижал. Впрочем, резонно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #54

53. Сообщение от Онаним (?), 07-Янв-21, 19:12	+/–
> Людей, умудряющихся внедрить ZFS в mission-critical Fixed
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #58

54. Сообщение от Онаним (?), 07-Янв-21, 19:14	+/–
ext4 в этом сравнении поезд. Тупой как доска, но везущий пассажиров (сиречь данные). ZFS - проходчик тоннелей, который неспешно и с грохотом закладывает ваши данные во все труднодоступные места, сжирая на свою работу кучу ресурсов, но применимость ограничена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #57

55. Сообщение от zzz (??), 07-Янв-21, 19:18	+3 +/–
Линуксопроблемы, разделившие дисковый кэш и кэш ZFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #56

56. Сообщение от Онаним (?), 07-Янв-21, 19:19	+1 +/–
Как раз таки ZFSопроблемы, кэш ZFS на системный кеш не ложится что в пингвинах, что в бзде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #68, #101

57. Сообщение от zzz (??), 07-Янв-21, 19:22	+/–
Что-то похожее я уже слышал от фанатов FAT32 и ext2. Завязывай с геронтофилией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #60, #134

58. Сообщение от zzz (??), 07-Янв-21, 19:23	+/–
>криворуких ламерков Fixed
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #59, #61

59. Сообщение от Онаним (?), 07-Янв-21, 19:24	+/–
Согласен c корректировкой, я просто не стал уж настолько экспрессивно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #69

60. Сообщение от Онаним (?), 07-Янв-21, 19:25	+1 +/–
FAT32 до сих пор в каждой второй мобилке на SD. Из-за простоты и поддержки виндой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #70

61. Сообщение от bOOster (ok), 07-Янв-21, 20:26	+2 +/–
Написал криворукий ламерок совместно с каким-то пидси%алой. Сравнивать ext4 с ZFS которая по своему рождению enterprise class файловая система. Которую проектировала SUN, в которой я хочу заменить и с логикой и пониманием бизнеса в котором она вращалась было все в порядке, в отличии от полумертвых поделок рожаемых Linux сообществом, и не приживающихся за пределами Linux. Не надо, не стоит упоминать о продаже SUN.. Это никак не умоляет того чего SUN привнес в IT индустрию в целом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #85

62. Сообщение от bOOster (ok), 07-Янв-21, 20:31	+/–
Ну судя твоему посту садится голой жопой на кактус это конечно забава для тебя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #64

63. Сообщение от Аноним (22), 07-Янв-21, 20:43	–3 +/–
Ай да молодец. Установи сначала steam, игру более-менее большую, поиграй и посмотри, прежде чем писать "типичную" писанину но и чём. При использовании ext4, btrfs и xfs ничего подобного не происходит, а с zfs - даже после выхода со всех программ из 8 гб доступными остаются только 1-2 гб. Побегал по форумам и да, действительно, zfs при определенных обстоятельствах жрёт очень много оперативки. Она вообще очень сырая, и на текущий момент её уровень соответствует уровню btrfs 5-летней давности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #75, #80, #88

64. Сообщение от Аноним (35), 07-Янв-21, 20:46	+2 +/–
Это ещё почему? Потому, что я не склонен слепо доверять свои данные сырой косячной технологии и сперва проведу тестирование и проанализирую результаты? И, по возможности, сымитирую ускоренную деградацию, чтобы внезапно не столкнуться с ней, когда будет уже поздно? Или это зависть? Мне вот hammer очень нравится, но это не значит, что я ей что-нибудь доверю. Так там хотя бы разработчик у неё есть. В данном же случае оракл не особо заинтересован в развитии форка своего старого кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #146

65. Сообщение от Аноним (22), 07-Янв-21, 20:46	–3 +/–
Смех, да и только;) Поверьте, лучше не создано, и не будет создано ещё очень долго. И сейчас btrfs становится фс номер один, и будет номер один очень долго.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #66, #67

66. Сообщение от псевдонимус (?), 07-Янв-21, 20:51	+2 +/–
Федорактивиста вижу в треде я...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #77, #129

67. Сообщение от псевдонимус (?), 07-Янв-21, 21:00	+/–
> Смех, да и только;) Поверьте, лучше не создано, и не будет создано > ещё очень долго. И сейчас btrfs становится фс номер один, и > будет номер один очень долго. Петя, ты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #83, #131

68. Сообщение от Аноним (35), 07-Янв-21, 21:12	+/–
Так вроде в соляре этот кеш интегрирован в системный (или наоборот), в таком случае, у ZFS нет проблем с этим. Она просто инородная и все остальные ядра не разработаны под неё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #90, #126

69. Сообщение от zzz (??), 07-Янв-21, 21:24	+/–
Ну так исправляй руки, и не будет проблем с ZFS. А лучше не майся дурью и иди мести дворы, в такие руки титановые шарики давать опасно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #84

70. Сообщение от zzz (??), 07-Янв-21, 21:26	–1 +/–
Диск С-то отформатил под этот "поезд"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #86, #117

71. Сообщение от Егор (??), 07-Янв-21, 23:32	+/–
Пусть уж лучше уменьшается при создании снапшота, чем будет уменьшена с самого начала работы постоянно включенным COW.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #115

72. Сообщение от Аноним (72), 07-Янв-21, 23:35	+1 +/–
В пространстве пользователя ядерного модуля, ты хотел сказать. Не благодари.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #213

73. Сообщение от none_first (ok), 08-Янв-21, 00:22	+1 +/–
> Кривое чудо. Добавил ssd в комп. Угадайте как на него перенести свою > хоум папку? Спорю что не знаете. > После этого еще пул начал периодически исчезать. Вылечил через import. После очередного > обновления ZoL при загрузке вообще вывалился в черный экран с сообщением > что импортировать нечего поэтому сами напишите мне в строке zfs import > root и тд возможно повреждён кэш-файл https://pbs.proxmox.com/docs/sysadmin.html возможно в ситуации проблемы загрузки рута... руками надо указать как написано ток добавить имя пула и -N (чтобы позже смонтировать) а далее zfs mount -a ^D (выход из шела, где стопарнулось) пойдёт загрузка (скорее-всего ;) ) > Н если это написать то ответ что импортировать нечего > Зато если написать exit  то загрузка продолжится и все будет норм... > но в zfs list  видно что все смонтировалось черте куда. > Вобщем странная штука с отсутствующей поддержкой (ни форумов ни групп ни ответов > на гитхабе). > Работает нормально только в дефолтном варианте иначе хер разберешься
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

74. Сообщение от xm (ok), 08-Янв-21, 02:03	+4 +/–
Любой файловой системе нужна ECC для надёжной работы. Просто другие об этом не пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #121

75. Сообщение от Аноним (75), 08-Янв-21, 03:46	+/–
Это zol такой. zfs в солярисах работает как надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #76, #145

76. Сообщение от Аноним (22), 08-Янв-21, 04:22	+/–
Спору нет, более чем уверен, что в Solaris оно работает наверное идеально, или около того.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

77. Сообщение от Аноним (22), 08-Янв-21, 04:34	+/–
Таки нет, хотя в последнее время fedora очень даже ничего. Вообще btrfs масштабно и по умолчанию начали применять в opensuse, а fedora упор на lvm делала? Но возможности и потенциал btrfs - огромны, хотите вы того или нет. Даже они это поняли, и в 33 версии по умолчанию её предлагают. А начиная с 34 версии появятся очень интересные фишки, благодаря возможностям btrfs. Да и вообще в будущем будет создано много классных вещей благодаря этой фс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #82

78. Сообщение от Аноним (78), 08-Янв-21, 05:31	+/–
И вот как Openindiana, FreeBSD, Linux на одном HDD сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

79. Сообщение от Аноньимъ (ok), 08-Янв-21, 05:33	+/–
Что за бред, вас Линукс покусал? Похерить зфс может всё что угодно. От ошибок оборудования ядра самой реализации зфс волшебным образом не спасает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #231

80. Сообщение от Аноньимъ (ok), 08-Янв-21, 05:41	+2 +/–
Потребление памяти зфс как бы настраивается. Дефолты там серверные. Про сырость это вы так толстите или туту?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #103

81. Сообщение от iCat (ok), 08-Янв-21, 06:47	+/–
>zfs лучше ext4? Чем? Не "чем", а "для каких задач".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

82. Сообщение от псевдонимус (?), 08-Янв-21, 06:57	–1 +/–
> Таки нет, хотя в последнее время fedora очень даже ничего. Вообще btrfs > масштабно и по умолчанию начали применять в opensuse, а fedora упор > на lvm делала? Но возможности и потенциал btrfs - огромны, хотите > вы того или нет. Даже они это поняли, и в 33 > версии по умолчанию её предлагают. А начиная с 34 версии появятся > очень интересные фишки, благодаря возможностям btrfs. Да и вообще в будущем > будет создано много классных вещей благодаря этой фс. А не могли бы они запили б такую фичу, как сохранение данных, а не превращение их в кашу без возможности восстановления? Джва..10 лет жду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #130

83. Сообщение от Аноним (-), 08-Янв-21, 10:09	+/–
Нет, это его жена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #87

84. Сообщение от Онаним (?), 08-Янв-21, 10:47	–1 +/–
У меня внезапно нет проблем с ZFS. Нет ZFS - нет проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #273

85. Сообщение от Онаним (?), 08-Янв-21, 10:48	–1 +/–
Не знаю, как там по рождению, но по настоящему это - hype class файловая система.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #223

86. Сообщение от Онаним (?), 08-Янв-21, 10:49	+/–
У каждой FS своё применение, чудик. И вот тут монстр ZFS с квадратными колёсами ложится разве что в область "подзюбить на модную FS", других не видится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

87. Сообщение от псевдонимус (?), 08-Янв-21, 11:23	+/–
> Нет, это его жена. Однополая надеюсь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #91

88. Сообщение от Аноним (34), 08-Янв-21, 16:52	+3 +/–
> Она вообще очень сырая, и на текущий момент её уровень соответствует уровню btrfs 5-летней давности. ЧИТД. Уровень икспердизы зашкаливает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

89. Сообщение от Ананимас008 (?), 08-Янв-21, 17:46	+/–
>zpool create pool mirror|raidz /dev/da1 /dev/da2 ..., и погнали. Сдох диск - zpool replace pool <A-Z0-9> /dev/da3 не лучше ли сначала сделать метки gpt и создавать на их основе, чем зависить от порядка устройств в "биосе".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #93, #100

90. Сообщение от Онаним (?), 08-Янв-21, 18:56	–1 +/–
Есть смысл труп обсуждать? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

91. Сообщение от Онаним (?), 08-Янв-21, 18:57	+/–
У вас есть двуполая жена? Покажите!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

92. Сообщение от Онаним (?), 08-Янв-21, 18:59	–1 +/–
> Продакшон на лимоны IOPS > теряло read-range locks, стопорило процессы в D-State Блджад, кто ж это в продакшн-то "на лимоны IOPS" пустил, насколько нужен особый талант, чтобы это сделать? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

93. Сообщение от Онаним (?), 08-Янв-21, 19:00	+/–
У них там своя, особая атмосфера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #119

94. Сообщение от 9nko (ok), 08-Янв-21, 19:26	+/–
Про планирование уже ответили ранее. В ситуации, когда 12-и терабайтник вдруг можно будет заменить двумя 8-и терабайтниками меня подвела. С фиксированным размером пула, который нельзя уменьшить это реально проблема. Я свой домашний NAS расширяю постепенно, данные перезаливаю с одного диска на другой (так нужно), он растёт не сразу, и соответственно имеет динамическую структуру и иерархию. С ZFS это проблема.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #112

95. Сообщение от 9nko (ok), 08-Янв-21, 19:27	+/–
Полулошадь-полуптица это пегас. И хуже всем - это чем именно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #118

96. Сообщение от 9nko (ok), 08-Янв-21, 19:29	+/–
У меня рейд только на 2 хардах из 6. Остальные диски иногда меняются на большие или меньшие по объёму, от чего в моём случае фиксированный пул является проблемой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

97. Сообщение от пох. (?), 09-Янв-21, 13:49	+2 +/–
> но она хуже чем ext4 потому что zfs нельзя использовать на одном диске Я использую, что я делаю не так? > если навернется часть данных - навернётся всё и полностью Нет. Более того, маловероятно что навернется у васян-десктопа так, что он потеряет больше чем последние изменения в файлике. _значительно_ вероятнее что в неописуемую кашу превратится именно ext4 (а накат кривого журнала, который ты, конечно же, забудешь отключить, даже если умеешь - ее добьет) > средств восстановления кроме бэкапа нет (никаких утилит для выколупывания файлов нет) Если ты надеешься на "утилиты для выколупывания" со своим единственным диском - значит, у тебя ценного там ничего и не было. А zpool destroy/create - на порядок или даже два быстрее аналогичной процедуры с ext4, не смотря на все "uninit bg". Проблема zfs как раз в обратном - нельзя доверять ее redundancy и self-healing там, где как раз положено - на больших массивах, где есть куда дублировать и есть на что откатываться, а вот бэкап технически невозможен или бессмысленнен. Ну, блжад, а как-будто у вас еще что-то хоть полурабочее есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #116

98. Сообщение от пох. (?), 09-Янв-21, 13:53	–1 +/–
Ну тебе правда интересны проблемы "оригинала", написанного саном в 2002м году, когда компьютеры были большие? Основная разница именно в этом - тот сановский был по сегодняшним меркам нерабочим прототипом, поскольку нам сегодня надо вовсе не "аж целых 100 гигабайт" и не "в аж целых 256mb оперативной памяти". А если ты про сегодняшний орацловский - так он ни разу ничего не оригинал, код закрыт, что там унутре - никто не знает, да и смысла нет. Упало - звони в техподдержку, как хотят, так пусть и чинят. Нишмагли? Ну бида-бида, у нас ведь все оформлено как полагается? Вот и хорошо...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

99. Сообщение от пох. (?), 09-Янв-21, 13:54	+2 +/–
Чего не так с всего лишь позапрошлогодними версиями софта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #106

100. Сообщение от пох. (?), 09-Янв-21, 13:57	+1 +/–
Совершенно ненужно - какой диск отвалился здесь и сейчас - zpool status тебе скажет. А как он там будет называться после перезагрузки через пару лет - и незачем знать. метки gpt (да и сам gpt, если это не загрузочная флэшка) нафиг не нужны - лишний набор глюков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #110

101. Сообщение от пох. (?), 09-Янв-21, 14:00	–1 +/–
Ну так это проблема систем с неотключаемым ненужно-"системнымкэшом". У BSD НЕТ никакого "системного кэша", если ты до сих пор не в курсе. Что вызывает нешуточный батхерт у любителей портировать туда линуксный мусор, кстати. Поскольку тот вообще не в курсах, что так бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #109

102. Сообщение от пох. (?), 09-Янв-21, 14:03	+/–
"а я и не сплю". В смысле, а исправлять никто и не собирался, md raid (с полным копированием всех данных после перезагрузки ресетом - хороший, полезный стресстест для твоего массива) ихнее всьо. Изучай thin lvm. Все равно ничего другого в обозримом будущем не останется (и zfs доломают, причем на всех платформах).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #107, #108, #132, #234

103. Сообщение от пох. (?), 09-Янв-21, 14:07	–1 +/–
То что его там надо "настраивать" - неисправимая ошибка в ДНК тех людей, которые, к сожалению, захватили контроль над проектом. Почему потребление памяти ext4 НЕ НАДО настраивать, это всегда вся свободная память системы (даром что используется неэффективно в виду родовых травм)? В солярисе ничего настраивать было не надо. Создать аналогичные фичи в любой другой системе (кроме линyпса, где не пустят) можно и небезумно сложно, просто некому - iX и дельфиксам платят не за это. slw@ свалил пилить ceph.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #105, #128

104. Сообщение от Moomintroll (ok), 09-Янв-21, 14:28	–1 +/–
> ZFS надежнее будет. Когда будет - тогда и приходите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

105. Сообщение от Аноньимъ (ok), 09-Янв-21, 14:32	+/–
Нет не вся. То же нужно настраивать для спецефических задачь. Коими для зфс является персональный компьютинг с низким объёмом ОЗУ. А в екс4 в принципе нет тех механизмов кеширования что в зфс. На счёт Соляриса незнаю, вы пользовались солярисом на десктопе? Попробуйте сравнить челе на одном и том же железе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

106. Сообщение от псевдонимус (?), 09-Янв-21, 15:01	+/–
Старые баги  ещё не починили, а новые уже доставили. Кушай не обляпайся!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

107. Сообщение от псевдонимус (?), 09-Янв-21, 15:07	+/–
> "а я и не сплю". > В смысле, а исправлять никто и не собирался, md raid (с полным > копированием всех данных после перезагрузки ресетом - хороший, полезный стресстест для > твоего массива) ихнее всьо. > Изучай thin lvm. Все равно ничего другого в обозримом будущем не останется > (и zfs доломают, причем на всех платформах). > Полезный стресс есть. Так данные от такой "пользы" похерится могут. Иихерятся. Надеюсь зфс окончательно не разломают. Линукса, тем более шапкообразного с на хранилке у меня не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #140, #149

108. Сообщение от псевдонимус (?), 09-Янв-21, 15:10	+/–
> "а я и не сплю". > В смысле, а исправлять никто и не собирался, md raid (с полным > копированием всех данных после перезагрузки ресетом - хороший, полезный стресстест для > твоего массива) ихнее всьо. > Изучай thin lvm. Все равно ничего другого в обозримом будущем не останется > (и zfs доломают, причем на всех платформах). Кроме того у бсд..ов есть геом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #142

109. Сообщение от Онаним (?), 09-Янв-21, 15:45	+/–
Извини, но ты гонишь :D Оно у них называется "буфером", но суть та же. "FreeBSD has a unified buffer cache. This means that ALL AVAILABLE MEMORY IS A BUFFER CACHE for all device IO."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #127, #143

110. Сообщение от Ананимас008 (?), 09-Янв-21, 16:49	+/–
Никогда не имел проблем с gpt Самое интересное начнется если пулов несколько и это не миррор, сиди потом гадай. Не лучше ли постелить соломку заранее и не зависить ни от порта, куда подключаешь ни от особенностей сата/пата/скази/ватэвер контроллера, особенно если он потом полетит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #120, #138

111. Сообщение от Ананимас008 (?), 09-Янв-21, 17:51	+/–
Человеческое сжатие, а не как в убогом нтфс лишь с кластером на 4к и убогим зипом. Возможность быстро прибить кучу бесполезных торентов с котиками или проном. Хоть млрд файлов там, пока твой этот шиндовс будет подсчитывать сколько и чего там удалять. "ленивый бекап" снапшотами, так что очередной скаченный тобой вирусец с торрентов для игрушек не зашифровал фотки твоих котиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #114

112. Сообщение от OpenEcho (?), 09-Янв-21, 18:42	+/–
> В ситуации, когда 12-и терабайтник вдруг можно > будет заменить двумя 8-и терабайтниками меня подвела. Но, так не нежно > С фиксированным размером пула, который нельзя уменьшить это реально проблема. В интернете масса примерров и обьяснений почему не надо жадничать и делать RAID5 подобные массивы ака RAIDZ. Eсли вы будете строить массивы зеркал, (да, в 2 раза дороже) то у вас не будет проблем с маштабируемостью, замена дисков в пуле делается "на лету" и не надо ждать месяц, другой пока весь пул синхронизируется(а учитывая, что диски как правило из одной партии, то велика вероятность, что грохнется еше один, а то и более дисков и тогда всему массиву кердык). Благодоря тому, что диски можно в этом случае вешать на пралелльные контроллеры, скорость чтения тоже увеличивается. > С ZFS это проблема. У нас не было (тьфу-тьфу) проблем, и я говорю о сотнях НАС-ов в продакшене
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #135

113. Сообщение от Аноним (-), 09-Янв-21, 18:47	+/–
> Налогов, семьи, фоток нет. Никого из перечисленных потерять будет не досадно. Есть еще фича: если при обновлении системы что-то пошло не так, есть довольно большая разница: откатить в вид как было за 2 минуты или полдня систему восстанавливать/переустанавливать. Но на Linux для rootfs лучше btrfs взять. К тому же он умеет дублировать метаданные даже на 1 носителе, что очень понижает риск его кончины от мелких случайностей. А чексуммы намекнут о проблемах с железом, если повезет то до того как это превратится в большую проблему. В btrfs еще можно reflinks делать. Когда 2 файла ссылаются на одинаковые блоки изначально. Так что вон тот образ диска виртуалки на 20 гиг можно "скопировать" моментально а CoW прозрачно обыграет отличия между виртуалками, при том храниться будет только шаблон и отличия от него, а не два полных 20-гиговых диска. Можно и еще что-нибудь прикольное, типа хранения 2 копий даже на 1 носителе, что повышает шансы в случае облома. А сказ про RAID это здорово, но вот так можно и с единичной флешкой, с 1 разделом. А RAID из нее делать - как минимум непрактично. В общем это совсем другой уровень технологий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #184

114. Сообщение от Аноним (-), 09-Янв-21, 18:51	+/–
> 4к и убогим зипом. Вообще-то там NTLZ, чтоли. Хоть он и ни о чем, жмет даже похуже LZ4 и LZO, а распаковывается медленнее. Единственное достоинство - MS это смог накодить в свои лохматые 90е. А потом совместимость... > "ленивый бекап" снапшотами, так что очередной скаченный тобой вирусец с торрентов для > игрушек не зашифровал фотки твоих котиков. Может и не помочь если вырусец диск лобовым доступом покорежит. Впрочем откуда вырусец в *никсах? А в винде zfs вроде и нет толком. Наверное fuse версия даже работает - но тогда виндузоиды ощутят себя как линуксоиды с нтфсом в фузе, который в проц упирается а не в диск.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #122, #227

115. Сообщение от Аноним (-), 09-Янв-21, 18:57	+/–
> Пусть уж лучше уменьшается при создании снапшота, чем будет уменьшена с самого > начала работы постоянно включенным COW. CoW сам по себе производительность не уменьшает. Наоборот - он почти аналог полного журнала при единичной записи, как без журнала совсем. Однако поскольку вся ФС превращается в подобие журнала, есть всякие нюансы. Поэтому кто кого - очень зависит от характера нагрузки. БД какая-нибудь с множеством мелких записей конечно дико зафрагментируется, а огромная кипа метаданных будет и тормозить и место сожрет. Но это лишь один из случаев. В btrfs по этому поводу cow сделали отключаемым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #226

116. Сообщение от Аноним (-), 09-Янв-21, 19:05	–1 +/–
> Я использую, что я делаю не так? А он дублировать метаданные на 1 диске как btrfs умеет? Или скопытится как ext4 от единственного бэда под метаданными? > Нет. Более того, маловероятно что навернется у васян-десктопа так, что он потеряет > больше чем последние изменения в файлике. _значительно_ вероятнее что в неописуемую > кашу превратится именно ext4 (а накат кривого журнала, который ты, конечно > же, забудешь отключить, даже если умеешь - ее добьет) И чего zfs будет делать если бэд под метаданными не прочитается, например? Развалится как ext4, только еще и без fsck? :) А дальше чего? Но, конечно, можно вместо единственного диска энтерпрайзную хранилку, блабла. Только для ноута это не практично. > Если ты надеешься на "утилиты для выколупывания" со своим единственным диском - > значит, у тебя ценного там ничего и не было. Однако такая монстрила могла бы и получше работать и на менее энтерпрайзных случаях - as seen in btrfs. Просто в ZFS это не надо никому, не LLNL же, право? > А zpool destroy/create - на порядок или даже два быстрее аналогичной процедуры с > ext4, не смотря на все "uninit bg". Не особо частая операция, особенно в петабайтных масштабах, чтобы скоростью заморачиваться. > Ну, блжад, а как-будто у вас еще что-то хоть полурабочее есть? btrfs же, ну? Или это фрибсдшникам вопрос? :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #133

117. Сообщение от Аноним (-), 09-Янв-21, 19:09	+/–
> Диск С-то отформатил под этот "поезд"? Прикинь, приходишь ты на станцию - а там рельсы уже положены и поезда ездят. А карточки прямо с фабрики в FAT32 идут. Форматировать не надо - и вообще нежелательно. Иначе море приколов на ровном месте можете получить, когда у вас ВНЕЗАПНО слетит таблица разделов с бутсектором например, или скорость записи в разы обвалится, с кончиной картой в разы быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #222

118. Сообщение от Аноним (-), 09-Янв-21, 19:11	–2 +/–
> Полулошадь-полуптица это пегас. И хуже всем - это чем именно? Наверное, тем что 50 000 файлов в дире даже еще и читаются за обозримое время, а не как в винде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

119. Сообщение от Аноним (-), 09-Янв-21, 19:14	+/–
> У них там своя, особая атмосфера. А зачем в общем то разделы если на 1 часть резать? Чтобы занять место и поместить дополнительную структуру, которая еще и слететь при случае сможет? И да, что-то такое и с btrfs катит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

120. Сообщение от Аноним (-), 09-Янв-21, 19:15	–1 +/–
В btrfs такой траблы просто нет - у дисков нет какой-то специальной выделенной функциональности, все равноправные. Но да, прикольные менеджментпроблемы там где их быть совсем не должно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

121. Сообщение от Аноним (-), 09-Янв-21, 19:16	–1 +/–
> Любой файловой системе нужна ECC для надёжной работы. Просто другие об этом > не пишут. А какой смысл им об этом писать? EXT4 без полного журнала вообще плевать хотел что там с данными случится при крахе. А раз так какой смысл париться ECC памятью? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #139, #153

122. Сообщение от Ананимас008 (?), 09-Янв-21, 19:17	+/–
>Впрочем откуда вырусец в *никсах? Wine же :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

123. Сообщение от Аноним (-), 09-Янв-21, 19:19	+/–
Эксперименты с btrfs показали что таки тот неплохо детектит идиотские взбрыки железа и даже ухитряется более-менее чинить все это из второй копии, если она есть. Прикол ситуации в том что так оно загаживается намного медленнее чем ФС с одной копией данных/метаданных, ухитрившись заметить и парировать порядочно сбоев железа. Хоть это и без гарантий совершенно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

124. Сообщение от Аноним (-), 09-Янв-21, 19:22	–1 +/–
> Ну про BTRFS Вы, очевидно, в теориях. Краха BTRFS никогда не было? Кроме теории, он довольно неплох и на практике. Нет, не было. > Очень забавный и чувствительный момент. ZFS надежнее будет. И да, бэкапов > никто не отменял. Особенно надежно когда фс вообще не маунтится после апдейта системы. Вдвойне круто когда это все на рутфс-е.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #237

125. Сообщение от Аноним (-), 09-Янв-21, 19:24	+/–
> Вообще-то, жрут. И btrfs тоже (особенно бтрфс). Btrfs ничем таким не особенный, он пользует обычные ядерные кэши. По поводу чего живет даже на роутере с 64 мегами оперативы. И даже не сильно тормознее EXT4, но намного надежнее и диагностируемее. Удачи в такой конфиге с ZFS'ом...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

126. Сообщение от Аноним (-), 09-Янв-21, 19:26	+1 +/–
> Так вроде в соляре этот кеш интегрирован в системный (или наоборот) Так у соляры не было своего менеджера кэша, они и накодили его прямо в файлухе. Но у остальных он таки есть и смысл в дубле оного в ФС почти как в стопсигнале для зайца - только мешает менеджменту памяти кернела, конкурируя с ним за ресурс довольно дурным образом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

127. Сообщение от Аноним (-), 09-Янв-21, 19:27	+/–
В бздях пох такой же эксперт как и в линуксе :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

128. Сообщение от Аноним (-), 09-Янв-21, 19:31	+/–
> ext4 НЕ НАДО настраивать, это всегда вся свободная память системы (даром > что используется неэффективно в виду родовых травм)? Более того - в btrfs его тоже не надо настраивать. Юзает сколько может, отдает когда надо другим, без дурацких драк за ресурс. Ну и вот так по приколу взлетает на мипсе с 64 мегами и особо не тормозит. Ext4 пошустрей конечно, но чексумы и дублирование метаданных все же не умеет. > В солярисе ничего настраивать было не надо. Так там это не было дублирующейся фичой, за ресурс драться было не с кем, ну и проблемам на стыке этого было неоткуда взяться. Но из линухов и бздей никто в здравом уме их кэши не выкинет, там другие users этого есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #148

129. Сообщение от Аноним (-), 09-Янв-21, 19:32	+/–
> Федорактивиста вижу в треде я... Кстати, от этих тоже патчей подвалило. Ничего сверхъестественного, но время монтирования поубавили, например. Пустячок а приятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

130. Сообщение от Аноним (-), 09-Янв-21, 19:34	+/–
Ты вообще линукс судя по всему только на скриншотах видишь, а бсдшный экспериенс относительно btrfs можно и 20 лет ждать, пожалуй. Скорее виндузоиды дождутся, но вот у них оно и правда сырое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #137

131. Сообщение от Аноним (-), 09-Янв-21, 19:34	+/–
> Петя, ты? Not Petya!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

132. Сообщение от Аноним (-), 09-Янв-21, 19:35	–1 +/–
> Изучай thin lvm. Лучше btrfs изучить - и почувствовать разницу. Рулится в духе zfs, только без некоторых его дурацкостей :-]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #136, #151

133. Сообщение от пох. (?), 09-Янв-21, 19:43	+/–
>> Я использую, что я делаю не так? > А он дублировать метаданные на 1 диске как btrfs умеет? Или скопытится это чтоб вместо 64x write amplify получить 256? Не, не умеет. > как ext4 от единственного бэда под метаданными? тоже нет (как и ext4) - обычно такую простую проблему можно обойти, даже если предыдущие уровни защиты (а они есть) не сработали. > И чего zfs будет делать если бэд под метаданными не прочитается, например? не прочитает. Это случай, когда остальное надо аккуратно копировать, если оно хоть малейшую ценность представляло, а диск - выкидывать, а не волшебные fs изобретать. > Развалится как ext4, только еще и без fsck? :) А дальше отдельный вопрос - как fsck помогает ext4 при нечитающихся метаданных. > Однако такая монстрила могла бы и получше работать и на менее энтерпрайзных она вполне хорошо работает в этих случаях - значительно лучше недоделка btrfs (кстати, опачки при штатной перезагрузке, надысь. Ну не то чтобы не для того и брали...) > Не особо частая операция, особенно в петабайтных масштабах, чтобы скоростью заморачиваться. ты только что гнал какую-то чушь про ноутбук - у тебя в нем петабайтные масштабы? Пойди проспись, праздники уже кончились, в понедельник на галеру. >> Ну, блжад, а как-будто у вас еще что-то хоть полурабочее есть? > btrfs же, ну? Или это фрибсдшникам вопрос? :)) Нет, это совсем нерабочее. Я больше доверяю thin lvm с xfs - оно глючит и перезагружается от неведомых причин, но последнее время - вроде, каждый раз перезагружается, а не опачки-чавойтаянемагу. Но, надо признать, когда навернется, destroy/create там дольше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #154

134. Сообщение от пох. (?), 09-Янв-21, 19:45	+/–
> Что-то похожее я уже слышал от фанатов FAT32 и ext2. Завязывай с > геронтофилией. для них (в отличие, кстати, от ext4) существовали еще некоторые средства ручного восстановления, если что. Ну и было, из чего восстанавливать, а не "uninit bg" и экстенты, которых никто не понимает и чинить не умеет. С другой стороны - диски сильно подешевели, теперь уже в общем и незачем восстанавливать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #181

135. Сообщение от пох. (?), 09-Янв-21, 19:50	+/–
> В интернете масса примерров и обьяснений почему не надо жадничать и делать > RAID5 подобные массивы ака RAIDZ. Eсли вы будете строить массивы зеркал, Хотел бы я быть таким нежадным. Но, блин, чавойта не получаетцо. Деньгов, что-ли, не хватает, на второй массив того же размера? Э...при нынешних дисках еще и третий ведь нужен. > Благодоря тому, что диски можно в этом случае вешать на пралелльные > контроллеры, скорость чтения тоже увеличивается. как будто с raidz кто-то мешал. А в таком режиме - не то что btrfs, в таком и lvm будет работать почти прилично. И геморроя меньше. Я до сих пор в восторге от того, что ZoL - _единственная_, сцуко, из общедоступных линуксных fs, требующая перезагрузки или export чтобы подцепить увеличившееся место на том же диске.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #158, #176

136. Сообщение от псевдонимус (?), 09-Янв-21, 19:56	+/–
>> Изучай thin lvm. > Лучше btrfs изучить - и почувствовать разницу. Рулится в духе zfs, только > без некоторых его дурацкостей :-] И без некоторых сохранностей данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #141

137. Сообщение от псевдонимус (?), 09-Янв-21, 19:58	+/–
К счастью я его в виртуалке в основном вижу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #144

138. Сообщение от пох. (?), 09-Янв-21, 20:01	–1 +/–
> Никогда не имел проблем с gpt держи в курсе. Я вот развлекся, недавно. Мне нимало доставил тот интересный факт, что из общедоступных средств починить битый gpt есть по факту ровно одно - подключить такой диск к винде. И руками тоже не получится из-за миллиона бесполезных контрольных сумм, которые все непременно проверяют, непонятно зачем. > Самое интересное начнется если пулов несколько и это не миррор, сиди потом не вижу разницы. Все что надо - узнать, кто у нас сдох, и прочитать с него серийник, если получится. А как он сегодня называется - совершенно фиолетово, да и что там за метки и были ли они - тоже (если не читаются, то поздно уже, если читаются - от серийника больше проку) > Не лучше ли постелить соломку заранее и не зависить ни от порта, соломку за тебя sun двадцать лет назад уже постелила. Пул соберется независимо ни от порта, ни от чего еще. Стандартным фокусом пять лет назад было перед созданием пула завести себе gnop с 4k вместо фейковых 512 на самом носителе. А потом его просто удалить, экспортнув на прощанье пул - он после create низачем не нужен. zfs ничуть не расстраивалась, при следующей загрузке не обнаружив вообще того устройства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #212

139. Сообщение от пох. (?), 09-Янв-21, 20:03	+/–
> А какой смысл им об этом писать? EXT4 без полного журнала вообще > плевать хотел что там с данными случится при крахе. А раз > так какой смысл париться ECC памятью? :) такой, что, внезапно, она не от крахов, а от штатной записи мусора вместо данных или метаданных. От крахов в ext4, внезапно, fsck.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #147

140. Сообщение от Аноним (-), 09-Янв-21, 20:04	–1 +/–
> Линукса, тем более шапкообразного с на хранилке у меня не будет. А вот это уже твои проблемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #150

141. Сообщение от Аноним (146), 09-Янв-21, 20:09	–2 +/–
> И без некоторых сохранностей данных. Естественно, бсдшнику виднее что у нас там в этих наших линуксах с сохранностью данных. > Линукса, тем более шапкообразного с на хранилке у меня не будет. Тебя за язык никто не тянул, это все что на самом деле надо знать о твоем уровне экспертизы по поводу данных в Linux. Ты это небось даже на скриншоте не видел но мнение имеешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #152, #155, #209

142. Сообщение от Аноним (146), 09-Янв-21, 20:11	–2 +/–
> Кроме того у бсд..ов есть геом. Чего с ним делать предлагается? Инновационный UFS развернуть? Или таки FAT? Что там у вас еще есть? Какой-то кастрированный вариант EXT'а, чтоли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

143. Сообщение от пох. (?), 09-Янв-21, 20:12	+1 +/–
> Извини, но ты гонишь :D > Оно у них называется "буфером", но суть та же. нет, не та же. > "FreeBSD has a unified buffer cache. This means that ALL AVAILABLE MEMORY > IS A BUFFER CACHE for all device IO." а это и просто бред сивой кобылы. Ну да, с тем же успехом можно сказать что all available memory is arc в случае zfs. К счастью, можно все же сделать, чтоб не all. А то какой-нибудь просто шелл внезапно уезжает из под тебя по sigbus. Чтобы полностью осознать отличия - можешь попробовать запустить пресловутый ntfs3g. Только не забудь отключить зависимости при сборке, а то там-то, из-за древности технологии, вручную подложен костылик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #160, #183

144. Сообщение от Аноним (146), 09-Янв-21, 20:13	+1 +/–
> К счастью я его в виртуалке в основном вижу. А я вот его к счастью вижу везде. И на десктопе, и на лаптопе, и на сетевых штуках и много чем еще. То что у тебя он работает через зад - логично. Не твоя технология, инструмент не по руке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #156

145. Сообщение от пох. (?), 09-Янв-21, 20:13	+1 +/–
> Это zol такой. zfs в солярисах работает как надо. ноль остается? Ну да, примерно так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

146. Сообщение от Аноним (146), 09-Янв-21, 20:16	+/–
Практика лучший критерий истины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

147. Сообщение от Аноним (-), 09-Янв-21, 20:22	+/–
> такой, что, внезапно, она не от крахов, а от штатной записи мусора > вместо данных или метаданных. А смысл улучшать на полшишечки EXT4 который на integrity данных заведомо клал? Блин, да даже с RAID если у тебя копии разойдутся ты даже не узнаешь какая из них правильная. Чего хочешь - то и делай. Btrfs скажет csum error, corrected и поедет дальше. Посмотрев по чексумме какая из копий правильная. Так прикольнее. > От крахов в ext4, внезапно, fsck. Fsck очень клево, особенно на автопилотируемых системах или когда он хомячку в морду вопросы задавать начинает. И вообще мы все только и мечтаем что отвечать на дурацкие технические вопросы компьютеров вместо эксплуатации систем и занятий своими проектами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #206, #278

148. Сообщение от пох. (?), 09-Янв-21, 20:26	+/–
>> ext4 НЕ НАДО настраивать, это всегда вся свободная память системы (даром >> что используется неэффективно в виду родовых травм)? > Более того - в btrfs его тоже не надо настраивать. Юзает сколько > может, отдает когда надо другим, без дурацких драк за ресурс. Ну только неэффективно - поскольку кэш этот не ее, а дядин. А дядя ничего не знает о том, что можно отдавать, а что попридержать. Баг 12309 - он именно оттуда, на вымывании кэша. > Так там это не было дублирующейся фичой, за ресурс драться было не Было, у нее тоже была ffs с afair уже даже buffer cache в последних версиях. Как не с кем? Память для программ откуда по твоему взяться должна? Просто ее инженеры проектировали, и как один общий проект, а не как лебедьщукураком и "мы вам запретим пользоваться avx-фичами процессора чтоб у вас все плохо работало, патамушта могем". Взяли и запилили апи специально для избегания global lock и быстрого отъема лишнего - просто потому что он коллегам был нужен именно такой. > Но из линухов и бздей никто в здравом уме их кэши > не выкинет, там другие users этого есть. Внезапно, vm_obj shadowing с (uncompressed) arc - работает. А никакой другой кэш поверх arc - не нужен (и особенно ненужен ZoL'овый abd с его локапами. Кстати, эта память жрется как не в себя, и ее нигде не видно).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #162, #232, #233

149. Сообщение от пох. (?), 09-Янв-21, 20:30	+/–
> Линукса, тем более шапкообразного с на хранилке у меня не будет. synology жрет, и добавки просит, а он, вишь, не хочет! А что там внутре netapp - нам не расскажут и не покажут (точнее, по принципу "на те Боже, что нам не гоже")
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #159

150. Сообщение от псевдонимус (?), 09-Янв-21, 20:36	+1 +/–
Т.е. моя проблема будет состоять в отсутствии проблем? Принято.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #164

151. Сообщение от пох. (?), 09-Янв-21, 20:36	+1 +/–
>> Изучай thin lvm. > Лучше btrfs изучить - и почувствовать разницу. Рулится в духе zfs, только > без некоторых его дурацкостей :-] вот, к примеру, без объявления войны не смонтировался надысь. ага.  Вполне в духе современной zfs, конечно, тут ты прав. Кстати, а как там сделать замену диска? Не send/receive, это-то и бестолковая zfs могет, а просто был sda, стал sdb, а sda надо отдать прямщас. Не останавливая систему, потому что я хз как ее потом загрузить. Предположим даже, для простоты, что никаких зеркал и, б-же упаси, raid там нет (хотя для lvm это было бы совершенно неважно).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #172

152. Сообщение от псевдонимус (?), 09-Янв-21, 20:42	+1 +/–
Конечно виднее. К несчастью видел не на скриншоте кашицу, в которые БТР превратил данные. Но да, виновата была не только лишь фс. Админ-линуксоид по скудоумию пытался с упорством,  достойным лучшего применения восстановить данные средствами этой калечной фс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #166

153. Сообщение от псевдонимус (?), 09-Янв-21, 20:47	+/–
>> Любой файловой системе нужна ECC для надёжной работы. Просто другие об этом >> не пишут. > А какой смысл им об этом писать? EXT4 без полного журнала вообще > плевать хотел что там с данными случится при крахе. А раз > так какой смысл париться ECC памятью? :) Что ты несёшь? Ецц нужна чтобы мусор вместо данных не записывался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #182

154. Сообщение от Аноним (154), 09-Янв-21, 20:50	–1 +/–
> это чтоб вместо 64x write amplify получить 256? Не, не умеет. А вот это уже мне решать что я хочу. И если что, чисто статистически протирание системного SSD под btrfs - примерно однохренственно с EXT4. Чтобы x64 получить надо быть похом, стреляя в пятки с прецизионностью эксперта. > тоже нет (как и ext4) - обычно такую простую проблему можно обойти, > даже если предыдущие уровни защиты (а они есть) не сработали. Какие уровни защиты от бэда, лол? Диск просто не смог прочитать тот сектор. Это нарушает допущения и ZFS и EXT4. Далее - undefined. > не прочитает. Это случай, когда остальное надо аккуратно копировать, если оно хоть > малейшую ценность представляло, а диск - выкидывать, а не волшебные fs изобретать. На винчах, особенно емких, изредка может проскакивать 1-2 бэда без последствий. Оно не развивается, даже не факт что ремапнется, может прекрасно прочитатся при очередной записи, тогда статистика ремапов останется девственной. На тупых ФС ты это можешь и не заметить даже. Особенно в винде где она сотни ошибок в логи валит и никто их не читает, плюс-минус парочку никто не заметит. > отдельный вопрос - как fsck помогает ext4 при нечитающихся метаданных. А вот так - делает проход, проверяет корректность, пытается более-менее нейтрализовать или перестроить некорректное. Что-то потеряется, но хотя-бы стораж смонтируем и какую-то часть можно будет как человеку вынуть, через драйвер ФС. Хексредактором файлы доставать не прикольно, я пробовал. > она вполне хорошо работает в этих случаях - значительно лучше недоделка btrfs 1) В каких именно случаях? 2) Чем именно лучше? 3) Чем это вызвано? 4) Какие из этого бенефиты пользвателю? > (кстати, опачки при штатной перезагрузке, надысь. Ну не то чтобы не > для того и брали...) Чего? Нельзя ли развить эту мысль? > ты только что гнал какую-то чушь про ноутбук - у тебя в > нем петабайтные масштабы? Пойди проспись, праздники уже кончились, > в понедельник на галеру. Нет, там не петабайтные масштабы - однако нет ни одной причины по которой лаптоп не достоин менеджмента на манер виртуалок, с снапшотами и всем таким. > Нет, это совсем нерабочее. Я больше доверяю thin lvm с xfs - Он как-то в вопросах менеджмента - ну воообще не XFS. И еще шляпа очень весело придумала - сделать новые метаданные, не совместимые с старыми, назвать старые deprecated, конверсию их пихтонраст макаки видимо не сумели, это вам не btrfs, так что ипитесь с ващим XFS как хотите, дескать. Хочу посмотерть как обладатели петабайтов будут конвертить "старый" формат в новый. > оно глючит и перезагружается от неведомых причин, но последнее время - > вроде, каждый раз перезагружается, а не опачки-чавойтаянемагу. Кто перезагружается? Почему перезагружается? > Но, надо признать, когда навернется, destroy/create там дольше. В случае btrfs вроде вообще после краха монтирование столько же сколько и обычно, fsck не надо, он просто выкинет свежие изменения которые не прокатили а фс в целом корректной остается. И хрен тебя знает что ты там с петабайтами делаешь, гигантоманию прокачиваешь? А то почему-то баги на 20Тб файлах только фэйсбук и поймал. У остальных, видимо, такого тупо нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #238

155. Сообщение от пох. (?), 09-Янв-21, 20:52	+2 +/–
>> И без некоторых сохранностей данных. > Естественно, бсдшнику виднее что у нас там в этих наших линуксах с > сохранностью данных. А, оно из-за этого навернулось? Как учуяло-то за двадцать километров...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #168

156. Сообщение от псевдонимус (?), 09-Янв-21, 20:53	+/–
> инструмент не по руке Согласен. Руки у меня не под хрен заточены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #163

157. Сообщение от Аноним (154), 09-Янв-21, 20:55	+/–
> Продакшон на лимоны IOPS. Резко всё стало идеально с ZoL 0.8.3/Ubuntu_20.04. Всё > что раньше - теряло read-range locks, стопорило процессы в D-State. Пох, залогинься, у тебя ус отклеился :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #275

158. Сообщение от Аноним (154), 09-Янв-21, 20:56	+/–
> Я до сих пор в восторге от того, что ZoL - _единственная_, > сцуко, из общедоступных линуксных fs, требующая перезагрузки или export чтобы > подцепить увеличившееся место на том же диске. Хренасе, инновации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #210

159. Сообщение от псевдонимус (?), 09-Янв-21, 20:57	+/–
У синолоджи с нетапом в штате целый полк псевдонимусов и рота похов. А у псевдонимуса всего один псевдонимус :-(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #165

160. Сообщение от Онаним (?), 09-Янв-21, 21:01	+/–
Нет. ZFS делает аллокации сам, и отдаёт когда сочтёт нужным, не сообщая ядру, что и как может отдать. А страницы буферов/кеша дропаются/отписываются ядром и отдаются при запросе на аллокацию. В этом и вся разница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #161, #187, #211

161. Сообщение от Онаним (?), 09-Янв-21, 21:02	+/–
ALL AVAILABLE MEMORY поэтому и возможно, что оно не препятствует собственно аллокациям. Системный кеш может хоть на всю память распухнуть - но если в ней будет потребность, ядро его освобождает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

162. Сообщение от Аноним (162), 09-Янв-21, 21:08	+/–
> только неэффективно - поскольку кэш этот не ее, а дядин. А дядя > ничего не знает о том, что можно отдавать, а что попридержать. Намного прикольнее если ФС не тормозит, зато программа огребла out of memory и вообще навернулась, потому что отнять память под ее запрос здесь и сейчас сдув дисковый кэш ядро не смогло. А это точно фича на системах которые не файлопомойки? > Баг 12309 - он именно оттуда, на вымывании кэша. Он не оттуда, он из-за thrashing с отбрасыванием страниц из файлов а потом метаниями по всему диску с бинарями чтобы подчитать все это взад, потому что программы, падлы, работают и страницы потребовались взад. Своп тасующий данные усугубляет картину. Дисковый кэш тут довольно сбоку, ты же не предлагаешь кэшировать, ..., своп, всамделе?! > Было, у нее тоже была ffs с afair уже даже buffer cache > в последних версиях. Как не с кем? Память для программ откуда по твоему взяться должна? Откуда может память взяться вариантов много. А может и ниоткуда. Вернуть гаду NULL, и пусть что хочет то и делает. > Просто ее инженеры проектировали, и как один общий проект, а не как > лебедьщукураком и "мы вам запретим пользоваться avx-фичами процессора чтоб у вас > все плохо работало, патамушта могем". Им очень популярно объяснили что удобно и хорошо - тем кто помогает друг другу, а не тем кто думает что паразитировать на чужом труде ничего не отдавая взамен - валидная идея. > Взяли и запилили апи специально для избегания global lock и быстрого отъема > лишнего - просто потому что он коллегам был нужен именно такой. И получили в результате нечто пригодное только для файлопомоек, по большому счету. Там это похрен, а вот в остальных случаях программы очень нервно реагируют на NULL при аллокации памяти. Половина вообще не реагирует - прет как танк, полагая что память закончится не может. Потом оно конечно где-то упадет, но ты даже с поллитрой не угадаешь почему. > Кстати, эта память жрется как не в себя, и ее нигде не видно). Прикольно, чо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #180

163. Сообщение от Аноним (162), 09-Янв-21, 21:09	–1 +/–
> Согласен. Руки у меня не под хрен заточены. Ну так тогда и твое мнение в др^W пингвинах учитывать ни к чему. А на что они заточены? Минет корпорации Майкрософт? Или ты таки свои бзды как десктопы и лаптопы осилил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #167

164. Сообщение от Аноним (162), 09-Янв-21, 21:10	+/–
> Т.е. моя проблема будет состоять в отсутствии проблем? Принято. Про это все метко говорится - дай дураку стеклянный х... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #169

165. Сообщение от Аноним (162), 09-Янв-21, 21:11	+/–
> У синолоджи с нетапом в штате целый полк псевдонимусов и рота похов. > А у псевдонимуса всего один псевдонимус :-( Да какой у синоложи полк? Хотя справедливости ради они даже что-то комитили в btrfs, но на полк было не похоже. Так, 1-2 мелких дева для дежурных фиксов, они даже не core devs технологии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

166. Сообщение от Аноним (-), 09-Янв-21, 21:16	–3 +/–
> Конечно виднее. Верю-верю, всякому зверю. Почему-то больше всего проблем - у лиц с бсдшным бэкграундом. В чем же дело? Как же так? :) > К несчастью видел не на скриншоте кашицу, в которые БТР превратил данные. > Но да, виновата была не только лишь фс. Админ-линуксоид по скудоумию > пытался с упорством,  достойным лучшего применения восстановить данные средствами этой > калечной фс. А может вы там по скудоумию просто буфернули диск виртуалки для лучшего перфоманса, послав допущения файлух и прочие ненужности типа смеантики к лешему? Ну оно при крахе и продолбало вагон всего из буфера хоста. Для бсдшников с линухом я скорее в что-то такое поверю, unless declared otherwise. С вашим уровнем знания технологий подобные версии как-то лучше объясняют наблюдаемое. А восстановить чего, там офлайн ридер есть, даже работает, если не идиотничать. Но при этом надо все же соображать что и нафига делаешь немного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #170

167. Сообщение от псевдонимус (?), 09-Янв-21, 21:16	–1 +/–
Уж по пинетки мелкософту линуксоиды впереди планеты всей. Даже на всл насоса..подарил имиплатпновцй спонсор! А чего там на десктопа осиливать? Программы так же как на Лине работают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #194

168. Сообщение от Аноним (-), 09-Янв-21, 21:17	–2 +/–
> А, оно из-за этого навернулось? Как учуяло-то за двадцать километров... Как, как, вы так мастерски мины себе на пути раскладываете и подрываетесь на них - что за 20 километров бабах слышно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

169. Сообщение от псевдонимус (?), 09-Янв-21, 21:19	+1 +/–
"дай линуксоиду докер и бтрфс" ты хотел сказать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #195

170. Сообщение от анонн. (?), 09-Янв-21, 21:43	+3 +/–
> А может вы там по скудоумию просто буфернули диск виртуалки для лучшего > перфоманса, послав допущения файлух и прочие ненужности типа смеантики к лешему? > Ну оно при крахе и продолбало вагон всего из буфера хоста. > Для бсдшников с линухом я скорее в что-то такое поверю, unless > declared otherwise. С вашим уровнем знания технологий подобные версии как-то лучше объясняют наблюдаемое. Вы там поаккуратней с разоблачениями, а то недавно выяснилось, что "ваши" (которые с лапками перепончатыми) не "может", а точно сделали: https://m.opennet.ru/openforum/vsluhforumID3/122280.html#26 Хорошо хоть детали слили - разобраться можно было, а то ведь столько ору в фряшных темах до этого было: "фряшная файловая система херится на ровном месте после выключения!", "Почуму-то только правильная бздешичка ломается" и проч в том же духе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #171, #173, #179

171. Сообщение от анонн. (?), 09-Янв-21, 21:53	+1 +/–
> Вы там поаккуратней с разоблачениями, а то недавно выяснилось, что "ваши" (которые > с лапками перепончатыми) не "может", а точно сделали Причем, это не какой-то там очередной диванный форумчанин, а разработчик коммерческого пингвинячьего дистра ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #174

172. Сообщение от Аноним (172), 09-Янв-21, 22:27	+/–
> вот, к примеру, без объявления войны не смонтировался надысь. ага.  Вполне > в духе современной zfs, конечно, тут ты прав. А error message какой? И какие версии кернела и проч? Ну и чего с ним сделали для такого? > Кстати, а как там сделать замену диска? btrfs replace ... Альтернативный вариант: device add -> device remove. Второй вариант умеет крайне неортодоксальныее трансформации, btw. Как тебе перенос системы? device add -> RAID 1 -> single -> device remove. Можно -> DUP вместо single как вариант. Это странный способ перенести систему на другой винч, но работает и быстро, переноятся только используемые области. А, grub еще установить. ФС остается той же самой с точностью до UUID, а винч под ОС заменяется без остановки системы. Сможешь нонстоп замену системного диска с твоими технологиями? И если да, то как? Block-level для этого плохо подходит: non stop означает работающую ОС которая может писать, меняя блоки. > Не send/receive, это-то и бестолковая zfs могет, а просто был sda, стал sdb, а sda надо > отдать прямщас. А в чем проблема сделать btrfs device remove? Удвинет данные с него - и забирай! При том удвинет только то что фактически аллоцировано, а backrefs делают это быстрым. Так что эта операция умеет заканчиваться быстрее ожидаемого. Даже больше! Было у тебя 5 дисков, RAID1, половина места не юзалось, но по дискам раскидалось. Сказал device remove, удвинул данные, вынул диск, единственное отличие - на ФС стало немного меньше места. А 4 там диска или 5 и какого размера - решительно похрен. А ZFS уже научили пулы уменьшать, девайсы изымать и все такое? Уровень RAID выбирается раз и навсегда? > Не останавливая систему, потому что я хз как ее потом загрузить. Я систему на новый диск перебросил без остановки... > Предположим даже, для простоты, что никаких зеркал и, б-же упаси, raid там > нет (хотя для lvm это было бы совершенно неважно). RAID в btrfs полностью прозрачен для этих процедур. Btrfs похрен, он видит block group, и moving его away с изымаемого диска. По backref смотрит чье это и двигает на любой другой диск с свободным местом подходящий под требования схемы хранения этого block group (он еще и разный может быть, даже смесь таковых, уровни избыточности data и metadata могут отличаться опять же). Т.е. RAID1(metadata) совершенно не означает RAID1(data). Может быть и RAID0, если данные относительно похрен но развал ФС наповал по метаданным все же неохота.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #178

173. Сообщение от Аноним (-), 09-Янв-21, 22:44	–2 +/–
> Вы там поаккуратней с разоблачениями, Это не разоблачения а всего лишь здоровый дефолтный скепсис на основе смотряния на уровень владения технологиями и понимания как все это работает. > ору в фряшных темах до этого было: "фряшная файловая система херится > на ровном месте после выключения!", "Почуму-то только правильная бздешичка ломается" и > проч в том же духе. Ну там первый же комент на проблему просто эпик, в характерном стиле бсд-про, > qemu+KVM на Linux Проблема здесь. Алсо: Запускают системы дендрофекальным образом, а потом плачутся в инторнетах, ... Сразу видно уровни владения технологиями и общий как бы и не-луддизм, ога. Одно вот это уже отличная причина не иметь дел с бсдшным сообществом. Напыщеная ламота имеющая мнение основанное на их измышлизмах - визитная карточка современной бсдшной экосистемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #177

174. Сообщение от Аноним (-), 09-Янв-21, 22:46	+/–
> Причем, это не какой-то там очередной диванный форумчанин, а разработчик коммерческого > пингвинячьего дистра ;) А чего за дистр? Впрочем, разработчику линукса и не обязательно быть профи в фрибзде. А вот ответы фрибсдшного сообщества как на подбор. Странно что ему еще не рассказали что он лох и виртуализация - нинужно, поставьте лучше на сервак под кроватью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #175

175. Сообщение от анонн (ok), 09-Янв-21, 23:02	+1 +/–
>> Причем, это не какой-то там очередной диванный форумчанин, а разработчик коммерческого >> пингвинячьего дистра ;) > А чего за дистр? Rosa Linux > Впрочем, разработчику линукса и не обязательно быть профи в фрибзде. И знать, чем чреват запуск kvm+qemu с cache=writeback для гостя, тоже похоже не обязательно и даже после разжевывания детально ему дозволяется писать "что доказать-то пытаетесь? Что qemu виноват? А если реальную железяку из розетки выдернуть". Ведь он линуксоид, а "это другое, понимать надо!"(с) Казалось бы, причем тут "быть профи в фрибзде". > А вот ответы фрибсдшного сообщества как на подбор. Странно что ему еще не рассказали что он лох и виртуализация - нинужно, поставьте лучше на сервак под кроватью. Эталонный пример избирательного чтения с додумыванием - прямо хоть в палату мер и весов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #197

176. Сообщение от xm (ok), 09-Янв-21, 23:22	+1 +/–
> Я до сих пор в восторге от того, что ZoL - _единственная_, сцуко, из общедоступных линуксных fs, требующая перезагрузки или export чтобы подцепить увеличившееся место на том же диске Чё-то я не припоминаю наличия такой потребности во FreeBSD...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #240

177. Сообщение от анонн (ok), 09-Янв-21, 23:26	+3 +/–
> Ну там первый же комент на проблему просто эпик, в характерном стиле бсд-про, > >> qemu+KVM на Linux > Проблема здесь. > > Алсо: > > Запускают системы дендрофекальным образом, а потом плачутся в инторнетах, ... > > Сразу видно уровни владения технологиями и общий как бы и не-луддизм, ога. Похоже, делать на основе кратких (и удивительно точно, хоть и невежливо, описывающих суть проблемы) комментариев выводы о владении технологиями и попутно, отношении к научно-техническому прогрессу, при этом "изящно" игнорируя все остальные комментарии - не менее эпичный, характерный опеннет-линукс-про стайл. Получается, запускать виртуалку с (умолчательным, лет 8 как) cache=writeback, By default, the cache.writeback=on mode is used. It will report            data writes as completed as soon as the data is present in the host            page cache.  This is safe as long as your guest OS makes sure to            correctly flush disk caches where needed. If your guest OS does not            handle volatile disk write caches correctly and your host crashes            or loses power, then the guest may experience data corruption. расчитанным на "специально пропатченного" гостя (читай: пинвгинчика, там в этом режиме пробрасывают пингвинячий fdatasync, если дока шапки-суси не врала. RedHat этот режим очень "не рекомендовал" это для гостя RHEL 5.5 и меньше), искренне удивляясь сопутствующему "оно при крахе и продолбало вагон всего из буфера хоста" - это на самом деле не запуск "дендрофекальным образом" и "высокий уровень владения технологиями"? Вот оно как! > Одно вот это уже отличная причина не иметь дел с бсдшным > сообществом. Напыщеная ламота имеющая мнение основанное на их измышлизмах - визитная карточка современной бсдшной экосистемы. Отличная демонстрация напыщенной "солидарности" вашего "линукс-про" сообщества, благодарю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #198

178. Сообщение от пох. (?), 10-Янв-21, 00:16	+1 +/–
> А error message какой? дык, никакого. Есть типовые мусорные сообщения, которые при нормальном монтировании в лог зачем-то валятся (хз что означают, и зачем у них дурная привычка логать мусор). Монтирования - нет. > Ну и чего с ним сделали для такого? shutdown -r К сожалению, времени разбираться не было, там не терабайты и вообще большая часть была бэкапом самой себя, поэтому плюнул и пересоздал. Но, надо отметить, с zfs у меня бывало всякое, но ВСЕГДА оно об этом внятно писало прямо в консоль. lvm писала невнятно, но хотя бы тоже пыталась разговаривать. А тут молча опаньки. > А в чем проблема сделать btrfs device remove? а он один. То есть меня интересовал аналог pvmove (не то чтобы эта тварь была безопасной). > А ZFS уже научили пулы уменьшать, девайсы изымать и все такое? Уровень RAID выбирается раз и > навсегда? слава Аллаху, навсегда. Я вообще не представляю, что там должно быть такое на том пуле, чтобы я рискнул на подобную процедуру и при этом оно имело смысл вообще (в смысле не проще снести и заново создать как надо). То есть vdev теперь в некоторых случаях таки можно удалить и убрать с него данные, и обещали что прямо вот скоро это будут любые случаи, когда есть еще один, но все это для тех кому данные, по-моему, вообще не нужны. А тогда - чего ж страдать? А что, btrfs'ным рэйдом (а не зеркалом) уже в принципе пользоваться можно стало? Расскажи это synology, а то ребята не в курсах и мучаются. А то с зеркальными конфигурациями и у zfs проблем почти нет (только ну его нафиг). > RAID в btrfs полностью прозрачен для этих процедур. если бы еще и работал...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #185, #201

179. Сообщение от пох. (?), 10-Янв-21, 00:21	+/–
> Вы там поаккуратней с разоблачениями, а то недавно выяснилось, что "ваши" (которые > с лапками перепончатыми) не "может", а точно сделали: > https://m.opennet.ru/openforum/vsluhforumID3/122280.html#26 ой, прелесть какая. Не, с другой стороны - извращенцы и должны же ж страдать. При запуске линуксов в bsd'шных виртуалках, знаете ли, ничего само собой почему-то не ломается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #199

180. Сообщение от пох. (?), 10-Янв-21, 00:34	+/–
> Намного прикольнее если ФС не тормозит, зато программа огребла out of memory Ну вот до нашествия openzfs еще были шансы это починить. >> Баг 12309 - он именно оттуда, на вымывании кэша. > Он не оттуда, он из-за thrashing с отбрасыванием страниц из файлов а у меня он был именно оттуда - свопа при этом по факту не было. (понятно, discard активных процессов это тоже такой своп, только всем хуже - а с чего оно, по-твоему, подискардилось и кому память-то понадобилась, причем совершенно бестолку?) >> Взяли и запилили апи специально для избегания global lock и быстрого отъема >> лишнего - просто потому что он коллегам был нужен именно такой. > И получили в результате нечто пригодное только для файлопомоек, по большому счету. в каком месте sun'ы у тебя работали файлопомойками? Причем у них, в результате, в отличие от всех остальных, не возникал deadlock в случае, когда для освобождения памяти надо бы сперва потратить память, и они могли себе позволить держать swap в zfs. >> Кстати, эта память жрется как не в себя, и ее нигде не видно). > Прикольно, чо. ЛинOOPSь, сэр... Они ТАК управляют большими блоками памяти. Опять же до поры, до времени, это вредительство можно было слегка поубавить, а теперь уже вряд ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

181. Сообщение от Аноним (181), 10-Янв-21, 03:36	+/–
> для них (в отличие, кстати, от ext4) существовали еще некоторые средства ручного > восстановления, если что. А в btrfs такое средство просто в штатную утилсу btrfs встроено. "Оффлайн" читалка без монтирования, позволяющая выбрать точки с которых начать парсинг, благо в cow их более 1. > Ну и было, из чего восстанавливать, а не "uninit bg" и экстенты, > которых никто не понимает и чинить не умеет. См. выше. > С другой стороны - диски сильно подешевели, теперь уже в общем и > незачем восстанавливать. Да вот почему-то народ бэкапается только после того как все профакает а не до.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #239

182. Сообщение от Аноним (181), 10-Янв-21, 03:43	+/–
> Что ты несёшь? Ецц нужна чтобы мусор вместо данных не записывался. Если ФС может данные профакать без ложной скромности, поскольку EXT4 видите ли не парится о довольно большом количестве проблем ведущих к порче данных - смысл платить за ECC достаточно маргинальный. Это заткнет один путь разрушения данных а еще куча останется. Ну например EXT4 с полным журналом тормозной как слоупок. А без него - вырубленая на середине запись оставит полуперезаписаный файл, который ни вперед, ни назад. И чего потом с ним делать? Или если был супер-дупер RAID но диск вместо того чтобы скопытиться совсем бэды изволил выдать с мусором - как определить которая копия вообще правильная? Теоретически, конечно, гад должен IO error (UNC) наверх пульнуть, но практически это зависит от приколов его фирмвари и бывает весьма по разному. От ухода в себя на неопределенное время до тихой отгрузки наверх какой-то трухи, возможно лобового результата чтения как есть, с пофигом что FEC не сжевал столько и это труха.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #207, #228

183. Сообщение от Аноним (-), 10-Янв-21, 03:49	+/–
> Ну да, с тем же успехом можно сказать что all available memory > is arc в случае zfs. Тут ключевой вопрос - а может ли кернел это быстро забрать взад когда сие потребуется программам? А то иначе может получиться довольно дурацки - в системе вагон свободной памяти, его заняли под буферизацию, а тут кто-то из прог попросил память которой якобы дофига. А ей в ответ - а вот тебе?! Что за бред? Не говоря о том что нынче прогеры размякли и к mem alloc failure часто не готовы морально, так что дальше идет фееричнейший UB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #186

184. Сообщение от maximnik0 (?), 10-Янв-21, 04:50	+3 +/–
>А чексуммы намекнут о проблемах с железом, если повезет то до того как это превратится в большую проблему. Позавчера наткнулся опять на проблему с BTRFS.Старый жесткий,валялся лет эдак 5 ,бтрфс -бэкап информация.Обнаружил что раздел только чтение-ругаеться при монтирование на чек суммы и проблемы с fs .Ну ладно скопировал информацию,попытался чинить -фиг вам,как не ремонтируется эта fs ,так и продолжает нуждаться в "шамане".Btrfs check restore,удалил чек суммы-не фига,доходит до 70% веритификация и падает в корку программа починки,до этого на куча блоков ругаеться.(btrfsck -не потдерживаеться,в большенстве дистрибутивов ссылка на btrfs check ) Ладно еще есть один бэкап за архивированный на другом жестком-есть к файлам md5 контролька-проверил контрольные суммы,все ок.Снес тогда я раздел ,проверил жесткий на бадблоки,посмотрел смарт-не хрена нечего нет.Ну и какого хрена тогда на чексуммы и блоки фс ругаеться ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #224, #255

185. Сообщение от псевдонимус (?), 10-Янв-21, 06:33	+/–
Райд5 в БТР работает отлично. Данные полностью потеряны. Но хоть холодный бэкап был у админа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #202

186. Сообщение от пох. (?), 10-Янв-21, 10:37	+/–
> Тут ключевой вопрос - а может ли кернел это быстро забрать взад когда сие потребуется программам? Быстро - не может, чудес не бывает. Вот тебе старый линукс, с еще человекочитаемым free:              total       used       free     shared    buffers     cached Mem:       3085136    2863632     221504          0     415804    1005072 -/+ buffers/cache:    1442756    1642380 Swap:      4194300      52244    4142056 Чего бы он в swap залез, когда оно "free"? И зачем-то держит зазор, пусть и 5%, хотя весь тот своп бы поместился и еще осталось. Причина вполне банальная - быстро отдать это cached не получится. Чтобы оттуда отдать - надо перебрать табличку структурок, состоящую, на минутку, у нас 4k pages, из 251268 (блжад!) айтимов - желательно не первые попавшиеся оттуда выбрасывать, а хотя бы те к которым долго не было обращений (лучшее, что умеет линукс). Кстати, для этого потребуется память, нужна ж нам табличка кандидатов из той таблички на вынос ;-) Добавь сюда что системы у нас дохреллион-процессорные и все это через локи. Поэтому, если ты полезешь рыться в исходниках - почти наверняка найдешь ровно то же самое, что и в исходниках zfs - асинхронный механизм, возможно и не один, пытающийся предугадать, сколько памяти может потребоваться в ближайшее время - на основании того, сколько ее уже попросили недавно. И вот эти механизмы - они сложные, не всегда быстрые и завязаны на кучу внутренних систем ядра. Неаккуратное вмешательство в них ведет к 12309 в лучшем случае (в худшем - к lockup, когда негде взять память, чтобы поискать свободную память, потому что мы уже ищем свободную память и память для этого кончилась). Кстати, никто не обещал тебе, что это единственное место в системе, где есть динамически расходуемая память, и что ее вообще надо сейчас трогать (представь систему с основными дисками на nfs, или, того хуже, ceph). К сожалению, в линуксе нет никакого общедоступного способа ее посмотреть, и даже понять, относится ли она к "buffers" или показывается просто как занятая ядром. > Не говоря о том что нынче прогеры размякли и к mem alloc failure часто не готовы морально они часто еще более неготовы к подождать, пока освободится (ты в линку в бравзере ткнул - и у тебя повисло все вообще - потому что понадобилась память отобразить инвалидо-френдли индикатор бурной деятельности, и система пошла поискать - пупсики ж не поймут такого)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #190, #191

187. Сообщение от пох. (?), 10-Янв-21, 23:08	+/–
Б-ть, ничего что zfs и есть ядро, его часть? > А страницы буферов/кеша дропаются/отписываются ядром мистическим таким ядром в сферическом вакууме, конечно же. Волшебным прямо. А как функцию из чуждой лицензии вызовет - сразу все волшебство пропадает. А не где попало натыканным как попало кодом. Причем mpu-safe, и при этом старающимся избегать global lock где только можно - поэтому зохавать обычно в десять раз быстрее и проще, чем что-то отдать. > В этом и вся разница. В этом разница в пользу zfs, где этот код весьма внятно локализован и человекопонимаем за конечное время (не считая пингвинятины, в которой понятно что ее надо было выбросить сразу же, не изучая, но это ж был кого надо комит). В смысле - у нее отобрать проще, там кода было - пару страничек (правда, и еще было, куда копать, но некому). Отобрать у сетевухи, где в этот же самый момент лежат никак не используемые гигабайты - существенно более интересное и менее практичное занятие, потому что каждый драйвер сам по себе. А у драйвера любой другой fs ты вообще ничего не отберешь (а там есть metadata и тоже иногда  кэшируется отдельно - ведь буферному кэшу все равно, он ее дропнет на равных правах с уже ненужными данными). Но оно тебе показывается как used, без деталей, кем, поэтому ты спишь спокойно. А у поганой freebsd нет команды free, нишва6одные оне. А vmstat всех палит, и никакого спокойного сна :-(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #189

189. Сообщение от Онаним (?), 10-Янв-21, 23:39	+/–
В ZFS свой собственный кеш, который оторван от системного совершенно. Что в бзде, что в ZoL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #193

190. Сообщение от Онаним (?), 10-Янв-21, 23:40	+/–
В swap он залез, потому что алгоритмы такие. Ставь vm.swappiness = 1 , будет меньше залезать. Но не в ноль. Плюс мог залезть когда был реальный оверкоммит, а освобождать не торопится - пока обращений не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #192, #196

191. Сообщение от Аноним (191), 10-Янв-21, 23:40	+/–
> отдать - надо перебрать табличку структурок, состоящую, на минутку, у нас > 4k pages, из 251268 (блжад!) айтимов - желательно не первые попавшиеся > оттуда выбрасывать, а хотя бы те к которым долго не было > обращений (лучшее, что умеет линукс). Head seek винча занимает больше. Так что девы купили ссд. А проблемы начинаются тогда, когда какая-то часть системных дел оказывается залоченой на такие скорости железа. Туда же и флешки с скоростью мег в секунду. 256 pps, можешь посчитать сколько времени оно гиг будет отбирать. Сейчас доформатирую дискетку^W отберу память и покажу тебе интерактивность. > Кстати, для этого потребуется память, нужна ж нам табличка кандидатов из той > таблички на вынос ;-) А список кандидатов на вынос не держится постоянно? Или в чем смысл его постоянно аллоцировать, если он часто нужен? А те циферки не мировая константа и зависят от настроек swappiness и вокруг. Дистры могли за это время дефолты поменять, например. Решив что RAM прибавилось и теперь не обязательно хрустеть диском до тех пор пока реально не прижмет, например. > Добавь сюда что системы у нас дохреллион-процессорные и все это через локи. Локам давно дали бой, твое 2.6.чтототам для которого это релевантно и 5.10 скорее всего 2 большие разницы. В btrfs на эту тему патчи активно прут, они там локи перетряхнули, роботы репортят приколы с стрельбой палок раз в год, естественно в RC и до юзеров не долетит. > Поэтому, если ты полезешь рыться в исходниках - почти наверняка найдешь ровно > то же самое, что и в исходниках zfs - асинхронный механизм, > возможно и не один, пытающийся предугадать, сколько памяти может потребоваться в > ближайшее время - на основании того, сколько ее уже попросили недавно. Может и найду. Но mm/ нынче довольно большой и сложный, копаться в нем должна быть хорошая причина. Кстати, если ты думал что знания о всем этом мировая константа, как тебе c843966c556d7370bb32e7319a6d164cb8c70ae2 допустим? Да, ему меньше года, так что в 2.6.чотам оно не так. > И вот эти механизмы - они сложные, не всегда быстрые и завязаны > на кучу внутренних систем ядра. Они сложные. А что до не всегда быстрые, большие головы все же воротят core techs дабы "не всегда быстрые" случалось поменьше, им за это денег даже платят. При том железо тоже эволюционирует, пример чему и даден выше (изначально найдено как git log mm/vmscan.c вокруг других любопытных изменений). > Неаккуратное вмешательство в них ведет к 12309 в лучшем случае (в худшем - к lockup, > когда негде взять память, чтобы поискать свободную память, потому что мы уже ищем > свободную память и память для этого кончилась). Я делаю с Linux много странного г-на в разных конфигах. Но именно это я видел только в 1 случае: в роутерах где контрек настраивают неверно, так что он сжирает RAM, а когда она кончается под тяжелым флудом, отобрать неоткуда т.к. контрек тоже ядро, трололо. Но это вообще ошибка конфигурации. Систембилдер лох. > К сожалению, в линуксе нет никакого общедоступного способа ее посмотреть, и > даже понять, относится ли она к "buffers" или показывается просто как > занятая ядром. Кто бы сомневался что в большой и сложной системе найдется причуд, особенно если конфиг чудесатый взять. И да, тут такой оборот что я даже и не знаю куда корректнее такие аллокации было бы отнести. То-есть, буфер для внутренних нужд ФС можно обозвать и так и сяк в принципе и это технически корректно. > они часто еще более неготовы к подождать, пока освободится Их вообще никто не спрашивает. И таки спорный вопрос что хуже: подвисшая на эн прога или прога которая толи сразу вылетит совсем, толи поработает 5 минут и сдохнет в диких глюках, да таких что ты в жизни не отдебажишь - откуда ж ты знал что там память не выделилась просто? Ты ж не трейсил все аллокации от сотворения мира небось? > (ты в линку в бравзере ткнул - и у тебя повисло все вообще - При 12309 таки повиснет сперва браузер. А остальное - только если ты будешь дергаться как муха в паутине провоцируя новые аллокации другими прогами. Один програмер как-то сказал: если система тупит, хучшее что можно сделать это начать дергаться. Это все только усугубит. Это, кстати, вообще видовый програмер, но идея достаточно универсальна. > потому что понадобилась память отобразить инвалидо-френдли индикатор бурной деятельности, > и система пошла поискать - пупсики ж не поймут такого) У лично меня в моих конфигах это все вообще проблемой не является. Но я все же умею пингвинов готовить и разбираться с поведением которое мне не симпатично. И вместо воплей как все плохо у меня обычно находится твик настроек, а то и радикальный пересмотр подходов. У меня нет свопа, кроме zram. И для него более релевантно то что написано в c843966c556d7370bb32e7319a6d164cb8c70ae2 - но боже упаси это механическому винчу вкрутить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

192. Сообщение от Онаним (?), 10-Янв-21, 23:41	+/–
(освобождать - в смысле назад в RAM затягивать, освободить-то в любой момент может, если аппликуха отдаст)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

193. Сообщение от пох. (?), 10-Янв-21, 23:46	+/–
БТЬ.... НЕТ никакого волшебного "системного". Кэш zfs - он настолько же "системный", как и любой другой. Отдельный вопрос, что линyпси с их странностями пытаются кэшировать внутри драйвера блочного устройства, и, похоже, даже O_DIRECT не помогает от этого избавиться. Но это их проблемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #215

194. Сообщение от Аноним (-), 10-Янв-21, 23:56	–1 +/–
> Даже на всл насоса..подарил имиплатпновцй спонсор! Платиновый спонсор имхо сссыт что девелоперс, девелоперс, драп-драп, потому что как дев воркстэйшн этот крап ни о чем, а реклама и кейлогеры с онлайн аккаунтами - девы все же не совсем хомяки, сорян. > А чего там на десктопа осиливать? Программы так же как на Лине работают. Ага, только компил в линухе раза в 2 быстрее, б-дских кейлогеров и рекламы нет, уйма полезных мне технологий. Нахрен мне платный обкоцный крап с бэкдорами, если я могу бесплатно оригинал заюзать? К тому же он работает на в 10 раз большем количестве железок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #200, #203

195. Сообщение от Аноним (-), 10-Янв-21, 23:59	+/–
> "дай линуксоиду докер и бтрфс" ты хотел сказать. Я уже давно заметил что если результат достигнут без фигурной гребли в привязанной лодке на два дня, бсдшники оказываются очень недовольны и вопят как все плохо. Собственно, именно поэтому их отовсюду и послали к чертовой бабушке. Никому ваша камасутра кроме вас не интересна, интересны работающие системы и результат их работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #208

196. Сообщение от пох. (?), 11-Янв-21, 00:02	+/–
> В swap он залез, потому что алгоритмы такие. вопрос не в этом, а почему у нас при этом _пропадает_ даром память, хотя она свободная. Правильный ответ - что если ее занять, то новой будет взять негде - в том числе даже на процесс освобождения памяти. Поэтому, вопреки легендам, он ни разу не бесплатный и в "волшебном" линуксе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #230

197. Сообщение от Аноним (197), 11-Янв-21, 00:13	–1 +/–
> Rosa Linux А, ну эти довольно чудесатые. С другой стороны... попробуй стать разработчиком коммерческой бзды, лол. Звучит почти как мишн импасибл, поэтому ты небось занимаешься какой-нибудь фигней в какой-нибудь маздайке, так что твои рассказы о прелестях бсдшных свобод или "истории успеха" стоят довольно дешево. > И знать, чем чреват запуск kvm+qemu с cache=writeback для гостя, тоже похоже > не обязательно и даже после разжевывания детально ему дозволяется писать "что > доказать-то пытаетесь? Что qemu виноват? Оно как бы да. И все же - в этом мире довольно много неидеальностей. Если другие с ними умудряются жить, а плохеет только кому-то одному - ну, наверное, это ему не в плюс. При всем согласии с мыслью что нарушение семантики доступа - не вина ФС как таковая. > А если реальную железяку из розетки выдернуть". Для меня это стандартный тест при оценке устойчивости ФС к внешним воздействиям. Зачем мне ФС которая скопытится и провалит задачу? > Эталонный пример избирательного чтения с додумыванием - прямо хоть в палату мер и весов. Куда ссыль, там и прочитал. А то что все это барахло целиком читать обломно - да, есть занятия и поинтереснее этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #218

198. Сообщение от Аноним (-), 11-Янв-21, 00:39	–3 +/–
> научно-техническому прогрессу, при этом "изящно" игнорируя все остальные комментарии > - не менее эпичный, характерный опеннет-линукс-про стайл. Хм, если нечто выглядит как глупый, агрессивный, неэффективный луддит - его очень хочется посчитать таковым. Разбираться в фибрах души людоеда желающих мало, сорь. > расчитанным на "специально пропатченного" гостя (читай: пинвгинчика, там в этом режиме > пробрасывают пингвинячий fdatasync, если дока шапки-суси не врала. То-есть, в пингвине была фича, а в бзде - как обычно. Ооок! > RedHat этот режим очень "не рекомендовал" это для гостя RHEL 5.5 и меньше), Спасибо что хоть не гайд по майнтенансу пушек 1812 года. > искренне удивляясь сопутствующему "оно при крахе и продолбало вагон всего из буфера > хоста" - это на самом деле не запуск "дендрофекальным образом" и "высокий уровень > владения технологиями"? Вот оно как! Это, кажется, называется "человек не подозревал что бзда настолько в технологической ж...е". Еще бы виртио потребовал, авангардист клятый! В линухе то как-то приняно нормально интегрировать ос с виртуализатором и за счет этого оно по скорости мало отличимо от железяки на которой работает - и таки при этом неплохая изоляция от хоста. > Отличная демонстрация напыщенной "солидарности" вашего "линукс-про" сообщества, благодарю. Не знаю про какую солидарность речь, но чисто по человечески, после такого велкама и такой демонстрации технологий лично я бы не стал ту штуку в следующие 5 лет трогать даже трехметровой палкой... не qemu-kvm, естественно ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #204

199. Сообщение от Аноним (-), 11-Янв-21, 00:42	–1 +/–
> запуске линуксов в bsd'шных виртуалках, знаете ли, ничего само собой почему-то > не ломается. Еще бы. Так никто не делает - оно и не ломается почему-то. Бзда как хост виртуализации? Пусть псевдонимус этот номер показывает, если здоровья хватает. И поха напарником в этот смертельный номер можно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #243

200. Сообщение от Аноним (-), 11-Янв-21, 00:48	+/–
>>> Или ты таки свои бзды как десктопы и лаптопы осилил? >> А чего там на десктопа осиливать? Программы так же как на Лине работают. > Ага, только компил в линухе раза в 2 быстрее, б-дских кейлогеров и > рекламы нет, уйма полезных мне технологий. Нахрен мне платный обкоцный крап > с бэкдорами, если я могу бесплатно оригинал заюзать? "Опеннетные предания о бздах", том 118
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

201. Сообщение от Аноним (-), 11-Янв-21, 01:45	–2 +/–
> дык, никакого. Прикалываться изволите? > Есть типовые мусорные сообщения, которые при нормальном монтировании в лог > зачем-то валятся (хз что означают, и зачем у них дурная привычка логать мусор). Дык, цитаты? Чего-нибудь типа failed to open ctree? Или тому подобное? А может просто логлевел никакой? > Монтирования - нет. Пока как-то мало данных для понимания чего там. Не знаешь почему у меня при вылезании проблем диагностических данных как-то больше обычно, эксперт? > отметить, с zfs у меня бывало всякое, но ВСЕГДА оно об > этом внятно писало прямо в консоль. Да собственно и btrfs пишет. Во всяком случае когда суперблок улетел в страну вечной охоты - диагностика была вполне понятной и достаточной для того чтобы вернуть его из копии. Но мало ли что там за чудо у экспертов случилось. Так то у них для дебага барабашек есть режим относительно приватного компактного дампа, когда в нем только метаданные, но ты небось и такой зассышь девам дать? Хотя идея в целом прикольная. > А тут молча опаньки. Вот это странно. А логлевел системные гениусы не догадались прибавить? Хотя это по любому должно быть как минимум error. >> А в чем проблема сделать btrfs device remove? > а он один. Так добавь второй, ремувни первый. Если ремотно надо - в чем проблемы send -> receive? А если локально - трансфер данных с диска на диск должен же случиться когда-то? (при device replace или device remove, ессно). Правда есть прикол, если дисков в ФС 2 и более, оно метаданные делает RAID1 по дефолту. Это хорошо и правильно, но если это именно data move с диска на диск, с планом вынуть второй, не в кассу. Но лечится ребалансом метаданных с фильтром уровня избыточности метаданных. Да, чтобы продвинутые фокусы гонять ман читануть все же придется, как и понять некоторые азы inner working. А у ZFS что, не так? :P > То есть меня интересовал аналог pvmove (не то чтобы > эта тварь была безопасной). Я ж описал что я систему на живую с винча на винч подвинул - на горячую цепанул 2-й - btrfs device add его, FS теперь временно 2-дисковая. - (зачем мне raid1 метаданных, rebalance тебе в block groups!) - btrfs device remove - GRUB install - отцепляем 1й. Система передвинута на другой диск. Онлайн. Без остановки. Вроде как раз как ты хотел, если не круче: другой системный диск без ребутов и отключки питания, с подцеплением нового и отключением старого нагорячую. Data move случится в момент btrfs device remove. Ни один открытый файловый дескриптор в процессе не пострадал. Система в этом процессе продолжает работать, диск подгружен io конечно. Его сильно меньше площади диска - move away случается только для фактически используемого места - это как раз плюс FS-aware аллокаций и рэйда. > слава Аллаху, навсегда. Ну его нафиг славу прибитого на гвозди... > Я вообще не представляю, что там должно быть такое > на том пуле, чтобы я рискнул на подобную процедуру и при этом оно имело смысл > вообще (в смысле не проще снести и заново создать как надо). В случае btrfs это миловая фоновая операция с конфигурируемым приоритетом, при крахе оно просто возобновляет с места облома, пока это идет прекрасно живет с смесью уровней (дизайн изначально такое предполагает) - и это онлайн ФС, доступная на R/W. В этом месте можно начать догадываться почему мне нравится это менеджить. Он удобный и фичастый. Корректность при этом ... изначально заложена в дизайн. Дизайн аллоцирует место "block groups", чушками, порядка 1..несколько гигов размерами. Юнит райда - они. Они же юнит ребаланса и прочих data move типа device remove. То-есть я добавил диск новый диск и изъял старый. Нюансом было объяснение btrfs'у что RAID1 для метаданных круто, но - забей, это у меня не планируется многодисковым. > То есть vdev теперь в некоторых случаях таки можно удалить и убрать > с него данные, и обещали что прямо вот скоро это будут любые случаи, У btrfs нет никаких vdev. Есть фс, есть свободное место. Ну, еще subvolumes есть, но это юнит администрирования, "супер-директория", технически - точка входа в иерархию некого, хм, снапшота. Writable или не очень. Снапшоты технически новые subvolumes, изначально на 100% реюзающие блоки исходной иерархии, но могут и разъехаться благодаря cow. А reflinks - когда блоки реюзнуты, но в снапшот не оформлялось. На самом деле довольно логично сделано, круто и гибко. > А что, btrfs'ным рэйдом (а не зеркалом) уже в принципе пользоваться можно > стало? Расскажи это synology, а то ребята не в курсах и мучаются. А чего они там мучаются? И да, RAID1 считается стабильным. И вполне юзабелен. У меня с ним проблем не было. А чего с ним у synology? > если бы еще и работал... Так работает вроде. Ну, RAID5/6 стабильными не заявлены, а в остальном - см. вику проекта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #217

202. Сообщение от Аноним (-), 11-Янв-21, 04:24	–1 +/–
> Райд5 в БТР работает отлично. Данные полностью потеряны. https://btrfs.wiki.kernel.org/index.php/Status - правильно, кто ж маны то читает? И эти люди что-то там про qemu и чтение манов :) > Но хоть холодный бэкап был у админа. А RTFM он делать все же не умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #205

203. Сообщение от псевдонимус (?), 11-Янв-21, 04:49	+/–
Когда это в бздю успели встроить кейлогер и рекламу? А вот дистрибутиве линукс--андроиде реклама и привязка к аккаунту есть. Винда же у меня мирно сидит в виртуалке и я не заплатил за нее ни копейки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

204. Сообщение от псевдонимус (?), 11-Янв-21, 04:57	+1 +/–
Это не фича, а кривой костыль. Очередной. Костылинукс он такой, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

205. Сообщение от псевдонимус (?), 11-Янв-21, 05:10	+/–
>> Райд5 в БТР работает отлично. Данные полностью потеряны. > https://btrfs.wiki.kernel.org/index.php/Status - правильно, кто ж маны то читает? И эти > люди что-то там про qemu и чтение манов :) >> Но хоть холодный бэкап был у админа. > А RTFM он делать все же не умеет. Да, за 7лет так и не допилии. Неудивительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

206. Сообщение от пох. (?), 11-Янв-21, 09:26	–1 +/–
> Btrfs скажет csum error, corrected и поедет дальше. Посмотрев по чексумме какая из копий > правильная. а обе неправильные. Потому что чексумма посчитана по уже битому блоку. Или, еще смешнее - блок не битый, битик уплыл в чексумме. И так и записался, разумеется, обоими копиями. В отличие от высосанной в общем-то из пальца проблемы необъяснимой порчи данных, мирно лежащих уже на диске, эта-то - вполне реальная, и ошибки ecc я вижу в логах. > Fsck очень клево, особенно на автопилотируемых системах или когда он хомячку в морду вопросы > задавать начинает. фанатики модных-молодежных технологий не умеют ей пользоваться, так и запишем. И не забудь передать авторам btrfsck что они все делали не так, и он ненужен, надо просто уничтожить поломанный пул и создать заново, как у всех. Впрочем, как там ниже некоторые убедились, оно примерно этим и кончается, если уж дело дошло до btrfsck.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

207. Сообщение от пох. (?), 11-Янв-21, 09:43	+/–
> Ну например EXT4 с полным журналом тормозной как слоупок. А без него - вырубленая на середине > запись оставит полуперезаписаный файл, который ни вперед, ни назад. И чего потом с ним делать? Удалить, заново начать работать с резервной копией. Все равно неизвестно, что там записалось, а что нет. Я понимаю, гораздо приятнее и проще когда за тебя его удалит и вернет к предыдущей копии чудо-fs, но, к счастью, юниксный софт и так обычно неплохо справляется - пока не изуродовали. > практически это зависит от приколов его фирмвари и бывает весьма по разному. практически я за очень уже немалую профессиональную жизнь видел ровно два варианта - диск дохлый, сразу же возвращается ошибка, и диск уходит в себя, хорошо если ненадолго, прежде чем вернуть ошибку. От второго не помогают даже энтерпрайзные контроллеры и энтерпрайзные диски с управляемым tler. Очень занятно, что (поскольку чудо-fs в линухе никогда не знают, что там ниже - то ли диск, то ли высокоуровневая херня типа lvm, то ли md, то ли ентер-прайсный контроллер и ничего не могут с этим сделать) обработка этих событий сделана у вас на от...сь, и единственный способ помочь системе - выдрать диск на ходу, смотри не перепутай, какой. (В zfs все еще смешнее, придет deadman и вызовет kernel panic. Чую я тут лапы девляпсов, непривычных ни в чем разбираться, и "некогда читать всякую муру на консоли, работать надо", но лень искать первоисточник.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

208. Сообщение от псевдонимус (?), 11-Янв-21, 13:42	+1 +/–
Так распространение программ через докер и ускорение работы пакетного менеджера с помощью файловой системы и есть фигурная гребля! Разве нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

209. Сообщение от псевдонимус (?), 11-Янв-21, 13:46	+/–
>> И без некоторых сохранностей данных. > Естественно, бсдшнику виднее что у нас там в этих наших линуксах с > сохранностью данных. >> Линукса, тем более шапкообразного с на хранилке у меня не будет. > Тебя за язык никто не тянул, это все что на самом деле > надо знать о твоем уровне экспертизы по поводу данных в Linux. > Ты это небось даже на скриншоте не видел но мнение имеешь. Админ линуксоид. Восстанавливал, пока диски не вылетели. На райд5.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #214

210. Сообщение от пох. (?), 11-Янв-21, 14:02	+/–
"Мы открыли физическое устройство в эксклюзивном режиме, чтобы избежать проблем с попытками линукса сунуть нос куда ни попадя и все поломать, но теперь бида - он не может в том числе заметить, что количество доступных блоков изменилось". Это у них в комит-логе такое. Я посмотрел-посмотрел, и решил что, пожалуй, не буду апгрейдиться на восьмую версию, пока что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

211. Сообщение от пох. (?), 11-Янв-21, 14:05	+/–
Все, я заканчиваю дискуссию. Если человек свято верит в чудеса - у нас за оскорбление чуйств сажают. Конечно же, есть еще какое-то "более ядро" чем то ядро, в котором у нас и работает zfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

212. Сообщение от анонон (?), 11-Янв-21, 14:32	+/–
Ну охренеть, спец по интерпрайзным СХД пох не знает про резервную таблицу gpt? И что с ней может работать чуть ли не любая линуксовая тулза по управлению разделами? И для починки gpt понадобилось аж в винду грузиться? Сразу виден уровень матерого специалиста...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #221

213. Сообщение от VladSh (?), 11-Янв-21, 14:39	+/–
В ядре пространства модуля пользователя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

214. Сообщение от Аноним (-), 11-Янв-21, 15:00	+/–
>> Тебя за язык никто не тянул, это все что на самом деле >> надо знать о твоем уровне экспертизы по поводу данных в Linux. >> Ты это небось даже на скриншоте не видел но мнение имеешь. > Админ линуксоид. Восстанавливал, пока диски не вылетели. На райд5. Забей. Это почти-трехсотый, с ним диалог невозможен - он или снова покажет мастер-класс передерга и чтения жопой или сменит неудобную тему или просто перейдет на ad hominem. Ну или все вместе, плюс опять придумет какую нибудь *рень, как выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #216

215. Сообщение от Аноним (215), 11-Янв-21, 15:24	+/–
Ты что! В zfs/arc.c особый kmem_cache_alloc, волшебный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #251

216. Сообщение от псевдонимус (?), 11-Янв-21, 15:28	+/–
Да пусть хоть кто-то прочтет, может не подорвет  и не навредит себе и окружающим. Чела уволили. Я к людям использующим Линукс никакой ненависти не испытываю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

217. Сообщение от псевдонимус (?), 11-Янв-21, 15:36	+1 +/–
>[оверквотинг удален] > но в снапшот не оформлялось. На самом деле довольно логично сделано, > круто и гибко. >> А что, btrfs'ным рэйдом (а не зеркалом) уже в принципе пользоваться можно >> стало? Расскажи это synology, а то ребята не в курсах и мучаются. > А чего они там мучаются? И да, RAID1 считается стабильным. И вполне > юзабелен. У меня с ним проблем не было. А чего с > ним у synology? >> если бы еще и работал... > Так работает вроде. Ну, RAID5/6 стабильными не заявлены, а в остальном - > см. вику проекта. Вместо документации "Вика проекта". Этого достаточно, чтобы не прикасаться к убожеству.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

218. Сообщение от анонн (ok), 11-Янв-21, 16:17	+/–
>> А если реальную железяку из розетки выдернуть". > Для меня это стандартный тест при оценке устойчивости ФС к внешним воздействиям. Зачем мне ФС которая скопытится и провалит задачу? Помимо того, что выдергивать чужие цитаты из контекста ... хотя не, похоже бесполезно объяснять. Вот так выглядит реальность вне россказней с опеннета: $ smartctl -x /dev/ada0 |grep -i "unexpec\|wr.*cache" Write cache is:   Enabled 174 Unexpect_Power_Loss_Ct  -O--CK   100   100   000    -    75 $ stattime / /usr /boot |grep -i birth Birth:    20:50:17 03/11/2013 Birth:    20:47:49 03/11/2013 Birth:    20:49:53 03/11/2013 $ df -T / /usr /boot|awk '{$0=$2};2'     Type ufs ufs ufs >> Rosa Linux > А, ну эти довольно чудесатые. С другой стороны... попробуй стать разработчиком коммерческой бзды, лол. Звучит почти как мишн импасибл, поэтому ты небось занимаешься какой-нибудь фигней в какой-нибудь маздайке, так что твои рассказы о прелестях бсдшных свобод или "истории успеха" стоят довольно дешево. Просто прелестно - опять сменил тему, опять что-то нафантазировал и подвел какие-то "обоснования", опять приписал каки-то "рассказы" и перевел в плоскость ad-hominem. В общем, "этот пингвиняш сдулся, вносите следующего!" (с)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #247

221. Сообщение от пох. (?), 12-Янв-21, 09:49	+/–
ну-ка, так тоже стало нельзя: А у л@п4@тых нет проблемы, у них ценных данных не бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

222. Сообщение от пох. (?), 12-Янв-21, 09:53	+/–
> поезда ездят. А карточки прямо с фабрики в FAT32 идут. Форматировать к сожалению, только уже с китайской фабрики. А не совсем 100% китайские идут теперь в exfat. MS нормальная лавка (была, по крайней мере), она позаботилась переделать поезда с конной тяги хотя бы на пар, когда лошадки перестали справляться с весом состава. А, ну да, ну да, сасунг о вас позаботился, и его комит даже приняли, поворчав для порядку. Правда, только в ядрах 5.99, в которые еще много нужных и полезных уничтожающих данные комитов приняли, но у л...х ведь нет ценных данных. Фоточки - сбегают переснимут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #269

223. Сообщение от пох. (?), 12-Янв-21, 09:56	–2 +/–
> Не знаю, как там по рождению, но по настоящему это - hype > class файловая система. зачем же вы от нее сп-ли все, от дизайна до терминологии? Только неуклюже, поэтому половина не работает - нет среди вас Левенталей, не завезли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #225

224. Сообщение от пох. (?), 12-Янв-21, 09:59	–1 +/–
>>А чексуммы намекнут о проблемах с железом, если повезет то до того как это превратится в большую проблему. > Ну и какого хрена тогда на чексуммы и блоки фс > ругаеться ? Намекает на проблемы с железом. У тебя их не было - щас создаст на пустом месте! ;-) Как и всегда у безумно переусложненных конструкций. P.S. ла..то фанатикам - обратите внимание, _данные_ у него - в порядке. Шах и мат др-рам на crc всего на свете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #241, #256

225. Сообщение от Онаним (?), 12-Янв-21, 10:13	+/–
Кто сп-л то? BTRFS имеешь в виду? Ну это к орацлу. На деле такое же полуюзабельное убожество. Хотя в отличие от зфсы чуть менее - кеширование таки используется системное, костыли не нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223 Ответы: #229, #260

226. Сообщение от Онаним (?), 12-Янв-21, 10:15	+/–
На ротационных носителях - уменьшает потому, что CoW - это априори безумная фрагментация. И в целом уменьшает, потому что фигова туча метаданных нужна для его поддержки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #259

227. Сообщение от пох. (?), 12-Янв-21, 10:16	–1 +/–
> как линуксоиды с нтфсом в фузе, который в проц упирается а > не в диск. Сказания впопеннета, том восемьсотписятшестой. Он не упирается в проц. Внезапно. Измеризмы на 32битном arm вообще не нашли существенной разницы между fuse и in-kernel реализацией. Сказание пошло из времен, когда упирался не в проц, а в линуксопроблему (создававшую ненужную нагрузку на проц там, где ее быть не должно). fuse - ее правильный сумасшедший проектировал, еще в забытые годы хороших программистов и хороших программ. Повторить это вы неспособны, а испортить - скорее всего, да, сможете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #258

228. Сообщение от Онаним (?), 12-Янв-21, 10:20	+/–
В общем случае достаточно ordered при рабочем механизме write barrier. Перезаписывать файлы по частям вообще так себе затея, и те, кому это реально нужно (СУБД и т.п.) - ведут свои собственные журналы так, как им надо и им оптимально. Этим достаточно только собственно наличия или отсутствия записи. CoW от полуперезаписи файла в общем случае (нет, не в сферическом в вакууме) вообще ничем не спасёт, потому что запись как правило не в один приём ведётся, и оборвать её посередине вполне возможно в любых условиях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #236

229. Сообщение от пох. (?), 12-Янв-21, 10:21	–1 +/–
> BTRFS имеешь в виду? > Ну это к орацлу. а, не вы, действительно. куда вам... > На деле такое же полуюзабельное убожество. Хотя в отличие от зфсы чуть > менее - кеширование таки используется системное, костыли не нужны. То есть вместо ARC - блочный кэш без управления, оок. Про твои камлания что он более системный чем системный - это к шаманам. Только того последнего арестовали при штурме Капитолия, предыдущего - кровавая гэбня. В отличие от zfs (у которой мильены работающих raidz систем, более того, именно эту конфигурацию обычно используют сходу, не задумываясь, если и было чем) только вот не работает рэйд, но лап..запрещенноесовсемнавпопеннетеслово не мешает камлать что "чуть менее".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #235

230. Сообщение от Онаним (?), 12-Янв-21, 10:22	+/–
Она не пропадает. Как только приложение её попросит - ОС ему даст, не ломаясь. Более того, даст и из cache/buffers при необходимости, не дожидаясь, как с ZFS, освобождения из ARC. Сама всё снимет и даст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

231. Сообщение от пох. (?), 12-Янв-21, 10:23	+/–
> Похерить зфс может всё что угодно. От ошибок оборудования ядра самой реализации > зфс волшебным образом не спасает. спасает. Успехи чувака с насмерть битым блоком питания во времена когда компьютеры были большие - таки впечатляли. Спасает не во всех случаях, а в каких-то странных и вырожденных, но тем не менее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #245

232. Сообщение от Онаним (?), 12-Янв-21, 10:24	+/–
12309 - он от интеловских ICH, которые начиная с 82801 встают раком при задержках от диска. И до сих пор встают раком, что-то там с обработкой оных награблили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

233. Сообщение от Онаним (?), 12-Янв-21, 10:25	+/–
(и даже в винде "12309" офигительным образом есть - на интеловском железе)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

234. Сообщение от Онаним (?), 12-Янв-21, 10:27	+/–
> md raid (с полным копированием всех данных после перезагрузки ресетом Это называется про bitmap забыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #242

235. Сообщение от Онаним (?), 12-Янв-21, 10:38	+/–
> То есть вместо ARC - блочный кэш без управления, оок Угу. То есть оно применимо на чём-то, кроме выделенных хранилок, потому что ARC внезапно память вовремя отдавать не умеет. В отличие от блочного кеша (который кстати "снаружи" не совсем 100% блочный, и внезапно реагирует на fsync с конкретной inod'ой, да ещё и write barrier в нужных местах умеет, а не как придётся).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #249

236. Сообщение от Онаним (?), 12-Янв-21, 10:42	+/–
(да, старые данные с CoW - возможно - найти ещё можно, но вот какой конкретно чекпоинт искать у софта, который сделал 100500 write'ов по 4K в этот файл, и на 100501 из 1005000 обломался - это уже для ниндзя)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228

237. Сообщение от Anonim (??), 12-Янв-21, 11:52	+/–
На практике это локалхост или в проде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

238. Сообщение от пох. (?), 12-Янв-21, 12:15	+/–
>> это чтоб вместо 64x write amplify получить 256? Не, не умеет. > А вот это уже мне решать что я хочу. И если что, Ну допиши недостающий код. А, нет, только жрать с лопаты ты можешь "решать"? > чисто статистически протирание системного SSD под btrfs - примерно однохренственно с > EXT4. Чтобы x64 получить надо быть похом, стреляя в пятки с Чисто практически - 64x. Это у человека, который _мерял_, а не камлал. (У ext4 - 4-8x) Без всякого еще и дополнительного удвоения данных на том же самом ssd (что вообще феерически бесполезно). Рассказывали и про 128, но там - рассказывали, а тут - меряли и описали процедуру. Но ты продолжай камлать - чем больше камлаешь, тем, прости уж, большим идиотом выглядишь. И тем хуже защищаемой тобой технологии, потому что и других, кто на самом деле владеет темой, будут воспринимать так же. > прецизионностью эксперта. да, да, все неправильно. вот у тебя-то все правильно, только мерять не вздумай (впрочем, ты не умеешь) Да и зачем, ssd быстрый, денег контора отсыпает лопатой, чего мозг морщить. > Какие уровни защиты от бэда, лол? Диск просто не смог прочитать тот > сектор. Это нарушает допущения и ZFS и EXT4. Далее - undefined. Нет, не нарушает. ext2 писали когда битые секторы не были фантастикой. Впрочем, при попадании в журнал вероятно таки п-ц, если не спохватиться самому. >> не прочитает. Это случай, когда остальное надо аккуратно копировать, если оно хоть >> малейшую ценность представляло, а диск - выкидывать, а не волшебные fs изобретать. > На винчах, особенно емких, изредка может проскакивать 1-2 бэда без последствий. Оно у меня не "проскакивает", что я делаю не так? > это можешь и не заметить даже. Особенно в винде где она > сотни ошибок в логи валит и никто их не читает, плюс-минус их робот читает, вам, л@...м не понять. >> отдельный вопрос - как fsck помогает ext4 при нечитающихся метаданных. > А вот так - делает проход, проверяет корректность, пытается более-менее нейтрализовать при _нечитающихся_. Нечего проверять, диск виснет при попытке прочитать набор экстентов. И? > или перестроить некорректное. Что-то потеряется, но хотя-бы стораж смонтируем и какую-то смонтируем мы без всякой fsck. Но вопрос был про fsck. Она вообще не для того, но ла..ые фанаты этого не вкуривают. >> она вполне хорошо работает в этих случаях - значительно лучше недоделка btrfs > 1) В каких именно случаях? физических проблем с носителем, приводящим к нечитаемым данным. Неидеально, но можно жить. > 4) Какие из этого бенефиты пользвателю? Не смотрит, удивленно моргая, на пустую точку монтирования, при отсутствии каких либо реальных предпосылок к этому. >> (кстати, опачки при штатной перезагрузке, надысь. Ну не то чтобы не >> для того и брали...) > Чего? Нельзя ли развить эту мысль? Нишмагла она. Чего нишмалга - мне лень было выяснять, там было использование btrfs по прямому ее назначению - для данных, которые в случае чего можно быстро восстановить, а управление не на уровне fdisk 1984 полезно. > Нет, там не петабайтные масштабы - однако нет ни одной причины по тогда не надо к ним аппелировать, говоря о васян-ноуте. > которой лаптоп не достоин менеджмента на манер виртуалок, с снапшотами и > всем таким. какая васян-ноуту польза от снапшотов, кстати? >> Нет, это совсем нерабочее. Я больше доверяю thin lvm с xfs - > Он как-то в вопросах менеджмента - ну воообще не XFS. И еще про thin lvm ла..й эксперт не понял, поскольку не в курсе, угу. > хотите, дескать. Хочу посмотерть как обладатели петабайтов будут конвертить "старый" формат > в новый. На ноутбуке, угу. >> оно глючит и перезагружается от неведомых причин, но последнее время - >> вроде, каждый раз перезагружается, а не опачки-чавойтаянемагу. > Кто перезагружается? Почему перезагружается? ведро лиnoopsя. потому что xfs так обрабатывает ошибки. >> Но, надо признать, когда навернется, destroy/create там дольше. > В случае btrfs вроде вообще после краха монтирование столько же сколько и После краха она не монтируется, тебе уже несколько разных человек сообщили эту радостную новость. А я вот нежданно познал дзен, что может не монтироваться без всякого краха, после штатного ребута - и хз почему. Ну не хочется ей, вот. > обычно, fsck не надо, он просто выкинет свежие изменения которые не > прокатили а фс в целом корректной остается. ну надо же. А мы-то с ext3 в 2005м году тоже так думали. И да, она это может. Она совсем другое нишмагла. > И хрен тебя знает что ты там с петабайтами делаешь, гигантоманию прокачиваешь? про петабайты это ты понес пургу. У меня нет и не предвидится никаких петабайт на настолько гнилом софте. > А то почему-то баги на 20Тб файлах только фэйсбук и поймал. > У остальных, видимо, такого тупо нет. У меня таких точно нет. Понятия не имею, что это за котик им такой попался и в своем ли они уме. У меня обычные файлы обычного размера. При этом общие объемы некоторых хранилищ - пара сотен тер. Но те под виндой, на энтерпрайзной fcшной немодной схд, некоторым уже по восемь лет, и за эти годы с ними ничего не сделалось - вероятнее всего, и не сделается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #246, #267

239. Сообщение от пох. (?), 12-Янв-21, 12:23	+/–
> А в btrfs такое средство просто в штатную утилсу btrfs встроено. "Оффлайн" Нет, не такое. И о его успехах нам там ниже докладывают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

240. Сообщение от пох. (?), 12-Янв-21, 12:26	+1 +/–
> Чё-то я не припоминаю наличия такой потребности во FreeBSD... Ниасиляторы, чо с вас взять. Даже грамотно запутаться в собственных лапах на ровном месте - и то не умеете. Впрочем, OpenZFS 2.0.1 и к вам спешит на помощь, на ходу оттопыривая гузку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

241. Сообщение от maximnik0 (?), 12-Янв-21, 12:29	+/–
> P.S. ла..то фанатикам - обратите внимание, _данные_ у него - в порядке. > Шах и мат др-рам на crc всего на свете. Уже обсуждал в linux.org.ru.В приватном сообщении- человек подсказал в чем дело-оказываеться существует 3 версии алгоритма чек сумм -новая и 2 старые.В ручной опции монтирование нужно указать нужную версию,кодеры забыли указать флаг в старой версии 32 бита или 64 бита (оптимизация под архитектуру),а авто монтирование ставит дефолтом -старая версия,архитектура локальной машины.Вот на чек суммы и ругаеться,а обещали флаги совместимости с потдержкой минимум 2 версии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224 Ответы: #248

242. Сообщение от пох. (?), 12-Янв-21, 12:34	+/–
>> md raid (с полным копированием всех данных после перезагрузки ресетом > Это называется про bitmap забыли. это называется непонимание элементарных вещей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234 Ответы: #244

243. Сообщение от пох. (?), 12-Янв-21, 12:40	+1 +/–
>> запуске линуксов в bsd'шных виртуалках, знаете ли, ничего само собой почему-то >> не ломается. > Еще бы. Так никто не делает - оно и не ломается почему-то. Я делаю. Виртуалке ДВЕНАДЦАТЬ лет. Пережила три разные виртуализации и четыре хоста, и до сих пор работает. А у л@...х все как всегда. Работать в волшебном qemu-kvm могут только лап@тые системы, специальным образом приготовленные (то есть вот та - не будет, кстати, она слишком стара для такого б-ского цирка). А все кто не в ногу - те луддиты и их быть вообще не должно. Ну ооок, так и записали. Я-то думал, вы хотя бы этой детской болезнью переболели. > Бзда как хост виртуализации? работает. Бредовых требований к гостевым системам о поддержке того, что даже не документировано - не предъявляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

244. Сообщение от Онаним (?), 12-Янв-21, 15:23	+/–
Именно так это и называется. Потому что bitmap в md позволяет полного рефреша избежать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242

245. Сообщение от Аноньимъ (ok), 12-Янв-21, 16:02	+/–
ZFS решает проблему гниения битов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231 Ответы: #277

246. Сообщение от Аноньимъ (ok), 12-Янв-21, 16:17	+1 +/–
>После краха она не монтируется Поврежденная ЗФС может вызывать панику и ребут на фре, например. При попытке импорта пула или при попытке востановления. Что очень весело и клёво. Но позволяет импортировать в только для чтения и вытащить данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238 Ответы: #250

247. Сообщение от псевдонимус (?), 12-Янв-21, 19:41	+/–
Это 294-й скорее всего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

248. Сообщение от пох. (?), 12-Янв-21, 20:00	+/–
> В приватном сообщении- человек подсказал в чем дело-оказываеться существует 3 версии алгоритма > чек сумм -новая и 2 старые. Прекрасно, дай угадаю - но места указать ее явно в куче ненужного мусора в метаданных - конечно же не нашлось. У модных-молодежных оно всегда так. Сколько там у zfs "версий" чексумм на разных алгоритмах? Штук пять, поди ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241 Ответы: #253, #285

249. Сообщение от пох. (?), 12-Янв-21, 20:02	+/–
>> То есть вместо ARC - блочный кэш без управления, оок > Угу. То есть оно применимо на чём-то, кроме выделенных хранилок, потому что > ARC внезапно память вовремя отдавать не умеет. В отличие от блочного ну разумеется, разумеется,  продолжай петь свои мантры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235

250. Сообщение от пох. (?), 12-Янв-21, 20:11	+/–
> Поврежденная ЗФС может вызывать панику и ребут на фре, например. Это может, notabug :-( Полагаю, поврежденная btrfs тоже прекрасно может все то же самое, а xfs так и неповрежденная, эта точно, может. > Что очень весело и клёво. Весело и клево другое - альтернативно-одаренные разработчики-копипастеры из iX не считают это своей проблемой. А конструкция проекта не позволяет никому перехватить у них управление. > Но позволяет импортировать в только для чтения и вытащить данные. Это как повезет. Иногда позволяет годами жить, если в определенный каталог не заходить, есть прецедент. Иногда не позволяет ни импортировать, ни прочитать. notabug. В принципе, потратив неимоверное количество времени и узнав много лишнего о структуре метаслабов, с помощью zfb, dd и какой-то матери такой пул иногда можно превратить в r/o импортируемый, но обычно оно того не стоит. А необычные кормят все ту же iX и дельфиксов. Правда, надо заметить, все известные мне случаи - не на ровном месте. В отличие от btrfs. Другое дело, что от этих неровных дизайн zfs должен был бы защищать. Но опаньки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #252

251. Сообщение от пох. (?), 12-Янв-21, 20:34	+/–
> Ты что! В zfs/arc.c особый kmem_cache_alloc, волшебный. Он лежит в /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c В bsd он просто однострочник-преобразователь аргументов, вызывает uma_zalloc. Точно так же как любой другой код в ядре, которому нужна zone memory. Никакого "волшебного" в нее не завезли: % find /usr/src/sys/ -type f -print0 | xargs -0 grep -l uma_zalloc /usr/src/sys/kern/sys_generic.c /usr/src/sys/kern/kern_time.c /usr/src/sys/kern/kern_rangelock.c /usr/src/sys/kern/kern_cpuset.c /usr/src/sys/kern/uipc_mqueue.c [skip, оставлю избранные фрагменты] /usr/src/sys/kern/kern_mbuf.c /usr/src/sys/kern/vfs_cache.c /usr/src/sys/kern/vfs_aio.c /usr/src/sys/kern/tty_outq.c /usr/src/sys/kern/kern_thread.c /usr/src/sys/kern/tty_inq.c /usr/src/sys/kern/vfs_lookup.c /usr/src/sys/ofed/drivers/infiniband/ulp/sdp/sdp_main.c /usr/src/sys/x86/iommu/intel_gas.c /usr/src/sys/dev/iser/icl_iser.c "Волшебство" самого чорного характера ты найдешь не там, а в abd.c Этого вот не было до 11 версии. Подарочек от пингвиноидов, и хрен теперь выпилишь. Я ж показывал недавно - там лежит половина размера ARC. Порезанная по 4k. А что там у ла..запрещенноенавпопеннетеслово - у них спрашивай, мне совершенно неинтересно. Очевидно, совсем г-но, иначе бы iX не дали пропасть прекрасному. P.S. пока этот find работал, стало еще веселее - arc радостно отрос до 473M (то есть честно отрабатывает свой хлеб). abd тоже не лох - он теперь 310 Напоминаю - всей памяти у виртуалки - гигабайт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

252. Сообщение от Аноньимъ (ok), 12-Янв-21, 21:39	+/–
Да, иэксеры нехорошие люди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250

253. Сообщение от maximnik0 (?), 12-Янв-21, 22:41	+/–
> Прекрасно, дай угадаю - но места указать ее явно в куче ненужного > мусора в метаданных - конечно же не нашлось. У модных-молодежных оно > всегда так. Мозгов сделать предупреждение им не хватило,как и утилиту конвертации.Мозгов !Заявляеть о потдержке 2 превыдущих версий спецификаций с возможностью конвертации ,забить в как сейчас принято на совместимость и при этом так и не сделать конвертор....Это как с  wayland - поставить в упрек Х-м отсуствие версирования,сделать версирование в waylandе и .....поломать совместимость потому что оказывается как всегда понадобилось костыли включать в протокол, а заморачиваться совместимым ари сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #254

254. Сообщение от maximnik0 (?), 12-Янв-21, 23:39	+/–
Дай еще уточню,там именно версии контролльной суммы,не кол-во алгоритмов.Они именно формат сломали.Последняя версия стала более компакная по размеру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #257

255. Сообщение от Аноним (257), 13-Янв-21, 04:38	+/–
> Позавчера наткнулся опять на проблему с BTRFS.Старый жесткий,валялся лет эдак 5 ,бтрфс > -бэкап информация.Обнаружил что раздел только чтение-ругаеться при монтирование на чек > суммы и проблемы с fs .Ну ладно скопировал информацию,попытался чинить -фиг > вам,как не ремонтируется эта fs ,так и продолжает нуждаться в "шамане". Я бы сказал что диск посыпался, но... > нечего нет.Ну и какого хрена тогда на чексуммы и блоки фс ругаеться ? Может у тебя RAM или CPU под нагрузкой дурят?! Очень уж похоже на сбойное железо. Но, конечно, прикольнее как на EXT4 - молчок в тряпочку, с неспешным засиранием файлов. Так чтоли? Если csum error лезет, с этим надо разбираться. И нет, это не баг ФС, это ее фича - хайлайтит ваше гамнецо в железе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #266

256. Сообщение от Аноним (257), 13-Янв-21, 04:42	+/–
> Намекает на проблемы с железом. У тебя их не было - щас > создаст на пустом месте! ;-) Железо или выдерживает пиковые нагрузки, или изредка подсирает глюками. На любой ФС. > P.S. ла..то фанатикам - обратите внимание, _данные_ у него - в порядке. > Шах и мат др-рам на crc всего на свете. А вот это, кстати, вполне похоже на битый RAM или проц. 1) Считали SCRUB, железо прогрелось, стало глюкать, вот тебе csum error 2) Железка остыла, все дела. 3) За один md5sum оно не успело прогреться как scrub И конечно в его сыпучем железе виноват btrfs. А, ну да, EXT4 молчал бы в тряпочку, а то что раз в год md5sum все же не верный или чота бэкап не распаковывается... вот за это я и люблю btrfs, с ним намного понятнее гадит мне железо или нет :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224 Ответы: #265

257. Сообщение от Аноним (257), 13-Янв-21, 04:43	+/–
> Дай еще уточню,там именно версии контролльной суммы,не кол-во алгоритмов.Они именно формат > сломали.Последняя версия стала более компакная по размеру. Чокаво? В btrfs on-disk формат не меняли несовместимым образом последних лет 10. Так что старый бэкап должен читаться. А поха лучше не слушать, известный эксперт по всему, одинаково крут во всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254 Ответы: #262

258. Сообщение от Аноним (-), 13-Янв-21, 04:53	+/–
> Он не упирается в проц. У top бывают другие идеи на этот счет. Если на быстром диске ядро в полку - это чего?! Может, если ты на зион ноутбучный винч 5400 приделаешь, тогда не упрется наверное. > Измеризмы на 32битном arm вообще не нашли существенной разницы между fuse и > in-kernel реализацией. А это еще зависит от характера доступов. В энных случаях оно в разы медленее. Особенно бесит народ на малохольных роутерах с хилым мипсом, где оно актуально для подхватывания флех в юсб и раздачи их по сети. > Сказание пошло из времен, когда упирался не в проц, а в линуксопроблему > (создававшую ненужную нагрузку на проц там, где ее быть не должно). Не, вот пардон, жрет проц именно фьюз а не линуксное ядро. > fuse - ее правильный сумасшедший проектировал, еще в забытые годы хороших программистов > и хороших программ. Повторить это вы неспособны, а испортить - скорее всего, да, сможете. Чудес не бывает, при нагрузке оно делает дохреналион переключений контекстов в секунду. Что естественно все здорово нагибает. В новых версиях, кстати, это вроде несколько улучшили, так что насчет испортить - вроде бы ровно наоборот все. Впрочем, это пох, у него и синус двух достигает, но к сожалению не тогда когда это позарез надо, а тогда когда это очень некстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227 Ответы: #261

259. Сообщение от Аноним (-), 13-Янв-21, 05:38	+/–
> На ротационных носителях - уменьшает потому, что CoW - это априори безумная фрагментация. Вообще совсем ниоткуда не следует. Если например прога одним куском весь файл переписывает - разницы вообще не будет во многих случаях. И это зажурналить по честному на обычной ФС - так его надо 2 раза писать, сперва в журнал, потом в основную область. И тут разглагольствования о скорости или надежности идут лесом - выбирайте уж одно из двух. Крутой выбор! А тут все и сразу. Хоть и ценой немного странных свойств. > И в целом уменьшает, потому что фигова туча метаданных нужна для его поддержки. Опять же - зависит от паттернов доступа. Показать как в обычной ФС сделать это же самое? А блин торент без преалокации скачайте. XFS какой будет потом 5 минут один дивидюк удалять, чего бы это он?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #264

260. Сообщение от Аноним (-), 13-Янв-21, 05:41	+/–
> На деле такое же полуюзабельное убожество. Хотя в отличие от зфсы чуть > менее - кеширование таки используется системное, костыли не нужны. Ага, попробуешь в ней девайсами рулить, потом дважды подумаешь кто там полуюзабельное убожество, а кто finally got it right. Разве не киздато когда на ходу и добавить, и изъять, и даже схему RAID переиграть? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #274

261. Сообщение от пох. (?), 13-Янв-21, 09:13	+/–
> У top бывают другие идеи на этот счет. Если на быстром диске ядро в полку - это чего?! А я знай? Может, к корявому софту, может к кривому железу, может к неэффективности самой фс под задачу. А может кто-то и big_writes включить забыл (но это надо еще суметь). Тут некоторые, не будем показывать пальцем, граждане - ceph используют для своей массовой  виртуализации. И, похоже, не считают что переплачивают за процессорные мощности, хотя контора ни разу не благотворительное заведение. Наверное, просто не знают, что у них есть прекрасный, параллельный, in-kernel nfs. Или знают ;-) > Чудес не бывает, при нагрузке оно делает дохреналион переключений контекстов в секунду. Повторяю: я, в отличие от некоторых - _тестировал_. Причем на железе, которое сейчас даже в телефоны стесняются ставить. Разница (для моей задачи, это ни разу не usb2 флэшка в твоем мипсе, где я и искал бы корни проблем) - на уровне с трудом различимом приборами. Я расстроился, потому что потратил довольно много времени, чтобы эту херню вообще запустить у себя, и ожидал чудес, а "3g" и так просто работала из коробки. И нет, она не использует fuse3. С которой я ковыряюсь отдельно, и пока тоже что-то щастья не обнаружил (в смысле не нашел конфигурации, способной что-то отдавать с такой скоростью, чтобы вообще заметить разницу - и это в целом неудивительно, все улучшизмы там в userspace, а значит - сомнительные. Говорю же - ту - правильный сумасшедший цыган писал. Сейчас таких не делают.) P.S. и еще один ньюанс - не забываем выключать kpti и прочую чушь. Вероятно - лучше всего путем установки ядра версии 3.0.последней или рядом что-то. Поскольку оно по настоящему не выключается. Но это актуально только для amd64 архитектуры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #271

262. Сообщение от maximnik0 (?), 13-Янв-21, 09:54	+/–
> Чокаво? В btrfs on-disk формат не меняли несовместимым образом последних лет 10. > Так что старый бэкап должен читаться. А поха лучше не слушать, > известный эксперт по всему, одинаково крут во всем. Хм -насколько я знаю формат raid 4-условно 7 не стабилизирован до сих пор,только в прошлом году как я читал что то в формате  методанных поменяли.Мне человек  ткнул в  чанлог за 18-19 год- я тоже думал что формат стабилизирован.. >сonvert and mkfs will try to use optimized crc32c >use hw assisted crc32c on more arches И ВИШЕНКА  (Mar 2019) metadata uuid - new feature that allows fast uuid change without rewriting all metadata blocks (backward incompatible)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257 Ответы: #263, #283

263. Сообщение от maximnik0 (?), 13-Янв-21, 10:20	+/–
Еще мне ткнули на такую вещь- This can catch consistency problems or bitflips-проблема была пофикшена на версии ядра 5.1.х ,с какой версии была проблема не написано. Это связано с тем что вынесли алгоритмы  контроля из драйвера бтрфс с целью унификации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #284

264. Сообщение от Онаним (?), 13-Янв-21, 10:24	+/–
> Вообще совсем ниоткуда не следует. Если например прога одним куском весь файл переписывает > А блин торент без преалокации скачайте Вот как раз на CoW будет задница хоть с преаллокацией, хоть без. На обычной FS можно ещё как-то уйти от этой задницы преаллокацией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259 Ответы: #280

265. Сообщение от maximnik0 (?), 13-Янв-21, 10:34	+/–
1) Считали SCRUB, железо прогрелось, стало глюкать, вот тебе csum error А данные с Божью благодатью записались с Сжатием нормально.Ух ты,пойду тогда все железо освещать .(шутка на грани фола-не обижайтесь верующие,простите атеиста.) Вы не смотрели в монитор -что происходит при записи на многоядерной машинке-чтобы избежать перегрева (по крайне мере так у АМД) задачи постоянно скачут по ядрам.Остается память -ну не знаю,сомнительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #282

266. Сообщение от maximnik0 (?), 13-Янв-21, 21:00	+/–
>Очень уж похоже на сбойное железо. А данные с сжатием записались нормально-чудеса и только.Вот меня ткнули носом что BTRFS которая как 5 лет считается устоявшимся формат (кроме раид )-до сих пор пилеться. (Mar 2019) metadata uuid - new feature that allows fast uuid change without rewriting all metadata blocks (backward incompatible) .18-19 год : >сonvert and mkfs will try to use optimized crc32c >use hw assisted crc32c on more arches Это трекер за 18-19 год мне прислали ,ткнули.А сколько фишек помимо контрольной суммы внедрили-до фига,т.к что не фига оказывается у бтрфс стабильный  формат,до сих пор появляться ломающие совместимость обновления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #281

267. Сообщение от Аноним (-), 14-Янв-21, 00:17	–1 +/–
> Ну допиши недостающий код. Дописать что? Куда? ZFS мне например не упал в том числе потому что он не в майнлайне. И для починки этого надо всего ничего - ДОПИСАТЬ ВЕСЬ КОД ЗАНОВО. И если уж кто настолько е...ся, ему логично с ноля переархитектить. С учетом современных тенденций. > А, нет, только жрать с лопаты ты можешь "решать"? До того как бросаться махать шашкой, надо разобраться кого и почему и оценить перспективы. Иначе это донкихотство от кодинга, когда можно обнаружить что пока ты год @#$лся, другие 2 года назад накодили впятеро лучше. > Чисто практически - 64x. Это у человека, который _мерял_, а не камлал. (У ext4 - 4-8x) А кто б этого человека знает, что за конфига, что за ворклоад, и как это стыкуется со мной? Описания нет нихрена, только понты известного эксперта. > Без всякого еще и дополнительного удвоения данных на том же самом ssd > (что вообще феерически бесполезно). Вообще-то это от SSD и его фирмвари сильно зависит. И об всем этом в вике btrfs'а написано сильно лучше чем твои бла-бла. Более того, именно поэтому оно на ssd по дефолту не врубается, но желающие могут врубить и проверить на практике что будет. > Рассказывали и про 128, но там - рассказывали, а тут - меряли и описали процедуру. Так где описание? > Но ты продолжай камлать - чем больше камлаешь, тем, прости уж, большим идиотом выглядишь. Зачем мне камлания? У меня статистика smart для оценки общего перфоманса и перспектив кончины накопителей. Это неплохая метрика, хоть и зависимая от фирмвары. > И тем хуже защищаемой тобой технологии, потому что и других, кто на > самом деле владеет темой, будут воспринимать так же. У любой технологии есть свои сильные и слабые стороны, которые к тому же не являются константой выбитой в камне. И то что у вон тех господ ворклоад такой же и с тем же результатом - ниоткуда не следует. А глядя на твои заявы, в которых некомпетентность сочетается с понтом, самоуверенностью, выводами на песке и протухлостью сведений лет на 10, вопрос как будут воспринимать технологии которые продвигаешь ты. > да, да, все неправильно. вот у тебя-то все правильно, только мерять не > вздумай (впрочем, ты не умеешь) Нет, я просто давно усвоил что пох эксперт в поиске максимально дурацких сочетаний конфигураций, если вопрос касается Linux. Ну вот не по поховской руке этот инструмент. Ты небось на соляру какую втихаря наяривал, а оно и не выгори. И вот ты пытаешься всем доказать какой пингвин крап. В твоих руках он и правда крап. Но дело не в пингвине. > Да и зачем, ssd быстрый, денег контора отсыпает лопатой, чего мозг морщить. Когда SSD быстрый, оверхед файловой системы заметнее. Однако, еще дедушка Кнут сказал что premature optimization is a root of all evil. А бизнес ответил про good enough. Так что до бросания грудью на амбразуру какой-то проблемы стоит понимать так ли уж проблема машает. Или же есть 20 более приоритетных дел? А, это пох, он в управлении проектами не ушел дальше джуна. > Нет, не нарушает. ext2 писали когда битые секторы не были фантастикой. Впрочем, > при попадании в журнал вероятно таки п-ц, если не спохватиться самому. При попадании на любую используемую данными/метаданными область undefined. Не додумает же она отсутствующее? А бэдсекторы и сейчас не экзотика. Емкие накопители довольно деликатные, пернуть парой UNC иногда не ржавеет особо. И довольно голимо если все наворачивается. RAID например не сделан в допущении что накопитель вместо того чтобы сдохнуть будет на некоторые сектора ругаться или мусор возвращать, а таки изредка такие пакости бывают. Те кто ставят чексумирующие ФС узнают много нового о своем железе и его failure modes. >> На винчах, особенно емких, изредка может проскакивать 1-2 бэда без последствий. Оно > у меня не "проскакивает", что я делаю не так? Как гласят законы Мерфи, если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили. > их робот читает, вам, л@...м не понять. А, может у тебя робот уже давно их и не читает или ... кладет? :) > при _нечитающихся_. А какая разница? То самое смысл имеет на образе диска, при реквери. А на железке - потрогать их палочкой. Либо это софт-бэд который самоустранится, либо переназначится. > Нечего проверять, диск виснет при попытке прочитать набор экстентов. И? Если данные надо было, отдай спецам по data recovery, они знают чего делать. Если попытка починить каку - запиши что-нибудь RAW доступом в сектор, UNC либо починится, либо ремапнется если фирмварь не совсем дрянь. А данные в секторе все-равно профаканы, какая разница. > смонтируем мы без всякой fsck. Вот это для порушеного стоража - не факт. Еще больше не факт дальше при попытках чтения из этого. FUZZить драйвер ФС хорошая идея, но только на тестовой машине, а не когда тебя интересовали данные и/или работа ос. > Но вопрос был про fsck. Она вообще не для того, но ла..ые фанаты этого не вкуривают. Fsck на автопилотных системах вообще источник проблем нежели решение. Автопилотные системы, видите ли, вообще не должны живых людей требовать для майнтенанса и интерактива. В этом плане у btrfs таки плюс есть. А с точки зрения data recovery у того есть очень клевый офлайн чтец, которого у ext4 внеазпно нет. Вроде какие-то коммерческие и для ext'ов умеют, но тут оно прямо в родных утилах фс такое красивое. >> 1) В каких именно случаях? > физических проблем с носителем, приводящим к нечитаемым данным. Неидеально, но можно жить. Есть обратный опыт, btrfs на сыпучем носителе выживает, если dup data+metadata сделать. Ext4 живет до первого бэда под системным файлом. А потом ему нечем крыть, система превращается в тыкву. Btrfs на таком может месяцами жонглировать теорвером, дав время на неспешное обнаружение и замену бяки. > Не смотрит, удивленно моргая, на пустую точку монтирования, при отсутствии каких либо > реальных предпосылок к этому. Конечно, он смотрит на unbootable операционку где бэд под системный файл попал. И fsck это не лечится, что он сделает? Данных для починки нет! Чего btrfs с dup сделает - я понимаю, из второй копии достанет, вот там данные для починки есть. Даже на 1 носителе. >> Чего? Нельзя ли развить эту мысль? > Нишмагла она. Чего нишмалга - мне лень было выяснять, там было использование > btrfs по прямому ее назначению - для данных, которые в случае чего можно быстро > восстановить, а управление не на уровне fdisk 1984 полезно. Дык там офлайн чтец прямо в btrfs, есть на случай когда оно не смонтировалось. Он к тому же исходный стораж не портит. А, ну да, это ж маны читать надо и мозг включать, к тому же гамноэтотвашпингвин!!111, да? %) > тогда не надо к ним аппелировать, говоря о васян-ноуте. На васян-ноутах btrfs неплохо способствует надежности этой штуки. Как оно на десятках терабайтов я сам в курсе, на сотнях, а может и единицах петабайт, фэйсбук проверил. А так чем экзотичнее и не массовее конфиг тем он обречен быть забагованнее, что бы там энтерпрайз пижоны не блеяли. > какая васян-ноуту польза от снапшотов, кстати? Да простая - если систему разъе...л экспериментом или апдейт криво сработал можно за пару минут вернуть все взад, как на виртуалке. В хучшем случае конечно может флеха загрузочная пригодиться, но это радикально быстрее полного реинсталла или раскатки полного бэкапа. > про thin lvm ла..й эксперт не понял, поскольку не в курсе, угу. Вся эта редхатовская камасутра и близко не стояла с btrfs'овским подходом. Но пох этого не понял, потому что никогда не пробовал просто добавить диск или просто вынуть его. Одной тривиальной командой цуко. Одной, Карл! С минимумом места для лажи, move away данных с накопителя, авторесайзом и прочим. Где там у тебя в твоем XFS такой хайтек? В стремной пыхтонрасии сратиса? Удачи тебе с ним. >> Хочу посмотерть как обладатели петабайтов будут конвертить "старый" формат в новый. > На ноутбуке, угу. На чем угодно. Неконвертабельная ФС старого формата - геморрой, требующий мануальной терапии. > ведро лиnoopsя. потому что xfs так обрабатывает ошибки. Оно что, кернел паник делает? А readonly filesystem оно не умеет как более нормальные? Я его благодаря такой политике редхата выпилил везде, сорь. Если один черт заново пересоздавать я и создал там btrfs. Там и cow нормальный сразу и чексумы есть и рулить этим приятнее сратисов и lvmов в 20 раз. > После краха она не монтируется, тебе уже несколько разных человек сообщили эту радостную новость. Учитывая что я это целеноправленно пытался воссоздать - у меня есть некий скепсис относительно того что они делали, в какой конфигурации, и вообще кто там виноват. Пока эта парочка assclown'ов даже в описание конфиги и сообщения системы не смогли. Так что достоверность этих сведений находится на уровне бабушкиных сказок. А вот то что XFS файлы до сих пор нулями оказывается тереть умеет я видел. Правда теперь он не обрубает файлы, это в хвост дописывается, с align размера файла до блока. Некоторый софт от такого подарка умудряется одуреть, именно так я о нем и узнал. > А я вот нежданно познал дзен, что может не монтироваться без всякого > краха, после штатного ребута - и хз почему. Это конечно ого описание проблемы, без конфига и сообщений. > Ну не хочется ей, вот. Так не бывает. Бывает хреновый сбор диагностики. Это вообще 1 дисковое? Многодисковое? Вручную маунт что делает? Код возврата сискола хотя-бы у мегаэксперта есть? Или о чем мы тут разговариваем? Что одна бабка что-то сказала? > ну надо же. А мы-то с ext3 в 2005м году тоже так > думали. И да, она это может. Она совсем другое нишмагла. Она это может, только в автопилотных системах никому не надо. Потому что там некому интерактивно рулить fsck и делать damage assessment за ним. Да и васяну на ноуте не очень удобно что от одного бэда система разится наповал. > про петабайты это ты понес пургу. У меня нет и не предвидится > никаких петабайт на настолько гнилом софте. Я бы сказал что петабайтные сторажи намекают на гнилость архитектуры. И собственно настолько упоротых немного, поэтому фэйсбук и был один из немногих кто файло более 20 Тб тестил. > У меня таких точно нет. Понятия не имею, что это за котик им такой попался и в своем ли они уме. Скорее какая-нибудь аналитика котиков КМК. > У меня обычные файлы обычного размера. При этом общие объемы некоторых хранилищ > - пара сотен тер. Но те под виндой, на энтерпрайзной fcшной > немодной схд, некоторым уже по восемь лет, и за эти годы > с ними ничего не сделалось - вероятнее всего, и не сделается. Ну, блин, а у кого-то и майнфреймы есть. Некоторые даже пытаются умничать про амеровских военных, при том что сами их даже на картинке не видели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238 Ответы: #268

268. Сообщение от пох. (?), 14-Янв-21, 02:10	+/–
>> Ну допиши недостающий код. > Дописать что? Куда? ZFS мне например не упал в том числе потому да не звизди, ты никакой не умеешь. Поэтому выбираешь что пейсбук подаст. > е...ся, ему логично с ноля переархитектить. С учетом современных тенденций. жаль что ты ничего такого не умеешь. > пока ты год @#$лся, другие 2 года назад накодили впятеро лучше. А потом оно херит твои данные. Накодили, угу. > А кто б этого человека знает, что за конфига, что за ворклоад, а тебе зачем? Ты камлай, камлай. >> Рассказывали и про 128, но там - рассказывали, а тут - меряли и описали процедуру. > Так где описание? там, где-то в интернете. А у тебя - ничего кроме заклинаний. > Зачем мне камлания? У меня статистика smart для оценки общего перфоманса и охереть. Ему про write amplification - он про статистику смарт. Ну ок, видимо все фанатики btrfs такие же, или еще хуже. > У любой технологии есть свои сильные и слабые стороны, которые к тому опять шаманские завывания. >> да, да, все неправильно. вот у тебя-то все правильно, только мерять не >> вздумай (впрочем, ты не умеешь) > Нет, я просто давно усвоил что пох эксперт в поиске максимально дурацких и опять. Не умеешь, вместо этого переходишь на хамство. Ну ок. > При попадании на любую используемую данными/метаданными область undefined. Не додумает додумает, там где есть из чего. Где не из чего - часть данных потеряет, или метаданных, а данные потом в lost+found найдутся. Так и жили, а ты думал? > же она отсутствующее? А бэдсекторы и сейчас не экзотика. Емкие накопители я ни одного не вижу. что я делаю не так? В 95м году - да, бывало. Даже и работали потом такие диски довольно долго. Сейчас достаточно grown defect list >0 чтобы диск сразу превентивно в помойку. Он точно навернется, только вот не факт что не повесив все целиком. >> Нечего проверять, диск виснет при попытке прочитать набор экстентов. И? > Если данные надо было, отдай спецам по data recovery, они знают чего Ну то есть ты что делать не знаешь - найди там, незнаю сям, спецов по хз чему. >> Но вопрос был про fsck. Она вообще не для того, но ла..ые фанаты этого не вкуривают. > Fsck на автопилотных системах вообще источник проблем нежели решение. Автопилотные системы, очередная шаманская мантра. > видите ли, вообще не должны живых людей требовать для майнтенанса и > интерактива. В этом плане у btrfs таки плюс есть. А с и в этом тоже нет. Ненужных знаний от этих людей - таки да, в разы больше потребует. Хотя бы чтоб быстро определить - стоит тут трахаться, или reboot,reinstall. Впрочем, учитывая что она пропихивается пейсбуком и присными, они эту проблему давно уже решили в корне - в пользу reinstall. Ваши котики были очень неважны для нас. >> Не смотрит, удивленно моргая, на пустую точку монтирования, при отсутствии каких либо >> реальных предпосылок к этому. > Конечно, он смотрит на unbootable операционку где бэд под системный файл попал. у меня никаких бэдов ни под что не попало. И операционка загрузилась - благодаря тому, что там обычная ext4. А вот раздел с данными не монтируется. А ты мне про метафизику. > И fsck это не лечится, что он сделает? Данных для починки В идеале - пометит битый блок и скажет тебе в какой файл попал - перезальешь с бэкапа или дистрибутива. К сожалению, это тоже магия древних, такому разучились лет десять уже назад окончательно (впрочем, и тех дисков тоже нет давно). > нет! Чего btrfs с dup сделает - я понимаю, из второй а без dup что делает? Крэшнется,надеюсь, красиво? > копии достанет, вот там данные для починки есть. Даже на 1 > носителе. а место для них взялось из воздуха. >> Нишмагла она. Чего нишмалга - мне лень было выяснять, там было использование >> btrfs по прямому ее назначению - для данных, которые в случае чего можно быстро >> восстановить, а управление не на уровне fdisk 1984 полезно. > Дык там офлайн чтец прямо в btrfs, есть на случай когда оно И зачем мне он нужен? Мне смонтированный раздел нужен. Наиболее быстрый способ - снести к чертям и создать заново. > не смонтировалось. Он к тому же исходный стораж не портит. А, спасибо, у меня нет никакого неисходного. > ну да, это ж маны читать надо и мозг включать, к и вообще потерять кучу времени на чужие баги. Оно мне надо? > На васян-ноутах btrfs неплохо способствует надежности этой штуки. Как оно на десятках ценой потери 2/3 диска? Ну ок, богатый васян, имеет свои причуды. > терабайтов я сам в курсе, на сотнях, а может и единицах > петабайт, фэйсбук проверил. А так чем экзотичнее и не массовее конфиг > тем он обречен быть забагованнее, что бы там энтерпрайз пижоны не Нет. Чем ближе к нему прикованный разработчик, тем спокойнее жизнь. А конфигурация вполне может существовать в единственном экземпляре вообще. У пейсбука есть, у синологии тоже есть. У меня нет. Поэтому пользоваться софтом такого трэш-качества я, пожалуй, подожду. Ну как минимум до поры пока моя конфигурация не станет такой же как у пейсбука. >> какая васян-ноуту польза от снапшотов, кстати? > Да простая - если систему разъе...л экспериментом или апдейт криво сработал можно > за пару минут вернуть все взад, как на виртуалке. В хучшем включая проделанную работу? Спасибо, спасибо. > случае конечно может флеха загрузочная пригодиться, но это радикально быстрее полного > реинсталла или раскатки полного бэкапа. радикально быстрее - таки откатить апдейт единичной софтины, которая поломалась, или починить систему. Что, обычно, и делаем. Ну да, ну да - я-то умею, а васяну выбирать не из чего. Стоп - так я ли целевая аудитория? >> про thin lvm ла..й эксперт не понял, поскольку не в курсе, угу. > Вся эта редхатовская камасутра и близко не стояла с btrfs'овским подходом. Но угу, не стояла, поскольку ее вообще-то продают за деньги, а не пользует один пейсбук в странной позе. > пох этого не понял, потому что никогда не пробовал просто добавить > диск или просто вынуть его. Одной тривиальной командой цуко. Одной, Карл! Мне обычно не нужно ни то, ни другое. > и прочим. Где там у тебя в твоем XFS такой хайтек? зачем мне такой трэш? Я еще могу себе, чисто теоретически, представить ситуацию с zfs, где диск добавляется вместе с другими, в виде vdev, вместо того чтоб добавить просто новый пул, и не класть все яйца в одну корзину. Если бы твоя чудо-fs нормально работала в raid6, от этого еще мог бы быть какой толк, добавить восьмой или девятый диск в 5+2 не очень страшно. Но опять же - бедным и жадным. Те кому дороги данные, добавили бы raid. Отдельный. Добавить, естественно, можно. pvcreate, vgextend > На чем угодно. Неконвертабельная ФС старого формата - геморрой, требующий мануальной терапии. с чем любителей этого дела и поздравляем. У вас там, оказывается, с чексаммами - именно такой? >> ведро лиnoopsя. потому что xfs так обрабатывает ошибки. > Оно что, кернел паник делает? А readonly filesystem оно не умеет как угу. Может и умеет, в других случаях, но я пока не видал. Собственно, а зачем мне readonly filesystem на полном ходу? Это авария сервера, которую придется вручную разбирать и чинить, спасибо если не в пять утра. А после перезагрузки - может и работать, некоторое время. > Учитывая что я это целеноправленно пытался воссоздать - у меня есть некий вероятно это вопрос к твоей квалификации, которой ты так усиленно гордишься. Зазубрить писят ключей- это немного не то, что тут требуется. > скепсис относительно того что они делали, в какой конфигурации, и вообще > кто там виноват. А мне это интересно? > и сообщения системы не смогли. Так что достоверность > этих сведений находится на уровне бабушкиных сказок. А вот то что XFS Для тебя - возможно, пока наконец не доиграешься. А для меня - реальность. И мне дальше разбираться просто неинтересо, какие мантры и камлания ты тут ни устраивай. >> А я вот нежданно познал дзен, что может не монтироваться без всякого >> краха, после штатного ребута - и хз почему. > Это конечно ого описание проблемы, без конфига и сообщений. Каких еще сообщений? Зачем тебе мой конфиг? Оно не монтируется. Молча. Все - больше ничего про такую чудо-технологию знать незачем. > Так не бывает. Бывает хреновый сбор диагностики. Это вообще 1 дисковое? Многодисковое? почему ее нет тут же в сообщениях в консоли/dmesg? Все, приехали. Какая разница сколько там дисков (0-дисковое, это fc) после такого захода? > Вручную маунт что делает? Код возврата сискола хотя-бы у мегаэксперта есть? Лолшта? Мне еще "код возврата сискола" из mount добывать?! (но, полагаю, таки 0 - иначе бы сам mount выдал хотя бы бессмысленную ошибку) > Или о чем мы тут разговариваем? Что одна бабка что-то сказала? О том что лично я - как и многие другие, получил вполне убедительное доказательство полной непригодности технологии. Это даже не сырость, это просто принципиальная жопорукость разработчика. >> ну надо же. А мы-то с ext3 в 2005м году тоже так >> думали. И да, она это может. Она совсем другое нишмагла. > Она это может, только в автопилотных системах никому не надо. Потому что Это для них и делалось. Не потому что кому-то надо было "интерактивно fsck" и прочую чушь, конечно. Бэды к тому времени ушли в область мифологии, где и остаются по сей день. Но ты явно опоздал родиться. > Я бы сказал что петабайтные сторажи намекают на гнилость архитектуры. И собственно Нет, они намекают что кому-то есть что там хранить. Фейсбуку, я уверен, есть. А вот одиночный файл в 20tb - действительно намекает, да. > Скорее какая-нибудь аналитика котиков КМК. видимо, в чем-то настолько прекрасном, что не умеет ни partitioning, ни кластеры, ну или умеет но ниасилили, или это и был partition, остальные n*20tb лежали где-то еще. > Ну, блин, а у кого-то и майнфреймы есть. Некоторые даже пытаются умничать для них специалистов нет. Поэтому даже оценить степень пригодности для современных задач - некому (мантры и камлания не в счет). С корпоративными схд ситуация получше. Но они немодные, немолодежные, и будут повсюду заменяться sds и кластерами из дерьма и палок. С кластерными решениями все даже хуже, чем с мэйнфреймами - вместо специалистов - "специалисты", зато тыщи их. Очень самоувереные и нихрена не понимающие в том, что творят. Сегодня прослушал вебинарчик, поблевал. Впрочем, этого https://www.opennet.me/tips/3083_ceph_cluster_replication.shtml похоже вообще убили и съели? (Поделом.) > про амеровских военных, при том что сами их даже на картинке > не видели. Я видел, х-ле толку. Зачем мне знать как разбирается М4? Про задержки я и так знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #298

269. Сообщение от Аноним (269), 14-Янв-21, 20:34	+/–
> к сожалению, только уже с китайской фабрики. Совершенно не обязательно, особенно для мелочи типа uSD. Навалом более мелких > А не совсем 100% китайские идут теперь в exfat. При том в основном потому что хотелось роялти за нестандартный gauge, а вовсе не то что вы подумали. Остальное было предлогом. > MS нормальная лавка (была, по крайней мере), Была. В 90-е лохматые. Которым exfat и соответствует как технология. > она позаботилась переделать поезда с конной тяги хотя бы на пар, > когда лошадки перестали справляться с весом состава. Вообще, поезда прекрасно ездили, но поразвелось производителей локомотивов и вагонов, а отчисления платить фиг: патенты или стухли или гады придумали как без патентов ездить. А так то оно куда больше 32 гиг может. > А, ну да, ну да, сасунг о вас позаботился, и его комит > даже приняли, поворчав для порядку. Самсунг посмотрел на кривые паровые машины да и сделал тепловоз и электровоз - F2FS. Правда, по первости хлипковаты оказались, технология не отлажена. Но производитель паровых машин уже прикинул перспективы, стал сговорчивее, тем более что тепловозы отлично рассекают по его рельсам, за которые к тому же платят охотнее чем за патенты. Да и паровозы куда логичнее перепахали, дважды. Теперь они разве что летать еще не умеют, но это до них просто Док еще не добрался. > Правда, только в ядрах 5.99, в которые еще много нужных и полезных > уничтожающих данные комитов приняли, но у л...х ведь нет ценных данных. Конечно, конечно, все ценные данные только у б333-щих маздайцев :) > Фоточки - сбегают переснимут. Да их как раз неплохо вытаскивают. А вот твою базу на 100500 гигов которой убернадежность надо - вот не факт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222 Ответы: #270

270. Сообщение от пох. (?), 14-Янв-21, 22:53	+/–
> Совершенно не обязательно, особенно для мелочи типа uSD. Навалом более мелких знатока вижу я. Вот все эти более мелкие - они уже совсем-пресовсем китайские-прекитайские, и других - днем с огнем не сыскать. Говорю как человек, вынужденно купивший их сотню - потому что очень, очень чуйка подсказывает, что скоро это станет либо очень дорого, либо совсем хреново, а скорее и то и другое, как было с предыдущими поколениями носителей. Из той сотни десяток таки оказался весьма странных. Рассовал по гуанокластеру, для фото-видео они стремные. > При том в основном потому что хотелось роялти за нестандартный gauge Ой, ну конечно же, во всем виновата корпорация зла. Правда, до того как ей что-то там захотелось, крупные (usb) флэшки приходилось форматировать в ntfs (в смысле, фабрике, они такими приезжали). > Была. В 90-е лохматые. Которым exfat и соответствует как технология. вообще-то она помоложе будет. И соответствует, вполне себе - весь мир пользуется, кроме пары больных на голову. > Самсунг посмотрел на кривые паровые машины да и сделал тепловоз и электровоз - F2FS. ОНО он сделал. В лучших традициях мистера Гаррисона. Причем ОНО никогда не предназначалось для сменных носителей, поскольку эффективно только в одном-единственном случае - когда ты точно знаешь внутреннее устройство. То есть ты самсунг и используешь флэш самсунг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269

271. Сообщение от Аноним (271), 15-Янв-21, 19:37	+/–
> Может, к корявому софту, может к кривому железу, может к неэффективности самой > фс под задачу. А может кто-то и big_writes включить забыл (но это надо еще суметь). Вот буду еще железо и задачи под всякий шит из 90х подбирать! Ты в своем уме? Почему-то замена на фс в ядре немедленно разгоняет все, иногда - в разы. > Тут некоторые, не будем показывать пальцем, граждане - ceph используют для своей > массовой  виртуализации. И, похоже, не считают что переплачивают за процессорные > мощности, хотя контора ни разу не благотворительное заведение. Наверное, просто не > знают, что у них есть прекрасный, параллельный, in-kernel nfs. Или знают ;-) Вебмакаки вообще на питоне програмят. Потом раза по три переписывают, если вдруг этот кусок крапа еще и взлетает каким-то чудом. И чего? > Повторяю: я, в отличие от некоторых - _тестировал_. Причем на железе, которое > сейчас даже в телефоны стесняются ставить. Я тоже тестировал, на довольно разном железе, от роутеров до десктопа который и сейчас недурно смотрится на фоне многих других железок. И после этого последние тома ntfs'а и были поперты цаными тряпками. > Разница (для моей задачи, это ни разу не usb2 флэшка в твоем > мипсе, где я и искал бы корни проблем) - на уровне с трудом различимом приборами. На мипсе с флешкой замена этого недоразумения на EXT* почему-то здорово разгоняет все. И вот как-то корень проблемы на EXT* не распостраняется. Черт, да там даже btrfs шевелится, и этот взамен оверхеда хотя-бы имеет что предложить. Ну там несколько накопителей по разным usb, например, так даже быстрее :D > С которой я ковыряюсь отдельно, и пока тоже что-то щастья не обнаружил > (в смысле не нашел конфигурации, способной что-то отдавать с такой скоростью, > чтобы вообще заметить разницу - и это в целом неудивительно, У тебя видимо напрочь отбитое файлопомойками и мегаэнтерпрайзом мышление, когда переросточный проц, все io-limited, задач нет (файлопомойка же), сервируем 1 терабайтный файл - и там конечно любая фигня работает примерно одинаково, со скоростью io. Но таким тестам грош цена в базарный день, они свойства железа тестируют, проскипав нюансы софта. > чушь. Вероятно - лучше всего путем установки ядра версии 3.0.последней или > рядом что-то. Поскольку оно по настоящему не выключается. > Но это актуально только для amd64 архитектуры. Я в принципе не собираюсь использовать ядра подобных версий. Даже на роутерах, не говоря уж про воркстэйшн и ноуты. А ты в своем праве пользоваться хоть win95! Да, кстати, как там твои файлопомойки на нтфс поживают? А то последние пару месяцев маздаю решительно везет на приколы с именно нтфс. То диски рушит fsck (у Рейзера научились?), то вон рядом непривилигерованый юзер систему может урыть - https://habr.com/ru/news/t/537328/ и вокруг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #272

272. Сообщение от пох. (?), 15-Янв-21, 20:09	+/–
> У тебя видимо напрочь отбитое файлопомойками и мегаэнтерпрайзом мышление у тебя его похоже нет вообще, так что даже с пониманием печатного текста проблемы. Я уже несколько раз повторил, на какой херне я тестировал. > Но таким тестам грош цена в базарный день, они свойства железа тестируют, проскипав нюансы > софта. они тестируют то, что нужно было мне. Никаких причудливых ньюансов у используемого мной софта нет. Потестировали, убедились, что возня с ручным бэкпортированием in-kernel модуля не стоит сэкономленных пяти процентов производительности и полупроцента загрузки единственного ядра из восьми. Наверное, если бы я не в основном читал громадные файлы, а писал миллион файлов по килобайту параллельно - разница бы была более существенной. Но у меня нет такой задачи, негде взять миллион. > Я в принципе не собираюсь использовать ядра подобных версий. Недостаточно теплое, не липнет? Ну, оок. Каковы принципы, таков и инженер. > Да, кстати, как там твои файлопомойки на нтфс поживают? хорошо поживают. Только опять надо новые 18 терабайт заводить, старые сожраты. > А то последние пару месяцев маздаю решительно везет на приколы с именно нтфс. ты б-жественную десяточку home от серверных версий тоже отличать не умеешь? Эксперт по ntfs. Да и a) не рушит, чинит - только запустить его немного сложно после неудачного обновления - я запущу, не ссы b) "самое ценное - в комментах". Там вообще ничего не повреждается кроме мнения винды о том что диск нуждается в срочной проверке. Ну и пусть его при себе держит. Ну и отдельный привет - хранилки не апгрейдят. Ни виндовые, ни линуксные, ни bsdшные. Только если уж совсем край.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271 Ответы: #279

273. Сообщение от пох. (?), 15-Янв-21, 20:12	+/–
> У меня внезапно нет проблем с ZFS. > Нет ZFS - нет проблем. Ну так тогда и не рассказывай сказок, о том как эти проблемы выглядят. Они есть, да. У чего угодно они есть. Но у тебя нет ни знаний, ни понимания вопроса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #276

274. Сообщение от пох. (?), 15-Янв-21, 20:15	+/–
> убожество, а кто finally got it right. Разве не киздато когда > на ходу и добавить, и изъять, и даже схему RAID переиграть? > :) киздато - когда этот рейд вдруг на ходу превращается в нечитаемую и невосстанавливаемую кашу, причем непонятно, почему - схему на ходу никто не менял, а оно - вот. На этом фоне остальные достижения, извини уж, не имеют ни малейшего смысла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #260 Ответы: #286

275. Сообщение от пох. (?), 15-Янв-21, 20:23	+/–
>> Продакшон на лимоны IOPS. Резко всё стало идеально с ZoL 0.8.3/Ubuntu_20.04. Всё >> что раньше - теряло read-range locks, стопорило процессы в D-State. > Пох, залогинься, у тебя ус отклеился :) Не, я бы зассал такое использовать. Я ж комит-логи этой 8 видел. Поставил бы фрю бородатого до-abdшного релиза, накатил бы пару левых патчей, и спал спокойно. Впрочем, у чувака, похоже, ни особо ценных данных нет, ни проблем с сдохшей нодой - reboot,reinstall. Иначе вряд ли бы он рисковал экспериментировать с недоделанными релизами что fs, что убунты. А раз так, то почему бы и нет... решение-то он на халяву получил, просто apt upgrade
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

276. Сообщение от Онаним (?), 15-Янв-21, 20:37	+/–
Позволю себе добавить: к счастью, нет. И без ZFS граблей достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273

277. Сообщение от Онаним (?), 15-Янв-21, 20:37	+/–
Зато заменяет на гниение мозгов. Любой RAID с чётностью точно так же решает проблему гниения битов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #287, #296

278. Сообщение от Онаним (?), 15-Янв-21, 20:39	+/–
RAID с чётностью внезапно тебе вообще ничего не скажет. Просто пофиксит кодом коррекции, и всё. Узнаешь в логах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

279. Сообщение от Аноним (279), 16-Янв-21, 05:34	+/–
> у тебя его похоже нет вообще, так что даже с пониманием печатного текста проблемы. Ну, раз я еще не помер с голода, наверное какое-то все же есть. > Я уже несколько раз повторил, на какой херне я тестировал. Урл? > они тестируют то, что нужно было мне. Никаких причудливых ньюансов у используемого мной софта нет. У тебя переклин на энтерпрайзных файлопомойках, с потерей понимания что у людей бывают другие задачи. > сэкономленных пяти процентов производительности и полупроцента загрузки единственного ядра из восьми. Это про ZFS? Или что вы там *бэкпортируете* из *кернела*? > Но у меня нет такой задачи, негде взять миллион. Зато меня вот например интересует такая банальщина как скорость раскатки на фс Linux Kernel. И не только на мега конфигах но и на десктопе и ноуте. Миллиона там правда нет, но 75К - пожалуйста. >> Я в принципе не собираюсь использовать ядра подобных версий. > Недостаточно теплое, не липнет? Ну, оок. 1) Я еще и юзаю некоторые фичи оттуда, от btrfs до wireguard'а. Просто потому что люблю безгеморные технологии. 2) Некоторое мое железо требует более свежих ядер. Например amdgpu. 3) Этот антик врядли сильно секурный, а юзать софт с пачкой known vuln мне "религия не позволяет" 4) Я нахожу девов из mainline конструктивными и приятными в взаимодействии. Они помогут мне замахать любую фигню на которую я наступлю. Но 3.х их уже давно не интересует. > Каковы принципы, таков и инженер. Однозначно. Я не арч-некромансер. И принципиально вбивать датчики кверхногами, даже если туго идет я не буду. Облом, да? > хорошо поживают. Только опять надо новые 18 терабайт заводить, старые сожраты. Да удачи. В btrfs такое просто. Доткнул винч(и) и вот тебе +n места. И да, я надеюсь твои сказки про не маунтится не были про 3.что-то? :) > ты б-жественную десяточку home от серверных версий тоже отличать не умеешь? Эксперт по ntfs. Дык там кернель поди один и тот же. Во всяком случае в 2003/2008 проблемы были 1 в 1 с домашними версиями. Делать Принципиально Иной кернел с принципиально другим ntfs.sys видите ли всем сильно впадлу. А что, индусы к десятке таки стали неленивые? > Да и a) не рушит, чинит - только запустить его немного сложно > после неудачного обновления - я запущу, не ссы Не обязано быть сложно. Скадем если btrfs progs в initrd есть, убить все настолько чтобы даже он не работал - ну даже не знаю, ты наверное и так сможешь, конечно. > b) "самое ценное - в комментах". Там вообще ничего не повреждается кроме > мнения винды о том что диск нуждается в срочной проверке. А также иногда слетает MFT, сообщение про проблему по кольцу при каждом ребуте и вообще нельзя загрузиться и тому подобные приколы. Там старичку фиксов штуки три досталось, один другого стебнее. > Ну и отдельный привет - хранилки не апгрейдят. Ни виндовые, ни линуксные, ни bsdшные. Да оно круто как бы, но мир на хранилках не заканчивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #291

280. Сообщение от Аноним (280), 16-Янв-21, 06:53	+/–
> Вот как раз на CoW будет задница хоть с преаллокацией, хоть без. Откуда? В идеале оба оформляют 1 экстент и метаданные указывающие на него. > На обычной FS можно ещё как-то уйти от этой задницы преаллокацией. А чем обычная FS и CoW в этом аспекте отличаются? В упомянутой ситуации они могут сделать примерно одно и то же, лишь бы регион более-менее непрерывного свободного места был. И если мы об этом, у btrfs есть какой никакой дефраг. У ext4 тоже в принципе есть, с неких пор. А у zfs ... ну тут был iZEN. И известен он тем что офигенный 3-дисковый пул собрал. С аж 18 мегами в секунду на чтение. Странно что нам в этом не нравится, да? Даже учитыая ноутбучность его винчей. И таки нет, вот на zfs он походу ничего с фрагментацией своими торентами уже не сделает, это да, только разобрать к хренам и заново пересобрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #290

281. Сообщение от Аноним (-), 16-Янв-21, 07:07	+/–
> BTRFS которая как 5 лет считается устоявшимся формат (кроме раид )-до сих пор пилеться. Если софт вообще совсем не пилится - он, очевидно, сдох. > metadata uuid - new feature that allows fast uuid change without rewriting > all metadata blocks (backward incompatible) .18-19 год : Это иллюстрация по теме "смотрю в книгу, вижу фигу"? Это фича для быстрой смены UUID фс, если ждать перемаркирования всех экстентов новым UUID западло (на большом стораже это может занять порядком времени). И да, старые кернелы сие не поймут - потому что не было им известно. Но это довольно мелкое изменение правил игры, без изменений формата как такового. Просто старые ядра посчитают ситуацию невалидной, они не знали что так можно было. Для начала UUID фс вообще меняют ... скажем так, сильно некоторые люди, в специальных ситуациях. И это обычно интеграторы, системные инженеры и тому подобные, делающие образа VM или девайсов. Для смертного это деяние для начала чревато *немедленным UNBOOTABLE*, если вы не понимаете зачем это. Так что обычно это если и трогает кто, то они знают что и зачем делают. И RTFM наверное сделают. Во всяком случае для интегратора будет странно юзануть новый фич в FS tools но не зающать кернел ему под стать. >>сonvert and mkfs will try to use optimized crc32c use hw assisted crc32c on more arches > Это трекер за 18-19 год мне прислали ,ткнули.А сколько фишек помимо контрольной > суммы внедрили-до фига,т.к что не фига оказывается у бтрфс стабильный   > формат,до сих пор появляться ломающие совместимость обновления. Вы совсем упали с дуба? Это вообще не изменение формата ФС. Просто научили тулсы юзать хардварное ускорение счета CRC32 если оно в системе есть. Представляете себе, CRC32 можно самому в софте посчитать, а можно отдать вон той железке на вход данные, а на выход она CRC32 отгрузит. Это полностью прозрачно с точки зрения совместимости и всего лишь оптимизация скорости на железках которые так умеют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266 Ответы: #294

282. Сообщение от Аноним (-), 16-Янв-21, 07:11	+/–
> А данные с Божью благодатью записались с Сжатием нормально. Вот это без гарантий. Но - да, знаете, обычно SCRUB греет систему сильнее "обычных" ситуаций. Поэтому заодно он подрабатывает RAM/CPU test'ом. Получше "выделенных" ram test'ов. Хинт: попробуйте 10 раз большой ZIP распаковать. Желательно в /dev/null или типа того. Если CRC error иногда лезут - 100% оно, это железо прогревается и дурить начинает. > Ух ты,пойду тогда все железо освещать . Освещать? В прессе чтоли? :P > Вы не смотрели в монитор -что происходит при записи на многоядерной машинке-чтобы > избежать перегрева (по крайне мере так у АМД) задачи постоянно скачут > по ядрам.Остается память -ну не знаю,сомнительно. Я много во что смотрю. И вероятно в инструменты поинтереснее ваших порой. Однако кроме смотрения еще надо понимать что видишь. Мое понимание говорит мне что вон то похоже на нестабильное железо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #265 Ответы: #295

283. Сообщение от Аноним (-), 16-Янв-21, 07:19	+/–
>  методанных поменяли.Мне человек  ткнул в  чанлог за 18-19 > год- я тоже думал что формат стабилизирован.. А он и стабилизирован. Но не до состояния надгробия на кладбище, чтобы вообще ничего не улучшать и новые фичи не делать. >>сonvert and mkfs will try to use optimized crc32c use hw assisted crc32c on more arches Это оптимизация скорости. Как это на формат чего-либо влияет? То что модуль ФС и утилсы не будут считать crc32 сам а спихнет ее железку коли она так умеет - на формат данных на диске никак не влияет. > И ВИШЕНКА  (Mar 2019) > metadata uuid - new feature that allows fast uuid change without rewriting > all metadata blocks (backward incompatible) 1) Это не влияет на чтение старых бэкапов. Старое ядро обломается смонтировать ФС с неизвестной ему фичой, но не наоборот. Идея класть бэкап на фс с новой фичой и читать его старым ядром вообще достаточно интересная. Но лучше читать все же новым ядром, как по мне. Вообще с точки зрения багфиксов. 2) Ума не приложу зачем на диске с бэкапами менять UUID 3) И сие вообще трогать стоит только понимая зачем вы это делаете. На системном диске это ведет к немедленному unbootable зачастую. А потому что boot будет старый uuid искать. А его - опа - нету. И монтирование - аналогично. Т.е. это еще в 2 местах конфигурации надо синхронно патчить. Иначе вы получите интересный сюрприз. И наверное если вас туда занесло, вы RTFMнете. Иначе вас ждет много приколов...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #293

284. Сообщение от Аноним (-), 16-Янв-21, 07:21	+/–
> Это связано с тем что вынесли алгоритмы  контроля из драйвера бтрфс с целью унификации. Это не изменило формат ФС. Только внутреннее устройство модуля. В ядре Linux есть реюзабельные алгоритмы, в том числе с аппаратным ускорением если железо умеет. Ну вот этот модуль фс тоже обучили этими функциями пользоваться. Это никак не влияет на пользователей или устройство ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #292

285. Сообщение от Аноним (-), 16-Янв-21, 07:24	+/–
> Прекрасно, дай угадаю - но места указать ее явно в куче ненужного > мусора в метаданных - конечно же не нашлось. Как обычно - пох не угадал. Так что там еще blake2, sha256 и xxhash сделали. И да, старые кернелы и бутлоадеры ессно не знают как это считать. Впрочем половина бутлоадеров на чексумы тупо кладет. А вот с zstd я разок выкусил, когда grub мне и сказал - ухтыблин, а я не знаю чем распаковать твой kernel! Ну, пришлось и его заапдейтить, временно рекоспреснув kernel в более привычный ему zlib.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248

286. Сообщение от Аноним (-), 16-Янв-21, 08:00	+/–
> киздато - когда этот рейд вдруг на ходу превращается в нечитаемую и > невосстанавливаемую кашу, причем непонятно, почему - схему на ходу никто не > менял, а оно - вот. Это не похоже на btrfs. У него там block groups, он ими ворочает и конверсия одного в другое вот именно там не особо стремная процедура. Затрагивающая к тому же только реально занятое место и в отличие от классического RAID это и трекингу поддается, и смесь bg разных типов - абсолютно штатная ситуация. "Выбор схемы хранения" лишь указывает как новые данные/метаданные раскладывать - какой тип block group искать под них. > На этом фоне остальные достижения, извини уж, не имеют ни малейшего смысла. Не, ну если у тебя там твой тридевятый кернел там и не такое еще может быть, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274

287. Сообщение от Аноним (-), 16-Янв-21, 08:02	+/–
> Любой RAID с чётностью точно так же решает проблему гниения битов. Каким макаром? Ну вот допустим у нас 3 диска, D1, D2 и P1. Мы видим что D1^D1 != P1. Внимание, вопрос: кто из этих троих нам врет?! Если оно вообще совсем не читается, вопрос не возникает. Но если оно читается но не совпадает - тогда как?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277 Ответы: #288, #289

288. Сообщение от Аноним (-), 16-Янв-21, 08:05	+/–
Ну вот допустим у нас RAID5, 3 диска, D1, D2 и P1. Мы видим что D1^D2 != P1. Внимание, вопрос: кто из этих троих нам врет?! Если оно вообще совсем не читается, вопрос не возникает. Но если оно читается но не совпадает - тогда как? Аналогично с RAID1: если D1 != D2 - ок, и чего? А врет который из двух? Чексум данных дает ответ, мы по его несовпадению вычисляем врунишку. В случае RAID56 чексум для parity - лишний. Пардон, bugfix примера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287

289. Сообщение от Онаним (?), 16-Янв-21, 09:49	+/–
Если проблема на шине - просто читаем ещё раз. Прочитали второй раз - снова не совпало - третий - далее херачим ошибку. Всё ровно то же самое, что и у мистической "защиты" ZFS. А проблемы на диске такой быть не может. Потому, что у самих дисков есть ECC, и "не совпадает" в случае битрота на диске до RAID-контроллера (или софта) не дойдёт - будет "не читается". Это ответ на твой вопрос. Ниже пойдёт уже другое рассуждение. --- Даже если предположить, что ECC диска может допустить массовый (!!!) bitrot в очень редком ограниченном случае (а именно массовое искажение битов нужно, чтобы "пройти" ECC) - берём RAID6, это уже полноценный двухбитовый ECC код, у которого "не совпадает" не бывает. Тем более, что у RAID5 есть другая проблема - высокая вероятность отказа второго диска в момент восстановления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #297

290. Сообщение от Онаним (?), 16-Янв-21, 09:54	+/–
>> Вот как раз на CoW будет задница хоть с преаллокацией, хоть без. > Откуда? В идеале оба оформляют 1 экстент и метаданные указывающие на него. Вот только при рандомной записи в тот экстент CoW-based данные раскладывают, увы, не туда, где они должны быть, а просто так, линеечкой. Да, сама запись при этом даже быстрее будет - линейно же, прекрасно. А потом мы пытаемся это читать, и хр-хр-хр др-др-др головы бегают туда-сюда по 100500 раз. К сожалению, медицинский факт. У SSD этой проблемы нет, но SSD и CoW как собаке пятая нога, там свой левелинг внутри :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280

291. Сообщение от пох. (?), 16-Янв-21, 11:05	+/–
> Ну, раз я еще не помер с голода, наверное какое-то все же есть. Ты не поверишь, сколько совсем не помирает с голода, не умея толком прочитать написанное. Но мы тут не на совете инвесторов, тут это не ценится. Дальше - все вопросы ровно из неумения читать и пользоваться инструментом под рукой. Ищи, читай написанное, а не свои выдумки, еще раз перечитывай если не дошло с первой попытки. Извини, мне неинтересно. До встречи на совещании инвесторов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

292. Сообщение от maximnik0 (?), 17-Янв-21, 07:08	+/–
>Это никак не влияет на пользователей или устройство ФС. При условии -при переходе не запутались с ари,была проблема,пофиксили:-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284

293. Сообщение от maximnik0 (?), 17-Янв-21, 07:38	+/–
>Старое ядро обломается смонтировать ФС с неизвестной ему фичой, но не наоборот. Идея класть бэкап >на фс с новой фичой и читать его старым ядром вообще достаточно интересная. Но лучше читать все же >новым ядром, как по мне. Вообще с точки зрения багфиксов Читайте внимательно- диск лежал нетронутым 5 лет.Пытался на него кое что записать,скопировать старые бэкапы- обнаружил режим чтение,ядро ругаеться на чек-суммы и блоки ,типо ошибки.Проверил с другого архива-контрольные суммы и размер все в порядке,файлы проверил нормальные.Сам старый жесткий тоже в порядке,нормально записывает,ошибок нет-но починить фс мне не удалось,даже снес контрольные суммы,верификация 71-74 % и падает программа проверки.Проверил железо -2 часа тестов процессор и память ,по аварийке через 108 минут сработало отключение ноутбука из-за перегрева,но глюков не было.Не знаю что и думать -у меня еще 2 жестких с бэкапами  такого же возраста если не старше,но на них данные пополнялись,проблем нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #283

294. Сообщение от maximnik0 (?), 17-Янв-21, 07:46	+/–
> Это полностью прозрачно с точки зрения совместимости и всего > лишь оптимизация скорости на железках которые так умеют. Теоретически,умудряются и здесь глюки словить .Не помню в каком выпуске ядра при оптимизациях чтоб на аппаратном контролере просчитывать crc32 народ инверсионную ошибку допустил,поправили быстро ,но кое-кто влетел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281

295. Сообщение от maximnik0 (?), 17-Янв-21, 07:53	+/–
>Хинт: попробуйте 10 раз большой ZIP распаковать. Желательно в /dev/null или типа того. Если CRC >error иногда лезут - 100% оно, это железо прогревается и дурить начинает. Уже чем можно и нельзя протестировал,ошибок нет.Единственное срабатывает защита про перегреву приблизительно через 2 часа,отрубает ноутбук.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282

296. Сообщение от Аноньимъ (ok), 17-Янв-21, 13:18	+/–
Ну, несовсем. Если востановить неудалось вы получаете либо рассыпавшейся рейд, либо сами имеете свободу выяснять где и что у вас сгнило, таблица арзделов, метаданные, файл(и какой).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277

297. Сообщение от Аноньимъ (ok), 17-Янв-21, 13:22	+/–
1. ECC дисков может востановить неправильно. А может вообще не восстановить. 2. Данные могут быть записанны неправильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289

298. Сообщение от Аноньимъ (ok), 17-Янв-21, 13:28	+/–
Я честно как-то пытался научиться пользоваться бтрфсом, меня там отпугнула система собственно управления, писанная гуманоидами пришельцами из другимх миров. Они для всего на свете придумали какие-то свои странные названия и ритуалы (снапшоты разделы вот это всё) Так и не понял КАК этим управлять. В смысле кое что понял, но логики за этим неувидел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #299

299. Сообщение от пох. (?), 17-Янв-21, 13:38	+/–
> Я честно как-то пытался научиться пользоваться бтрфсом, меня там отпугнула система собственно > управления, писанная гуманоидами пришельцами из другимх миров. и это тоже да. Ручное подставление бессмысленных цифирок volid в команды монтирования чего только стоит. Или альтернатива вида "угадай, как правильно в этом месте надо написать путь от корня - где он, кстати?" Терминологию еще можно понять и простить - типа, защита от патентных исков, назло маме сделаю все не так как в zfs. Хотя, конечно, глупость все равно фееричная, хуавея с его нечеловеческими интерфейсами ни разу не спасло. Снапшотов в смысле zfs по факту просто не существует - снапшот у них не снимок состояния, отдельный от собственно данных, он, сразу после создания - просто subvolume, совершенно неотличимый от обычного, не являющегося снапшотом чего либо. Логика в этом есть, но она лично мне неудобная, мне удобнее иерархическая zfsа. И для бэкапов, с инкрементальным send, и для экспериментов, когда сразу понятно, кто кому предок-потомок. Меньше шансов запутаться, когда их сильно не один.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298

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

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