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

"В ветку ядра Linux-next добавлена реализация ФС Bcachefs"	+/–
Сообщение от opennews (??), 20-Сен-23, 08:36
В состав ветки linux-next, в которой тестируются возможности для будущих выпусков ядра Linux, принят код файловой системы  Bcachefs. Ранее, Кент Оверстрит (Kent Overstreet), автор Bcachefs и входящей в состав ядра Linux системы кэширования блочных устройств на SSD-накопителях BCache, отправил Линусу Торвальдсу   poll-запрос на включение кода Bcachefs в основной состав ядра Linux, но Линус отклонил их и рекомендовал вначале оценить пригодность предложенных патчей в экспериментальной ветке Linux-next. В случае успешного  рецензирования ФС Bcachefs может быть включена в состав ядра 6.7, выпуск которого ожидается в декабре... Подробнее: https://www.opennet.me/opennews/art.shtml?num=59785
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 20-Сен-23, 08:36	+9 +/–
И ext4 хватает за глаза
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #8, #12, #102, #231

2. Сообщение от Аноним (2), 20-Сен-23, 08:36	–1 +/–
Уровень XFS недостижим
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56, #99, #110

4. Сообщение от Голум (?), 20-Сен-23, 09:22	+18 +/–
Да и 640кб хватит всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #15

5. Сообщение от Аноним (5), 20-Сен-23, 09:26	+2 +/–
Так это же она — новейшая революционная единая файловая система для всего и вся, собравшая лучшие передовые решения своих предшественников!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

7. Сообщение от Аноним (7), 20-Сен-23, 09:44	–2 +/–
Сказал как старый коммунист. Молодой бы сказал на твоём месте - "серебрянная пуля".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9

8. Сообщение от Аноним (8), 20-Сен-23, 09:46	–2 +/–
Трактор не нужен, «газельки» хватает за глаза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #16

9. Сообщение от Анонизмус (?), 20-Сен-23, 09:50	+10 +/–
стеклянный, деревянный, оловянный серебряный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #18, #97, #98

10. Сообщение от Аноним (10), 20-Сен-23, 10:15	+/–
>Целью разработки Bcachefs является достижение уровня XFS в производительности, надёжности и масштабируемости Хороший ориентир, и цели хорошие ага, главное не забыть запилить фичу порчи файлов при отключения света.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #81

11. Сообщение от Аноним (11), 20-Сен-23, 10:27	+/–
> По производительности Bcachefs опережает Это при недостатке фич или пропорционально количеству граблей?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

12. Сообщение от InuYasha (??), 20-Сен-23, 10:27	–4 +/–
в ext4 за глаза не зватает снапшотов аки ntfs. Хотя, скоро можно будет и ntfs накатывать...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17, #30, #73, #103, #158

13. Сообщение от Аноним (11), 20-Сен-23, 10:27	+/–
А когда будет Ext5 уже где всё это из коробки?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #111

14. Сообщение от Аноним (11), 20-Сен-23, 10:28	+/–
> Btrfs и другие ФС на базе механизма Copy-on-Write А другие это какие? У ZFS RoW
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #72

15. Сообщение от Аноним (1), 20-Сен-23, 10:41	–10 +/–
Да? Тогда чего ж у тебя место и память везде исчисляется в гб?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #25

16. Сообщение от Аноним (1), 20-Сен-23, 10:42	–2 +/–
Глупый человек всегда не понимает, как, что и с чем сравнивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #43

17. Сообщение от Аноним (1), 20-Сен-23, 10:51	+2 +/–
Если б за глаза не хватало, тогда была бы необходимость. снапшоты нужны, но их реальная необходимость не столь велика, как вам кажется. из абсолютного большинства, большая часть сидит именно на ехт4, без снапшотов и без проблем. отсюда вывод, что либо у вас руки кривые, что вы каждые пол часа рушите систему и не понимаете, как вернуть взад, либо вы рушите данные, что говорит опять же о кривости рук. по крайней мере, если б вы мои данные чаще возвращали из снапшотов, а не безопасностью, я б не стал пользоваться вашими услугами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #19, #26, #35

18. Сообщение от Аноним (18), 20-Сен-23, 10:51	–1 +/–
Посеребренная
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #58, #60

19. Сообщение от Аноним (8), 20-Сен-23, 10:56	+6 +/–
> из абсолютного большинства, большая часть сидит именно на ехт4, без снапшотов и без проблем На десктопах абсолютное большинство сидит на винде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #53, #129

20. Сообщение от Аноним (8), 20-Сен-23, 10:56	+2 +/–
Вот только в ext это всё пихать не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #106

21. Сообщение от Аноним (21), 20-Сен-23, 11:10	+/–
>дополнительные возможности, свойственные Btrfs и ZFS, такие как включение в раздел нескольких устройств Опять велосипеды вместо того, чтобы использовать lvm2. Ну откуда они такие лезут то?!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #28, #82, #112

22. Сообщение от fumanchez (ok), 20-Сен-23, 11:17	+4 +/–
Ты из 2010?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #31, #62

23. Сообщение от Аноним (23), 20-Сен-23, 11:18	+/–
зачем лишняя прослойка, когда можно без лишней прослойки? башкой думай иногда
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29, #63, #94

24. Сообщение от fumanchez (ok), 20-Сен-23, 11:22	–1 +/–
Для меня лично теперь основной критерий выбора - поддержки сжатия на уровне фс. Запилить такую опцию не должно составлять труда, а ее отсутствие должно настораживать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #33, #34

25. Сообщение от Аноним (25), 20-Сен-23, 11:30	+16 +/–
Да? Тогда почему у тебя нет понимания что такое сарказм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #51

26. Сообщение от Аноним (25), 20-Сен-23, 11:43	+1 +/–
Тебе кто-то мозг разрушил. Миллионы мух это вообще не показатель.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #145

27. Сообщение от Аноним (8), 20-Сен-23, 11:46	+/–
NTFS, уже почти тридцать лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #37

28. Сообщение от _ (??), 20-Сен-23, 11:47	+/–
Ну если слаще морковки ничего и не пробовал … то можно и LVM2. Оно в принципе - рабочее, для простых сетапов - вполне себе хороший вариант. Но всё же попробуй какую нибудь ZFS, чтобы хотя бы понимать о чем тут взрослые дяденьки печалятся. Но поначалу будет … больно 😁
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #32, #95, #179

29. Сообщение от _ (??), 20-Сен-23, 11:52	+/–
Сходи к программерам - вот где прослоек … LVM - рабочая, но еЯ IBM ещё в 1980-е сделала… она постарше вас будет, ну а старую цирковую собачку обучить новым фокусам … 🤷♂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

30. Сообщение от пох. (?), 20-Сен-23, 11:53	–3 +/–
> Хотя, скоро можно будет и ntfs накатывать... нельзя. владелец кода занят обустройством личной жизни в Германии, ему не до бесплатного софта. Рабы прячутся от военкома и им тоже не до чего. Так что если ты ждал поддержку vss - тебе в винду. А... ну собственно, чего ждать-то...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #109

31. Сообщение от пох. (?), 20-Сен-23, 11:54	+9 +/–
нет, он гораздо ранешний попаданец - даже в 2010м уже умели фичу порчи файлов без всякого выключения света, что это еще за прошловековые фокусы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

32. Сообщение от пох. (?), 20-Сен-23, 11:55	+/–
по началу - как раз нет, все работает из коробки и сразу. Вот при продолжении наступаешь на интересные грабли - но у владельца локалхоста они могут так и не вылезти вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от пох. (?), 20-Сен-23, 11:56	+2 +/–
тооочна! При ширпотребных дисках по 20 терабайт и nvme модулях работающих уже почти на скорости оперативки - сжатие на уровне фс это вот супернеобходимейшая фича.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #36, #132

34. Сообщение от _ (??), 20-Сен-23, 11:56	–1 +/–
А ты в курсе что ход дисков менее 100 гиг больше даже не продаётся? Зойчем сжимать на уровне файлов , а не FS - вообще за гранью понимания…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

35. Сообщение от keydon (ok), 20-Сен-23, 12:06	+3 +/–
> из абсолютного большинства, большая часть сидит именно на ехт4, без снапшотов и без проблем. А вот и демократия подъехала. Большинство людей не пользовались туалетной бумагой до ее изобретения. Судя по большинству самая лучшая и безопасная система это андройд. > по крайней мере, если б вы мои данные чаще возвращали из снапшотов, а не безопасностью, я б не стал пользоваться вашими услугами Хотелось бы посмотреть как "безопасность" возвращает удаленные данные полугодовой давности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #52, #54

36. Сообщение от Аноним (36), 20-Сен-23, 12:08	+2 +/–
> nvme модулях работающих уже почти на скорости оперативки Разница в пропускной способности на порядок, в лучшем случае (это если PCIe 5.0 и средний DDR5 сравнивать; если более дешманский PCIe 3.0 или 4.0, то всё еще печальнее). Разница в задержке на несколько порядков. А учитывая стоимость этих самых NVMe, особенно больших объемов, сжатие, внезапно, начинает казаться не такой плохой идеей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #65

37. Сообщение от Ананий (?), 20-Сен-23, 12:23	+/–
лол было бы чем гордиться, сжатие работает лишь для кластеров <=4к ну и бонусом идет фрагментация
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #40

40. Сообщение от Аноним (8), 20-Сен-23, 12:41	+/–
Даже не вспомню, когда я видел NTFS с размером кластера, отличным от 4К.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #41

41. Сообщение от Ананий (?), 20-Сен-23, 12:52	–1 +/–
На диске С: (кстати когда уже этот анохронизм сподобятся убрать? или так и будем жить як в 90х, с дисководами на 360к от роботрона) по умолчанию да. На всем остальном в 202Х делать такой размер смысла мало. Или ты прон блюреи на 50Г тоже хранишь с кластером на 4к? Или баттлфилды на 100Г? Ну удачи, че.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #42, #64

42. Сообщение от Аноним (8), 20-Сен-23, 13:01	+2 +/–
Давай посмотрим на вопрос под другим углом: много ли кто при создании NTFS-раздела выбирает размер кластера, отличный от умолчального 4К? > Или ты прон блюреи на 50Г тоже хранишь с кластером на 4к? Или баттлфилды на 100Г? Ну удачи, че. А что страшного в данном случае происходит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #45, #46

43. Сообщение от Аноним (43), 20-Сен-23, 13:05	+3 +/–
Нет, глупый человек всегда обо всём судит категорично и исходит только из своих потребностей и потом говорит за всех.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

44. Сообщение от Аноним (44), 20-Сен-23, 13:06	+1 +/–
Как я понимаю при меньшем количестве факапов и проблем и лицензиями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #105

45. Сообщение от пох. (?), 20-Сен-23, 13:22	+/–
Многие - те самые владельцы современных дисков по 20 тер (c 4 лимит 16, но устанешь ждать пока оно проверяется). Но им, конечно же, очень актуально пофайловое сжатие. (нет) > А что страшного в данном случае происходит? не получается включить сжатие для несжимаемого файла, бида, пичаль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #47

46. Сообщение от Ананий (?), 20-Сен-23, 13:25	+/–
Меньше скорость чтения/записи, особенно для нжмд, разрастание двух MFT Впрочем о чем тут говорить, все вокруг идиоты, придумывают разные размеры экстентов и recordsize для зфс, но раз аноним за всех порешал, значит не нужно. Все сидим на 4к и не жужим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #48

47. Сообщение от Ананий (?), 20-Сен-23, 13:27	+/–
ну так еще и не зашифровать самым лучшим на свете (тм) битлокером.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #49

48. Сообщение от Аноним (8), 20-Сен-23, 13:36	+1 +/–
> Меньше скорость чтения/записи Скорость чтения/записи стогигабайтных файлов ограничивается исключительно носителями, на которых они лежат. > разрастание двух MFT MFT занимает мизер, хвосты больших кластеров отъедят куда больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

49. Сообщение от пох. (?), 20-Сен-23, 13:39	+/–
> ну так еще и не зашифровать самым лучшим на свете (тм) битлокером. 20T ? Мгм... Др-чи что-ли в разрешении поменьше... ну или хотя бы на разрешенный контент...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

50. Сообщение от Аноним (50), 20-Сен-23, 13:47	+1 +/–
Ура! Очередной бтрфс завезли! На ближайшие 10 лет разработчикам файловых систем будет чем заняться, а там и очередная инновация появится. А люди как сидела на ext4/xfs, так и поодолжат.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #77, #122

51. Сообщение от коньюктивит (?), 20-Сен-23, 13:53	+5 +/–
Когда на сисблоке есть кнопка "turbo" и монитор всё ещё выпуклый - не до сарказма.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #85

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

53. Сообщение от Аноним (53), 20-Сен-23, 13:57	+1 +/–
Но, при этом, зачем-то ещё и здесь сидят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #78

54. Сообщение от Аноним (53), 20-Сен-23, 13:59	+/–
>Судя по большинству самая лучшая и безопасная система это андройд. Но, на самом деле, она безопасТная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #80

55. Сообщение от 12yoexpert (ok), 20-Сен-23, 13:59	–2 +/–
что такое ФС? FS?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #61

56. Сообщение от Аноним (53), 20-Сен-23, 14:01	+/–
Было бы чего достигать. Отрицательного ресайза нет, аккуратного использования дискового пространства для мелких файлов нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #84

58. Сообщение от 12yoexpert (ok), 20-Сен-23, 14:03	+/–
гугли разницу между отглагольными прилагательными и причастиями, а лучше в школу сходи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

60. Сообщение от Аноним (53), 20-Сен-23, 14:03	–1 +/–
Ну да, серебрянная, сделанная в Китае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

61. Сообщение от Аноним (8), 20-Сен-23, 14:03	+9 +/–
Да, Failovaya Sistema.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #96

62. Сообщение от Аноним (53), 20-Сен-23, 14:05	+/–
РАО ЕЭС закончилось в 2008.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #67

63. Сообщение от Аноним (53), 20-Сен-23, 14:09	–2 +/–
Не делай слишком маленькие экстенты и не заметишь её существования. Оптимально, где-то, 32 М.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

64. Сообщение от Аноним (53), 20-Сен-23, 14:19	+/–
>На диске С: (кстати когда уже этот анохронизм сподобятся убрать? И ещё один анахронизм: заголовок MZ у файлов формата PE, заодно и расширение .ехе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #68, #116

65. Сообщение от Минона (ok), 20-Сен-23, 14:26	+1 +/–
Во сколько раз сжимаются документы, раз в 10? Ну будет у тебя отчёт открываться за 10 мс вместо 100, что ты выиграешь от разницы в 90 мс?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #75, #76, #118, #119

66. Сообщение от Аноним (66), 20-Сен-23, 14:34	–1 +/–
"В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных" это называется Redirect on Write (RoW)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #123

67. Сообщение от Аноним (8), 20-Сен-23, 14:43	+1 +/–
…И качество электроснабжения изменилось кардинально, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

68. Сообщение от Аноним (8), 20-Сен-23, 14:54	+/–
Можно в .com переименовать для разнообразия. Раньше ещё сигнатура ZM вместо MZ работала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #93

71. Сообщение от Минона (ok), 20-Сен-23, 15:22	+/–
> "В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят > к перезаписи данных" > это называется Redirect on Write (RoW) Нет, это CoW. Отличия смотри тут: https://support.huawei.com/enterprise/ru/doc/EDOC1100200561
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #90

72. Сообщение от Минона (ok), 20-Сен-23, 15:23	+1 +/–
>> Btrfs и другие ФС на базе механизма Copy-on-Write > А другие это какие? У ZFS RoW У ZFS - CoW.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #104, #201

73. Сообщение от Аноним (73), 20-Сен-23, 15:27	+/–
в ext3/4 есть снапшоты - но этот код не был принят в основную ветку ядра. Последний раз я их видел у фуджитсу, можно даже найти эти патчи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #89, #161

74. Сообщение от Kuromi (ok), 20-Сен-23, 16:16	+/–
Очередная "SSD-ориентированная" и еще NOVA на подходе. Притом что когда появилась F2FS все сразу по умному сказали что "да зачем это, контроллеры и так умные". Как же так?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #126

75. Сообщение от 1 (??), 20-Сен-23, 16:20	+1 +/–
Увеличение ЧСВ на порядок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

76. Сообщение от Аноним (36), 20-Сен-23, 16:22	+/–
В первую очередь я выиграю место на диске, и уже одного этого мне будет достаточно. Во-вторую, я, возможно, выиграю в скорости загрузки и запуска приложений, если сожму директории с бинарниками, к примеру. Но тут выиграю или нет - зависит уже от скорости накопителя и CPU.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

77. Сообщение от Самый умный из вас (?), 20-Сен-23, 16:23	+/–
Люди сидят на cow, на ехт4 сидит масса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #120

78. Сообщение от пох. (?), 20-Сен-23, 16:31	+/–
ну не у всех же хватает денег на лопатку на ведроиде, с единственноправильной ОС, приходится сидеть здесь с "десктопа".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #88

79. Сообщение от keydon (ok), 20-Сен-23, 16:33	+/–
>>Судя по большинству самая лучшая и безопасная система это андройд. > А вы же написали это как сарказм? Надеюсь что это все очевидно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

80. Сообщение от коньюктивит (?), 20-Сен-23, 16:45	+/–
Ну, не знаю. Андроид - основная операционная система, которую я использую. Мне всё нравится. И с безопасностью тоже вроде всё в порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #83, #107

81. Сообщение от Аноним (81), 20-Сен-23, 16:53	+1 +/–
Вот чего нет — того нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #283

82. Сообщение от Аноним (81), 20-Сен-23, 16:54	+/–
Слишком сложно. Используй EXT2 и не беспокойся этих глупостев™.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #100

83. Сообщение от YetAnotherOnanym (ok), 20-Сен-23, 17:00	+/–
> с безопасностью тоже вроде всё в порядк Именно такое впечатление она, вроде, и должна производить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

84. Сообщение от Менеджер Антона Алексеевича (?), 20-Сен-23, 17:04	+/–
Как только напишешь непротиворечивый алгоритм «отрицательного ресайза» — пиши в lkml, там найдётся кому накодить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #92, #113

85. Сообщение от Аноним (85), 20-Сен-23, 17:40	+5 +/–
А если к той кнопке подключить reset - вот тогда реально смешно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

86. Сообщение от Аноним (86), 20-Сен-23, 17:53	+1 +/–
> прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), зачем этот выбор?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #124, #182, #243

88. Сообщение от Аноним (88), 20-Сен-23, 18:11	+/–
> сидеть здесь с "десктопа" С какой ОС?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

89. Сообщение от Аноним (88), 20-Сен-23, 18:13	+/–
ссылки, явки, пароли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #219

90. Сообщение от Аноним (90), 20-Сен-23, 18:34	+/–
по описанию в новости- ROW, а чо там внутри я без понятия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

91. Сообщение от Анончик (?), 20-Сен-23, 18:48	+/–
Когда смотрел оно было очень монструозным
Ответить | Правка | Наверх | Cообщить модератору

92. Сообщение от Аноним (-), 20-Сен-23, 19:06	+/–
Разработчики Ext4 такой алгоритм знают, в NameSys тоже знали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

93. Сообщение от Аноним (-), 20-Сен-23, 19:08	+/–
А вообще без расширения никак?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

94. Сообщение от microcoder (ok), 20-Сен-23, 20:00	+1 +/–
Не лишняя, котлеты отдельно, мухи отдельно. А когда намешано в одну кучу, то это помойка называется
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #127, #170

95. Сообщение от microcoder (ok), 20-Сен-23, 20:03	+/–
> Но всё же попробуй какую нибудь ZFS Одна большая помойка. Лучше котлеты отдельно, мухи отдельно. Не надо в файловую систему пихать LVM
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #174

96. Сообщение от InuYasha (??), 20-Сен-23, 20:17	+3 +/–
Da, Fail System. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

97. Сообщение от Аноним (97), 20-Сен-23, 20:41	+/–
Повеяло чем-то тёплым и ламповым ) Ещё бы напомнили о «раненом» и «раненном в плечо»
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #117

98. Сообщение от Аноним (97), 20-Сен-23, 20:43	+1 +/–
... и уж замуж невтерпёж )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

99. Сообщение от Аноним (99), 20-Сен-23, 20:50	+1 +/–
Это какой-такой уровень? Разрешать каждой программе пихать свои васяноатрибуты на твои файлы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #175

100. Сообщение от Аноним (99), 20-Сен-23, 21:00	+/–
Во! Апдейт сломал систему? Выключаешь компу питание и перезапускаешь в состоянии до сбоя! Сила EXT2!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #191

101. Сообщение от Аноним (101), 20-Сен-23, 21:43	+/–
> По производительности Bcachefs опережает Btrfs и другие ФС на базе механизма Copy-on-Write > В Bcachefs используется механизм Copy-on-Write (COW) Она получается сама себя опережает?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #125, #206

102. Сообщение от Аноним (-), 20-Сен-23, 22:05	+/–
> И ext4 хватает за глаза Зато если под системной либой случайный бэд образуется - глаза получаются довольно большие. Когда система резко, внезапно и без предупреждения в тыкву превращается. При том сразу наповал. Без шансов что-то с этим сделать вообще. Еще интереснее когда железо немного подглюкивает. Там что угодно может быть. Например все как живое - но в 1 не очень прекрасный момент все почему-то дохнет. И не факт что чинится fsck. И конечно в лучших традициях RAS (а точнее его отсутствия) это выносит систему резко, внезапно и без намека на предупреждение о грядущих проблемах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #131, #147, #178, #298

103. Сообщение от Аноним (107), 20-Сен-23, 22:08	+/–
> в ext4 за глаза не зватает снапшотов аки ntfs. Хотя, скоро можно будет и ntfs накатывать... Сравнивать эти костяшки с сабжем - как сравнивать конную тягу с скоростным поездом. В принципе, конины тоже могут тянуть небольшой вагончик по рельсам, но разница в деталях - колоссальная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

104. Сообщение от Аноним (11), 20-Сен-23, 22:10	+/–
Нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #157

105. Сообщение от Аноним (11), 20-Сен-23, 22:10	+/–
Это не так работает, попробуй ещё раз
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

106. Сообщение от Аноним (11), 20-Сен-23, 22:11	–2 +/–
Надо. Ты скучный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

107. Сообщение от Аноним (107), 20-Сен-23, 22:11	+/–
> Ну, не знаю. Андроид - основная операционная система, которую я использую. > Мне всё нравится. И с безопасностью тоже вроде всё в порядке. Да зашибись просто. Рекламой - смердит, данные - сливает, пароли от точек доступа - бэкапает. Just as planned.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #114

109. Сообщение от Аноним (-), 20-Сен-23, 23:27	+1 +/–
> Так что если ты ждал поддержку vss - тебе в винду. А... ну собственно, чего ждать-то... Последний писк технологий девяностых. С эрзац-подобием снапшотов ставящий колом все живое на минуты. Самое то, пох дурного не посоветует! И операционочку технологиям под стать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

110. Сообщение от Аноним (-), 20-Сен-23, 23:30	+/–
> Уровень XFS недостижим Майнтайнер оного тоже так подумал - и съ...ся восвояси от греха подальше, когда за syzbot-ом устал баги в индусском коде своих раджей разруливать, весьма колоритно высказав что он думает про это все - и объяснив что в всяком легаси типа v4 чинить это вообще не бу! Просто дропнем - и порядок. В принципе имеет пойнт - под такие уровни стандартов качества ТОТ код того XFS и правда не делался. И не, кент врядли ЭТОТ уровень догонит, он не настолько энтерпрайзный :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

111. Сообщение от Аноним (-), 20-Сен-23, 23:32	+/–
> А когда будет Ext5 уже где всё это из коробки? А как переименуют сабжа так и будет. EXTn - всегда делался на основе легаси дизайна EXT2. Натянуть на это современные фичи проблематично. Если вам нужен самолет, не надо брать автомобиль в качестве основы. Он не для этого делался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #152

112. Сообщение от Аноним (-), 20-Сен-23, 23:37	–1 +/–
> Опять велосипеды вместо того, чтобы использовать lvm2. Ну откуда они такие лезут то?! Да вот видишь ли, хотят люди нормальное управление файлухами. И впном - вайргад, а не полунерабочие ужастики типа IPSec - по тем же причинам. Хорошо когда типовые СОВРЕМЕННЫЕ хотелки в современных реалиях настраиваются без IPSEC'аса с потугами гальванизации всякого легаси. Представляете, менеджмент файлухи может быть так прост как добавление и изъятие девайса. Без сношений с выравниваниями. С моментально работающими снапшотами. В приличных количествах. И это все - с избыточностью. Чексумами. Self repair-ом битых кусков. И так далее. А тут еще с кешированием в SSD и распихиванием свежезаписаного или часто нужного по SSD и подпором HDD "bulk storage" (опционально). В виде когда при настройке этого еще и не сойдешь с ума. И все это - вместо вон того кошмара из спичек и желудей. Нормальному менеджменту систем поем мы славу. Время пришло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #130, #154, #155, #176

113. Сообщение от Аноним (-), 20-Сен-23, 23:46	+1 +/–
> Как только напишешь непротиворечивый алгоритм «отрицательного ресайза» — > пиши в lkml, там найдётся кому накодить. В btrfs накодили - сделали backrefs которые указывают кому блок принадлежит. При нужде убавить размер ФС, 1) идем в хвост фс 2) смотрим по backref чей это блок, 3) двигаем его, 4) апдейтим метаданные, 5) goto 1 если еще больше надо расчистить. Чего тут вообще противоречивого? Это прекрасно работает, и для 1 девайса, и для эн, в том смысле что можно и конкретный девайс из многодевайсной файлухи так вынуть. Маленький catch только в том что это структурами файлухи должно быть подперто для эффективной реализации. А в легаси-дизайне из прошлого века о таком никто вообще совсем не парился. А потом прикнутить на проволоку такое - если совсем не думать о такой фиче при кодинге остального - ну, сами понимаете. А без этого всего - изъятие места сделать при сильном желании можно, но инверсный лукап кому блок принадлежит может оказаться медленным и печальным, если такого индекса сразу не было. В принципе такой инжекс можно отстроить и опосля если сильно захотеть, и даже "сбоку" - но дизайн должен допускать такую мысль и предполагать гибкую аллокацию, когда экстент можно малой кровью подвинуть в логическом размещении и НЕМНОГО отапдейтить метаданные. Если много - скорость всего этого пробьет пол. Подземного этажа. Глубокого бункера. И юзер может не дожить до окончания операции на более-менее крупном хранилище.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #196

114. Сообщение от коньюктивит (?), 20-Сен-23, 23:52	+/–
Где реклама? В гугл плей реклама? вот прямо сейчас зашёл и нет там её. Сливает.. сначала обратитесь к своему сотовому оператору и в госуслуги. > пароли от точек доступа Читал. Там не всё так однозначно. Взять хоть каменты на хабре. Да мне и похер на знание моих паролей анбешниками. А вы лучше себе альт-базальт линукс устанавливайте, глядишь и не обляпаетесь :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #128, #146

116. Сообщение от Аноним (-), 20-Сен-23, 23:54	+/–
>>На диске С: (кстати когда уже этот анохронизм сподобятся убрать? > И ещё один анахронизм: заголовок MZ у файлов формата PE, заодно и > расширение .ехе. Они это даже в UEFI затолкали. И вот этот гуашь уже и дос то загружать в части реализаций разучился - а в части и не умел никогда (откуда он на ARM/MIPS/RISCV?). А заголовок, вот, есть. Интеерсно кстати - на ARM всяких там x86 код, чтобы совсем уж бессмысленно и беспощадно? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #149

117. Сообщение от коньюктивит (?), 20-Сен-23, 23:55	+/–
Стрелой в колено же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

118. Сообщение от User (??), 20-Сен-23, 23:57	+/–
Эм, смотря какие. Если docx - то не восколько, они уже пожаты. А если кто-то чего-то в любимом vi наплейнтекстил - то таки да, есть разница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

119. Сообщение от Аноним (-), 20-Сен-23, 23:57	+1 +/–
> Во сколько раз сжимаются документы, раз в 10? > Ну будет у тебя отчёт открываться за 10 мс вместо 100, что > ты выиграешь от разницы в 90 мс? Да вот видите ли - он выиграть может... 1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару раз?! 2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить - но это как минимум не транслируется в выигрыш по емкости, т.е. вон то все равно лучше. 3) Документы и вообще файлы - разные бывают. Где 10 мс а где и 10 с. 4) А если это сервак, то через всего то 1000 запросов 10 мс станут теми же 10 с.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #133, #141

120. Сообщение от коньюктивит (?), 20-Сен-23, 23:58	+/–
Сидят на корове? Они не знают, что корова не ездовое животное? Ох уж эти маргиналы внутри маргиналов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #168

122. Сообщение от Аноним (-), 21-Сен-23, 00:00	+/–
> Ура! Очередной бтрфс завезли! На ближайшие 10 лет разработчикам файловых систем будет > чем заняться, а там и очередная инновация появится. А люди как > сидела на ext4/xfs, так и поодолжат. Ну так до сих пор вон чувак с деревянной телегой в правом ряду тошнится. Если от крупных городов отъехать. В перди куда подальше. И оправляется в дырку удобств во дворе. Присоединяйся! И вообще нахрен тебе файлухи? И грамоту можно не учить. Понапридумывали тут всяких компьютеров, ироды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #255

123. Сообщение от Аноним (-), 21-Сен-23, 00:05	+/–
> "В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят > к перезаписи данных" > это называется Redirect on Write (RoW) У этой технологии много имен. Примерно то же по смыслу для памяти называется RCU - Read-Copy-Update. Ну а смысл примерно одинаковый. Copy-on-write лучше всего отражает суть - при отличии делается копирование отличающейся версии в другое место. Параллельно начинают существовать 2 версии изменившегося региона. Т.е. довольно близкое к копированию по эффекту действо. Это не совсем точное название т.к. копии более не идентичные. Но остальные названия не отражают суть действа и не дают понимание что место будет потрачено на старый и на новый вид, и почему GC может захотеться в некий момент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

124. Сообщение от Аноним (126), 21-Сен-23, 00:08	+/–
>> прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), > зачем этот выбор? Потому что один размер на всех - не катит. Кому-то надо максимальную скорость, а сжатие лишь приятный бонус. Для них LZ4 на минималочках. А кому-то захочется место сэкономить, на сжатии можно попыхтеть, распаковывать лучше не очень тормозно - и ему тогжа зайдет zstd на высоких уровнях. И так далее. Gzip - где-то посередине но при наличии zstd не сильно нужен уже. Видимо чтобы старые ФС читать - zstd в ядре относительно недавно. А сабжу так то уже около 10 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #134

125. Сообщение от Аноним (126), 21-Сен-23, 00:09	+/–
>> По производительности Bcachefs опережает Btrfs и другие ФС на базе механизма Copy-on-Write >> В Bcachefs используется механизм Copy-on-Write (COW) > Она получается сама себя опережает? Да легко. Программа новой версии может оказаться быстрее старой из-за улучшения алгоритмов. Уж в ФС это вообще норма жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

126. Сообщение от Аноним (126), 21-Сен-23, 00:15	+2 +/–
> Очередная "SSD-ориентированная" и еще NOVA на подходе. Оно не SSD ориентированное а "универсальное" и "многодевайсное". Все новые дизайны будут делаться с учетом существования SSD и их свойств. Это так странно? Глупо дизайнить ФС не учитывая существующие типы сторажей. > Притом что когда появилась F2FS все сразу по умному сказали что "да зачем это, > контроллеры и так умные". Ну вообще f2fs таки удобен флешу - и в целом снижает возню для контроллеров. Но он не многодевайсный. И у него есть проблемы с надежностью. И каких-то продвинутостей в управлении у него нет. Это пофиг если это на веки вечные прибитый на гвозди раздел в мобилке. Зато это большие грабли если это хранилка с несколькими дисками. > Как же так? Ну вот так. Люди дизайнят новые дизайны с учетом наблюдаемых реалий. Не стесняясь брать удачные идеи из соседних дизайнов, между прочим. Улучшая свои.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #225

127. Сообщение от Аноним (-), 21-Сен-23, 00:28	+2 +/–
> Не лишняя, котлеты отдельно, мухи отдельно. А когда намешано в одну кучу, > то это помойка называется Ну, понимаешь, в btrfs в результате можно "btrfs device add" на вооон тот наобум взятый диск. В пуле +n места, без делания мозга выравниваниями и проч. При том что критерии RAID1 или чего там - по прежнему будут выполнены, 2 копии на 2 разных девайса уйдет. Просто вариантов куда разместить пару блоков - прибавилось, вот. А можно и remove. И это буквально 1-2 простыми командами. Быстро. Эффективно. Или вот если у меня 3 диска на допустим 2, 3 и 4 терабайта. Вон там оно таки станет, таки RAID1, суммарной емкости примерно (2+3+4 / 2) = 4.5 терабайта места формата RAID1. А из LVM свогое е...чего ты такое вообще смогешь при тех же условиях с таким же доступным местом?! И если да то сколько тантров для этого потребуется? И будет ли оно при расхождении чтения с 2 копий знать какая копия - битая? Чтоб еще и self repair сделать, прозрачно и в фоне? Ну вот тебе и ответ почему твой LVM - кусок хлама. Там даже отдаленно приблизиться к вот такому поведению - сойдешь с ума. А тут вот ненапряжный менеджмент парой командочек в лучшем виде. А твои знания как там шкворни правильно салом мазать - ну, так и быть, будешь у нас музеем-заповедником старины, будем экскурсии водить показывая как раншьше все сложно было, вместо того чтобы робот на линии колеса прикрутил в 5 секунд - вот, самому кувалдой надо было #$%шить полдня!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #153, #177

128. Сообщение от Аноним (-), 21-Сен-23, 00:38	+1 +/–
> Где реклама? В гугл плей реклама? вот прямо сейчас зашёл и нет там её. Как нет? А в верху самом это не реклама, типа? Да и если софт поставить - особенно бесплатный - там реклама прет из всех щелей. А у особо наглых - и в платном тоже прет, денег много не бывает же. > Сливает.. сначала обратитесь к своему сотовому оператору и в госуслуги. У меня вообще никаких госуслуг нету. Да и сказ о том кого и где линчуют - прохладный. Впрочем, некоторые пользователи, типа вас, заслуживают именно такой линукс и именно такое к себе отнощение. >> пароли от точек доступа > Читал. Там не всё так однозначно. Взять хоть каменты на хабре. Ну да конечно - эти туррели, колючая проволока и злые овчарки и прочие залоченые бутлоадеры для моего же блага. Кто бы сомневался. > Да мне и похер на знание моих паролей анбешниками. А вы лучше > себе альт-базальт линукс устанавливайте, глядишь и не обляпаетесь :D Да нам и с дебианом как-то неплохо, подальше от рфии и ее навязчивых госуслуг, с повестками и чем там еще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

129. Сообщение от Аноним (-), 21-Сен-23, 00:41	+/–
>> из абсолютного большинства, большая часть сидит именно на ехт4, без снапшотов и без проблем > На десктопах абсолютное большинство сидит на винде. Это не мешает миллиарду юзерей мордокниги юзать btrfs на его серваках :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #150, #151, #160

130. Сообщение от Аноним (130), 21-Сен-23, 01:00	+/–
Wireguard - это не VPN, а кастрат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #135

131. Сообщение от Вопрос (?), 21-Сен-23, 01:26	+/–
О чем ты? Расскажи подробнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #138

132. Сообщение от fumanchez (ok), 21-Сен-23, 01:28	+/–
> тооочна! При ширпотребных дисках по 20 терабайт и nvme модулях работающих уже > почти на скорости оперативки - сжатие на уровне фс это вот > супернеобходимейшая фича. Полный бред, как про объемы, которые составляют 1-2 ТБ для HDD и 256+ ГБ для SSD, так и про скорости, но тут пожалуй без комментариев. И это именно что опция, чтобы у тебя была возможность при необходимости эту опцию задействовать (почему вообще это приходится объяснять?). Плюс тут люди пограмотнее уже поясняли, что это может быть полезно для уменьшения количества записей на SSD и I/O в целом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #140

133. Сообщение от fumanchez (ok), 21-Сен-23, 01:40	+1 +/–
У меня хомяк похудел почти на треть с zstd при самой легкой степени сжатия, а там, к примеру, лежал флатпаковский .var (я с флагом --user все ставлю). А сервер в теории можно более равномерно загрузить, если он до этого не упирался в процессор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #136, #274

134. Сообщение от fumanchez (ok), 21-Сен-23, 01:47	+/–
Еще скорость разжатия почти не меняется даже после запаковки хоть с самым высоким уровнем. Может быть актуально для внешнего диска.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #137

135. Сообщение от Аноним (-), 21-Сен-23, 01:48	–1 +/–
> Wireguard - это не VPN, а кастрат. То ли дело IPSec, уровень на уровне и уровнем погоняет - и когда вы фигурно потрахались с этим всем два дня вы обнаруживаете что оно застревает на первом же файрволе и нате и решительно непригодно для ремотных сотрудников, так что плотные сношения были - зазря, а знания можно слить в толч. Все равно от них толку нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #143, #163

136. Сообщение от Аноним (-), 21-Сен-23, 01:55	+1 +/–
> У меня хомяк похудел почти на треть с zstd при самой легкой > степени сжатия, А у меня система (и ее снапшоты!) раза в 2 с гаком полегчали на SSDшнике. Поди плохо то, если это еще и не в ущерб скорости, а то и с бонусом к ней. Я типа жаловатсья должен что мне гигов досыпали, а то и скорости? :) > а там, к примеру, лежал флатпаковский .var (я с флагом --user все ставлю). Я вообще не ставлю никакие флатпаки, ибо нафиг винды. Но на нормальной файлухе это кроме сжатия наверное еще и дедупнется неплохо. > А сервер в теории можно более равномерно загрузить, если он до этого не упирался в процессор. Ну как бы если IO еще и ускорится - то это всяко лучше. А если и нет - меньше займется места, меньше протирания SSD. Тоже неплохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #142

137. Сообщение от Аноним (-), 21-Сен-23, 02:09	+/–
> Еще скорость разжатия почти не меняется даже после запаковки хоть с самым > высоким уровнем. Может быть актуально для внешнего диска. У LZ-based (все три именно оно) есть довольно большая асимметрия по ресурсам на сжатие и распаковку. В первом приближении, сжатие LZ - поиск совпадений, чем длиннее, тем лучше. Это довольно ресурсокмко, как ни крути. Особенно "чем длиннее" до упора. Чем больше ресурсов на это убито тем лучше может получиться совпадения нащупать и меньше данных на выход. С тем же самым результаом декодирования. И уровень сжатия - регулирует в общем то в какой момент matchfinder'у надоест пытаться нащупать наилучшее, и он посчитает что то что есть - "good enough", и отдаст результат. При распаковке это фактически следование инструкциям вида "скопируй X байтов от сих до сих". Там нечему так уж тормозить. И от уровня сжатия структура этого мало зависит. Иногда даже улучшение может быть от повышения уровня - ведь с точки зрения распаковки, "на вход немного меньше, результат точно такой же" - и суммарный результат сведется к "немного разгрузили шины" т.е. даже еще и сэкономили какие-то крохи времянок. Реальность конечно чуть сложнее - у gzip и zstd еще уровень "кодирования энтропии" поверх этого. LZ4 чистый LZ, он целиком про скорость и поэтому с кодированием энтропии там не заморачиваются (сильно скорость распаковки рушит, хоть и улучшает сжатие). Но общая идея что распаковка LZ быстрая - остается. LZ4 конечно самый быстрый на расппковку, у него нет дожатия энтропии и формат потока рыхлый, зато простой в парсинге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #162

138. Сообщение от Аноним (-), 21-Сен-23, 02:35	+1 +/–
> О чем ты? > Расскажи подробнее 1) В btrfs можно даже на 1 устройстве разложить данные в схему хранения DUP. А метаданные так по дефолту хранятся в 1-дисковых конфигах если юзер явно не захочет иного. Это когда запись 1 блока идет в 2 разных логических смещения. Емкость устройства, конечно, ополовинивается. Зато в случае вот именно единичного бэда или тому подобной ерунды - EPIC WIN! Порушеное просто достается из второй копии. И чинит первую копию. Т.к. данные проблемной копии при этом более не нужны, и туда будет записано что-то иное, это еще и к процедуре ремапа и верификации секторов дружественно. И вот вместо ВНЕЗАПНОГО разлета системы в хламину когда не прочтется системная либа или метаданные какие лишь нытье в лог "csum failed .... corrected". И все просто работает. Ну, ок, если это чаще чем скажем раз в год в логах, надо наверное поднапрячься что у нас железо "не очень" и его по хорошему стоит заменить. Чем чаще пиндит тем быстрее заменить/починить, конечно же. 2) Пункт 2 является расширением этой идеи. Чексуммы в файлухе хайлайтят все. Будь это кривая оперативка, плохой кабель, дурящий контроллер или даже глюкавый проц (и такое тоже бывает!) - если в логах часто лезет "csum failed" - вы знаете что железо у вас хреновое. А не так что все вроде-работало - но потом почему-то все резко и внезапно подохло, а половина файлов на поверку загажено каким-то мусором, когда там оказывается проц уже пару лет глюкавил, или что там. Это end to end проверка данных которая подсвечивает дочерта мыслимых и немыслимых проблем железа. В моем случае трофеями являются кривой SATA шнурок, планка оперативки, глюкавый проц и несколько сыпучих-текучих usb-флех и карт памяти. Последние используются для издевательств над теорвером - так пока и не получилось джекпот срубить, так что по факту можно на сыпучей флехе файло таскать, ополовинив емкость - уж хоть 1 из копий да прочитается нормально. ...и это я еще не упоминал что систему можно заснапшотить, а если все плохо, можно сгонять на машине времени в прошлое, взять систему в виде когда все еще работало. И вот оно, мы починили себе систему за пару минут. Вместо дурацкого хардкора, переустановок и проч. На минималочках можно загрузиться в другой снапшот даже одним grub'ом аж.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

140. Сообщение от пох. (?), 21-Сен-23, 07:22	+/–
> Полный бред, как про объемы, которые составляют 1-2 ТБ для HDD и 256+ ГБ для SSD у тебя криокамера потекла. С разморозочкой, но тебе у нас не понравится. Чини быстрей пока есть чем и давай дальше в свое гребаное будущее. Вот во времена твоих дисков "1-2 ТБ" как раз была актуальна та фича в ntfs. Но им вполне хватало кластера в 4k. А сегодня _ширпотребный_ диск выглядит как-то вот так: https://www.amazon.com/dp/B09QFV1HNZ/ (ширпотребный, даром что помечен как "data center". В твой дрисктоп даже можно вставить и будет жужжать. Неширпотребные - это какие-нибудь hm-smr)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #164

141. Сообщение от пох. (?), 21-Сен-23, 07:26	+1 +/–
> Да вот видите ли - он выиграть может... > 1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару сколько его? > раз?! вообще похрен всем. Неплохо если терабайт подешевеет - но откуда у него СТОЛЬКО сжимаемых данных чтоб освободить терабайты. > 2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить - ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад). > 3) Документы и вообще файлы - разные бывают. Где 10 мс а > где и 10 с. у меня для тебя опять облом - пока ты в криокамере мерз, ТАКИЕ документы перестали сжиматься, они уже. > 4) А если это сервак, то через всего то 1000 запросов 10 > мс станут теми же 10 с. То есть снова ни о чем. А сервант твой потеряет гораздо больше времени на обработку запроса а не собственно отдачу файла. Особенно если он пришел к нам из тех же годов что чудо-диски по терабайту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #207

142. Сообщение от пох. (?), 21-Сен-23, 07:41	+/–
> А у меня система (и ее снапшоты!) раза в 2 с гаком полегчали на SSDшнике. Поди плохо просто пофигу. Никому в 2k23 неинтересно занимает ли твоя "система" вместе с ненужно-снапшотами которы ты никогда не будешь использовать, 12 гигабайт или восемь.  Вообще. Совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #205

143. Сообщение от пох. (?), 21-Сен-23, 07:45	+/–
> То ли дело IPSec, уровень на уровне и уровнем погоняет очередной свидетель ужасов ipsec, видевший его только во сне. > и решительно непригодно для ремотных сотрудников наши ~4000 смотрят на тебя как на ... А вот как ты будешь приземлять 4000 вайергадов и следить за тем что кто-то лишний не получил чего-то ненужного - я поржу. >   зазря, а знания можно слить в толч. Все равно от них толку нет. от твоих - нет. Потому что это не знания а сборник мифов и легенд в пересказах перепевов. Сливай и иди в плесень-и-точка. Там опять некому убирать сортиры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #204

145. Сообщение от Бывалый смузихлёб (?), 21-Сен-23, 07:54	+1 +/–
а одна муха - показатель ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #185

146. Сообщение от Бывалый смузихлёб (?), 21-Сен-23, 07:58	+/–
В бесплатных приложениях, например Самое забавное, что с некоторых пор гугел практически обязывал разработчиков бесплатных приложений впиливать туда рекламу( даже если они этого не хотели ) - одно время активно банил тех, кто делал бесплатные приложения но и без рекламы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

147. Сообщение от Бывалый смузихлёб (?), 21-Сен-23, 08:07	+/–
Под винду и на подобные случаи были штуки вроде WinHex В былые времена позволявшие очень многое - от непосредственного сканирования данных с поиском заголовков известных типов файлов Хотя там и не ext4 была И вплоть до собирания свободного пространства кластеров в отдельную "кучу", по которой делается нужный поиск. По крайней мере на винде удаление файла означало просто пометку что файла больше нет, с возможностью перезаписи поверх него чего-то другого. Но, поскольку новый файл обычно весит меньше  суммы занимаемых им кластеров - в последнем кластере остаётся кусок старого удалённого файла. Но при копировании - копировались покластерно, т.е переносился и кусок удалённого файла Иногда следаки из подобных остатков много интересного вытаскивали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #183

149. Сообщение от Аноним (150), 21-Сен-23, 08:33	+/–
Ну если вы найдёте MS-DOS под ARM…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

150. Сообщение от Аноним (150), 21-Сен-23, 08:35	+/–
Именно так, на серверах. А на десктопах абсолютно неважно, на чём там сидят линуксоиды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #159

151. Сообщение от User (??), 21-Сен-23, 09:12	+/–
Да. И старый php в c++ компилить - предлагаешь всем на вооружение брать, раз САМА мордокнига?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

152. Сообщение от User (??), 21-Сен-23, 09:20	+3 +/–
Большинству людей того... Ножками за хлебушком через день ходить, а им каждый раз пытаются кривой космолет на паровом ходу впарить и рассказывают, что из автомобиля менее кривой бы тоже не получился. Что характерно - на винде с макосью просто гоняют в булошную кто на самокате, кто на лисапеде - и чот не парятся. Такие вот дела.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #165, #187

153. Сообщение от User (??), 21-Сен-23, 09:24	–1 +/–
... вы прослушали рассказ о том, как страшна и безблагодатна жизнь пользователей ms word, В котором нельзя так просто взять - и одной командой удалить три последних символа в каждой четной строке файла начиная с девятой...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

154. Сообщение от User (??), 21-Сен-23, 09:32	+/–
Вот ни разу не видал людей, которые хотели бы wireguard - обычно у всех хотели "я такой тык! И оно работает!" - из любой, что характерно, ос - а не только между двумя своими виртуалками. У безов конечно свои желалки - централизованно управление ключами, маршрутами, комплаенс полиси на устройствах, сертификат фстэк и прочий ГОСТ - вот это всё. Им ваш вайргад тоже ээээ... Нафиг не сдался. Инфраструктурщикам - поддержку со стороны оборудования подавай. И со стороны вендора. И официальную инструкцию по настройке. Полтора линуксойда - те да, могут пердолиться как им угодно - пока с вышеозначенными множествами не пересекутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #156, #167

155. Сообщение от User (??), 21-Сен-23, 09:38	+/–
Вот ни разу не видал людей, которые хотели бы wireguard - обычно у всех хотели "я такой тык! И оно работает!" - из любой, что характерно, ос - а не только между двумя своими виртуалками. У безов конечно свои желалки - централизованно управление ключами, маршрутами, комплаенс полиси на устройствах, сертификат фстэк и прочий ГОСТ - вот это всё. Им ваш вайргад тоже ээээ... Нафиг не сдался. Инфраструктурщикам - поддержку со стороны оборудования подавай. И со стороны вендора. И официальную инструкцию по настройке. Полтора линуксойда - те да, могут пердолиться как им угодно - пока с вышеозначенными множествами не пересекутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

156. Сообщение от пох. (?), 21-Сен-23, 10:03	+/–
> Вот ни разу не видал людей, которые хотели бы wireguard - обычно у всех хотели "я такой тык! > И оно работает!" - из любой, что характерно, ос - а не только между двумя своими виртуалками. ну тут есть нюанс - оно может и работает - только не всегда и не у всех. Впрочем, вайргада это касается не в меньшей степени, особенно учитывая категорическое нежелание автыря читать документацию и разбираться в том как принято работать сетевому драйверу в системах отличных от единственноверной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #171

157. Сообщение от Минона (ok), 21-Сен-23, 10:21	+/–
> Нет Да. RTFM!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #166

158. Сообщение от swarus (ok), 21-Сен-23, 10:42	+/–
ntfs медленнее ext4 на 25%
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #271

159. Сообщение от EULA (?), 21-Сен-23, 10:47	+/–
Тогда почему все линуксойдами становятся, сразу, как запускают броузер?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

160. Сообщение от swarus (ok), 21-Сен-23, 10:56	+/–
btrfs значительно медленней ext4, btrfs при заполнении диска не может удалить файл, пишет не хватает место приходится бежать с флешкой к серверу, расширять раздел на флешку, удалять файлы стягивать обратно, такое поведение не поменяют ибо такая архитектура. (беготню можно заменить, на покупку раздела доп раздела)[br] Это то, с чем лично столкнулся. Использовать на серверах не готов. Аналог функционала btrfs, реализую созданием файлов с образами ext4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #181, #184

161. Сообщение от swarus (ok), 21-Сен-23, 11:04	+/–
просвети тёмных, ссылку дай. снапшоты нафиг сдались (для меня), а вот ограничения на папку для контейнеров нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #227

162. Сообщение от fumanchez (ok), 21-Сен-23, 11:40	+/–
> В первом приближении, сжатие LZ - поиск совпадений, чем длиннее, тем лучше. btrfs жмет не файл целиком, а его куски по 128 КБ, поэтому тут навряд ли количество совпадений будет сильно отличаться при разных уровнях сжатия, а решать будет скорее то, как алгоритм отрабатывает в среднем, но я не шарю. Страдают только экстенты жирных файлов - на каждый скомпрессированный кусок надо хранить метаданные, и по идее это тоже бьет по времени доступа к содержимому из-за фрагментации, но я чето уже и не помню где глянуть бенчмарки, чтобы оценить какой выигрыш дает хранение файла "сплошняком".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #210

163. Сообщение от tipa_admin (?), 21-Сен-23, 11:56	–1 +/–
Не используй винду - не надо будет в реестре ковыряться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

164. Сообщение от fumanchez (ok), 21-Сен-23, 12:16	+/–
Ок, ширпотребный НОВЫЙ хард на текущий момент это 8ГБ для ПК и 2 ГБ для ноутов, судя по первым результатам категории "Internal hard drives". Конечно же, у всех на данный момент стоят именно харды (нет), еще и купленные в 2023 (нет), а даже если и не стоят, то обязательно будут стоять (нет). Если начать комментировать, что за ширпотребный хард (пусть даже будущего) ты берешь хард из линейки для датацентров, то в конце можно подытожить только диагнозом. А может будут какие-то экспертные комментарии относительно сжатия на SSD (в частности внешних), на флешках? Или даже может быть какие-то экспертные подсчеты издержек на содержание датацентра с компрессией и без?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #180, #208

165. Сообщение от Аноним (11), 21-Сен-23, 13:14	–2 +/–
Никому не интересно на каком лисапеде ты дома от мамки гоняешь, у дядечек петабайты с репликацией и бекапами на тридварас, макоси и винде такое в страшном сне не снилось
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #193

166. Сообщение от Аноним (11), 21-Сен-23, 13:15	+/–
Нет, кури мануалы поактуальнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #218

167. Сообщение от Аноним (11), 21-Сен-23, 13:17	+/–
А что не так с WG на любой актуальной ОС? Кажется везде кроме форток он уже чуть ли не по уши в ядре
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #173

168. Сообщение от Аноним (11), 21-Сен-23, 13:19	+1 +/–
apt moo
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

170. Сообщение от Пряник (?), 21-Сен-23, 14:36	+/–
Пробовал летать на самолёте отдельно без крыльев, кабины и двигателя?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #172

171. Сообщение от User (??), 21-Сен-23, 14:38	+/–
Ну вот sstp от ms скорее работает. Anyconnect от Cisco - скорее "да". Даже какой-нибудь l2tp+ipsec уже скорее "да", чем "нет". С wg на оффтопике у меня проблемы были. Про то, что сопровождать вышеописанные решения in scale > 1000 человек можно, а у wg'шников столько воображаемых друзей не набирается, так что они не в курсе, какие при этом проблемы возникают - мы милостиво промолчим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

172. Сообщение от microcoder (ok), 21-Сен-23, 14:38	+1 +/–
> Пробовал летать на самолёте отдельно без крыльев, кабины и двигателя? Всё летает, LVM отдельно, FS отдельно. Ноу проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #216

173. Сообщение от User (??), 21-Сен-23, 14:39	+1 +/–
Нукакгбэ да - но у 97% людей возможны варианты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

174. Сообщение от Пряник (?), 21-Сен-23, 14:43	+/–
К сожалению LVM копирует оригинальные данные в снапшот при изменении (Copy-on-Write). Снапшот может переполниться. А в ZFS снапшот это адреса блоков, а пишет новые данные он всегда в новые блоки. Снапшот не может переполниться, ведь он фиксированный набор данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #192

175. Сообщение от Аноним (175), 21-Сен-23, 14:44	+/–
Поддержка атрибутов - необходимое требование для UNIX FS. И по умолчанию, без задания необходимых опций проги на твои, васянские файлы, атрибуты не накладывают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

176. Сообщение от Пряник (?), 21-Сен-23, 14:47	–1 +/–
IPSec как раз таки и является самым нормальным VPN. Точнее IPSec это лишь шифрование. VPN делается через IKEv1+l2tp или IKEv2. Шифрование AES аппаратно поддерживается много где.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #215

177. Сообщение от microcoder (ok), 21-Сен-23, 14:50	–1 +/–
В LVM тоже самое делается, только безопасней (на мой взгляд). У тебя атомарная функция (скорее всего) на уровне FS progs, а LVM это отдельная сущность, вначале добавляешь диски, а потом только действия по раширяемости с ФС. На одну-две команды больше, не кричтино, в этом вопросе соревноваться на пару секунд не имеет смысла. VOLUME отдельно, RAID отдельно, FS отдельно. Никакого компота, каждый на своём уровне
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #188, #190, #194

178. Сообщение от AlexYeCu_not_logged (?), 21-Сен-23, 15:23	+/–
>Без шансов что-то с этим сделать вообще. В смысле без шансов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #186

179. Сообщение от Аноним (179), 21-Сен-23, 15:35	+/–
Такое впечатление, что это ты кроме морковки ничего не едал. Постоянно про морковку вспоминаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

180. Сообщение от пох. (?), 21-Сен-23, 15:42	+/–
> Ок, ширпотребный НОВЫЙ хард на текущий момент это 8ГБ для ПК и 2 ГБ для ноутов дружище, не все живут в помойном бачке. Первые результаты тебе видимо показывают трэш который продаваны годами не могут уже сбагрить или вовсе адаптированы к твоим нехитрым запросцам. (А еще можно внезапно выключить сортировку "lowest price first") Те, у кого есть данные чтобы их хранить, а не только любимая винда и двадцать обоев с котиком - не покупают такое. > Если начать комментировать, что за ширпотребный хард (пусть даже будущего) ты берешь хард из > линейки для датацентров https://www.amazon.com/dp/B09VCXWPQG/ - на тебе точно не для датацентров (только корпус не открывай - а то наверное удивишься, что там внутри ровно такой же ultrastar) Это просто диски для тех у кого есть данные чтобы их хранить, а не только чтоб кое-как загрузить любимую дрисняточку чтоб др-ть на опеннете - на это вполне хватит встроенной nvme платки за $30 - вот она да, будет аж один терабайт. Вот для тех людей которым есть что хранить и делают файловые системы сегодня. Для тех у кого обои и дрисяточка и какие-то еще там сжимаемые "документы" - уже все сделали в 1999м году и пофайловые сжатия остались примерно там же в прошлом веке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

181. Сообщение от Аноним (-), 21-Сен-23, 15:42	+/–
> btrfs значительно медленней ext4, Сильно зависит от ворклоадов. При случае так cow и мастеркласс "in place" антикам может дать, умея аналог полного журнала по сути - без двойной записи при этом всем. Во многих практических случаях разницу просто не заметно "по жизни". А вот продвинутые фичи и нормальное управление файлухой - очень даже заметно. Если у вас конечно энтерпрайзными SSD все забито под завязку... ну вот сабж весьма многообещающ тогда :) > btrfs при заполнении диска не может удалить файл, > пишет не хватает место приходится бежать с флешкой к серверу, расширять > раздел на флешку, удалять файлы стягивать обратно, такое поведение не поменяют > ибо такая архитектура. (беготню можно заменить, на покупку раздела доп раздела) Свежо предание. Там уже давно есть глобальный резерв на такие случаи. > Это то, с чем лично столкнулся. Использовать на серверах не готов. Аналог > функционала btrfs, реализую созданием файлов с образами ext4. Да хоть на EXT2 сидите, хоть на FAT16 - кому от этого хуже кроме вас будет то? Ну может еще всем полутора юзерам вашего сервака. Заодно как раз и перестанут пользоваться серваками профакивающими фоточки котят без предупреждения. Видал я такие сервера, качаешь картинку - а там полфайла ок, полфайла битое, а админ даже и не в курсах что у него его мусорка сыпется. Таким серверам и админам - место на помойке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

182. Сообщение от Пряник (?), 21-Сен-23, 15:43	+/–
Предположу, что, как Горк и Морк: одно жмёт быстро, но слабо, а другое долго, но сильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

183. Сообщение от Аноним (183), 21-Сен-23, 16:04	+/–
> Под винду и на подобные случаи были штуки вроде WinHex Это антипод вон тех техноолгий. Там видите ли рояль в кустах разложен так чтобы оно САМО себя фиксило по максимуму из избыточной копии. Или накрайняк, если полсистемы стерли или там что еще - ну вот за пару минут снапшот переключить на заведомо исправный, где все еще ок было. Винда так не умела по нормальному никогда. Это уповает на "гибкую аллокацию" (write-anywhere) для записи 2 копий в разные логические смещения с одной стороны. И на недеструктивность CoW операций с другой: даже если я перезаписал системный файл в хламину, в снапшоте он таки останется как был. И это простая, дешевая и быстрая операция. Которая в CoW ничем не отличается от нормальной записи. Так что даже и не задумываешься сколько там снапшотов и проч. А откат - по сути переназначение 1-2 дир с которых грузиться будем, грубо говоря. Там нечему время занимать. В винде ничего сравнимого никогда не было. Каким-то отдаленным подобием является ReFS но это классическое "too little and too late" и к тому же домашних юзеров на него совсем надрали. > В былые времена позволявшие очень многое - от непосредственного сканирования данных с > поиском заголовков известных типов файлов Хотя там и не ext4 была Testdisk и photorec это и сейчас позволяют. И им вообще пофиг что за ФС. И варез качать не надо - алилуя, можно опенсорсом под линухом хомякам данные вытаскивать оптом. И "продвинутые читалки" для осыпающихся дисков - есть. Так что достаточно продвинутый датарекавери можно и в линухе забацать. Я проверял, это работает. > И вплоть до собирания свободного пространства кластеров в отдельную "кучу", по которой > делается нужный поиск. Есть довольно большая разница между корректным монтированием файлухи или хотя-бы оффлайн парсингом на (почти) полном автомате и вот этим вот. И вот эти технологии на фоне тех уже не поражают воображение. А передовой свинцово-кислотный акум, достижение конца XIX века - в XXI выглядит тяжелым, токсичным балластом с хреновыми параметрами. > чего-то другого. Но, поскольку новый файл обычно весит меньше  суммы > занимаемых им кластеров - в последнем кластере остаётся кусок старого удалённого файла. А в CoW файло - и даже метаданные в случае btrfs - так сразу вообще не сносятся. Это кроме всего прочего означает что если стало совсем тяжко, то при хардкорном рековери такого уровня вообще есть более 1 точки входа для начала парсинга. ...а крашрекавери CoW файлухи - его почти нет! Это в общем то "отбросить неудавшиеся записи". И вуаля, поскольку сперва делается запись, в новое место, а потом апдейтятся метаданные указывать на уже новое состояние, с учетом этого - если это не успели - ну, окей, этой записи никогда и не случалось. В btrfs эту механику и к метаданным смогли применить, так что ему вон то в общем случае просто не надо. А в каких-то очень частных аномалиях есть возможность попробовать разные точки входа для парсинга. Что умеет даже ее встроенная оффлайн читалка. Ога, это тул уровня лучших коммерческих прог под винду для NTFS - нашару, в тулките ФС. Пожелаем остальным файлухам чтобы они свои тулкиты так же делали, а не отдавали это на откуп левым комерсам. > Но при копировании - копировались покластерно, т.е переносился и кусок удалённого файла > Иногда следаки из подобных остатков много интересного вытаскивали Добро пожаловать в чудный мир forensic analisys. Как вы понимаете, никто и никогда нигде не стирает данные от и до де факто протирая регион, это очень медленно и ресурсоемко. В ряде программ есть "secure erase" но даже так у FTL и проч все равно могли быть свои идеи куда там запись отправится. Так что если вы не хотите чтобы данные нашли, лучше всего никогда их и не записывать. В остальных случаях возможны варианты. Ну или хотя-бы шифрованные диски использовать. Бинарный мусор неинформативен. Но всегда есть риск что интрудер влезет когда он прицеплен - и таки утащит файло, понятия не имея какой ключ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

184. Сообщение от Аноним (184), 21-Сен-23, 16:05	–1 +/–
> btrfs значительно медленней ext4 Спорно. Зависит от диска (HDD/SDD), характера данных, настроек монитрования, типа операции (запись/чтение). У меня Btrfs даже на шифрованном (dm-crypt/LUKS) HDD со сжатием (zstd) прекрасно работает. > btrfs при заполнении диска не может удалить файл btrfs balance start -musage=0 -dusage=0 / Но вообще, хорошей практикой на любой ФС считается следить за заполнением диска.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

185. Сообщение от Аноним (184), 21-Сен-23, 16:09	+/–
Один сердитый шмель вполне может преподать тебе урок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #248

186. Сообщение от Аноним (186), 21-Сен-23, 16:26	+/–
>>Без шансов что-то с этим сделать вообще. > В смысле без шансов? В самом простом. У меня на EXT4 разок вылез редкий, меткий, мерзкий бэд аж под libc6. Догадайся, что случилось с системой после этого? И какие там "шансы"? На что, Карл?! Ну вот не работает операционка если libc6 прочесть не вышло. Вообще совсем. Странно, да? А самое печальное в этой истории было в том что это - одноплатник заэмбедованый у черта на куличиках, и пришлось с ж@ в мыле лететь в ацкие перди, резко, обломно, за свой счет. С тех пор я подосвоил технологии self heal где это теперь иначе выглядит, "csum failed ... corrected" - из второй копии, и оно просто загрузится. Починив рушеную копию. И единственное заметное миру явление уже не полный резкий внезапный даун, а ругань в лог да инкремент счетчика corrupted, с сохранением функциональности. ...так что вместо пересборки системы с ж@ в мыле я лишь в фоне узнаю что вон там что-то сыпнулось немного. Если это часто повторяется, окей, там поддуривает стораж и надо в фоне это пофиксить по хорошему. Заметьте - не в режиме аврала когда функциональность железки уже резко и совсем накрылась медным тазом. Это то что и называется RAS. И те кто пользуется EXT4 в это не вхожи от слова вообще. Или решают это сильно другими способами. Ну вот гуглу и EXT4 можно, у них распределенная оверлейная мегаструктура справится еще и не с таким. Но вы же не гугл, у вас то мегаструктуры поверх ненадежного хлама нет... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

187. Сообщение от Аноним (187), 21-Сен-23, 16:40	+/–
> Большинству людей того... Ножками за хлебушком через день ходить, а им каждый > раз пытаются кривой космолет на паровом ходу впарить и рассказывают, что > из автомобиля менее кривой бы тоже не получился. Можно пойти дальше, треть россиян вообще в позе орла нужду справляет до сих пор. Давайте на них ориентироваться?! Это же предел мечтаний, да? А тянуть водопровод к толкану = столько возни, в самом деле. > Что характерно - на винде с макосью просто гоняют в булошную кто > на самокате, кто на лисапеде - и чот не парятся. ...и потом вон там в травмате, кто с переломом, кто с разбитой харей, а особо пафосные эксперты - решают погонять за автобусом с ветерком, в аэродинамическом мешке, только у автобуса колесо во, а у них во. И когда на скорости 60 в ямку ух - спасибо если не в морге вообще. С файлухами это примерно так же работает - вон те зиллионы вынутых с порушеных дисков котят не дадут соврать. Но вот самому так раскладываться об асфальт своими данными - что-то не хочется, спасибки. Человек разумный может и получше чем ЭТО. > Такие вот дела. Ну да, ну да. Участь хомяка - хомячить. Да и данные он перекачает, а если и не перекачает, ну и хрен с ним - там самое ценное это фоты котят, ну, новых нащелкать накрайняк. Хотя существование датарекавери лаб как бы намекает :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #189

188. Сообщение от пох. (?), 21-Сен-23, 16:56	+/–
на твой безграмотный взгляд. И дело не в на одну команду больше, а в том что у тебя нижний уровень ничего не знает о том что на нем лежит, а верхний не может переспросить нижний если что-то пошло не так. И да, повреждения на уровне lvm не диагностируются (кроме спонтанных крэшей вышележайшей fs) и не исправляются. Хотя он сам по себе адски сложная структура с кучей метаданных и сложных агломераций. И вполне умеет обернуться тыковкой. Вся эта ненужная иерархия ненужных "уровней" - от бедности. Попытка подкостылить устаревшие файловые системы образцов 70х годов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #195

189. Сообщение от User (??), 21-Сен-23, 16:56	+/–
Ну да. А у нехомяков появилась ещё одна замечательная уже почти-но-ещё-не-совсем production риди(ТМ) фс на костыльно-грабельном ходу с паровым приводом - скоро можно будет на альфа центавра за хлебушком сгонять (но глядя на f2fs/zfs-on-linux/btrfs - это, разумеется, не точно). Ура, товарищи!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #199

190. Сообщение от Аноним (81), 21-Сен-23, 16:58	+/–
Вот только не нужно говорить так, как будто это что-то хорошее. В отсталыхгосударствах тоже по любому поводу нужно пробежать по 10 местам, каждое — со своими часами работы, записью, требованиями и причудами. Потому что все отдельно друг от друга. Ну, если по другому представить себе не можешь — то, конечно, нормально. Спасибо, что не расстреляли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

191. Сообщение от Аноним (81), 21-Сен-23, 17:00	+/–
Апдейт выполняется в авторизованной мастерской квалифицированным персоналом. Сам тронешь — лишишься гарантии и права доступа к облаку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

192. Сообщение от пох. (?), 21-Сен-23, 17:07	+/–
В thin lvm это уже не так, но связываться с ним - такое себе...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174

193. Сообщение от пох. (?), 21-Сен-23, 17:11	+1 +/–
главное - веровать! Что есть мудрые дядечки у которых таааакие приборы (мы за гаражом вам покажем!) И что их петабайты вообще куда-то там бэкапаются а не как обычно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #269

194. Сообщение от Аноним (183), 21-Сен-23, 17:14	+/–
> В LVM тоже самое делается, только безопасней (на мой взгляд). Btrfs на поверку переживает крах и ребут даже при конверсии схемы RAID, на минуточку. И потом может возобновить конверсию, без напряга. Или даже жить неопределенное время с смесью схем, дизайну так то похрен: 1 из вариантов конверсии это запрос новой схемы для НОВЫХ записей, а старые блоки вообще не трогать. Ему так то пофиг, это логически-корректная ситуация для того дизайна. Ни к каким суровым проблемам сие не ведет. > У тебя атомарная функция (скорее всего) на уровне FS progs, а LVM это отдельная > сущность, вначале добавляешь диски, а потом только действия по раширяемости с ФС. В случае btrfs это вообще совсем иначе случается и радикально подперто внутренней механикой ФС. Есть block groups с той или иной схемой хранения. Просто регионы аллокации, 1...несоколько гиг на том или ином девайсе, для хранения данных или метаданных. Экстент лежит там или сям, у него вот такая схема хранения (RAID1 значит что те же блоки дублированы на другом девайсе/девайсаз). При конверсии схемы хранения экстент как я понимаю сперва создается с новой схемой, в другие блочные группы, после этого переназначаются указатели, а если все вышло, можно маркировать старый регион как свободный. Остальные операции ворочаются в таком же стиле. Де факто оно может быстро и довольно безопасно "расчистить регион интереса". А было это для конверсии схемы (перепрофилирования типа BG в иной), уменьшения ФС, изъятия девайса, или чего там еще - да не так уж важно, core логики примерно одинаковое. Ну вот такой вот забавный крутой дизайн. Пока вы там на конской хребитине бока пинали, другие тут уже эвон какие звездолеты с гипердрайвом вона как научились. И да, это атомарное - сперва копия, потом апдейт указателей на нее, потом деаллокация. Прелесть cow в том что аналог полного журнала халявен. И как вы понимаете - там не так уж много поводов для облома операций в таком то стиле. При крахе неудачная операция сама аннулируется "как обычно" - пока указатели не переназначили в новую локацию, этого вообще не существует. И это не блочный уровень уже, а скорее file-aware и space-aware, по backref известно чье оно, и можно удвигать только то что реально аллоцировано, со знанием дела. Если мы хотим почистить 10 гиг хвоста, и там чьи-то 100 кило на дороге стоят, удвигаются только эти 100 кило. И после этого можно спокойно откусить 10 гиг. Этим интеграция с ФС и аллокатором и крута. > На одну-две команды больше, не кричтино, в этом вопросе > соревноваться на пару секунд не имеет смысла. Ну, понимаете, ваши пинки по конским бокам пятками выглядят немного старомодно по сравнению с возможностями звездолета с гипердрайвом, бортовыми компьютерами и даже машиной времени, которая может просто отмотать взад если мне наблюдаемые реалии не нравятся. > VOLUME отдельно, RAID отдельно, FS отдельно. Никакого компота, каждый на своём уровне И в результате менеджмент становится миндфаком. Операции становятся медленными и печальными. А RAID1 сам по себе понятия не имеет ни какой файл побился, ни какая копия верная и не сделает self heal из исправной копии вот так сразу, в фоне, сам. В чем разница? Вон то в btrfs 1 командой делается. И даже на 1 девайсе похожее можно. И все это прозрачно, ненапряжно. А у вас спятишь пока даже половину от этого нарулишь в этом месиве циферблатиков, проводочков и стрелочек. А чтобы все и сразу - в вон том виде... эм... И да, знаете, когда оно само заруливает случайный разовый бэд, легко расширяется, конвертится, проверяет корректность работы железа чексум и проч - это прсото другой уровень менеджмента систем. Кент это понимает в отличие от "такпривыкли". Мир не вернется к более быстрым лошадям когда уже можно звездолет, как угодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

195. Сообщение от Аноним (-), 21-Сен-23, 17:23	+/–
> И дело не в на одну команду больше, а в том что > у тебя нижний уровень ничего не знает о том что на > нем лежит, а верхний не может переспросить нижний если что-то пошло не так. Ну а и btrfs интегрированность cow + знание аллокации таки дает все знания которые нужны, и недеструктивность для безопасности, и аналог журнала нашару. И на самом деле из продвинутого cow можно так то выжать что угодно завязанное на гибкость аллокации в любой точке - и реаллокации/реконфигурации при случае. > И да, повреждения на уровне lvm не диагностируются (кроме спонтанных крэшей вышележайшей > fs) и не исправляются. Ну а btrfs при креше вообще не имеет поводов что-то портить. Он вообще не успел перевесить указатель и это даже откатывать не надо. А если успел - ну, эта операция успешно завершена. И там не так уж много вариантов "in between". Кентушка посмотрел на этот праздник жизни да и подумал - а чего б ему не разыграть пару карт в дополнение к этому. Как то... 1) Низкий оверхед под суперскоростных то. 2) Иерархические хранилки с кешированием на более быстрых. В принципе это логичная хотелка, это логичная надстройка над гибким write-anywhere аллокатором так то. Раз дизайн может гибко (ре)аллоцировать что угодно куда угодно можно и вот еще свойства стоража учитывать в процессе. Почему нет?! Имеет свой пойнт вроде. > Хотя он сам по себе адски сложная структура с кучей метаданных и > сложных агломераций. И вполне умеет обернуться тыковкой. А чего ему не? Чудес не бывает. Если кто реализует энную логику, он никуда не денется от связанных с этим проблем. Интегрированные дизайны избегают проблем на стыке взаимодействий. > Вся эта ненужная иерархия ненужных "уровней" - от бедности. Попытка подкостылить устаревшие > файловые системы образцов 70х годов. Интегрированные дизайны так то в сумме сильно проще, дублирующаяся функциональность выпадает, а вон те взаимодействия без интеграции, когда правая рука не знает что делала левая - неуклюжие и стремные так то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #197

196. Сообщение от Менеджер Антона Алексеевича (?), 21-Сен-23, 17:24	+/–
> Маленький catch И не один! Дьявол в деталях. Как это всё по-твоему должно работать когда на ФС активно пишутся данные? Где и как хранить обратный индекс? Как обрабатывать ситуации аварийного завершения работы ядра? Что делать, если место на носителе кончилось посреди операции? Каково должно быть поведение резервирования свободного места? Про главный вопрос — производительность всего этого — ты сам написал. Действительно, можно и не дождаться окончания работы на забитой и фрагментированной ФС размером в 20Тб. Получается, что отрицательный онлайн-ресайз не такая уж и простая задача. А для оффлайна нет нужды морочиться: перенос данных на другой носитель будет быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #203

197. Сообщение от пох. (?), 21-Сен-23, 17:31	+/–
> Ну а и btrfs интегрированность cow + знание аллокации таки дает все знания которые нужны "если б еще и работало" - но raid6 "пишутъ!" (что в общем-то как бы и намекает на качество и всего остального кода) Но вон синоложы как-то выкрутилась, все же ухитрившись связать несвязываемое - у нее каким-то непостижимым чудом btrfs обломавшаяся о несовпадение контрольки, может сообщить этот факт lvm'у (но мы вам о них не расскажем и даже за гаражом не показывают - и возможно это жжж неспроста) Что разумеется не отменяет факта неумения никем из живущих (да и о мертвых известо скорее ничего чем хорошее) чинить рухнувший lvm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #202

199. Сообщение от Аноним (-), 21-Сен-23, 17:40	+/–
> Ну да. А у нехомяков появилась ещё одна замечательная уже почти-но-ещё-не-совсем production > риди(ТМ) фс на костыльно-грабельном ходу с паровым приводом - скоро можно > будет на альфа центавра за хлебушком сгонять (но глядя на f2fs/zfs-on-linux/btrfs > - это, разумеется, не точно). > Ура, товарищи! Я совсем не возражаю если вы будете упражняться в тао фигачения по конским бокам пятками, потому что вы так привыкли, занимать позу орла и наслаждаться тантрами с управлением систем с резким развалом без предупрежления. А насчет хлебушка... ммм... "do not ring-transport!" (c) надпись на ящике. Ну вот такая разница уровня технологий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189

200. Сообщение от Аноним (200), 21-Сен-23, 17:41	+1 +/–
> Особенностью Bcachefs является поддержка многослойного подключения накопителей, при котором хранилище компонуется из нескольких слоёв - к нижнему слою подключаются наиболее быстрые накопители (SSD), которые используются для кэширования часто используемых данных, а верхний слой образуют более ёмкие и дешёвые диски, обеспечивающие хранение менее востребованных данных. Вот уж реально киллер фича, но в комментах почему-то спорят о совсем другом
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #209, #222, #234, #244

201. Сообщение от kvaps (ok), 21-Сен-23, 17:55	+/–
> Actually, it's Redirect-On-Write, but nowadays Copy-On-Write usually refers to Redirect-On-Write as implementation
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #284

202. Сообщение от Аноним (-), 21-Сен-23, 18:01	+/–
>> Ну а и btrfs интегрированность cow + знание аллокации таки дает все знания которые нужны > "если б еще и работало" - но raid6 "пишутъ!" Дык работает. А RAID56 как бы явно маркированы как экспериментальные. Таки не вижу к чему придираться. > (что в общем-то как бы и намекает на качество и всего остального кода) В штуке размером с звездолет могут быть более отлаженные и менее отлаженные функции. И если тебе интересно как работает гипердрайв в атмосфере, ты можешь проверить на свой страх и риск, но тебе честно сказано - разработчики и сами лишь приблизительно понимают как оно :) > Но вон синоложы как-то выкрутилась, все же ухитрившись связать несвязываемое - у > нее каким-то непостижимым чудом btrfs обломавшаяся о несовпадение контрольки, может сообщить > этот факт lvm'у (но мы вам о них не расскажем и даже за гаражом не показывают - и > возможно это жжж неспроста) Агаблин, они смогли собрать эрзац варпдрайва из какого-то металлолома и похоже и сами не поняли как это вышло. Ну круто, приятного полета :) > Что разумеется не отменяет факта неумения никем из живущих (да и о > мертвых известо скорее ничего чем хорошее) чинить рухнувший lvm. Ну дык. Выбираем из того что есть. И поменеджив btrfs'а - на lvm вообще совсем не хочется что-то. Кент вот тоже меня в этом понимает по большинству пунктов. Поэтому делал свой звездолет по мотивам этого. Мне почему-то кажется что и остальные новые дизайны будут как-то так теперь. А вовсе не то что там в EXT4, с лимитом блин инодов. И прочие LVM где если потрахаться то может и будут чексумы и снапшоты но в таком виде что без слез не взглянешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

203. Сообщение от Аноним (-), 21-Сен-23, 18:40	+1 +/–
> И не один! Дьявол в деталях. Как это всё по-твоему должно работать > когда на ФС активно пишутся данные? Элементарно, Ватсон: 1) Избегаем записей в регион интереса. 2) Расчищаем его в фоне. Разумеется, возможен сценарий когда на маневр места не хватит. Если фс забита, удвинуть может быть некуда. Ну тут ой, "сотрите некоторые файлы и попробуйте еще раз". Нельзя ресайзнуть меньше чем реально занятое место. И желательно какой-то разумный резерв места после завершения операции + маневровый резерв. А так я это в btrfs проферял, работает. > Где и как хранить обратный индекс? Btrfs на это дерево завел, насколько я помню. Но вообще где угодно можно. Даже нигде - и отстроить с ноля в момент когда приперло, но тогда ценой концентрированной ломовой нагрузки в момент когда вон то приспичило - придется все forward indices обойти и отстроить реверс, а вон то в фоне при нормальной работе его отстроило. Это тоже не бесплатно и чуть замедлило операции. Но зато ускорило менеждмент. Как менеджер вы должны понимать "tradeoff". > Как обрабатывать ситуации аварийного завершения работы ядра? Это CoW. Записи недеструктивны. Сначала создается КОПИЯ экстента. Если будет крах, окей, этого никогда не было. Машина времени вернется в чуть более старое состояние. Можно попробовать еще раз. Если скопировать вышло, на передвинутый экстент будут переназначенй указатели в метаданных. В этот момент новое состояние зафиксировано, после чего можно деаллоцировать расчищаемый экстент в старом месте. У этой механики не так уж много мест для развала. Благодать cow в бесплатном по ресурсам эквиваленте полного журнала и простом крашрекавери :). Это кроме всего позволяет и передвинуть что-то относительно легко и безопасно. Расчистка конкретного девайса для ремува ничем принципиально не отличается. И даже конверсия в другую схему - примерно так же, проход по блочным группам с разбираемой схемой, а копии экстентов идут в другие BG с новой схемой. > Что делать, если место на носителе кончилось посреди операции? Сообщить -ENOSPC юзеру и вернуть неуспех операции ресайза. Ведь регион интереса расчистить не удалось и нельзя урезать логический размер. Пусть сотрет какое-то файло и попробует еще раз. > Каково должно быть поведение резервирования свободного места? Какой-то маневровый резерв должен быть конечно. А расчищаемый регион должен по возможности не использоваться. Но на самые пиковые случаи там есть GlobalReserve - если все остальное обломалось, немного маневрового места есть вот там. Тем не менее, если фалуха забита, странная идея ее ресайзить вниз. Обычно ресайзят если есть куда. > Про главный вопрос — производительность всего этого — ты сам написал. В случае btrfs это может быть довольно легкой, быстрой и ненапряжной операцией, потому что индекс как раз уже сразу есть, и можно просто взять и просто удвинуть что угодно из любого региона интереса. Если это хвост чтобы сократить размер ФС - ну окей. Или конкретный девайс, вот, вынуть. Просто удвинув с него то что реально аллоцировано. И если на 4Тб диске реально юзалось 20 гигз, удвинуто будут 20 гигз. Разумеется на других девайсах должно быть место для того чтобы их туда переопределить в нужной схеме. > Действительно, можно и не дождаться окончания работы на забитой > и фрагментированной ФС размером в 20Тб. Если кто забил cow на 20 тб до отказа - хотя мог просто диск подоткнуть, без заморочек - ну и кто ему доктор? Еще более странно что он это вниз ресайзить хочет при этом. Дурацким желаниям дурацкие свойства при реализации. Если вы хотите варпдрайв в атмосфере, бортовому компу пофиг, просят - сделает. Что будет дальше - не его проблемы. > Получается, что отрицательный онлайн-ресайз не > такая уж и простая задача. А для оффлайна нет нужды морочиться: > перенос данных на другой носитель будет быстрее. Это уже реализовано как минимум в btrfs. Что ресайз ФС по размеру вниз, что вынуть конкретный девайс из пула. Если на это все место есть - прекрасно работает. Так что сложно. Было. Кому-то. А нам вот тут в звездолете кнопочку нажать - и варпдрайв нас переместит в назначение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #228

204. Сообщение от Аноним (-), 21-Сен-23, 19:06	–2 +/–
> очередной свидетель ужасов ipsec, видевший его только во сне. Ты как минимум в чем-то прав. Например, я предпочел забыть такие технологии как страшный сон. Если можно @#$ться в разы меньше а результат даже лучше, way to go. > наши ~4000 смотрят на тебя как на ... - Так, хорошо... очень хорошо. - А что хорошо, док?! - Хорошо, что все это - не у меня! > А вот как ты будешь приземлять 4000 вайергадов и следить за тем > что кто-то лишний не получил чего-то ненужного - я поржу. Да ржи себе, ржи. А я посмотрю что твои road warriors будут делать оставшись без впн в наобум взятой кафехе где никто не будет рулить им кастомные правила фаера. Впрочем твои галерщики небось те еще road warrior, с цепью и на галере. > от твоих - нет. Потому что это не знания а сборник мифов > и легенд в пересказах перепевов. > Сливай и иди в плесень-и-точка. Там опять некому убирать сортиры. Как говорится, рекомендации лучших собоководов, но, погоди, ты вроде ж собак мыть собирался? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #214, #285

205. Сообщение от Аноним (-), 21-Сен-23, 19:11	–2 +/–
> просто пофигу. Никому в 2k23 неинтересно занимает ли твоя "система" вместе с > ненужно-снапшотами которы ты никогда не будешь использовать, 12 гигабайт или восемь. >  Вообще. Совсем. Да то что у тебя менеджмент систем унылый и ты знаешь как сделать все хреново, криво и подолбаться по максимуму - я уже понял. Поэтому ориентироваться на тебя смысл разве что в вопросе - фу каким именно быть :P. Иди вон свой айписекас настраивай, в перерывах между окучиваниями XFSов на LVM. А я предпочту что-то менее брейнфакерское.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

206. Сообщение от Аноним (90), 21-Сен-23, 19:19	+/–
нет тут RoW, если правильно описано в новости
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

207. Сообщение от Аноним (-), 21-Сен-23, 19:21	+/–
>> Да вот видите ли - он выиграть может... >> 1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару > сколько его? А где как. На системных SSDшниках места не так уж и дохрена, оно денег сотит, а там на него и еще претендентов немеряно. У меня /builds весит более 300 гиг. И то что он сжался раза в 2.5 было очень кстати так то. > вообще похрен всем. Неплохо если терабайт подешевеет - но откуда у него > СТОЛЬКО сжимаемых данных чтоб освободить терабайты. Ну я вот например софт билдую чартерными рейсами, в том числе и довольно увесистый, мало ли. А иногда у меня достаточно забавные датасеты вот есть. Ну там например здоровенные вербозные трейсы всякой отладочной байды. Которые жмутся изумительно - а вот размер может быть довольно почтенный, ибо трекало что-то довольно быстрое, околореалтаймно. >> 2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить - > ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад). Ну я больше верю статистике своих девайсов чем каким-то гугелям. И просто здравому смыслу. > у меня для тебя опять облом - пока ты в криокамере мерз, > ТАКИЕ документы перестали сжиматься, они уже. Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука. Там правда есть и более разумные форматы, в том числе и уже-сжатые. Но planet xml больше софта жрет и вот там декомпресс от и до почти 300 гигз архивером - видите ли очень напрягает. А прозрачно и фс, может даже сделать лучше чем было. Seek в произвольное место же остается. > А сервант твой потеряет гораздо больше времени на обработку запроса а не > собственно отдачу файла. Если сервант на 1000 запросов профакивает 10 секунд - что он там делал? Пыхтонрас чтоли запускал? > Особенно если он пришел к нам из тех же годов что чудо-диски по терабайту. И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел. А уж какой LZ4 даже и на энтерпрайзном SSD может не спасовать по скорости распаковки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #211

208. Сообщение от Аноним (-), 21-Сен-23, 19:24	+/–
> Ок, ширпотребный НОВЫЙ хард на текущий момент это 8ГБ для ПК и > 2 ГБ для ноутов, судя по первым результатам категории "Internal hard > drives". Вот прям ГБ? Путешественник во времени не палится :) > Если начать комментировать, что за ширпотребный хард (пусть даже будущего) ты берешь > хард из линейки для датацентров, то в конце можно подытожить только > диагнозом. А поэтому дома у него будет кака-то виндочка в хомячной конфигурации. И тут он только кислотой плюется на тему как у нас там зелен виноград.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #212

209. Сообщение от Аноним (209), 21-Сен-23, 19:42	–1 +/–
ZFS такую "особенность" имеет с рождения
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #213

210. Сообщение от Аноним (-), 21-Сен-23, 19:49	+1 +/–
> btrfs жмет не файл целиком, а его куски по 128 КБ, поэтому > тут навряд ли количество совпадений будет сильно отличаться при разных уровнях сжатия, А таки - некая зависимость плотность сжатия vs скорость остается. Поэтому сие делают выбирабельно. Если у вас супербыстрый SSD а проц маломощный вы наверное LZ4 на минималках хотели. А если тормозной винч, на мощном проце, вас и zstd с солидной степенью сжатия не напряжет, а IO немного убавится. Как и суммарное время операции. Ну да, может на несколько процентов. > а решать будет скорее то, как алгоритм отрабатывает в среднем, но я не шарю. Ну вон то и определяет что будет в среднем. Низкие уровни - вырубают matchfinder рано. Поэтому жмет заметно быстрее, хоть и хуже. А какое соотношение оптимально в конкретном случае - зависит от деталей. И может завести в довольно дальние дебри pareto frontier'а, у этих, от сжатия, свои граали тоже есть. > бьет по времени доступа к содержимому из-за фрагментации, но я чето > уже и не помню где глянуть бенчмарки, чтобы оценить какой выигрыш > дает хранение файла "сплошняком". На механике фрагментация это фу. На SSD - сильно меньше фу, можно не очень париться. А большой непрерывный экстент всяко эффетивнее кучи мелочи. Вопрос в масштабе эффекта и стоит ли оно заморочек в конкретном случае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #224, #226, #297

211. Сообщение от пох. (?), 21-Сен-23, 20:23	+/–
> А где как. На системных SSDшниках места не так уж и дохрена, оно денег сотит, а там на него и еще > претендентов немеряно. У меня /builds весит более 300 гиг. страдания долбанавтов держащих какой-то ненужный мусор в системном разделе вместо системы - очень конечно ценны для мироздания (нет) >> ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад). > Ну я больше верю статистике своих девайсов чем каким-то гугелям. И просто здравому смыслу. ну да, ну да - типа тех что выше. Куда там гуглю с его миллионами серверков. (вот у него - статистика, а не высосанные из пальца на основании трех экземпляров прогнозы) > Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука. сочувствую. > Seek в произвольное место же остается. естественно, нет. Имитируется с изрядными потерями. > И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел. пока она не превращает твои данные в невосстановимую кашу. Что с модными технологиями увы сплошь и рядом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207 Ответы: #220

212. Сообщение от пох. (?), 21-Сен-23, 20:31	+/–
>> Ок, ширпотребный НОВЫЙ хард на текущий момент это 8ГБ для ПК и >> 2 ГБ для ноутов, судя по первым результатам категории "Internal hard >> drives". > Вот прям ГБ? Путешественник во времени не палится :) если по цене отсортировать то могут и дискеты вылезти. Пятидюймовые. > А поэтому дома у него будет кака-то виндочка в хомячной конфигурации. И > тут он только кислотой плюется на тему как у нас там > зелен виноград. да-да. конечно-конечно. Владелец хлама страдающий от 300гигового какого-то там build точно знает. Кстати, кому продать восемь штук тех самых "новых на текущий момент" 8T самовывозом в Москве? (тоже датацентровских но не совсем - ну собственно, не дятел по тем двум ссылкам подряд бы все понял) Они, конечно... а впрочем, зачем дятлам лишняя информация. Новые, пля буду! Вон поциент уверенно говорит что во всех новейших ПК такие! Проект под который я их покупал, к сожалению, уже не будет реализован - в спецоперационное время не место подобным проектам. Только зря место занимают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #221

213. Сообщение от пох. (?), 21-Сен-23, 20:33	+/–
> ZFS такую "особенность" имеет с рождения отродясь не имел. тут layered storage а не т-пой да еще и де-факто неработающий кэш только на чтение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #223, #256

214. Сообщение от пох. (?), 21-Сен-23, 20:54	+1 +/–
> Ты как минимум в чем-то прав. Например, я предпочел забыть такие технологии как страшный сон. "забыть" то о чем никогда ни малейшего представления не имел. Ну да. Уровень местных "гуру". Ну так может тогда и не будешь звездить о том чего не знал а потом забыл? >> наши ~4000 смотрят на тебя как на ... > - Так, хорошо... очень хорошо. > - А что хорошо, док?! > - Хорошо, что все это - не у меня! но ты продолжай рассказывать сказочки о том что "решительно непригодно". Твой огромный опыт виден за версту! Опыт локалхоста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #217

215. Сообщение от пох. (?), 21-Сен-23, 21:01	+/–
> IPSec как раз таки и является самым нормальным VPN. Точнее IPSec это > лишь шифрование. ipsec это и есть vpn. Вполне образует эту самую virtual network произвольной топологии. (или не образует - это уж кому как удобно) Причем, вполне себе может обойтись и вовсе без ike, и уж тем более - windows-only костыля l2tp (его смысл в том же в чем ipsec interface в некоторых других ОС, только слепили из того что было, не заморачиваясь эффективностью). ike - это всего лишь механизм key exchange (первая буква там преданье старины глубокой и давно устарела). Один из возможных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #237

216. Сообщение от Аноним (-), 21-Сен-23, 21:08	+/–
>> Пробовал летать на самолёте отдельно без крыльев, кабины и двигателя? > Всё летает, LVM отдельно, FS отдельно. Ноу проблем. Вас наели, это не самолет, это жигуль ржавый. А летит он и правда без двигателя. То-есть двигатель конечно на месте, но не тот. Просто с обрыва что угодно летит. Вон тот то читер гипердрайв ща врубит - ДО встречи с поверхностью. А у вас в жиге оно где?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #270

217. Сообщение от Аноним (-), 21-Сен-23, 21:16	–2 +/–
> "забыть" то о чем никогда ни малейшего представления не имел. Ну да. > Уровень местных "гуру". Ну так может тогда и не будешь звездить о том > чего не знал а потом забыл? Да вот к сожалению пришлось немного познакомиться. Откуда и узнал что знатный пример как протоколы и технологии делать не нужно. Оверинжерентутое ушлепище, неоправданно канительное в кофигурации. Designed by comittee такой, классический просто. > но ты продолжай рассказывать сказочки о том что "решительно непригодно". Да я могу себе представить как оно у тебя работает и насколько вон те похожи на road warrior'ов в их нормальном виде. > Твой огромный опыт виден за версту! Опыт локалхоста. Ну как бы твой чудный опыт привел тебя к тому что заниматься хобби - низя, и это свободой называется. Почему-то. И прочие рекламы виндов. А я имею наглость полагать что возможны варианты и поприкольнее чем такой ацкий трешак. Так что спасибо за ценные советы по достижению успеха, коенечно. Я буду знать на твоем примере как именно делать ни в коем разе не стоит. Учиться на чужих ошибках это прикольно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

218. Сообщение от Минона (ok), 21-Сен-23, 21:17	+/–
> Нет, кури мануалы поактуальнее Угощай, покурим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

219. Сообщение от maximnik0 (?), 21-Сен-23, 21:30	+/–
https://www.opennet.me/opennews/art.shtml?num=30826
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

220. Сообщение от Аноним (220), 21-Сен-23, 21:35	+/–
> страдания долбанавтов держащих какой-то ненужный мусор в системном разделе вместо системы > - очень конечно ценны для мироздания (нет) Я уже понял что твой потолок использования компьютеров - это хомячить. А софт видимо как булки. на деревьях растет. И остальное тоже. > ну да, ну да - типа тех что выше. Куда там гуглю > с его миллионами серверков. (вот у него - статистика, а не > высосанные из пальца на основании трех экземпляров прогнозы) А кто сказал что ворклоады гугля похожи на мои? Поэтому ориентироваться на локальные показатели в конкретике мне как-то больше доверия внушает. >> Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука. > сочувствую. Да чего мне сочувствовать? Я в результате могу себе up-to-date карты "региона интереса" с нужными объектами, вот, скрафтить, по вкусу, за обозримое время. Из глобальных общепланетарных данных OSM. И далее навигировать по этому - в полном офлайне, не спрашивая "благодетелей" типа гугла и проч, c пофигом на то есть ли в локации интернет вообще. Это позволяет мне быть в аспекте "навигация" сильно выше средне-хомячьего. Имел возможность сравнить. >> Seek в произвольное место же остается. > естественно, нет. Имитируется с изрядными потерями. Да ну там максимум кил 128 чтоли, и это быстро распаковывается а seek в XML не так уж часто нужен. На выбор жатые protobuf - они компактней в 10 раз но видите ли там random seek нету и скорость процессинга ничуть не лучше, а есть o5m - уже более потребное по структуре, но с ним мало софта работать умеет, вот и выбирай? что называется, как эту "бигдату" окучивать. Как одна из опций распакованая но сжатая ФС чушка XML - не такой уж плохой вариант оказался. >> И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел. > пока она не превращает твои данные в невосстановимую кашу. Что с модными > технологиями увы сплошь и рядом. Ну хз, что-то нет у меня этих каш. Да и я знаю где btrfs'ники и более-менее понимаю структуру звездолета и основные инженерные системы. И принципы работы основных частей знаю, так что при острой нужде могу и более-менее пофиксить, с пониманием что и зачем я делаю. А вот как ты из тех железок LVM и проч эрзац варпдрайва пытался собрать для меня вообще загадка, тем более что работает это все еще сыкотнее - ну я и не понял почему оно круто и безопасно. Если для тебя это лучше пашет - ну и лажушки. А я лучше вон то погоняю. Каждый человек имеет выбор - а потом выбор человека.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

221. Сообщение от Аноним (-), 21-Сен-23, 21:49	+/–
>> Вот прям ГБ? Путешественник во времени не палится :) > если по цене отсортировать то могут и дискеты вылезти. Пятидюймовые. Эм, ну я бы взял себе несколько штук для антуражу. И винчей и дискет. Если по бросовой цене, конечно. Данные я конечно там хранить не буду, чисто как артефакт или клевую механику. > да-да. конечно-конечно. Владелец хлама страдающий от 300гигового какого-то там build точно знает. Ну ты сам же и вещал что у тебя виндочка. Отмазывайся теперь. Желающие могут клацнуть профайл сэра поха и найти все художества лично, интернет цуко злопамятный :). А вот на виндочке те развлечения будут смотреться тухловато, там с такими объемами операций ФС перфоманс будет в разы хуже и это совсем не круто. > Кстати, кому продать восемь штук тех самых "новых на текущий момент" 8T > самовывозом в Москве? (тоже датацентровских но не совсем - ну собственно, > не дятел по тем двум ссылкам подряд бы все понял) > Они, конечно... а впрочем, зачем дятлам лишняя информация. Новые, пля буду! Вон > поциент уверенно говорит что во всех новейших ПК такие! Я бы покупая у сэра поха что-то - смотрел бы SMART в оба и что за модели и почему этот тип вообще слить хочет :) > Проект под который я их покупал, к сожалению, уже не будет реализован > - в спецоперационное время не место подобным проектам. Только зря место занимают. Посматривая на длинный список эвентов за неделю - КМК не очень долго тебе уже печалиться уже осталось, несмеяна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

222. Сообщение от Аноним (-), 21-Сен-23, 21:53	+/–
> Вот уж реально киллер фича, но в комментах почему-то спорят о совсем другом Видимо не всем столько счастья надо и не все понимают что вообще можно вытворять с улучшенным вариантом гипердрайва Mk II :) Дла этого надо все же немного войти во вкус и познать вещи за пределами EXT4, блин.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

223. Сообщение от Аноним (-), 21-Сен-23, 21:56	+/–
> тут layered storage а не т-пой да еще и де-факто неработающий кэш > только на чтение. Ну да. В общем то Кент достаточно забавно понял как еще можно с write-anywhere развернуться, учитыая свойства девайсов. Не "прикрутив пороховую ракету к телеге" - а именно заархитектив изначально как нечто сразу сделаное для таких вещей. КМК так оно сильно лучше будет работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

224. Сообщение от fumanchez (ok), 21-Сен-23, 22:02	+/–
> Если у вас супербыстрый SSD а проц маломощный вы наверное LZ4 на минималках хотели. Пожалуй да, хоть zstd:1 неожиданно хорошо себя показал в плане сжатия, но ради интереса перегоню на днях хомяк в lz4, не думаю, что он пожмет сильно хуже. А для раздела с играми на харде zstd:6 оказался хорошим выбором, не заметил каких-то заметных просадок в еле идущей на этом ноуте Baldur's Gate 3 (а я еще и сейвскамер). Но я пока не могу определиься с 2-мя разделами - корень (тут у меня пока с древних времен ext4) и раздел с гит-репозиториями (а тут xfs, просто надеюсь, что она хоть что-то дедуплицирует). Корень это пожалуй рекордсмен по количеству операций чтения, и постоянное разжатие это повышенное использование процессорного времени. А репозиторий с сорцами ядра или просто папка node_modules это тонна файлов, а у btrfs как раз основная проблема, что она неадекватно распухает от метаданных. Так что в обоих случаях может оказаться, что игра не стоит свеч. Может быть даже есть смысл вместо btrfs смотреть в сторону zfs, ведь по идее ноутбучная DDR память довольно энергоэффективная, а сама zfs более продвинута в плане размещения данных на диске.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #230

225. Сообщение от Kuromi (ok), 21-Сен-23, 22:12	+/–
> Ну вообще f2fs таки удобен флешу - и в целом снижает возню > для контроллеров. Но он не многодевайсный. И у него есть проблемы > с надежностью. И каких-то продвинутостей в управлении у него нет. Это > пофиг если это на веки вечные прибитый на гвозди раздел в > мобилке. Зато это большие грабли если это хранилка с несколькими дисками. На самом деле он уже несколько лет как многодевайсный, при создании ФС (и позже тоже) есть режим который объединяет несколько разных устройств в одну ФС. Там и много поточность задумана и вцелом оно так быстрее. Но есть косяк - никаких особых метаданных идентифицирующих отдельные "тома"в связке нет, поэтому если при создании использовать имена устройств вида /dev/sda оно так к этим именам жестко и привяжется. Не дай Бг у вас изменится имя хоть одного девайса в связке и ФС не смонтируется. Выход из этого есть - создавать на каждом устройсве таблицы разделов с 1 разделом  и при форматировании собирать их в связку адресами по UUID разделов. Проблема в том что документация у F2fs очень так себе. Все буквально надо методом проб и ошибок выяснять. Самсунг такой самсунг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #229

226. Сообщение от fumanchez (ok), 21-Сен-23, 22:23	+/–
> А соотношение оптимально в конкретном случае - зависит от деталей. И может завести в довольно дальние дебри pareto frontier'а, у этих, от сжатия, свои граали тоже есть. Кстати раз уж btrfs выбрали жать фиксированные куски, то может когда-нибудь они вкорячат что-то по типу радужных таблиц для хеш-функций, и будет какой-нибудь вариант с зарезервированной таблицей, где какие-то блоки заранее просчитаны с самыми лучшими параметрами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #232

227. Сообщение от ivan_erohin (?), 21-Сен-23, 23:43	+/–
> ограничения на папку для контейнеров нужны. какого рода ограничения ? man ext4 | grep -i quota
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

228. Сообщение от Менеджер Антона Алексеевича (?), 22-Сен-23, 00:57	+/–
Так BTRFS и ZFS уже есть, туда кодить не надо, там всё уже работает. Если ты посмотришь с чего ветка началась, увидишь, что накодить это нужно для XFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #236, #249

229. Сообщение от Аноним (-), 22-Сен-23, 01:46	+/–
> На самом деле он уже несколько лет как многодевайсный, при создании ФС > (и позже тоже) есть режим который объединяет несколько разных устройств в одну ФС. О, и правда завезли. Но ты уж извини, там про лишь рассмотрение как 1 большого девайса, а это по надежности... ну знаешь, у меня оно пару раз при тестах и с 1 девайсом наповал подыхало, да так что ни ядром смонтировать, ни fsck не чинит - и в общем то финиш. На этот случай плана нет совсем. А если туда эн девайсов еще - это ж как я понимаю не RAID с избыточностью, а нечто типа абстракции типа JBOD, и оно скопытится еще быстрее стал быть. Я своим данным не настолько враг. > Там и много поточность задумана и вцелом оно так быстрее. Многопоточность можно сделать и без таких извращений с девайсами, XFSники проверяли. А для вон того звездного крейсера btrfs - так то тоже Mk II для гипердрайва как раз именно эту тему обыгрывает. Известно под кодовым именем "Extent Tree v2", пока WIP и не финализовано. А тут еще кентушка вот - посмотрел на это все и в целом "содрал с btrfs" только основательно облегчив, ускорив и озаботившись еще и иерархией девайсов и учетом свойств. Что как бы круто и правильно. CoW write-anywhere аллокатор и фоновая логика может учитывать свойства носителей и статистику обращений при решениях. Почему нет? Хорошо когда о такой крути подумано на фазе дизайна. > Но есть косяк - никаких особых метаданных идентифицирующих отдельные "тома"в связке нет, > поэтому если при создании использовать имена устройств вида /dev/sda оно так > к этим именам жестко и привяжется. Не дай Бг у вас > изменится имя хоть одного девайса в связке и ФС не смонтируется. Я уже догадался что f2fs не парится сохранностью данных когда при powerloss-тестах он у меня вскоре скончался и fsck не смог починить до моунтабельного состояния. А вон то дополняет общую картину. Не думаю что среднего пошиба кодеры серьезно умеют в "архитектуру", это даже не мэйсон хотя-бы. И даже не кент слизывающий идеи с лучших из. Это замордованый корейский кодер на котором висело 3-4 здоровых проекта. Тут даже если умеешь в архитектуру, на это тупо ресурсов не хватит. Человек может воротить в единицу времени ограниченный объем работ, и манагерье из самса явно забыло про такую фигню. Ну оно и работает под стать, f2fs стремноватая штука, в ksmbd cve'шки и проч. Скажите спасибо что с такой нехваткой ресурсов вообще трепыхается как-то. Для референса, btrfs вообще ни разу на таких тестах не сдох. Ext4 тоже в принципе живет, но в конце концов он мне начал икаться тем что все может сдохнуть на рандомных единичных бэдах. С парой тазиков может и терпимо, а если выводки одноплатников гонять, годами - такое себе, пришлось btrfs с схемой DUP любить, более живуче получилось + раннее предупреждение. > Выход из этого есть - создавать на каждом устройсве таблицы разделов с > 1 разделом  и при форматировании собирать их в связку адресами > по UUID разделов. Я конечно понимаю что некоторые любят сами фигачить кувалдой по колесу телеги. Но вот сходишь так, посмотришь как промробот все 4 колеса за секунды привинчивает и понимаещь что это можно делать и поприличнее уже. Да и ради чего это все? У этой шляпы даже чексум на данные как я понимаю нет, а с ее надежностью пачка девайсов - улучшает шансы на залет. > Проблема в том что документация у F2fs очень так себе. Все буквально > надо методом проб и ошибок выяснять. Самсунг такой самсунг. У нее по моему ВСЕ ВООБЩЕ - "так себе". Потому что 1 перегруженного jeon'а на все и сразу ну вот никак не хватает. Чувак просто в какой-то момент зашился окончательно. Нельзя столько работ на 1 чела подвешивать, результатом их хреновое выполнение становится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #239, #242

230. Сообщение от Аноним (-), 22-Сен-23, 02:41	+/–
> Пожалуй да, хоть zstd:1 неожиданно хорошо себя показал в плане сжатия, Zstd делал тот же кодер что LZ4, это творение Cyan'а. Технически это "что-то типа LZ4" но - мощнее, жирнее и с entropy coder за ним, на основе новомодного ANS от Jarek Duda. По своему забавное комбо. Потому что как минимум точно может по степени сжатия дать мастеркласс gzip'у, на топовых уровнях почти садясь на хвост грандам типа LZMA (который слоупок) и Brotli (этот читерит, и "в чистом виде" не так уж крут) - но при этом даже быстрее в распаковке. Смысл брать gzip при существовании zstd минимальный, но видимо уже были тома с вот этим, не обламывать же их?! LZ4 технически в общем случае быстрее за счет отсутствивя entropy coding за ним. Но и жмет он хуже в результате. Так что оптимальность штука многогранная. Уровень сжатия zstd актуален если много ЗАПИСЫВАТЬ и быстро: на высоких уровнях да с хилым процом это может в проц упереться, недогрузив девайс на ЗАПИСЬ. Распаковка в разы быстрее и ее скорость не сильно зависит от поюзаного уровня. Врядли baldurs gate много ЗАПИСЫВАЕТ. Зачем гамесе много записывать? А на распаковку - там еще зависит жатые ли у него ресурсы или нет. Некоторые гамесы сами сжатые типа-архивы юзают, им с сжатия в ФС мало что перепадет. А если ассеты не сжатые тогда сжатие что-то отыграет. Что до XFS сам по себе ничего не дедуплицирует. Но с неких пор его таки научили в рефлинки. И можно сделать "thin" копию которая изначально ссылается на блоки оригинала а дальше по мере расхождения обеспечивает абстракцию что это независимые файлы. Изначально фокус btrfs, но XFS а недавно наконец и ZFS этому научили. Сабж тоже это вероятно или умеет или скоро будет уметь, куда оно денется, для cow стыдно такую семантику не уметь. В btrfs также можно и оффлайн-дедупнуть идентичные файлы тулсами типа jdupes. Хз, может уже и на XFS работает если оно заимплементило "same extent ioctl", для XFS я это не проверял. После их демарша с выносом v4 в obsolete без путя конверсии в v5 я их разобрал и btrfs'ом сделал, коли уж крушить так пусть тогда и cow полноценный и управление местом по первому классу. Они вон scrub и автопочинку до сих пор осилить не могут, да и многодевайсность там это боль. > zstd:6 оказался хорошим выбором, не заметил каких-то заметных просадок в еле > идущей на этом ноуте Baldur's Gate 3 (а я еще и сейвскамер). Да я и сам zstd местми юзаю на btrfs. Главное /boot в zstd не сжать случайно если grub старый и без поддержки zstd, а то тот очень обижается на "unknown compression algo". Каким-то дистрам актуально у каких-то он уже zstd умеет. > это пожалуй рекордсмен по количеству операций чтения, и постоянное разжатие это > повышенное использование процессорного времени. XFS вообще довольно интенсивная по метаданным штука и идея разложить на него пачку репов git как по мне довольно спорная. У меня такое ощущение что даже btrfs его заметно делает на таких нагрузках. При том умея кучу продвинутостей. > проблема, что она неадекватно распухает от метаданных. Так что в обоих > случаях может оказаться, что игра не стоит свеч. Да черт знает, от штук размером с линукскернел вроде не так уж и распухает, я еще рефлинкаю билддиры на оригинала и они и копируются "очень быстро" и места жрут сильно меньше суммарного веса. > Может быть даже есть смысл вместо btrfs смотреть в сторону zfs, ведь > по идее ноутбучная DDR память довольно энергоэффективная, а сама zfs более > продвинута в плане размещения данных на диске. ZFS был самым первым - с фига ему эффективным быть? Это даже еще не экстентный аллокатор, какой-то недопилок с "блоками переменных размеров" как максимум. Поэтому и затыкают его скорость работы гигазами рамы, рамдиски то быстрые. Но с подпором ...цать гиг опертивы что угодно - быстрое. Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым. Btrfs появился позже и их поэтому хватило на нормальные экстенты, tail packing, хранение мелких файлов сразу в деревьях (что быстрее, особенно на механике, не надо головы гонять хз куда, данные сразу доступны). Ессно свои проблемы тоже есть. Но актуальны больше на многодисковых конфигах и особенно желающим продвинутостей типа RAID5/6 и проч. На самом деле крутой и фичастый дизайн, но это же и усложняет доведение до ума в мелких деталях. Самый заметный минус - не делался под "низкий оверхед" с самого начала, на суперскоростных SSD все же заметно. Сабж - дизайнился еще позже. И потому пытается вобрать лучшие черты всех предшественников. Обойдя их недостатки. Серебряных пуль - не бывает. Но в целом - ключевые решения btrfs напоминают но с вниманием к оверхеду и скорости, и вот еще иерархические хранилки, это конечно не для тех кто на разделы что-то нарезает, а для тех кто несколько девайсов хочет, сочетая сильные стороны разнородных устройств. Есть скажем гибриды SSD+HDD где SSD буферизует запись, а потом неспешно сливается на HDD. Сабж делает сие уже софтварно - из того что есть - и подконтрольно владельцу, не требуя гибридных устройств и давая больше контроля над этим аспектом. По своему круто. Если есть HDD и SSD можно получить почти скорость SSD и емкость HDD. Если правильно нарулить вон то. Нюансы конечно будут. Но все же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224 Ответы: #240

231. Сообщение от Аноним (231), 22-Сен-23, 02:43	+1 +/–
> И ext4 хватает за глаза Тебе на твоём localhost хватит и windows 98 с fat32.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

232. Сообщение от Аноним (-), 22-Сен-23, 03:19	+/–
> Кстати раз уж btrfs выбрали жать фиксированные куски, то может когда-нибудь они > вкорячат что-то по типу радужных таблиц для хеш-функций, и будет какой-нибудь > вариант с зарезервированной таблицей, где какие-то блоки заранее просчитаны с самыми > лучшими параметрами. Боюсь вам ОЧЕНЬ не понравится размер таких таблиц. Для них даже ZFS с его зеттабайтами маловато будет. Просто для понимания, всего 16 байтов уже 2^128 вариантов значений, комбинаторика штука злая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #241

234. Сообщение от Аноним (66), 22-Сен-23, 07:15	+/–
Устарело, нынче модно всё на ssd или nvme
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #245

236. Сообщение от пох. (?), 22-Сен-23, 08:54	+/–
> Так BTRFS и ZFS уже есть, туда кодить не надо, там всё уже работает. лолшта? zfs научилась уменьшать размер пула? А пацаны-то и не знают... Все что она кое-как научилась делать - это выкинуть из пула целиком vdev, но... только не raid. Т.е. феерично бесполезная фича.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228 Ответы: #247

237. Сообщение от Пряник (?), 22-Сен-23, 10:20	–1 +/–
> ipsec это и есть vpn У IPSec два режима: транспортный и туннельный. В транспортном шифруется только сам IP пакет, поэтому нужно создавать туннель, для чего как раз и используется L2TP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

239. Сообщение от Kuromi (ok), 22-Сен-23, 13:01	+/–
Да, у F2FS вообще нет никакиого намека на менеджмент томов, там просто объединяют устройсва в одну ФС. Примитивно - да, но вот такой ответ "модным ФС". ут можно лишь сказать что ext* и так не умеет. Ну, насчет надежности у F2FS все хитро. Она под SSD рассчитано, а они обычно работают-работают да и умирают, напрочь. Частенько даже в SMART никаких явных намеков на проблемы, просто либо табилца трансдяции умирает (и  привет) либо read-only режим и досвиданья. С копированием фич у других ФС наверное не так просто выходит, все таки у F2FS битмэпы, log-based и все дела. Архитектура такая что не все новое и можное можно взять и приделать. Ну а что разраб перегружен, это да. Даже жаль, у меня на F2FS  на SSD  в общем неплохо себя показывает. С мощными косяками пока не встречался, но резервные копии ценного имею.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #251

240. Сообщение от fumanchez (ok), 22-Сен-23, 13:33	+/–
Вчера таки еще разок заглянул на страничку Compression в доке btrfs, и оказывается lz4 у них нема, только lzo, так что кажется я вспомнил, почему именно выбрал zstd:1. А так по методам сжатия полностью согласен, для меня есть только lz4, zstd и понемногу уходящий старичок gzip, а всякие xz, bzip2, brotli слишком медленные даже на разжатие. Причем даже zip архивы удобнее, DEFLATE все-таки хорошие цифры показывает. > Зачем гамесе много записывать? F5 - и пошла запись, правда это обычно объемы небольшие, но в процессе игры. > А на распаковку - там еще зависит жатые ли у него ресурсы или нет. На самом деле многие файлы btrfs не трогал, а игру я уже удалил и точно не помню, как она разместилась, вроде игра похудела на 12 ГБ, т.е. почти на 10%. А так, многие игры перестали жать ресурсы и постоянно подгружают какие-нибудь текстуры с диска, и я видел игры, которые даже не тромбуют ресурсы в архив типа tar, а тупо держат каждую текстурочку в виде отдельного файла - интересно как такие пациенты себя поведут. Но игры обычно упираются в GPU, а в CPU по идее должно оставаться немного "воздуха" на незатратное разжатие, так что игоры я буду жмать. > XFS вообще довольно интенсивная по метаданным штука и идея разложить на него пачку репов git как по мне довольно спорная. Ну тут просто надо остановиться на чем-то одном, а xfs (v5) вроде пободрее мейнтейнят и inode он выделяет динамически, значит по идее не должны внезапно закончиться. С дедупликацией только я так и не поигрался, но как-нибудь создам 2 раздела с xfs и btrfs, гляну чего можно добиться для тех же исходников ядра. Особенно интересно, можно ли добиться online дедупликации на моменте git clone. > ZFS был самым первым - с фига ему эффективным быть? > Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым. Вот этого не знал, я думал это btrfs долгое время был вообще непригодным к использованию и до сих пор легко ломается, а zfs сразу бодро встал и пошел за счет удачного дизайна. Надо пожалуй будет матчасть таки прочитать, потому что рассматривание бенчмарков себя не оправдало - по-прежнему многие места не понятны, да и милисекунды - хреновая метрика, как и синтетические случаи, в которых можно израсходовать все место на разделе c btrfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230 Ответы: #262

241. Сообщение от fumanchez (ok), 22-Сен-23, 13:38	+/–
Ну да, тут херню сказанул, да и таблицы для паролей еще и под укороченный алфавит делаются. И какие-то словари уже запихнуты в сам алгоритм. Хотя наверное можно что-то придумать, как-то подшаманить алгоритм под задачу сжатия фиксированных блоков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232

242. Сообщение от Kuromi (ok), 22-Сен-23, 13:52	+/–
Кстати многопоточность в F2FS была всегда. По умолчанию она пишет на диск в 4 (кажется так) потока в рассчете на многоканальные контроллеры памяти. Другой вопрос что недорогие диски сейчас частенько имеют 1 канал всего, да и вообще канальность зависит от количества чипов NAND, если он один (а так клепать М.2 намного проще и формфакто может быть еще меньше), то извините. Поддержка многих устройсв одной ФС позволяет эту проблему слегка порешать. На форониксе тесты были, прирост и правда есть, хотя и не гигантский, порядка 10%. Там кстати в проблему с именованием устройсв при форматировании не заметили тупо потому что протестировали и забыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

243. Сообщение от Kuromi (ok), 22-Сен-23, 14:01	+/–
>> прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), > зачем этот выбор? У F2fs тоже несколько на выбор. Это нынче норма, главное чтобы в будущих обновлениях ВДРУГ не оказалось бы что данные сжатые алгоритмом Х больше не читаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

244. Сообщение от Kuromi (ok), 22-Сен-23, 14:03	+/–
>> Особенностью Bcachefs является поддержка многослойного подключения накопителей, при котором хранилище компонуется из нескольких слоёв - к нижнему слою подключаются наиболее быстрые накопители (SSD), которые используются для кэширования часто используемых данных, а верхний слой образуют более ёмкие и дешёвые диски, обеспечивающие хранение менее востребованных данных. > Вот уж реально киллер фича, но в комментах почему-то спорят о совсем > другом Так это наследие от Bcache, который собственно это и делал - кэшировал HDD на SSD. Много лет уже доступно, а раньше SHDD тоже самое делали только сами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #292

245. Сообщение от Kuromi (ok), 22-Сен-23, 14:05	+/–
> Устарело, нынче модно всё на ssd или nvme Хранить жирные рипы и прочие медиафайлы на SSD все еще не особо модно. Записываешь раз, читаешь кусками, 7 гигабайт в секунду чтения (PCIE4) тут не нужны вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234 Ответы: #246

246. Сообщение от пох. (?), 22-Сен-23, 15:36	+/–
причем записываешь тоже не из мегаскоростного источника, откуда бы ему такому взяться. Остается только проверить - а сработает ли моднявый bcache правильно в таком формате - или таки будет переписывать этот рип с hdd на ssd layer чтобы потом отдавать в секунду не гигабайты а 7 килобит да и те не факт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #257

247. Сообщение от Менеджер Антона Алексеевича (?), 22-Сен-23, 17:04	+/–
> выкинуть из пула целиком vdev, но... только не raid Выкидывание устройства из рейда действительно феерично бесполезная фича. У меня не хватает фантазии представить себе реальный кейс, где это могло бы понадобиться вне локалхоста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236 Ответы: #250, #253

248. Сообщение от Бывалый смузихлёб (?), 22-Сен-23, 17:25	+/–
Шмели никак не касаются мух. И живут в земле, реально в земляных норах Ладно бы оса или шершень, которые аккурат насекомых и ловят. А, если есть возможность - то и мясо/рыбу Но, нет. Шмель, который в стороне от всего этого
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185

249. Сообщение от Аноним (-), 22-Сен-23, 17:25	+/–
> Так BTRFS и ZFS уже есть, туда кодить не надо, там всё > уже работает. Если ты посмотришь с чего ветка началась, увидишь, что > накодить это нужно для XFS. Вы спросили какой _алгоритм_ этого действа. Я и обрисовал вполне валидный и работающий курс действий, в первом приближении описывающий то что btrfs делает. Насколько что-то такое сложно к XFS прикрутить - я не знаю. Они вон пока заняты потугами SCRUB сделать, и, видимо, туговато идет раз в процессе сдриснул майнтайнер с аргументами "бот завалил меня багами в индусокоде, разгребать некому, ваааах!". В любом случае с этажерками типа LVM и проч это все равно не ведет к простому и ненапряжному изъятию например девайса 1 простой командой за минимальное время, так что пойнт всей этой камасутры лично мне не очевиден. Господа истошно пытаются опилить доставшийся от деда из SGI жигуль^W старый форд до аэроплана, потому что форда не хочется, хочется - аэроплан, как у соседей! Но кроме этого ничего не было. И вот упираются господа. Учитывая сложность задачи и нехватку ресурсов, сдобренную тем что для кодеров такая задача эпичной совсем не выглядит, так что идея присоединиться к такой команде с такими задачами выглядит тухловато, типа работы заведомо в мусорный бак - ну, сами понимаете. А пусть вон гражданин пох как фанат энтерпрайза и кЮшает что получилось у редхатокреативщиков с их XFS, лол. Ему как фану лютого энтерпрайза - полезно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228

250. Сообщение от Аноним (-), 22-Сен-23, 17:32	+/–
> Выкидывание устройства из рейда действительно феерично бесполезная фича. У меня не хватает > фантазии представить себе реальный кейс, где это могло бы понадобиться вне > локалхоста. Мне вот это было полезно для примерно такого: Датарекавери с большого диска. Можно временно у кого-то занять пару дисков или выкроить в общем то нужные диски откуда-то еще с своих мощностей. Собрать хранилку с резервом места чтобы было где развернуться, на нее восстановить все. Починить, вынуть данные (рефлинки позволят скостить требования к хранилке в пару раз, не создавая рисков). А потом - если я не профессиональный датарек, ну и зачем мне потом такая дылда? Вынуть из нее половину дисков, вернуть где было, остальное под какие-то другие цели юзануть. Да, это не энтерпрайзный кейс, скорее на стыке любителя и полупро. Btrfs крут тем что может окучать и такие кейсы тоже. И многие другие. В отличие от ZFS, который кроме как для вот именно энтерпрайз хранилок ни на что не годится. И сабж, кажется, эту идею тоже уловил. Скажем вон та иерархическая штука круто. Но - опция. А если столько не надо - можно и в 1 морду всем межгалактическим крейсером рулить на минималках, в целом предусмотрено. Хорошо когда имеюищмися ассетами можно маневрировать по своему усмотрению, без прибивания на гвозди. А RAID без этого всего и с канителью по выравниванию и проч, извините, таки уже легаси когда делом показано что можно и получше чем вот это вот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #252

251. Сообщение от Аноним (-), 22-Сен-23, 18:15	+1 +/–
> Да, у F2FS вообще нет никакиого намека на менеджмент томов, там просто > объединяют устройсва в одну ФС. Примитивно - да, но вот такой ответ "модным ФС". Ответ ради ответа? А смысл? Аналог этого сто лет можно было lvm/md/dm и ко дюжиной способов. > ут можно лишь сказать что ext* и так не умеет. Ну как не умеет, вон теми и его можно так раскрячить. Получится менеджмент любимый господами типа поха, когда все сложно, криво, хреново, неуклюже и состоит из проблем, недостатков, ограничений и брейнфака чуть менее чем полностью. Зато можно пальцы гнуть - "осилил". Мне же "осиливать" всякий миндфак не очень хочется, хочется имплементить системы с оговоренными свойствами. Чем это проще тем лучше. > Ну, насчет надежности у F2FS все хитро. Она под SSD рассчитано, а > они обычно работают-работают да и умирают, напрочь. Ну я на флешовых сторажах и тестил, правда больше SD/eMMC но именно там оно и используется как правило, на мобилах тех же. Так что тут я вообще не делал ничего выходящего за сватаемые сценарии использования. Что самое то интересное. > Частенько даже в SMART никаких явных намеков на проблемы, просто либо > табилца трансдяции умирает (и  привет) либо read-only режим и досвиданья. Ну это у совсем уж лажовеньких. И не, у меня таблицы трансляции все на месте - те же конфиги для EXT4 и Btrfs использовались и я бы заметил если транслятор - того. Просто что-то развалилось в структурах до вида когда смаунтить уже не может а fsck еще не чинит, или что-то типа того. Самый дурацкий сценарий для ФС, спасибо что это тестовые конфиги и данные не нужны, сугубо валидация "а что будет, если ... ?" > С копированием фич у других ФС наверное не так просто выходит, все > таки у F2FS битмэпы, log-based и все дела. Архитектура такая что > не все новое и можное можно взять и приделать. На самом деле оно и правда в таком виде довольно удобно флешу вышло. Так что работает на флешевых девайсах резвенько, не отнять. Но в моем случае - небутабельный девайс например, требующий человеческого вмешательства - перевешивает все остальное. Да и для хранения данных ФС с такими свойствами стремновато. А что я буду делать если оно вот так помрет? Хексэдитором ковырять и сам за Jeon код патчить? Если меня так разопрет я лучше с btrfs это - там я хотя-бы с живыми кодерами законтачусь, они не настолько перегружены и смонут дельно ассистировать. А у Jeon'а на такое ресурсов тупо не хватит, даже если б он захотел. > Ну а что разраб перегружен, это да. Даже жаль, у меня на > F2FS  на SSD  в общем неплохо себя показывает. С > мощными косяками пока не встречался, но резервные копии ценного имею. Ну а я вот встречался - при том не делая ничего такого из ряда вон, я аж удивился что оно при совершенно стандартных тестах имитирующих типовые нежданчики типа слета питания скончаться смогло. Но, вот, смогло, да так что по простому не чинилось уже. А в идеале - все должно приходить в рабочий вид без участия человека. Btrfs пока по-моему ближе всего к этому подобрался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

252. Сообщение от Менеджер Антона Алексеевича (?), 22-Сен-23, 18:17	+/–
> это не энтерпрайзный кейс Именно. И поскольку Линукс пишется корпорациями для своих корпоративных нужд, локалхостные кейсы всерьёз не рассматриваются. С другой стороны, ты на локалхосте не ограничен ни объёмами данных, ни их материальной ценностью, ни циклами закупок, поэтому можешь пользоваться буквально чем угодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #254, #258

253. Сообщение от пох. (?), 22-Сен-23, 19:30	+/–
> Выкидывание устройства из рейда там нельзя выкинуть даже целиком вдев с рейдом. заколдованные оне. >  У меня не хватает фантазии представить себе реальный кейс, где это могло бы понадобиться вне локалхоста. большие стораджи на коленке - всегда в некотором роде локалхост. Собрал ты какое-нибудь 8+2 и тут до тебя доходит что столько не понадобится. Можно продолжать греть воздух, а можно найти парочке дисков применение получше. Или просто собрал ты 6+1, для чего-то не очень важного но нужного под рукой, оно пожужжало пару лет, пара дисков сдохла и была заменена - а в продаже таких мелких уже и нет. И вот у тебя пропадает десяток терабайт. Здорово если у тебя рядом есть вторая такая же хреновина и можно просто zfs send (и пусть весь мир подождет), но немного обидно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #260

254. Сообщение от пох. (?), 22-Сен-23, 19:36	+/–
>> это не энтерпрайзный кейс > Именно. И поскольку Линукс пишется корпорациями для своих корпоративных нужд нормальные люди уходят в винду, которую корпорация пишет - для людей. Именно так. (чуток поправил, не благодари) > кейсы всерьёз не рассматриваются. С другой стороны, ты на локалхосте не > ограничен ни объёмами данных, ни их материальной ценностью, ни циклами закупок, > поэтому можешь пользоваться буквально чем угодно. угу, на нас деньги ж из воздуха падают. А вот купить пяток лицензий чтоб собрать S2D - в принципе, почти любой может себе позволить (если уж у него хватило на железо под это все). И оно будет работать как надо мне, а не как у этих рабов корпораций на от...сь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252 Ответы: #259

255. Сообщение от Аноним (255), 22-Сен-23, 21:10	+/–
То ли дело ты - на феррари с хомяком в колесе вместо двс. Ачо, всё равно только по пробкам ездишь, хватает. И дороги нормальные (в треугольнике "дом-работа-пятёрочка").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #261

256. Сообщение от Аноним (209), 22-Сен-23, 23:07	+/–
> отродясь не имел. Подождите минуточку, давайте посмотрим на второй абзац новости: > Целью разработки Bcachefs является достижение [...], > предоставляя при этом дополнительные возможности, свойственные Btrfs и ZFS, такие как > включение в раздел нескольких устройств, > многослойные раскладки накопителей, > кэширование, > прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), срезы состояния (снапшоты), верификация целостности по контрольным суммам К пулу ZFS при желании может быть присоединен слой (кэш) на быстрых дисках, который, понятно, заполнится "часто используемыми данными". Т.е особенностью Bcachefs это не является, хотя понятно, что наука ушла вперёд за время существования ZFS, и реализация кэша в ней может быть очень умной. Это, кстати, отражено и её названии :) С другой стороны,"автоматическая миграция данных" как-то настораживает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #263

257. Сообщение от Kuromi (ok), 22-Сен-23, 23:30	+/–
> причем записываешь тоже не из мегаскоростного источника, откуда бы ему такому взяться. > Остается только проверить - а сработает ли моднявый bcache правильно в таком > формате - или таки будет переписывать этот рип с hdd на > ssd layer чтобы потом отдавать в секунду не гигабайты а 7 > килобит да и те не факт. Теоретически модный bcache при записи должен пихнуть рип на SSD, потом потихоньку в фоне перенести его в на HDD, а дальше смотреть как часто дергают данный файл. Если это что-то активно используемое, то держать на SSD, если нет, то нет. Тут все упирается в то насколько умная эвристика. У пресловутого F2FS для этого есть категоризация файлов на холодные и горячие данные (по расширению файла). Задумано это больше под зонированные устройсва (вроде SMR), где есть быстрая и медленная зона, но логика та же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #264, #267

258. Сообщение от Аноним (-), 23-Сен-23, 00:33	+/–
> Именно. И поскольку Линукс пишется корпорациями для своих корпоративных нужд, локалхостные > кейсы всерьёз не рассматриваются. Ну как бы я с своими кейсами довольно неплохо вписываюсь в это все. Например, пачка одноплатников не группа серверов. Но не так уж и далеко от них... 1) Там тоже некому жать эникей, отвечать на вопросы fsck, "чинить систему", вот это все. 2) Я тоже не хочу деплоить новый юнит по часу! 3) Я тоже не хочу носиться в мыле все это постоянно чинить. Даже больше чем они. 4) Особенно уделяя персональное внимание по часу каждому десятибаксовому тазику. 5) Откат снапшота за мизер времени - не хучший вариант "reset to factory defaults". Корпы тоже к этому пришли, просто чуть попозже и чуть дольше. А между нами - я и на десктопе в общем то совершенно не хочу тр@хаться полдня с системной рутиной, починкой, реконфигурацией и проч - вместо того чтобы например в каде порисовать, опробовав клевую идею. Представляете?! Корпы - рациональные штуки. Побывав в корпах из фортуны 500 я решил что определенный пойнт в их decision making есть. И вполне себе пользуюсь их парадигмами, хоть и под моим соусом. Почему нет? Это работает. А как лайфхак, де факто опенсорсники часто фанаты того что делают и - таки - за хорошую работу софта который они делают. Даже если это немного и выезжает за кейсы их нанимателя. Ну да, бухать ломовые ресурсы в какой-то бесполезняк типа reiserfs "потому что васян им пользуется" никто конечно не будет. Пусть васян и майнтайнит если ему оно надо и он понимает зачем такие мучения с этой штукой. > С другой стороны, ты на локалхосте не ограничен ни объёмами данных, ни их > материальной ценностью, ни циклами закупок, поэтому можешь пользоваться буквально чем угодно. Ну вот нет. Это у вас может быть данные ничего не стоят. А если у меня допустим проект факапнется - я пролечу на деньги. Я в линухе все мои воркфлоу ворочаю, от и до. А если одноплатник у клиента факапнется, это и для репутации вредно. Никто не любит системы которые создают проблемы. И никто не вспомнит 5 лет успешной работы толпы железок - зато вспомнят если что-то сдохло и создало неудобства или поставило на деньги. Это не очень справедливо, но мир работает так. И похобразные оправдания на тему почему лажа - никому не интересны на самом деле. Это только унылые совкообразные конторы с таким же менеджментом могут схарчить, и то 50/50. ...а с другой стороны корпы воротят эвона сколько работ. Никакой пох, или я, или кто там так то столько же не своротил бы. А благодаря GPL это все можно просто взять и просто поюзать, вообще никого особо и не спрашивая. В результате большой вопрос в минусе ли я с такого состояния дел. Это вон похи всякие в поворот не вписались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

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

260. Сообщение от Аноним (260), 23-Сен-23, 00:41	+/–
> большие стораджи на коленке - всегда в некотором роде локалхост. Собрал ты > какое-нибудь 8+2 и тут до тебя доходит что столько не понадобится. > Можно продолжать греть воздух, а можно найти парочке дисков применение получше. Ну, кроме локалхоста есть и смежные применения. Кастомдев там всякий и проч, когда ну вот реально что-то разовое для кого-то. И ничего зазорного в этом нет, отделы кастомдев есть даже у корпов из фортуны 500. Оптимальный корп - это тот который набрав обороты не утратил хватку. > Здорово если у тебя рядом есть вторая такая же хреновина и можно > просто zfs send (и пусть весь мир подождет), но немного обидно. Ну вот IBM видимо тоже так было. Они и озадачили Мэйсона. И таки показали что если сильно захотеть, можно и так. И много как еще. Планка взята, теперь нельзя сказать что так невозможно. И новые дизайны будут неизбежно ориентироваться на то что так можно и - очень желательно даже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253

261. Сообщение от Аноним (-), 23-Сен-23, 00:58	+/–
> То ли дело ты - на феррари с хомяком в колесе вместо > двс. Ачо, всё равно только по пробкам ездишь, хватает. И дороги > нормальные (в треугольнике "дом-работа-пятёрочка"). Я уже давно не езжу. Я навигирую по 4-мерному пространству, в чем-то типа гибрида звездолета и машины времени. Давно забив на те глупые концепции. А если меня при парковке угораздит материализоваться посреди фонарного столба, failsafe, вот, отмотает время назад и я попробую еще раз. Вбив немного другие координаты бортовому компьютеру на этот раз. Такая вот разница в эксплуатации систем. При том первыми этот стиль освоили как раз корпорации с виртуалками так то. Потому что это эффективно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #279

262. Сообщение от Аноним (-), 23-Сен-23, 02:35	+1 +/–
> Вчера таки еще разок заглянул на страничку Compression в доке btrfs, и > оказывается lz4 у них нема, только lzo, так что кажется я > вспомнил, почему именно выбрал zstd:1. LZO по смыслу похож на LZ4, тоже скоростной 1-компонентный алгоритм, с прицелом на скорость распаковки. LZ4 не стали встраивать потому что слишком похожие по свойствам алго, и ради чего возиться тогда?! На момент дизайна btrfs LZ4 в ядре еще не было, взяли похожий LZO. Более новые дизайны берут LZ4 т.к. он немного резвее, а степень сжатия при желании скорости все же вторична. Но в целом сравнимые алго подвида "simple LZ". > А так по методам сжатия полностью согласен, для меня есть только lz4, > zstd и понемногу уходящий старичок gzip, а всякие xz, bzip2, brotli > слишком медленные даже на разжатие. Ну дык. Xz это LZMA на стероидах. Жмет круто, но даже скорость распаковки - в разы хуже. Им пользуются когда надо до последнего байта экономить. Как вон тот uboot с вебмордой для для TPLink-ов. Там оно либо втиснется в 64 кил регион со ВСЕМ, либо нет, а больше некуда. Вот и приходится хардкорить, даже если и дольше стартует это лучше чем никак. В менее радикальных случаях скорость его распаковки так себе, даже на initrd - от него заметная на глаз задержка при старте на распаковку, например. А бротли сильно оптимизирован на вебпаги, мухлюя с встроенным предзагруженным словарем. Улучшает сжатие вебпаг - ценой хранения надерганого из них словаря 120 кило в либе. Так что можно сразу ссылаться на совпадения еще не вгрузив данных. А если не вебпага, тогда фокус может и не прокатить и сам по себе он "чуть помедленнее и чуть хуже жмет чем zstd". Поэтому кроме браузеров и вебсерверов мало кем используется. > Причем даже zip архивы удобнее, DEFLATE все-таки хорошие цифры показывает. У deflate словарик склерозный, 32 кило. На больших повторяющихся файлах он не увидит совпадение через мегабайт - и может основательно проиграть на этой почве. По скорости распаковки хуже в основном за счет Huffman vs ANS в второй части. ANS это более забористая абстракция, сочетающая плюсы arithmetic coding в сжатии с скоростью даже лучше huffman, за что и используется в новых кодеках. Эпл что-то тоже делал и сорц даже публиковал, но zstd мастеркласс им дал, потому что Cyan (автор LZ4) и Jarek Duda (создатель ANS) в 1 команде могут порвать на пару много кого, ну zstd и зарулил много кого. Facebook кроме этих 2 и еще пару приличных алгоритмистов нанял, уделать такую тиму нелегко. > F5 - и пошла запись, правда это обычно объемы небольшие, но в > процессе игры. Оно все ж может в буфер улететь, особенно если объемы небольшие, врядли гамеза в том же треде что основное действо будет синкать сэйвы и проч, так что это все может относительно асинхронно случиться если авторы гамесы не совсем дятлы. > на 12 ГБ, т.е. почти на 10%. А так, многие игры > перестали жать ресурсы и постоянно подгружают какие-нибудь текстуры с диска, Ну тут все зависит от конкретики. Бывает и так что ассеты 50/50, т.е. часть сжатые, скажем PNG какой или текстуры пакованые, а часть - жмется. > tar, а тупо держат каждую текстурочку в виде отдельного файла - > интересно как такие пациенты себя поведут. Им в целом перфоманс файлухи актуален. В этом смысле - я бы их на XFS складывать не стал, тот с кучей файлов работает "не очень". А в остальном EXT4/btrfs/f2fs/....  в принципе не особо тормозят с разлапистыми иерархиями. > Но игры обычно упираются в GPU, а в CPU по идее должно оставаться немного "воздуха" на > незатратное разжатие, так что игоры я буду жмать. Ну да. Особенно с крутыми настройками и солидным двиглом, если GPU не самый топовый. Хотя на сильно крутом GPU при заурядном проце может и проца не хватать для прогрузки GPU в каких-то случаях. Но это относительно экзотичный сценарий. Фороникс изредка натыкался и на такое. > Ну тут просто надо остановиться на чем-то одном, а xfs (v5) вроде > пободрее мейнтейнят и inode он выделяет динамически, значит по идее не > должны внезапно закончиться. С дедупликацией только я так и не поигрался, > но как-нибудь создам 2 раздела с xfs и btrfs, гляну чего > можно добиться для тех же исходников ядра. Особенно интересно, можно ли > добиться online дедупликации на моменте git clone. Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. На энтерпрайз файлопомойке то претендентов на RAM и CPU нет, можно все сожрать. А на более обычном компе... ближайшее к этому наверное прога "bees". Некая приблуда строящая базу потенциальных дупов, в том числе и инкрементально могет если в фоне держать. Изначально для btrfs делано но может и с XFS работает, если уж оно рефлинки научилось то может и в "same extent" смогет. Лично для XFS не проверял. >> Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым. > Вот этого не знал, я думал это btrfs долгое время был вообще > непригодным к использованию и до сих пор легко ломается, Ну как, btrfs это довольно большой и сложный дизайн. Его отладка заняла время. И до сих пор RAID5/6 имеет свои нюансы. Для RAID5 частично починеные, 6 еще нет. Если они нужны, читать мануал и думать окей ли оно вот так. И метаданные в RAID1 лучше. Сильно безопаснее. Но он технически более поздний чем ZFS и сделан с оглядкой на него - и попытками обойти неудобные места. Более прозаичные кейсы типа RAID1 вполне юзабельны как по мне. И в целом у дизайна больше задел на будущее. Разопрется ли кто когда ВСЕ его возможности раскрыть - вопрос номер два. Скажем теоретически на btrfs можно разным файлам разную схему хранения давать. Не все файлы одинаково ценны. Практически - ну там и без этого наворотов хватает и слабых мест. > а zfs сразу бодро встал и пошел за счет удачного дизайна. Ага, конечно. Его тоже так то отлаживали дофига, своих грабель у него тоже есть, scope у него изначально меньше - энтерпрайзные файлохранилки, btrfs более универсальный. А технологии тогда были менее развиты. Так что максимум на что их хватило это блоки переменного размера, сильно меньше нормальных экстентов, значит оверхеда в метаданных больше. С чего этому быстрому быть только фаны марки и знают. А с десятками гиг буферов что угодно "быстрое". > Надо пожалуй будет матчасть таки прочитать, потому что рассматривание бенчмарков себя не > оправдало - по-прежнему многие места не понятны, да и милисекунды - > хреновая метрика, как и синтетические случаи, в которых можно израсходовать все > место на разделе c btrfs. Бенчмарки бывает довольно сложно интерпретировать - да и насколько оно похоже на то что вон там актуально - как повезет. Самое очевидное - cow'ать большие нагруженные базы неважная идея. Но это надо не всем и не всегда, а btrfs умеет для этого no-cow, становясь чем-то типа EXT4 для таких файлов. Но и все плюсы cow типа снапшотов и чексум при этом в ауте. Zfs и это не умеет и постепенно может зафрагментиться в хлам. А дефрагера у него как я помню совсем нет. На самом деле лучше всего попробовать самому и что понравится и пойдет под требования то и оставить. Бенчи это прекрасно а юзать все же не автору бенчмарков. Вот сабж - обещает быть интересным и крутым. Но опять же - он даже еще не в основном майнлайне, и пока из него лажу вытряхнут - ну это будет вовсе не моментально. И займет сколько-то лет, вероятно. А Кент узнает много нового о том что его файлуха может отколоть, как фэйлят девайсы у юзеров, ... :) но это будет интересная дорога в будушее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240 Ответы: #268

263. Сообщение от Аноним (-), 23-Сен-23, 02:42	+/–
> К пулу ZFS при желании может быть присоединен слой (кэш) на быстрых > дисках, который, понятно, заполнится "часто используемыми данными". Т.е особенностью > Bcachefs это не является, хотя понятно, что наука ушла вперёд за > время существования ZFS, и реализация кэша в ней может быть очень > умной. Это, кстати, отражено и её названии :) > С другой стороны,"автоматическая миграция данных" как-то настораживает. Может вас еще и авто-репайр битой копии с исправной настораживать станет? Хорошие штуки так то необслуживаемы и не требуют к себе внимания. А цимес в том что все вон то по задумке должно продолжать обеспечивать запрошенные гарантии. Если скажем RAID1 и оно запромотилось в кеш, все равно должно выжить даже если "кешовый" девайс дуба дал. Это как раз упражнения на тему интеграции кеша и write-anywhere CoW типа btrfs'а. Весьма забавный фокус так то. Как это на практике будет? Нечто из разряда не попробуешь - не узнаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256

264. Сообщение от Аноним (-), 23-Сен-23, 02:49	+/–
> У пресловутого F2FS для этого есть категоризация файлов на холодные и горячие > данные (по расширению файла). Задумано это больше под зонированные устройсва (вроде > SMR), где есть быстрая и медленная зона, но логика та же. Это под гибриды где HDD и SSD в одном девайсе. Зонирование - немного не про то. Оно про управление зонами с хоста и работу с ними по определенным правилам, когда только дозапись, но перезаписывать можно только после очистки. И кстати zoned это как черепица может быть так и - тадам - скоростные SSD, потому что вон те правила очень хорошо описывают идею работы флеша с eraseblock. И для SSD это позволяет заметно упростить и ускорить транслятор, заодно сделав ему удобнее и потому быстрее. ...в этом месте и btrfs с zoned оказывается такой себе "почти файлухой для флеша". По сути это часть FTL передвинута в ФС из фирмвари давая больше контроля как и что. Для флеша это более удачная семантика чем потуги с trim и ЭМУЛЯЦИЕЙ мелкоблочного стоража здоровой фирмварой. Так что грань кто там флешовая ФС и проч - начинает немного стираться. Поразвели вот всяких гибридных решений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257

266. Сообщение от Аноним (266), 23-Сен-23, 05:16	+1 +/–
Без длинных имен файлов и 16 битных символов так же не нужна как Btrfs, ZFS, Linux, хотя OpenZFS думают над добавлением.
Ответить | Правка | Наверх | Cообщить модератору

267. Сообщение от пох. (?), 23-Сен-23, 09:13	+/–
> Теоретически модный bcache при записи должен пихнуть рип на SSD ага. Напоминаю - откуда он взялся-то? Правильна - либо с флэшки, либо с интернета, и скорость поступления этих данных не то что для ssd, а для mfm hdd вполне посильна. Поэтому мы просто даром тратим ресурс. Теперь мы его начинаем "активно использовать". Т.е. смотрим и подр..4иваем. Он, напоминаю - бааааальшоой. Поэтому места для всяких любимых тут некоторыми "/build" немножко перестает хватать и они идут нахрен писаться на медленный уровень. (хуже вариант - пишутся таки на ssd потому что он в приоритете, а потом переписываются потому что рип все еще читается - снова зря тратим ресурсы) Чтение идет со скоростью аж 8 килобит в секунду (что по-моему даже перебор для прона, чего там прыщи на п-де разглядывать-то) - опять справился бы древний диск. В пресловутом zfs ARC очень старались не допустить вымывания кэшей линейными медленными чтениями и разовыми доступами к ненужно-данным. С arc2 по разным причинам получилось не очень по несвязанным с этими причинам (в основном потому что компьютеры были большими, а с тех пор никто этим не занимался нормально, нет ресурсов и туалетной бумаги).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257 Ответы: #287, #296

268. Сообщение от fumanchez (ok), 23-Сен-23, 15:17	+/–
> LZO по смыслу похож на LZ4 > Более новые дизайны берут LZ4 т.к. он немного резвее, а степень сжатия при желании скорости все же вторична. Я смотрю в первую очередь на скорость разжатия, все-таки данные пишутся один раз, а читаются потом всегда. А разжатие у lz4 заметно быстрее, чуть ли не в 1.5-2 раза. Я в основном тут смотрю цифры http://quixdb.github.io/squash-benchmark, странно правда, что там zstd только с 1 уровнем, но зато наглядно. В частности на графиках Ratio / Decompression видно, что lzo и lz4 вообще в разных областях располагаются, а zstd по скорости разжатия рядом с lzo, вот только он еще и жмет. Я правда из датасетов там только enwiki и mozilla глядел, может для обычного десктопа оно и нерелевантно, да и gcc и дистры какие-то старые, может есть смысл на локалхосте погонять. Хотел тогда на раздел с /home lz4 с высоким уровнем, но подумал, что и zstd:1 пойдет, а lzo - точно мимо. > Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. Вроде на бумаге задача решаемая, пусть и с небольшим количеством приседаний. Если git clone делать в tmpfs или ramfs достаточного размера, тут уже ФС сможет оценить все, что будет писать на диск, и решить как это лучше всего разместить, в т.ч. и с онлайн дедупликацией. Выигрыш может будет и сомнительный, но если есть на это ресурсы - почему бы так не делать? > ближайшее к этому наверное прога "bees" Это я так понял демон, который всю ФС смотрит, и опять же это оффлайн. А хотелось бы сразу скинуть на диск дедупнутую директорию. Да и обычно пользователю виднее, где могут быть потенциальные дубликаты, и проще "дедупликатор" ручками натравлять, чем мониторить диск 24/7. > лучше всего попробовать самому и что понравится и пойдет под требования то и оставить Да на самом деле все ФС нормально работают и не требуют к себе повышенного внимания, особенно при обычной десктопной нагрузке. Вопрос скорее в том, что из ФС можно выжать и какой ценой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #286

269. Сообщение от InuYasha (??), 23-Сен-23, 19:43	+/–
А на чём там сейчас петабайты у дядек? А то я давно не интересовался. Развели всяких зубастиксёрчей и прочих зайцев - и большие сторажи никому стали не нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #289

270. Сообщение от InuYasha (??), 23-Сен-23, 19:52	+/–
Да нет - это у вас крылья лежат в салоне самолёта и пассажиры ими машут. Файлы пусть лучше лежат в ФС Тома в ллвввмммм А рэйд пусть будет в SmurfArray (6ой и с батарейкой)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216 Ответы: #272

271. Сообщение от InuYasha (??), 23-Сен-23, 22:19	+/–
Даже в ядре? Я готов на 20% лишь бы иметь общую нормальную ФС, поддерживаемую всеми акронисами с 2000 года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

272. Сообщение от Аноним (-), 24-Сен-23, 05:57	+/–
> Да нет - это у вас крылья лежат в салоне самолёта и > пассажиры ими машут. Да нет, чувак, тот то читер имел весьма годный план: врубив гипердрайв он проскочит планету насквозь - рематериализуется на орбите, как будто ничего не было. Одним куском. И, конечно, не будет сам наносекунды отмерять, бортовой компьютер сам все сделает, задача человека лишь маневр описать. Поэтому я вот видел несколько раз тот самый self heal в действии. Который спас от кучи головняка на ровном месте. Шляпе тоже так хочется но пока они мягко говоря еще не там с их XFSом, они как раз чем-то там машут, и уже майнтайнера - замахали. А ты можешь показать мне такой фокус с твоими технологиями. Я не очень понимаю какой у тебя на такие случаи хитрый план, поэтому посмтрю с безопасной дистанции: дымящийся кратер от предыдущего такого умника намекает что это не совсем безопасно. > Файлы пусть лучше лежат в ФС > Тома в ллвввмммм > А рэйд пусть будет в SmurfArray (6ой и с батарейкой) Угу. А теперь на своем лаптопе этот номер повтори. Или на десктопе. Или почему они должны быть лишены подобной благодати напрочь? Чтобы иллюстрировать сапожника без сапог? Ну или вон в одноплатниках - куды мне твой RAID с батарейкой? А вон тот фокус - таки, катит. И как раз при self heal самому ничем махать не надо, полностью автоматически все. Сюрприз! У шляпы с этого пригорает, пытаются из своего металлолома эрзац гипердрайва собрать. Получается так себе, майнтайнер заманался и уже практически открытым текстом кенту завидует, у того то подобные хотелки явно лучше будут реализовываться :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270 Ответы: #273

273. Сообщение от InuYasha (??), 24-Сен-23, 10:14	+/–
> какой у тебя на такие случаи хитрый план Коробка новых однотипных хардов в шкафу, Парагон и Акронис, телефон службы рекавери. > А теперь на своем лаптопе этот номер повтори. Зачем ЭТО на лаптопе? Там fat32 достаточно. > или вон в одноплатниках там вообще хардов нет, только микросхемка флэша - тоже фат32 хватит > Или на десктопе. Ну, повторил. Дальше что? (правда, через LSI, но это не важно)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #276

274. Сообщение от InuYasha (??), 24-Сен-23, 10:18	+/–
Я до слёз от мысли как ты будешь файлы каким-нибудь O&O recovery по заголовкам искать. И не найдёшь. :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #275

275. Сообщение от fumanchez (ok), 24-Сен-23, 10:54	+/–
Был бы умный - знал бы, что жмется не все подряд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274 Ответы: #278

276. Сообщение от Аноним (-), 24-Сен-23, 16:32	+/–
>> какой у тебя на такие случаи хитрый план > Коробка новых однотипных хардов в шкафу, Парагон и Акронис, телефон службы рекавери. Ну да, ну да, видал я это все. Проблема в том что все это д@рьмо не может в результате обеспечить даже вот сапожника сапогами. И допущения неудобны даже фирмачам, которые с превеликим удовольствием отправят вот это все вслед за *bsd всякими и прочим трудным в менеджменте мусором ставящим их на бабки лишний раз. Они уже тоже начинают догадываться что можно и получше чем это. >> А теперь на своем лаптопе этот номер повтори. > Зачем ЭТО на лаптопе? Там fat32 достаточно. Ну так и скажи что ты эникей, рубль-пачка, ценных проектов у тебя нет, время нихрена не стоит, ничего интересного с компами типа созидательной активности ты не практикуешь, сколь-нибудь масштабные вещи не ворочаешь... и вот умеешь - ритуал с переставлением хардов. Нюансик в том что для компании хранить всякий хлам в своих помещениях, невозможность реаллокации ассетов на другие таски и проч - денег стоит, и создает неудобства. И за это таки можно вылететь пинком под зад когда руководство прочухает что можно дешевле и гибче. И кажется это уже начинается, судя по истошным потугам XFSников online repair'а. >> или вон в одноплатниках > там вообще хардов нет, только микросхемка флэша - тоже фат32 хватит Ну вот у меня EXT4 там был. И я из-за одного рандомного бэда пришлось за свой счет внепланово подрываться переть к черту на куличики и в режиме аврала чинить железку. На ровном месте буквально. Если тебе так ЗБС - отлично, так и делай. А мне нравятся работающие системы. Не дохнущие от одного рандомного бэда за 5 лет. А вот свободного места там на SD/eMMC навалом и ополовинивание места на избыточность меня там вот вообще совсем не парит. ...а за сколько-то лет, вот, было несколько успешных срабатываний self heal. Куда как круче когда "csum failed ... corrected" в лог, инкремент счетчика "corrupted", и дальше себе пашет, вообще не требуя внимание. Ну а если это часто и счетчик corrupted большой - окей, это еще и индикатор что это фиксить или менять надо. При том - хаялайтящий проблему ДО того как все трансформируется в видимые проблемы. Так что можно все же в фоне и без суеты - а не в режиме аврала когда все сдохло. >> Или на десктопе. > Ну, повторил. Дальше что? (правда, через LSI, но это не важно) Ну а вот у меня на лаптопе - оно рандомный бэд пару лет назад, вот, тоже парировало. Без всяких LSI и прочего бесполезного пропириетарного "супер" хлама за много денег. Или на вооооон том компе (не своем) я был не уверен насчет апгрейда системы. Ну мне не понравилось как там Debian 12 работает и я снапшот с 11 вернул. А с FAT32 я бы чего делал? Убивал день на реинсталл оси? Вместо 5 минут на откат? Во круто. И не, знаешь, LVMом ты там сам снапшотайся как-нибудь. Btrfs'у оно и в подметки не годится. А сабжу... ух, если не ошибаюсь Кент возможно мировой рекордсмен по числу снапшотов на планете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #277

277. Сообщение от InuYasha (??), 24-Сен-23, 21:21	+/–
Так весь твой хвалебный опус про что в итоге был - про bcachefs или btrfs? От бэдов, если что, смарт и прочие чеки должны защищать. Хотя, я всё о хардах... И не то чтобы я эти ФС ругаю. Нет. Просто надоели эти сотни ФС. ПОд винду всё никак EXT2-то не допилят, а тут опять новое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276 Ответы: #281

278. Сообщение от InuYasha (??), 24-Сен-23, 21:23	+/–
И что же? Как, интересно, фс узнает, что у BMP-файла есть заголовки, а внутри что-то пожать можно? Ну, ерунда какая-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #275 Ответы: #280

279. Сообщение от InuYasha (??), 24-Сен-23, 21:25	+/–
Навигируешь на виртуальной машине, получается? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #261 Ответы: #282

280. Сообщение от fumanchez (ok), 25-Сен-23, 00:08	+/–
Если тебе лень открывать документацию, то кратко: btrfs пытается сжать первые 128 КБ файла, чтобы прикинуть, стоит ли его жать, если конечно не проставлено принудительное сжатие. И хорошо жмется как правило то, что восстанавливать нет смысла - логи, бинарники, кеш и т.п..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278 Ответы: #294

281. Сообщение от Аноним (-), 25-Сен-23, 00:31	+/–
> Так весь твой хвалебный опус про что в итоге был - про > bcachefs или btrfs? Пока - про btrfs. Сабж рановато в активную эксплуатацию! Но как дизайн он мне весьма интересен. Потому что технологически содран с btrfs, имеет предпосылки предоставлять большую часть того что мне в btrfs нравится, зарулив ряд аспектов, как то снизив оверхед, и вот еще и простое создание иерархических/буферизованых штук. Так что вот вам перфоманс почти SSD по цене за гиг почти HDD, и хотя это иллюзия, она здорово разгоняет эксплуатационные свойства ряда конфиг. Нашару. Без проприетарных супер-решений за чемоданы денег. Да, конечно, можно к всем этим lvm, md, dm и прочему черти что и сбоку - вот - bcache прилепить. Знаешь в чем проблема?! Во первых, не спятить при конфигурации этого мусора сможет не каждый. И даже ты сам через пару годиков будешь озадаченно чесать репу "блин как это вообще работает?!" боясь тронуть эту штуку. Во вторых, любая переконфигурация такой помойки - боль. Много что может пойти не так. В третьих, я видел как это все работает. И я бы сказал что мне оно "не очень". В четвертых, сабжик явно в настроении дать мастеркласс этому позору на тему как это делать правильно. И, имхо, даст. Будучи автором bcache то пуркуа б ему не па?... :) Например: XFS, EXT и т.п. интересно реагируют на начинающуюся кончину SSD'шника под буфером. Чаще всего заканчивается резким и ВНЕЗАПНЫМ фаталити всей ФС. Специальный бонус для многодисковых, вот и вспомните камасутру от и до, в темпе вальса, когда все уже померло! Вы же такое управление ОС хотели? :) Да что там, т.к. это не интегрированная часть дизайна, даже btrfs в ряде конфиг может заметить проблемы лишь тогда когда "assumptions failed". И это совсем не круто, потому что ВНЕЗАПНО мы им пользуемся для иного экспериенса управления системами. И в отличие от вас Кент, вот, понимает как это должно быть на самом деле. И насколько позорно работает такое МЕСИВО. > От бэдов, если что, смарт и прочие чеки должны защищать. Это шутка такая? Есть такие вещи как теорвер и "read error rate". То-есть если читать много и часто, или просто завести более 1 тазика и погонять их подольше... даже на хорошем и вполне исправном в целом накопителе может РАНДОМНО взбрыкнуть 1-2 сектора. Раз в дофига, конечно. Если чаще - оно сыпется, менять надо. Поэтому фирмвары умеют в (авто) REMAP. И предоставляют резерв на именно переназначение run-time бэдов. И собссно 1-2 бэда в несколько лет у профильных экспертов не считаются проблемой, совершенно крейсерское состояние дел. ...но если теорвер прикололся и бэд попадет под системную либу, система таки словит резкое и внезапное фаталити на ровном месте. И мы проигрываем по критерию "бэд вынес метаданные или любой критичный системный файл". Это довольно слабое требование и при достаточном времени эксплуатации достаточного числа тазиков можно заметить что этот джекпот порой выигрывается. А вот штуки типа DUP в этом случае просто чинят проблему из копии. Да еще... на дефектном секторе "обычные" ФС будут до упора долбиться в нечитаемый сектор. Но до записи в него можно и не дожить. А вот в случае COW с избыточностью оно таки восстановит избыточность, и туда либо сразу запись зафутболится, либо регион будет деаллоцирован. В любом случае фирмварь сможет в REMAP при ближайшей записи туда - а эти данные более не нужны - и это как раз то что дружественно парадигме SELF HEAL. В отличие от in-place дизайнов. > Хотя, я всё о хардах... И не то чтобы я эти ФС ругаю. Ну а вот харды - да и SSD/eMMC/SD/флешки... таки умеют иногда либо фэйлить чтение энного сектора "на ровном месте" либо "возвращать труху" даже не сообщив IO Error для приличия, видимо когда FEC не выдюжил. Ах да, теоретически FEC может подумать что выдюжил - а на самом деле - нифига. Это тоже теорвер. И если читать много, на дофига тазиков, годами, в какой-то момент даже и "редкое" становится "возможным" если не "обыденным". Или к вопросу зачем нам чексуммы данных, end to end и избыточность. Обычные ФС деланы под такие допущения которых на самом деле в природе - не бывает. Бывает некое приближение к ним. От которого происходит удаление по мере того как юзеры хотят быстро, терабайты и чтоб за копье. > Нет. Просто надоели эти сотни ФС. ПОд винду всё никак EXT2-то > не допилят, а тут опять новое. Мне пофиг на винду и ее проблемы. Я уже давно понял что продвинутые технологии это не про майкрософт, от них только маркетинг. И продажа 1 и того же кернела 20 лет подряд. А линух за это время стал из наколенной поделки мощной фичастой шустрой штукой способной давать мастеркласс. Чем оно и круто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277

282. Сообщение от Аноним (-), 25-Сен-23, 02:04	+/–
> Навигируешь на виртуальной машине, получается? :D Менеджмент большей части моих железок мало чем отличается от виртуалок, сюрприз! Потому что это круто и эффективно. Представляешь, так можно было! И я не один в понимании этого. Мягко говоря. Так что я не трачу часы на трах с инсталлерами, вместо этого деплоя образа. И могу откатить неудачный апдейт на заведомо рабочий снапшот. За пару минут. Даже на bare metal. Или, вот, расширить стораж просто подоткнув девайс, уж какой был, без выискивания "расово верных" в мыле. И даже вынуть девайс, реаллоцировав ресурсы в другое место если там это полезнее. Почти как VM. С современным уровнем технологий это уже все возможно. Добро пожаловать в будущее. Сабж тоже об этом. В отличие от всех ваших EXT, XFS и телег с деревянными колесами, где вы "осилили" замену колес кувалдой и смазку шкворней салом, и LVM где-то там же рядом, я вот осилил - нелинейный менеджмент систем, адаптивность под ситуацию. ...и да, первыми эти паттерны придумали именно корпы. На именно VM. Где я этому и научился. А теперь я хочу и железо в таком же стиле менеджить. Очень странно, да. К хорошему быстро привыкаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

283. Сообщение от bOOster (ok), 25-Сен-23, 11:04	+/–
Дурачек всегда думает - если его проблема не коснулась, то и проблемы нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

284. Сообщение от bOOster (ok), 25-Сен-23, 11:07	+/–
Теже яйца, только в профиль...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

285. Сообщение от bOOster (ok), 25-Сен-23, 11:24	+/–
Еще один "свидетель RUSTовый". Нах..на вы лезете туда, разбираться в чем не хотите? Дискредитируя всю отрасль в целом своими поделками на местах? Ничего сложного в IPSec нет. Ты еще скажи что не знаешь что такое модель OSI, хотя по твоим суждениям это понятно, что полный профан ждущий какое-нибудь решение вундервафлю - которое решит все проблемы. Только не будет такого, а ваш убогий удел жаловаться на opennet - как все в сетевых технологиях сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #290

286. Сообщение от Аноним (-), 25-Сен-23, 16:04	+/–
> Я смотрю в первую очередь на скорость разжатия, все-таки данные пишутся один > раз, а читаются потом всегда. А разжатие у lz4 заметно быстрее, > чуть ли не в 1.5-2 раза. Ну как бы в итоге все состоит из времени чтения + времени распаковки, и оптимальность сочетаний не константа и варьируется в зависимости от кучи факторов. В целом LZO относится к примерно тому же классу алгоритмов (скоростные "простые LZ") и профит от +1 алго по мнению девов btrfs в их кейсе умеренный. А вот например пожмешь /boot LZ4 а загрузчик и скажет "unknown compression", +1 алго в ФС не так уж безобидно. > Я в основном тут смотрю цифры http://quixdb.github.io/squash-benchmark, На самом деле это очень многофакторное и зависит от ряда соотношений (например мощь CPU и скорость RAM vs IO) и по факту лучше бенчить именно у себя на именно интересных кейсах. А чужие тесты в лучшем случае позволят ожидаемые соотношения прикинуть. Если понимать на что смотреть. > странно правда, что там zstd только с 1 уровнем, но зато наглядно. Ну как бы на более высоких уровнях жать будет медленнее. Распаковка примерно так же останется. Зависимость уровень vs скорость распаковки бывает, но слабая. > В частности на графиках Ratio / Decompression видно, что lzo и lz4 вообще > в разных областях располагаются, а zstd по скорости разжатия рядом с lzo, > вот только он еще и жмет. ИМХО LZO в целом поплотнее LZ4, а в ФС с требованием на рандомный seek и потому лимитом на размер блока zstd  негде на полную разогнаться. И таки LZO побыстрее zstd во многих случаях и инициализация дешевле: поток LZ4 и LZO можно распаковывать с места в карьер, zstd и zlib в этом более навернуты и надо состояние entropy coder еще инитить. > Я правда из датасетов там только enwiki и mozilla глядел, может для > обычного десктопа оно и нерелевантно, Учитывая что у ФС требование на рандомный доступ и потому лимит на размер блока - соотношения несколько изменятся. Сетап распаковки роялить больше будет. > с /home lz4 с высоким уровнем, но подумал, что и zstd:1 > пойдет, а lzo - точно мимо. Lzo имхо будет быстрее хоть какого zstd в тех случаях (на распаковку). У него фора есть, это "простой LZ" с довольно тривиальным потоком, как и LZ4, можно с места в карьер его распаковывать, даже без аллокаций памяти не говоря про инит кодера энтропии. А zstd куда навернутее, и такая развлекуха на каждый блок отольется по идее... >> Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. > Вроде на бумаге задача решаемая, пусть и с небольшим количеством приседаний. Да и на практике решаемая, только это как компрессия с супер-большим словарем и потому оперативы немеряно жрет и CPU грузит весьма прилично. И хотите ли вы это все вот именно в момент записи - очень отдельный вопрос. Офлайн дедупы позволяют выбрать момент когда ресурсы тратить более контролируемо, отложенно. А штуки типа bees могут и околореалтаймно пахать, сканируя дельту относительно прошлого забега и дедупая только это. Но и так можно себе "windows vista" организовать, когда оно все время что-то делает и грузит систему. > Если git clone делать в tmpfs или ramfs достаточного размера, тут уже > ФС сможет оценить все, что будет писать на диск, Проблема в том что для более-менее быстрого поиска дупов в RAM надо держать немеряную хештаблицу всех кандидатов, иначе скорость операции будет совсем печальной. Требует дофига рам, пропорционально объему стоража. Офлайн дедупалки могут пытаться какой-то компромисс с хранением индекса кандидатов в базе, так медленнее но снижает аппетиты к RAM. Которые могут начать измеряться десятками гигов на большом стораже. > и решить как это лучше всего разместить, в т.ч. и с онлайн дедупликацией. Проблема в том что процесс принятия решения чем-то напоминает сжатие в LZ (поиск совпадения хоть и с рядом ограничений) - ни разу не халявен по ресурсам. > Выигрыш может будет и сомнительный, но если есть на это ресурсы > - почему бы так не делать? Ну вот поэтому ZFS с онлайн дедупом только на файлопомойках с кучей ресурса и юзают, там все равно CPU и RAM может быть некуда деть. А если это не выделенная файлопомойка то на проц и раму и другие претенденты есть. > Это я так понял демон, который всю ФС смотрит, и опять же это оффлайн. Это примерно на границе миров. Поскольку именно демон, и может процессить именно дельту, мониторя изменения, это начинает напоминать онлайн. А совсем оффлайн - это именно прога, не демон, пинаемая мануально по усмотрению юзера. Например jdupes или duperemove. Они ресурсы сами по себе не жрут совсем. > А хотелось бы сразу скинуть на диск дедупнутую директорию. В конечном итоге что так будет эн референсов на 1 экстент из метаданных что сяк. Отличия будут только на интервале пока дуп не отпроцессили. В ZFS это настолько ресурсоемко вышло что пользуется этим довольно мало кто в именно таком виде. Это вот реально для энтерпрайзных файлопомоек выделенных под задачу, на жирной машине. > Да и обычно пользователю виднее, где могут быть потенциальные дубликаты, и > проще "дедупликатор" ручками натравлять, чем мониторить диск 24/7. Ну я как-то так и предпочитаю, чтобы вместо виндоус висты концентрированный жор ресурсов когда мне точно пофиг, скажем пока я сплю. Вон парочка примеров этсамого. >> лучше всего попробовать самому и что понравится и пойдет под требования то и оставить > Да на самом деле все ФС нормально работают и не требуют к > себе повышенного внимания, особенно при обычной десктопной нагрузке. Вопрос скорее в > том, что из ФС можно выжать и какой ценой. Ну я вот из btrfs выжал нехилое улучшение надежности моих систем за счет парирования единичных бэдов, вплоть до того что на сыпучей флехе можно стало таскать файло. EXT* там за месяц в хлам разваливается, а btrfs живет уже пару лет с схемой DUP - чтобы выбило обе копии блока в разных физических смещениях я должен нехилый такой джекпот у теорвера сорвать. С законами природы не стоит спорить, гораздо лучше ими пользоваться себе во благо :). Или снапшоты. Почти как виртуалка. Не понравился результат апдейтов операционки? Снес полхомяка? Автор лох и сделал "rm /usr /bin/..." как в bumblebee? Ну ок, я откачусь на снапшот в котором все было ЗБС. Ведь сделать его моментально, второй раз хранится только "дельта", а в результате управление почти как в виртуалках. Удобно. Но при этом лучше понимать как работает гипердрайв этого крейсра, в частности cow vs снапшоты vs "хранение дельты". Иначе будут вопросы куда место делось. На виртуалках все то же самое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #288

287. Сообщение от Аноним (-), 25-Сен-23, 16:13	+/–
> Теперь мы его начинаем "активно использовать". Т.е. смотрим и подр..4иваем. Он, напоминаю > - бааааальшоой. Поэтому места для всяких любимых тут некоторыми "/build" немножко > перестает хватать и они идут нахрен писаться на медленный уровень. Если кэш не совсем тупой он статистику вести будет - и забуферит даже не весь build а то что часто гоняют. А редкое - и хрен с ним. А если ты на огроменное порево так часто наяривать удумал, тебя, наверное, мозоли начнут больше напрягать. И не факт что только на руках :))). При этом как мне кажется тебе уже не до проблем SSD будет. "Козел у вас конечно задр@ченный, но жить будет" (c) анекдот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267

288. Сообщение от fumanchez (ok), 25-Сен-23, 20:49	+/–
> Ну как бы в итоге все состоит из времени чтения + времени распаковки, и оптимальность сочетаний не константа и варьируется в зависимости от кучи факторов. Мне лично задержки не критичны и большая часть пользовательских данных мне видится похожей на man'ы, которые в .gz и в основном пылятся. А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр, т.е. где в идеале никакой компрессии нет, но нужно как-то обойти ограничения по объему или пропускной способности. И вот в таких сценариях логичнее было бы брать начиная с самого быстрого, то бишь lz4, а если затык останется, то пробовать шаманить с уровнями сжатия или брать lzo. > На самом деле это очень многофакторное и зависит от ряда соотношений (например мощь CPU и скорость RAM vs IO) и по факту лучше бенчить именно у себя на именно интересных кейсах. Подход а-ля Gentoo конечно дает плоды, и при желании можно заморочиться, но бенчить все подряд времени не хватит, а качественных и актуальных замеров очень мало. А так, если есть результаты на разном железе и для разных данных, как на том же Squash Compression Benchmark, то по ним вполне можно делать выводы. Хотя я уже понемногу пилю свои бенчмарки, с упором на то, что лежит в /usr - шрифты, иконки, маны, бинарники и т.д.. > ИМХО LZO в целом поплотнее LZ4, а в ФС с требованием на рандомный seek и потому лимитом на размер блока zstd  негде на полную разогнаться. 128 КБ это не такой уж и маленький блок, я пощелкал графики и для файлов даже поменьше этого блока - в принципе динамика не сильно отличается. > И таки LZO побыстрее zstd во многих случаях и инициализация дешевле: поток LZ4 и LZO можно распаковывать с места в карьер, zstd и zlib в этом более навернуты и надо состояние entropy coder еще инитить. Ну да, это разные весовые категории, но zstd в своей лидер, а lzo - середнячок. > Да и на практике решаемая, только это как компрессия с супер-большим словарем и потому оперативы немеряно жрет и CPU грузит весьма прилично. И хотите ли вы это все вот именно в момент записи - очень отдельный вопрос. Вот клонирование жирной монорепы - это тот случай, когда придется ждать, а потом еще и скорее всего npm install делать. RAM и CPU в это время прохлаждаются - любимый VS Code или IntelliJ Idea еще не запущены, а Dota 2 не может загрузить все ваши 32 ГБ оперативы и 16 ядер Threadripper'а. Так что вот он момент, чтобы отжать кусок RAM'ы и начать онлайн-дедупить. > Ну я вот из btrfs выжал нехилое улучшение надежности моих систем за счет парирования единичных бэдов, вплоть до того что на сыпучей флехе можно стало таскать файло. Флешки к сожалению приходится держать в exfat / ntfs, а btrfs даже Ventoy не понимает. И как же я пожалел, что давно создал exfat раздел на ЖД под файлопомойку - прав доступа нет, преаллокации нет, уменьшить - хрен. Лучше уж ntfs, если нужен доступ из под винды и линукса. А теперь и вовсе может быть, что btrfs на эту роль подходит лучше, т.к. под винду есть драйвер, который ставится в пару кликов. > Или снапшоты. Почти как виртуалка. Мне бы их лет 15 назад, когда я обвешивал модами Обливион без всяких мод-менеджеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #291

289. Сообщение от пох. (?), 26-Сен-23, 09:21	+/–
> А на чём там сейчас петабайты у дядек? ну вот тебе показательная история (отрицательного) успеха (не нашего): https://lizardfs.com/wp-content/uploads/Cases/Tinkoff_case_s... (хватай пока дают - с сайта уже попрятали ибо стыдобища, но удалить из uploads забыли и вообще некому) Как видишь - все еще нужны, потому что никто не может позволить себе доверять надежности всяких губастиксерчей. И люди хватаются с горя даже за совсем странные решения за невменяемые деньги (только чтоб проклятой M$ за директ деньгов не платить...а...вы и не спите я смотрю...в смысле, там их засунуть некуда)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269 Ответы: #293

290. Сообщение от Аноним (-), 26-Сен-23, 15:25	–1 +/–
> Еще один "свидетель RUSTовый". Нах..на вы лезете туда, разбираться в чем не > хотите? Дискредитируя всю отрасль в целом своими поделками на местах? ИМХО, дискредитируют - напыщенные бакланы, которые свое мнение обосновать не способны, зато горазды пальцы загибать. Тоже мне эксперты, выучили пару заклинаний и давай корчить из себя умников и пуп земли на этом основании. А потом оказывается что можно в 20 раз проще, лучше и без этой камасутры. И всех этих ветеран-тормозов вместе с левыми ритуалами и уходят пачками. > Ничего сложного в IPSec нет. Все познается в сравнении. Вайргад по сравнению с этим мусором - просто образец логики и лаконичности. С нормальным крипто, приличным перфомансом, в дохрена раз меньше кода и это при простой настройке. За что и заслуженный титул - "compared to openvpn and ipsec ... work of art" (c) Linus Torvalds. И да, владелец адекватной точки зрения ее обосновать может. Не киванием на авторитет и загибанием пальцев а логически и технически. Но тебе и всяким похам это все не грозит. > Ты еще скажи что не знаешь что такое модель OSI, Это такой синтетический выпер академов. На который все дружно забили, потому что этому в его полном виде не соответствует вот тупо ни 1 протокол на этой планете. От слова вообще. Ну да, каких-то сов можно на глобус натянуть с переменным успехом, но факт в том что > хотя по твоим суждениям это понятно, что полный профан ждущий какое-нибудь > решение вундервафлю - которое решит все проблемы. Не, не так. Компьютеры нужны для решения задач людей. Они инструмент. А когда вы какие-то левые ритуалы, концепции и парадигмы возводите в ранг культа и самоцели - это булшит. Когда оказывается что целей можно достигать проще, с результатом не хуже, а то и лучше, отлично, это улучшение и шаг вперед по сравнению с тем что было до этого. Это не только с компьютерами так бывает. Сравни фигачение напильником часами самому vs CNC фрезерующий за считаныне минуты. Парадигмы могут и смениться - и вот твой скилл 80 уровня фигачения напильником уже и не котируется, котируется скилл рисования в каде вместо этого. Но можно рассказать про вундервафли, я даже согласен что навороченный CNC оно. Но проблемы же решает. > Только не будет такого, а ваш убогий удел жаловаться на opennet - > как все в сетевых технологиях сложно. Я не жалуюсь, чудик. Я констатирую что мне вайргад нравится на порядок больше. Он решает все проблемы которые мне надо было от VPN на самом деле - и делает это в 100500 раз проще и лучше. На мой вкус это большой шаг вперед. И да, кому надо было дохреналион клиентов на нем - таки это давно уже запилили. Есть чудные хостинги с буквально дохреналионом клиентов, на фоне которых пох с его 4000 клиентов жалкий любитель-гаражник... имена и сами найдете, ну или будете такими же любителями и в вопросах поиска.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #285

291. Сообщение от Аноним (-), 26-Сен-23, 19:48	+/–
> Мне лично задержки не критичны и большая часть пользовательских данных мне видится > похожей на man'ы, которые в .gz и в основном пылятся. Ну как, в случае быстрой SSD'хи на умеренном проце скорость записи zstd может заметно обвалить. А там еще чексумы считать надо, том тоже на скорость. В этом месте LZ4 и LZO деланные под "реалтаймное сжатие" получают пойнт. > А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр, Ну вообще я zram и с LZ4 или ща LZO+RLE модно у них стало. Довольно хорошее, кстати, комбо. RLE уменьшает тупняки на сжатие избыточных последовательностей коих в раме есть, в паре с LZO довольно хорошо жмет, там вопрос в том что либо сожмется минимум в 2 раза, и тогда профит, или нет - тогда зря сожрали ресурсы: там округление до страницы ради скорости. Можно 2 в 1 паковать. Или опциональный 3 в 1 (если данные позволили, конечно). Там рыхлость LZ4 икается больше: если 2x сжатие не вышло, проц тратили вообще зря. ...и в результате OOM с таким "свопом" без выгрузки в файлы/разделы - это секунд 5 просадки перфоманса, а потом OOM killer вынесет обжору. И никаких тупняков минутами как с свопом на дисках. > т.е. где в идеале никакой компрессии нет, но нужно как-то обойти ограничения > по объему или пропускной способности. Я в случае zram ничего не обхожу - я неспешно и в фоне оффлоажу оперативу от "cold" данных в их сжатый вариант, ну оно и выигрывает 2-3x от размера выделенного на zram региона. Даже мелкороутеру нормально - и будучи ram2ram сильно меньше причин тормозить. Если сжатие быстрое. > И вот в таких сценариях логичнее было бы брать начиная с самого быстрого, то бишь lz4, > а если затык останется, то пробовать шаманить с уровнями сжатия или брать lzo. На момент дизайна btrfs в ядре lz4 еще не было. А потом... см. про бутлоадер например. Хотя вон у кента, да и btrfs zlib так то тоже есть, не прокатывать же обладателей томов. > Подход а-ля Gentoo конечно дает плоды, и при желании можно заморочиться, но > бенчить все подряд времени не хватит, а качественных и актуальных замеров > очень мало. Их мало потому что те кто их может - понимают ограниченную ценность результата (привязано к конфиге и кейсу) в паре с тем что в других случаях соотношения могут быть иные, и им есть чем заняться. > по ним вполне можно делать выводы. Хотя я уже понемногу пилю > свои бенчмарки, с упором на то, что лежит в /usr - шрифты, иконки, маны, бинарники и т.д.. Хе, забавно. Ну и да, вот что-то такое неплохо жмется так то. > 128 КБ это не такой уж и маленький блок, я пощелкал графики > и для файлов даже поменьше этого блока - в принципе динамика не сильно отличается. Ну и не такой уж большой - на более жирных блоках скажем zstd vs zlib будет сильнее в пользу zstd. А на файлухе это менее выражено, 32 кил словарь не такая уж трабла если максимум 128К на все. И да, лидеры и аутсайдеры могут меняться от задачи. Я лю с simple LZ развлекаться. Скажем то что рулит на мелких блоках не обязано на бошьших рулить. И наоборот. Многое зависит от деталей формата потока vs макс словарь vs как оно match(offset, len) кодирует и есть ли у формата бонусы. У LZ4 неудачное (по степени сжатия) кодирование больших чисел, на хорошо жмущихся данных он заметно проигрывает хоть тому же LZO, у коего более продвинутый и компактный формат, в LZ4 в угоду скорости в жертву принесено вообще совсем все. Он вообще сильно плотно жать не может даже если данные хорошо жмутся, формат потока лимитирует. Длинный match или match на большом смещении требует куда больше байтов на кодирование чем в даже большинстве иных "simple LZ". За это ratio временами таки хромает. > Ну да, это разные весовые категории, но zstd в своей лидер, а > lzo - середнячок. А LZ4 это довольно экстремальный случай где ради скорости даже формат потока довольно дурной и в плотное сжатие он за это совсем не умеет, на уровне формата потока прямо. Так что есть ряд не очень известных перепевок где народ пытается жать поплотнее, не пролюбив особо скорость распаковки. Некоторые штуки при том на именно мелкие блоки специализируются. Их характерных представителей - lzsa, zx0 и тому подобное. Они не на это ориенитированы но с учетом ориентации на мелкие блоки возможно это не так уж плохо и для ФС было бы. > Вот клонирование жирной монорепы - это тот случай, когда придется ждать, а > потом еще и скорее всего npm install делать. RAM и CPU > в это время прохлаждаются - любимый VS Code или IntelliJ Idea > еще не запущены, а Dota 2 не может загрузить все ваши > 32 ГБ оперативы и 16 ядер Threadripper'а. Так что вот он > момент, чтобы отжать кусок RAM'ы и начать онлайн-дедупить. Ну тогда в случае какихнить bees и пустить их в "околореалтаймном" варианте, там наверное нормально. И это... т.к. файлуха всегда активна, она это все время хочет жрать. > Флешки к сожалению приходится держать в exfat / ntfs, а btrfs даже Ventoy не понимает. Ну мне на ventoy пофиг, для загрузочной флехи я делаю условно "инсталл моего десктопа на флеху". А если занесло на совсем чужой комп, есть стебная штука - WinBTRFS :). Не буду настаивать что это всегда и для всех, но... > И как же я пожалел, что давно создал exfat раздел на ЖД под файлопомойку - прав > доступа нет, преаллокации нет, уменьшить - хрен. Последний писк 90х прошлого века... > Лучше уж ntfs, если нужен доступ из под винды и линукса. > А теперь и вовсе может быть, что btrfs на эту роль подходит лучше, т.к. > под винду есть драйвер, который ставится в пару кликов. Ну да. WinBTRFS называется. И NTFS лично меня вымораживает скоростью работы с большими иерархиями. Если туда расжать что-то размером с линукскернел... ммм... не сильно то оно лучше ExFAt'а ощущается. >> Или снапшоты. Почти как виртуалка. > Мне бы их лет 15 назад, когда я обвешивал модами Обливион без > всяких мод-менеджеров. Да я бы тоже не отказался так то - чтобы cp --reflink'ать например образа винчей с которых файло восстанавливаю. Ну тут уж упс. Даже, вот, прикольные алгоритмы сжатия для мелочи появились - тадам - сильно опосля того как они были сильнее всего нужны. "Опыт это такая штука которая у вас появляется сразу после того как он был нужен" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288

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

293. Сообщение от InuYasha (??), 27-Сен-23, 10:40	+/–
> We managed > We are proud I'm lovin' it )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289

294. Сообщение от InuYasha (??), 27-Сен-23, 11:05	+/–
Ну, это уже прямое нарушение OSI. ФС вообще сжатием заниматься не должна. Решение о сжатии должен софт принимать или юзер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #295

295. Сообщение от fumanchez (ok), 27-Сен-23, 12:26	+/–
ФС может хранить данные вообще как угодно, и решение таки принимает юзер - сжатие можно как не включать вовсе, так и отключить на отдельном subvolume. Если нравятся костыли по типу zcat и zgrep, то никто вас не отговаривает от такой ручной работы, но это лишняя сущность. Захотел ты по man'ам поискать что-то - grep с флагом -R уже не сделаешь, а в zgrep флага -R нет. И может я не хотел бы, чтобы man'ы были пожаты в .gz, или хотел бы, но чтобы в .zst.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294

296. Сообщение от Kuromi (ok), 27-Сен-23, 16:14	+/–
>> Теоретически модный bcache при записи должен пихнуть рип на SSD > ага. Напоминаю - откуда он взялся-то? Правильна - либо с флэшки, либо > с интернета, и скорость поступления этих данных не то что для > ssd, а для mfm hdd вполне посильна. > Поэтому мы просто даром тратим ресурс. Ну так для тех же быстрых NVME даже в тестах данные льются чтобы скорость проверить - с другого такого же NVME, иначе откуда еще? Самый быстрый SATA SSD не загрузит на полную даже PCI-E 3 диск стоящий во втором слоте с двумя линиями PCI-E. С другой стороны там только в кэше такая скорсоть, так что...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267

297. Сообщение от Kuromi (ok), 27-Сен-23, 16:35	+/–
> На механике фрагментация это фу. На SSD - сильно меньше фу, можно > не очень париться. А большой непрерывный экстент всяко эффетивнее кучи мелочи. > Вопрос в масштабе эффекта и стоит ли оно заморочек в конкретном > случае. Меньше, конечно, но не настолько уж и сильно меньше фу. Мелкоблочное чтение даже на быстрых NVME НАМНОГО медленнее линейного и большого прогресса тут не видно (как минимум пока не откажутся от трансляции, что опять же потребует новых ФС и механизмов выравнивания). А распространение безбуферных дисков эту проблемку еще и усиливает - невозможность разместить всю таблицу трансляции в набортном RAM осложняет скачкообразное чтение по всему диску. В том же Линуксе безбуферники берут от системной памяти 128 (хотя кое где говорят что 256) мегабайт, а обычное соотношение RAM к NAND - 1 мегабайт на 1 гигабайт, т.е. 1 гигабайт буфера под 1 терабайт диска. Жить можно, но становится понятно почему вендоры так любят выпячивать именно линейную скорость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

298. Сообщение от swarus (ok), 26-Окт-23, 23:33	+/–
>> И ext4 хватает за глаза > Зато если под системной либой случайный бэд образуется - глаза получаются довольно > большие. Когда система резко, внезапно и без предупреждения в тыкву превращается. > При том сразу наповал. Без шансов что-то с этим сделать вообще. > Еще интереснее когда железо немного подглюкивает. Там что угодно может быть. Например > все как живое - но в 1 не очень прекрасный момент > все почему-то дохнет. И не факт что чинится fsck. И конечно > в лучших традициях RAS (а точнее его отсутствия) это выносит систему > резко, внезапно и без намека на предупреждение о грядущих проблемах. ext4 нормально фурычил на хреновых hdd бэд переводил в read-only режим, отмонтируешь fsck и всё работает, а вот проблему btrfs что в fs хранится файлов на 10гб, а места занято на 500гб, из-за одного файла и глючного скрипта забыть не могу, и это штатное поведение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

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

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