The OpenNET Project / Index page

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



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

"Продвижение Bcachefs в состав ядра Linux и переписывание на Rust"  +/
Сообщение от opennews (?), 19-Июн-23, 11:06 
Кент Оверстрит (Kent Overstreet), автор входящей в состав ядра Linux...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=59314

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

Оглавление

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


1. Скрыто модератором  –25 +/
Сообщение от DEF (?), 19-Июн-23, 11:06 
Ответить | Правка | Наверх | Cообщить модератору

2. Скрыто модератором  +8 +/
Сообщение от Аноним (2), 19-Июн-23, 11:09 
Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором  +12 +/
Сообщение от Аноним (3), 19-Июн-23, 11:10 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

6. Скрыто модератором  +/
Сообщение от Аноним (6), 19-Июн-23, 11:23 
Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором  +5 +/
Сообщение от Анонин (?), 19-Июн-23, 11:31 
Ответить | Правка | Наверх | Cообщить модератору

18. Скрыто модератором  +/
Сообщение от Аноним (6), 19-Июн-23, 12:09 
Ответить | Правка | Наверх | Cообщить модератору

30. Скрыто модератором  +3 +/
Сообщение от asdasd (?), 19-Июн-23, 12:50 
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

35. Скрыто модератором  –1 +/
Сообщение от Аноним (35), 19-Июн-23, 13:22 
Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором  +2 +/
Сообщение от Аноним (77), 19-Июн-23, 15:51 
Ответить | Правка | Наверх | Cообщить модератору

195. Скрыто модератором  +/
Сообщение от torvn77 (ok), 21-Июн-23, 00:30 
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

81. Скрыто модератором  +/
Сообщение от n00by (ok), 19-Июн-23, 16:54 
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

99. Скрыто модератором  –4 +/
Сообщение от DEF (?), 19-Июн-23, 19:30 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

113. Скрыто модератором  +/
Сообщение от Аноним (113), 19-Июн-23, 23:55 
Ответить | Правка | Наверх | Cообщить модератору

132. Скрыто модератором  +/
Сообщение от DEF (?), 20-Июн-23, 02:02 
Ответить | Правка | Наверх | Cообщить модератору

140. Скрыто модератором  +/
Сообщение от n00by (ok), 20-Июн-23, 05:59 
Ответить | Правка | Наверх | Cообщить модератору

170. Скрыто модератором  +/
Сообщение от Аноним (-), 20-Июн-23, 18:13 
Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

126. Скрыто модератором  +1 +/
Сообщение от Аноним (126), 20-Июн-23, 00:49 
Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

129. Скрыто модератором  +/
Сообщение от DEF (?), 20-Июн-23, 01:55 
Ответить | Правка | Наверх | Cообщить модератору

160. Скрыто модератором  +/
Сообщение от Аноним (160), 20-Июн-23, 13:14 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

162. Скрыто модератором  +/
Сообщение от Чукча (?), 20-Июн-23, 15:46 
Ответить | Правка | Наверх | Cообщить модератору

179. Скрыто модератором  +/
Сообщение от Аноним (-), 20-Июн-23, 18:59 
Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

8. Скрыто модератором  +5 +/
Сообщение от Аноним (8), 19-Июн-23, 11:25 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

52. Скрыто модератором  +/
Сообщение от Вы забыли заполнить поле Name (?), 19-Июн-23, 14:46 
Ответить | Правка | Наверх | Cообщить модератору

94. Скрыто модератором  +1 +/
Сообщение от Аноним (94), 19-Июн-23, 17:43 
Ответить | Правка | Наверх | Cообщить модератору

104. Скрыто модератором  +/
Сообщение от Аноним (104), 19-Июн-23, 21:32 
Ответить | Правка | Наверх | Cообщить модератору

112. Скрыто модератором  +/
Сообщение от Аноним (112), 19-Июн-23, 23:50 
Ответить | Правка | Наверх | Cообщить модератору

111. Скрыто модератором  +2 +/
Сообщение от Аноним (-), 19-Июн-23, 23:21 
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

168. Скрыто модератором  +/
Сообщение от Аноним (94), 20-Июн-23, 17:28 
Ответить | Правка | Наверх | Cообщить модератору

171. Скрыто модератором  +/
Сообщение от Аноним (-), 20-Июн-23, 18:30 
Ответить | Правка | Наверх | Cообщить модератору

191. Скрыто модератором  +/
Сообщение от Аноним (94), 20-Июн-23, 21:11 
Ответить | Правка | Наверх | Cообщить модератору

197. Скрыто модератором  +/
Сообщение от Аноним (197), 21-Июн-23, 01:36 
Ответить | Правка | Наверх | Cообщить модератору

222. Скрыто модератором  +/
Сообщение от Аноним (94), 21-Июн-23, 14:56 
Ответить | Правка | Наверх | Cообщить модератору

63. Скрыто модератором  +/
Сообщение от Аноним (63), 19-Июн-23, 15:20 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

118. Скрыто модератором  +/
Сообщение от Аноним (118), 20-Июн-23, 00:16 
Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором  +3 +/
Сообщение от Аноним (10), 19-Июн-23, 11:28 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

15. Скрыто модератором  +5 +/
Сообщение от Аноним (15), 19-Июн-23, 11:54 
Ответить | Правка | Наверх | Cообщить модератору

17. Скрыто модератором  +1 +/
Сообщение от Аноним (6), 19-Июн-23, 12:07 
Ответить | Правка | Наверх | Cообщить модератору

21. Скрыто модератором  +2 +/
Сообщение от Аноним (15), 19-Июн-23, 12:12 
Ответить | Правка | Наверх | Cообщить модератору

71. Скрыто модератором  +/
Сообщение от Аноним (6), 19-Июн-23, 15:44 
Ответить | Правка | Наверх | Cообщить модератору

158. Скрыто модератором  +/
Сообщение от Аноним (158), 20-Июн-23, 12:40 
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

159. Скрыто модератором  +/
Сообщение от Аноним (15), 20-Июн-23, 13:08 
Ответить | Правка | Наверх | Cообщить модератору

28. Скрыто модератором  +2 +/
Сообщение от leap42 (ok), 19-Июн-23, 12:46 
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

59. Скрыто модератором  +/
Сообщение от Аноним (15), 19-Июн-23, 14:56 
Ответить | Правка | Наверх | Cообщить модератору

73. Скрыто модератором  +/
Сообщение от Аноним (6), 19-Июн-23, 15:46 
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

138. Скрыто модератором  +1 +/
Сообщение от leap42 (ok), 20-Июн-23, 05:33 
Ответить | Правка | Наверх | Cообщить модератору

102. Скрыто модератором  +/
Сообщение от Аноним (102), 19-Июн-23, 21:27 
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

139. Скрыто модератором  +/
Сообщение от leap42 (ok), 20-Июн-23, 05:36 
Ответить | Правка | Наверх | Cообщить модератору

16. Скрыто модератором  +/
Сообщение от Аноним (16), 19-Июн-23, 12:07 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

24. Скрыто модератором  +/
Сообщение от НяшМяш (ok), 19-Июн-23, 12:22 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

114. Скрыто модератором  +1 +/
Сообщение от Аноним (114), 19-Июн-23, 23:59 
Ответить | Правка | Наверх | Cообщить модератору

25. Скрыто модератором  –1 +/
Сообщение от Аноним (118), 19-Июн-23, 12:29 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

26. Скрыто модератором  +/
Сообщение от Alladin (?), 19-Июн-23, 12:41 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

119. Скрыто модератором  +/
Сообщение от Аноним (118), 20-Июн-23, 00:18 
Ответить | Правка | Наверх | Cообщить модератору

33. Скрыто модератором  +1 +/
Сообщение от Аноним (33), 19-Июн-23, 13:20 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

39. Скрыто модератором  +2 +/
Сообщение от Аноним (39), 19-Июн-23, 13:48 
Ответить | Правка | Наверх | Cообщить модератору

41. Скрыто модератором  +1 +/
Сообщение от Витюшка (?), 19-Июн-23, 14:04 
Ответить | Правка | Наверх | Cообщить модератору

42. Скрыто модератором  –5 +/
Сообщение от Аноним (33), 19-Июн-23, 14:15 
Ответить | Правка | Наверх | Cообщить модератору

67. Скрыто модератором  +/
Сообщение от Аноним (35), 19-Июн-23, 15:33 
Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +2 +/
Сообщение от Аноним (-), 20-Июн-23, 00:34 
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

156. Скрыто модератором  –1 +/
Сообщение от Аноний (?), 20-Июн-23, 11:27 
Ответить | Правка | Наверх | Cообщить модератору

174. Скрыто модератором  –1 +/
Сообщение от Аноним (174), 20-Июн-23, 18:45 
Ответить | Правка | Наверх | Cообщить модератору

135. Скрыто модератором  +2 +/
Сообщение от Аноним (135), 20-Июн-23, 03:41 
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

154. Скрыто модератором  +/
Сообщение от Аноний (?), 20-Июн-23, 11:16 
Ответить | Правка | Наверх | Cообщить модератору

142. Скрыто модератором  +/
Сообщение от Администратор (?), 20-Июн-23, 06:46 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

155. Скрыто модератором  +1 +/
Сообщение от t (??), 20-Июн-23, 11:18 
Ответить | Правка | Наверх | Cообщить модератору

164. Скрыто модератором  +/
Сообщение от пох. (?), 20-Июн-23, 15:58 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

176. Скрыто модератором  +/
Сообщение от Аноним (-), 20-Июн-23, 18:49 
Ответить | Правка | Наверх | Cообщить модератору

19. Скрыто модератором  +2 +/
Сообщение от maximnik0 (?), 19-Июн-23, 12:10 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

116. Скрыто модератором  +/
Сообщение от Аноним (174), 20-Июн-23, 00:05 
Ответить | Правка | Наверх | Cообщить модератору

128. Скрыто модератором  +1 +/
Сообщение от maximnik0 (?), 20-Июн-23, 01:38 
Ответить | Правка | Наверх | Cообщить модератору

183. Скрыто модератором  +/
Сообщение от Аноним (-), 20-Июн-23, 19:22 
Ответить | Правка | Наверх | Cообщить модератору

192. Скрыто модератором  +/
Сообщение от maximnik0 (?), 20-Июн-23, 21:45 
Ответить | Правка | Наверх | Cообщить модератору

198. Скрыто модератором  +/
Сообщение от Аноним (-), 21-Июн-23, 01:53 
Ответить | Правка | Наверх | Cообщить модератору

206. Скрыто модератором  +/
Сообщение от maximnik0 (?), 21-Июн-23, 02:59 
Ответить | Правка | Наверх | Cообщить модератору

130. Скрыто модератором  –1 +/
Сообщение от DEF (?), 20-Июн-23, 01:57 
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

46. Скрыто модератором  +2 +/
Сообщение от анон (?), 19-Июн-23, 14:42 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

134. Скрыто модератором  +1 +/
Сообщение от DEF (?), 20-Июн-23, 02:08 
Ответить | Правка | Наверх | Cообщить модератору

97. Скрыто модератором  +/
Сообщение от Аноним (-), 19-Июн-23, 18:27 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

131. Скрыто модератором  +/
Сообщение от DEF (?), 20-Июн-23, 01:59 
Ответить | Правка | Наверх | Cообщить модератору

184. Скрыто модератором  +/
Сообщение от Аноним (-), 20-Июн-23, 19:24 
Ответить | Правка | Наверх | Cообщить модератору

4. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Аноним (4), 19-Июн-23, 11:13 
> он любит программировать, а не отлаживать код

99% современных кодерков именно такие

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

7. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Аноним (8), 19-Июн-23, 11:23 
ты понимаешь значение слова "отлаживать"?
Ответить | Правка | Наверх | Cообщить модератору

12. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от YetAnotherOnanym (ok), 19-Июн-23, 11:29 
Поделись своим пониманием этого слова.
Ответить | Правка | Наверх | Cообщить модератору

23. "Продвижение Bcachefs в состав ядра Linux"  +7 +/
Сообщение от Random (??), 19-Июн-23, 12:19 
Вычищать из кода лажу.
Ответить | Правка | Наверх | Cообщить модератору

22. "Продвижение Bcachefs в состав ядра Linux"  +5 +/
Сообщение от Самый Лучший Гусь (?), 19-Июн-23, 12:15 
Отлаживать значит ложить на более далёком расстоянии чем сейчас
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

75. "Продвижение Bcachefs в состав ядра Linux"  +4 +/
Сообщение от Аноним (75), 19-Июн-23, 15:51 
Устранять несоответствие между тем, что программист хотел написать, и тем что он написал в реальности.
И это важная часть любой разработки. если программист не хочет ей заниматься значит на выходе будет гавно. Язык программирования в той или иной степени может попытаться скрыть это гавно(сборка мусора в языках с GC), или не наступить на определенный вид граблей. Но видов граблей уйма, так что от дебага не уйти, если конечно хочется сделать продукт а не какашку.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

98. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (98), 19-Июн-23, 18:28 
И ни один язык не спасёт программиста от неправильно применённых алгоритмов. Если условная видеоигра не умеет нормально отсекать геометрию вне камеры, то переписывание на новый технологический стек не поможет.
Ответить | Правка | Наверх | Cообщить модератору

69. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Аноним_5 (?), 19-Июн-23, 15:41 
А написали бы "дебажить" как в оригинале
> loves to write code, but not to debug it
> just means a lot less time debugging

и никакого лингвистического спора не было бы))

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

172. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Neon (??), 20-Июн-23, 18:41 
А нет никакого спора. Зачем обезьянничать, когда есть свои слова ?
Ответить | Правка | Наверх | Cообщить модератору

196. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от torvn77 (ok), 21-Июн-23, 00:34 
На ютубе один лингвист высказал такое мнение: неправильных слов нет и если debug английское слово, то вот уже дебаг русское.(тем более что оно ещё и склоняемое, то есть не стоит особняком и полностью интегрировано в язык)  
Ответить | Правка | Наверх | Cообщить модератору

221. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (221), 21-Июн-23, 13:31 
> если debug английское слово, то вот уже дебаг русское

Железобетонная неоспоримая логика, конечно.

Давайте тогда "фуск" и "фак" добавим в лексикон русскоязычных людей.  Раз у лингвистов с YouTube нет "неправильных" слов.  Расширим и без того немалый запас ненормативной лексики.

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

237. Скрыто модератором  +/
Сообщение от Аноним (-), 24-Июн-23, 19:27 
Ответить | Правка | Наверх | Cообщить модератору

82. Скрыто модератором  +2 +/
Сообщение от n00by (ok), 19-Июн-23, 17:02 
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

86. Скрыто модератором  +/
Сообщение от Пушок (?), 19-Июн-23, 17:12 
Ответить | Правка | Наверх | Cообщить модератору

88. Скрыто модератором  +/
Сообщение от n00by (ok), 19-Июн-23, 17:16 
Ответить | Правка | Наверх | Cообщить модератору

89. Скрыто модератором  +/
Сообщение от Пушок (?), 19-Июн-23, 17:17 
Ответить | Правка | Наверх | Cообщить модератору

91. Скрыто модератором  +/
Сообщение от n00by (ok), 19-Июн-23, 17:29 
Ответить | Правка | Наверх | Cообщить модератору

93. Скрыто модератором  +/
Сообщение от Пушок (?), 19-Июн-23, 17:35 
Ответить | Правка | Наверх | Cообщить модератору

141. Скрыто модератором  +/
Сообщение от n00by (ok), 20-Июн-23, 06:03 
Ответить | Правка | Наверх | Cообщить модератору

153. Скрыто модератором  +/
Сообщение от Пушок (?), 20-Июн-23, 11:06 
Ответить | Правка | Наверх | Cообщить модератору

167. Скрыто модератором  +/
Сообщение от n00by (ok), 20-Июн-23, 16:32 
Ответить | Правка | Наверх | Cообщить модератору

85. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Дедобот (?), 19-Июн-23, 17:07 
>кхе-кхе раньше было лучше
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Аноним (6), 19-Июн-23, 11:22 
ZFS c Btrfs можно подумать сильно популярная ФС. А тут какое-то чудо-юдо им идёт на смену.
Ответить | Правка | Наверх | Cообщить модератору

110. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (110), 19-Июн-23, 22:52 
Узкий сегмент и узкая приминяемость в каком-то совем датацентре
Решили свою задачу и выдали миру, а применять или нет ваше дело
Может вы только пасьянсом пользуетесь чего уж там какой кеш
Ответить | Правка | Наверх | Cообщить модератору

117. "Продвижение Bcachefs в состав ядра Linux"  +2 +/
Сообщение от Аноним (174), 20-Июн-23, 00:08 
> ZFS c Btrfs можно подумать сильно популярная ФС.

Btrfs'ом пользуется миллиард фэйсбучных юзерей. Если это не популярная фс, то что ж тогда популярно то?

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

125. "Продвижение Bcachefs в состав ядра Linux"  +4 +/
Сообщение от Аноним (125), 20-Июн-23, 00:39 
А Minix используют все у кого процессор Intel, значит Minix тоже популярная операционная система.
Ответить | Правка | Наверх | Cообщить модератору

151. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Аноним (151), 20-Июн-23, 10:14 
>используют всех, у кого процессор Intel,

пофиксил

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

185. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (-), 20-Июн-23, 19:27 
> Minix тоже популярная операционная система.

Ну а что, нет чтоли? А линукс использует уже наверное и пара миллиардов, с андроидами то. Пока какие-то ретарды про 1% пиндят.

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

233. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Stellarwind (?), 22-Июн-23, 11:41 
Ну если применять логику, что все пользователи фейсбука используют btrfs, то можно сказать что и вообще все пользователи интернета используют linux - явно больше пары миллиардов.
Ответить | Правка | Наверх | Cообщить модератору

238. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 24-Июн-23, 19:29 
> Ну если применять логику, что все пользователи фейсбука используют btrfs, то можно
> сказать что и вообще все пользователи интернета используют linux - явно
> больше пары миллиардов.

Примерно так и есть. А еще у каждого найдется по нескольку устройств с линем, от телека до роутера. А майкрософт вещает про свои 1%. Им, понятное дело, с зафэйленым WinPhone считать с вон теми - неудобно.

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

163. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Чукча (?), 20-Июн-23, 15:49 
Стоит ли транслировать  своё местечковое мнение на всех, демонстрируя свою ограниченность?
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

186. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (186), 20-Июн-23, 19:50 
А разве в Убунточке по умолчанию не BTRFS?
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

207. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Аноним (207), 21-Июн-23, 03:40 
Желаешь судить по популярности? ZFS планировалось открыть в OpenSolaris, чего Sun Microsystems и добились открыв почти все исходники UNIX официально за исключением некоторых компонентов ядра что допиливали уже в проекте Illumos.
Сколько девушек тебе признавались в любви без твоего задаривания их чем-либо? Ты ведь хочешь по популярности у домохозяек оценить промышленную файловую систему без проблем с размером данных в принципе со 128 битным размером. Это только недавно стало так что 500 мегабайт, которые жрет ZFS по минимуму не такая большая часть от общей оперативной памяти. Плюс задействовать кеш данных через файловую систему вместо скажем кеша для Си исключительно чем плохо?
Ты просто мозгами шевелить не умеешь, вот тебе и нужны неопровержимые области применения. Но так как ты их не осилишь скорее всего такие как ты будут орать про ненужность. Ты наверное и медицину будешь орать что она ненужна пока тебе не понадобится. Смотрите какая непопулярная у людей восстановительная пластика лица у мужчин. Шрамы же мужчин украшают. Правильно, да?
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

239. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (239), 24-Июн-23, 19:33 
> 128 битным размером.

Правильно, тормозить так во всем. Чтобы даже 64-битным процам неудобно было. И не понятно будут ли в обозримом будущем 128-битные т.к. пока никто и близко не приблизился к порогу 2^64 байтов.

> Это только недавно стало так что 500 мегабайт,

А вон у того одноплатника с 256 оперативы - btrfs прекрасно работает. И сабж сможет. Какой грите процент оперативы 500 мегабайтов там? :) Случаи бывают разные.

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

9. "Продвижение Bcachefs в состав ядра Linux и переписывание на ..."  –3 +/
Сообщение от YetAnotherOnanym (ok), 19-Июн-23, 11:26 
> решить проблемы с высоким потреблением памяти при восстановлении и проверки ФС утилитой fsck
> использовать при разработке Bcachefs язык Rust

Что-нибудь одно.

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

11. "Продвижение Bcachefs в состав ядра Linux"  +4 +/
Сообщение от аНОНИМ (?), 19-Июн-23, 11:28 
>> - How does bcachefs avoid the dreaded RAID write hole?
> We're copy on write - and this extends to our erasure coding
> implementation, we don't update existing stripes in place -
> we create new stripes as needed, reusing buckets from existing
> stripes that still have data.

То, что в бтрфс ниасилили (и видимо уже никогда ниасилят), но осилили в openZFS.

>> - How does an O_DIRECT loop device on bcachefs compare to a zvol on ZFS?
> I'd have to benchmark/profile it. It appears there's some bugs in the way the
> loop driver in O_DIRECT mode interacts with bcachefs according to xfstests, and
> the loopback driver is implemented in a more heavyweight way that it needs to be -
> there's room for improvement.

То есть для образов дисков для виртуалок оно непригодно, как и btrfs. btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW образом диска и просто тормозит (в 2-3 раза медленее ext4) с no-CoW образом. Во втором случае ещё и остаётся без упаковки. в openZFS образы дисков в виде zdev просто ЛЕТАЮТ, быстрее чем голый диск работают. Не говоря уже о том, что упаковка на лету всегда имеется.

Про то чем лучше снапшоты так и не понял. в btrfs снапшоты просто замечательные, можно эн копий оси иметь например и грузиться по выбору в любую (пару раз пригождалось иметь новую и старую системы). В openZFS такое без доп ужимок и прыжков не выйдет (сначала надо снапшот сделать, потом его из снапшота преобразовать в полноценный датасет, а уж что делать чтоб забутиться из грёбанного initramfs в другой рут-датасет я даже не в курсе; в btrfs тупо в грубе выбирается аргументом ядру другой снапшот он же subvolume).

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

120. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Аноним (-), 20-Июн-23, 00:18 
> То, что в бтрфс ниасилили (и видимо уже никогда ниасилят)

Буквально пару версий назад радикально заделали для RAID5 - а для RAID1/10 никогда и не было актуально из-за наличия чексум. Так что реально проблемы есть только с RAID6. И кстати метаданные могут быть в другой схеме - том же RAID1 - что очень полезно в вон том плане.

> То есть для образов дисков для виртуалок оно непригодно, как и btrfs.
> btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW
> образом диска и просто тормозит (в 2-3 раза медленее ext4) с
> no-CoW образом.

По этой причине в Btrfs можно выбрать no-cow для конкретных файлов внезапно. И в сабже тоже можно будет. И да, делать двойной CoW и виртуализатором и ФС - тупая идея. Оставьте кого-то одного на этом пути. Либо RAW диск виртуалки и COW файлухой, либо COW диск виртуалки и nowcow файл. А вот cow cow'а - идея поганая.

> Не говоря уже о том, что упаковка на лету всегда имеется.

Она имеется также у btrfs и сабжа :)

> выбору в любую (пару раз пригождалось иметь новую и старую системы).

При том если делать как оно в убунте (2 subvolume, а истинный / файлухи вообще на 1 уровень выше / системы)  - еще и system и data можно раздельно снапшотить и откатывать. И спрятать уровень менеджмента от софта при нормальной работе ОС (например чтобы не повредить случайно).

> рут-датасет я даже не в курсе; в btrfs тупо в грубе
> выбирается аргументом ядру другой снапшот он же subvolume).

Ну да. Выбирается какого subvolume монтировать как / что довольно удобно. А операции с оными похожи на диры по сути. Стереть subvolume можно даже каким-нибудь миднайтом, как "директорию". Удобно так то.

Впрочем самые зачетные фичи btrfs это возможность подоткнуть или вынуть девайс с увеличением/уменьшением места, или даже схему хранения переиграть. И это все просто, шустро (только реально занятое место) и без останова системы. Можно даже device add -> new drive -> remove -> old drive -> прописать бутлоадер -> вы только что заменили rootfs device под ОС на ходу :). По своему забавно - сменить диск под системой нонстоп. А что, Шишкин, сможешь так же? :)

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

175. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от аНОНИМ (?), 20-Июн-23, 18:47 
> Буквально пару версий назад радикально заделали для RAID5 - а для RAID1/10 никогда и не было актуально из-за наличия чексум. Так что реально проблемы есть только с RAID6. И кстати метаданные могут быть в другой схеме - том же RAID1 - что очень полезно в вон том плане.

И как оно? write hole пропал? А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а) тоже переживает? OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не переживало. Но то было несколько лет назад.

> По этой причине в Btrfs можно выбрать no-cow для конкретных файлов внезапно. И в сабже тоже можно будет. И да, делать двойной CoW и виртуализатором и ФС - тупая идея. Оставьте кого-то одного на этом пути. Либо RAW диск виртуалки и COW файлухой, либо COW диск виртуалки и nowcow файл. А вот cow cow'а - идея поганая.

Во-1, я о том и сказал, что no-CoW файлы с образом диска виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят. Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть (ну или почти), и наоборот, летают быстрее голого диска. Это всё на свежесозданных пустых ФС.

> Она имеется также у btrfs и сабжа :)

Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет паковаться (и фрагментироваться). Например, 1 мегабайт. Меньше не будет. А в btrfs оно само будет резать на кусочки килобайт 128 упакованного - 16 неупакованного. А если в середину экстента с 128к данных байт записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.

> самые зачетные фичи btrfs это возможность подоткнуть или вынуть девайс с увеличением/уменьшением места, или даже схему хранения переиграть.

Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый тоже имеется.
Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2 дисках (и 2 sparse файлах на рамдиске, после чего те файлы отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками с loop deviceами.

А ещё, в OpenZFS шифрование по-датасетно искаропки. В btrfs вроде ещё не довпилили, хотя грозятся.

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

188. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (188), 20-Июн-23, 20:07 
> И как оно? write hole пропал?

У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.

> А заполнение целиком одного диска из трёх рандомом (аццкая имитация bitflip'а)
> тоже переживает?

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

Из _реалистичных_ проблемных сторажей точно переживает работу на текучках и сыпучках с DUP (так можно юзануть фиговую флеху/карту, одну). Просто берет и чинит - и теорвер так намного прикольнее. Теперь проигрыш не при 1 бэде в чем-то критичном, а при совпадении когда бэды сразу в 2 копиях - в физически разных местах - что довольно маловероятно. Вот так теорвер гораздо прикольнее ощущается. "Еж пищит, орет, но живет".

> OpenZFS переживает, я специально проверял. А btrfs, когда проверял -- не
> переживало. Но то было несколько лет назад.

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

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

> Во-1, я о том и сказал, что no-CoW файлы с образом диска
> виртуалки в btrfs раза в 2 тормознее файла на ext4 выходят.

Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.

> Во-2, в OpenZFS zvol'ы ровно те же самые CoW-файлы и есть
> (ну или почти), и наоборот, летают быстрее голого диска. Это всё
> на свежесозданных пустых ФС.

Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс. Это какое-то извращение понятное только ZFSникам. Я конечно понимаю что гребля только с девайсами и размерами слишком скучно, надо еще и вон той гребли добавить. А btrfs так то о простом и ненапряжном менеджменте. В гробу я видел управление какими там vol'ами дополнительно к остальному еще. В btrfs управление сводится по сути к add/remove/replace девайсов да может смене схемы. Удобно. А если стало мало места, можно подоткнуть +1 девайс. Ну может ребаланс пнуть если использование устройств сильно асимметричное вышло. Прокатит даже с RAID1 или там RAID5 каким. Без академической гребли с выравниваниями, рестрайпами, размерами и проч. За одно это авторам дизайна памятник надо поставить имхо.

> Тут тоже есть нюанс. В OpenZFS можно устанавливать размер блока, которыми будет
> паковаться (и фрагментироваться).

Насчет блоков: видите ли, это вовсе и не фича. Потому что, внезапно, не extent based дизайн даже еще! А какой-то block-based переросток. В чем трабл? Без ломового подпора рамой такой дизайн тормозной аки трактор! А btrfs почти как ext4, даже на роутере с 64 метрами оперативы (попробуйте там ZFS завести?!). Из-за этого как я понимаю на него рефлинки натянуть не смогли. Можно конечно поспорить за экстентные аллокаторы и их эффективность, но т.к. в целом мир выбрал для новых дизайнов их, они таки эффективнее в большинстве кейсов оказались. А btrfs живет даже на очень мелких конфигах, типа одноплатников и довольно непозорно я б сказал. Имея свои плюсы. Например, не дохнет от 1 бэда насмерть как EXT4. Да, представляете, 1 бэд под libc6 в EXT4 = система не грузится. То же самое на btrfs с dup - "csum failed ... corrected". Такая вот разница.

> Например, 1 мегабайт. Меньше не будет.

Ага, могу себе представить латенси всего этого и оверхед в менее удачных случаях, когда надо было 4К блок, а оно весь мег в результате кантовало.

> А в btrfs оно само будет резать на кусочки килобайт 128 упакованного -
> 16 неупакованного. А если в середину экстента с 128к данных байт
> записать, какого размера CoW-добавка будет, тоже неизвестно. Подозреваю, что 4к.

Я это специально не проверял, но в среднем файлухи с сжатием и проч ведут себя вполне одупляемо в целом вроде. Наверное можно подобрать дурацкие случаи, но их для чего угодно подобрать можно.

> Вот кстати да, забыл упомянуть. И это, и дефрагментатор свободного места онлайновый
> тоже имеется.

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

> Зато, например, в OpenZFS можно собрать degraded raid6 (raidz2) массив на 2
> дисках (и 2 sparse файлах на рамдиске, после чего те файлы
> отключить). В btrfs попытка собрать массив на файлах заканчивается ужасными плясками
> с loop deviceами.

Так их почти вроде все на loop девайсах и собирают. Ну и это как-то не основной кейс чтобы меня сильно парить.

> А ещё, в OpenZFS шифрование по-датасетно искаропки.

А это разве не в оракле только? Или они таки доделали?

> В btrfs вроде ещё не довпилили, хотя грозятся.

Ну да. И это еще можно записать в минусы - т.к. хоть и решаемо иными методами, но в ущерб вон тому, удобному менеджменту. Что как бы несколько пролюбливает пойнт.

К сожалению продвинутость дизайна имеет и обратные стороны медали... https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@re.../

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

215. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от аНОНИМ (?), 21-Июн-23, 12:25 
> У RAID1 его и не было, а в RAID 5 таки - да - радикально починили полным RMW в спорных случаях. Хоть это и медленнее.

Ну зашибись, в следующем LTS потестирую.

> от оригинальных данных вообще ничего не останется, даже суперблоков, и нельзя ЭТО идентифицировать как девайс пула

И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные (все файлы) мне вернуло после такого, а после ресилвера вовсе как новое стало. Потеря суперблока на 1 девайсе не помешала. btrfs -- больше половины не вернуло. С рейд1 обе ФС вернули всё.

> Ну насчет в 2 - хотелось бы деталей как мерялось и в какой конфиге.

Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt dist-upgrade -d делал, чтоб скорость качания не влияла).

> Для меня вообще загадка на кой ... надо псевдоблочный девайс поверх фс.

Во-1 скорость виртуалок с таким девайсом получается заметно больше, чем просто с файлом, прокинутым в виртуалку как диск, т.е. есть какие-то оптимизации. Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно делать), независимо от других. Это два технических преимущества.

> Насчет блоков: видите ли, это вовсе и не фича.

Ну мне если честно по барабану что там внутри. Btrfs просто жутчайше фрагментирует файлы под торрентами или файл (CoW) с образом виртуалки. В первом случае кол-во фрагментов оказывается даже больше, чем кол-во кусков торрента (потому что после 1ого файла границы блоков торрента оказываются посередине блоков ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее установленного размер блока не рассыпется фрагментами (зато сосёт полным отсутствием дефрагментатора).
С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже внутри датасета, не говоря уж о том, чтобы между ними. В btrfs последнее легко, если разные subvolume оказываются в одном mount point'е, cp --reflink=always офигенно между субвольюмами "копирует" таким способом.

В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у меня* получается так, что под рут или под хомяк, если нет необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на рейдах -- openZFS.

> Ну и это как-то не основной кейс

Когда я переезжал с 2 дисков в мирроре на 4 в рейд6 (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним balance тут.

> А это разве не в оракле только? Или они таки доделали?

Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в шифрованный дестинейшн.


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

225. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (225), 21-Июн-23, 22:48 
> Ну зашибись, в следующем LTS потестирую.

Это если что в 6.2 или 6.3 кернеле было. Решение компромиссное, изначально была идея заворкэраундить write hole _без_ RMW, но с актуальным дисковым форматом таки оказалось "все сложно".

При том суть проблемы - и что можно делать на этот счет - описано в их вике и readthedocs. При сильном желании можно гонять и без фикса, НО - есть нюансы. А метаданные вообще имеет смысл всегда как RAID1 (data = raid5) или RAID1c3 (data = RAID6) держать, их обычно не очень много и это для метаданных более удачная идея.

> И тем не менее, OpenZFS устроило срач в дмесге, но *ВСЕ* данные
> (все файлы) мне вернуло после такого,

Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем? Если сторажу совсем плохо, его фирмварь при старте тоже не прочтет служебные регионы, девайс не выйдет на режим. Если кто видел винчи клацающие при старте, девайсы не проходящие идентификацию и проч, знакомьтесь, ОНО. SSD и некоторые иные флешастые еще в readonly уходят когда резерва не осталось. Но это тоже не то. А какой практически значимый отказ вон то тестит?

Такой полный отвал девайса рюхается даже глупым классическим райдом. И в реальном случае бенефит вообще в чем? При редком постепенном вероятностном развале, характерном для текучек и сыпучек (FEC не справился, фирмварь решил вернуть "уж что вышло" вместо IO error) - btrfs ничем не хуже работает, чинит чексумы и вопит в dmesg. И так то выживает даже на откровенном трешаке где ext4 ушатывается менее чем за месяц.

И еще мне не совсем понятно - если будет как бы тот же девайс на вид, но де факто совсем другой уже, может даже с чем-то нужным, как оно определит: можно ли туда вообще писат и его ли это девайс вообще? Не то чтобы проблемный кейс просто случайно создать но в случае btrfs я понимаю как это: на девайсе 3 копии суперблоков, в них UUID фс и generation, так что можно проверить и что это наша ФС и что девайс не выпадал надолго, фатально отстав от эволюции состояний пула. А вон то как избегает факапов в таких случаях? Оно не сможет "похожий" девайс присвоить при случае и развандалить? Та же нумерация девайсов при сканировании может меняться, скан асинхронный и параллельный нынче - "кто первый ответил тот и /dev/sda", грубо говоря.

> а после ресилвера вовсе как новое стало.

Да это то понятно. Btrfs после полного scrub сыпучки тоже все утекшие регионы чинит на ура. Как и при просто натыкании на это при чтении.

> Потеря суперблока на 1 девайсе не помешала. btrfs --
> больше половины не вернуло. С рейд1 обе ФС вернули всё.

На самом деле если данные реально надо - btrfs'ный дизайн в этом достаточно любопытен, т.к. точек входа на самом деле более 1 и если стало тухло можно попробовать немало вариантов альтернативного парсинга с немного более старых вариантов деревьев которые GC еще не подгреб. Запись же недеструктивная. Но тут я сильно лучше в btrfsном дизайне шарю чем в zfs'ном.

> Гонял виртуалку, в которой делал apt dist-upgrade и засекал время (предварительно apt
> dist-upgrade -d делал, чтоб скорость качания не влияла).

Ну да блин, звездолет не очень ловко колесит по дорогам общего пользования. Но если вспомнить что у нас гиперпространственные движки есть, в отличие от лохов в пробках...
1) btrfs sub snap <system> </mgmt/before-upgrade>; sync; (снапшотим "систему сейчас")
2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
3) Если 2) зафейлился по любой причине, отваливаем на снапшот "before-upgrade". Если все прокатило ну, ок, тогда...
4) после всех проверок что результат устроил - стираем снапшот. Имеет смысл немного подождать и проверить весь софт до этого.

Зачем стоять на светофорах, если можно телепортироваться в назначение? А если не понравилась материализация в фонарный столб, сгонять на машине времени в прошлое, учесть препятствие, попробовать маневр еще раз, подкорректировав чуток :)

> Во-1 скорость виртуалок с таким девайсом получается заметно больше, чем просто с
> файлом, прокинутым в виртуалку как диск, т.е. есть какие-то оптимизации.

Зато менеджмент всего этого становтся просто адищем.

> Во-2, каждый такой псевдо-блочный девайс может быть заснапшотен (а также send-receive можно
> делать), независимо от других. Это два технических преимущества.

У btrfs в этом плане все сильно иначе, там subvolume всего лишь поддеревья (иерархии) с независимым снапшотированием. Это никак не отражается в блочные уровни а их райд "file based" как таковой. И в их дизайне вон то не имеет особого смысла. Я так понимаю что саням этот изврат надо было потому что у них не было управления девайсами и райдов в системе и они втянули классический варианто этого в ФС. Btrfs показал что не-классический вариант когда оно на уровне именно ФС - намного круче в менеджменте, имхо.

> Ну мне если честно по барабану что там внутри.

Не, вот на минутку, вы тут вещали что должно работать быстро. Или уж должно или уж нет. Моя ремарка - о том что "нативно" такой дизайн слоупок! А то что рамдиски быстрые - никто не сомневался. Только это не достоинство ФС и ее структур. И - внезапно - не катит без сотен рамы. Если сотен рамы на ломовой кеш нет (мир на файлопомойках не кончается) - ну оно и работает понятно как. А btrfs остается юзабелен даже на тощем роутере с мизером рамы, когда я ему в usb порт какойнить переносной винч с этим цепляю.

> Btrfs просто жутчайше фрагментирует файлы под торрентами

Вообще это зависит от кучи факторов. Я качал торенты и в зависимости от преаллокации, размера частей, и свободного места результат весьма варьируется. Ну и некто iZEN в свое время то же самое на zfs смог, догнав 3-дисковый пул (правда из ноутовых дисков) до чтения "аж" 15 мегов в секунду. При том там дефрага нет и очень интересно что он потом делал с столь крутым пулом, кроме пересоздания с ноля :). Настолько ушатать btrfs у меня не получалось, хотя, ок, у меня в многодисковых пулах с механическими дисками они все ж не ноутбучные, я не настолько мазохист.

> или файл (CoW) с образом виртуалки.

Опять же - все от конкретики сильно зависит. В данном случае от поведения виртуалки. Если виртуалка активно не пишет на диск - то и похрен вообще. Если пишет часто и мелко - ну, ой, фрагментируется конечно. Частично лечится увеличеением commit = и autodefrag в опциях монтирования, но вообще, у каждого дизайна есть сильные и слабые стороны. Логично юзать сильные и избегать слабые.

> ФС), OpenZFS тут рулит просто хотя бы тем, что мельче заранее
> установленного размер блока не рассыпется фрагментами

Минимально вменяемые торентклиенты обычно обладают своим кастомным кешом, как раз поэтому, и не гасят мелкими записями такого размера. Типовые фрагменты от них это какие-то мегабайты. Ну и запись менее чем чанк торента смысла не имеет особо, а сейчас народ и 4-8 мегов юзает - для уменьшения размеров торентфайла.

> (зато сосёт полным отсутствием дефрагментатора).

Вот мне и интересно что потом iZEN с своим супер-пулом делал :)

> С другой стороны, в OpenZFS никогда не будет (по-видимому) cp --reflink=always, даже
> внутри датасета, не говоря уж о том, чтобы между ними.

Это наверное как раз из-за блоков. В случае экстентов это заметно проще получается.

> cp --reflink=always офигенно между субвольюмами "копирует" таким способом.

Да оно и в пределах subvolume отлично работает. При этом оно просто 100% дедуп копии на старте, в уровень менеждмента не отсвечивает, именно "дешевый и сердитый дедуп" без ломового жрача проца и рамы, но логически это 2 разные копии.

Очень доставляет для data recovery: мастеркопию совсем не трогаем, а fsck и прочий дестрой на ее рефлинке. При номинальном размере в терабайтах реально создается за секунды, весит по размеру дельты, т.е. обычно немного, если не получилось, стереть попорченый рабочий образ, нарефлинкать за пару секунд новый и попробовать снова. Приятно себе оверсельнуть дохрена терабайтов под якобы-копию. Можно итеративно допинывать многотерабайтную чушку до кондиции не ожидая часами копирования и без мега-сторажей на 100500 терабайт, хранилка чуть больше образа нужна. А, надеюсь это объясняет почему возможность подоткнуть на время девайсов для расширения мне иногда полезна, а потом вынуть их и реюзнуть под иные цели.

> В целом каждый раз приходится выбирать, btrfs или openzfs. И пока *у
> меня* получается так, что под рут или под хомяк, если нет
> необходимости виртуалки гонять -- btrfs, для виртуалок или для файлопомойки/NAS на
> рейдах -- openZFS.

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

> (рейдz2) оказался основным :) Но конечно бтрфс наверное бы переехала одним
> balance тут.

Ну да, если места хватит - он это так делает: читает block group в старой схеме. Записывает в новую BG, с новой схемой, определяя чье это по backrefs. Апдейтит метаданные указывать на новый вариант. Освобождает старую BG. При чтении фиолетово в каком типа BG данные лежат, если половина в старой схеме, половина в новой - и похрен. Я даже крешил пару раз конверсию. Ну, после ребута возобновлял это дело да и дело с концом. Ничего не дохло. А вот с более классическими дизайнами я б так не рисковал - они откуда вообще знают прогресс конверсии допустим и как его возобновлять? Этой то штуке все просто - опять сканим bg в разбираемой схеме и переписываем их в новой, пока этого типа bg не останется. Т.к. cow-записи недеструктивные факап даже не портит данные по идее.

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

> Уже несколько лет как, с 2.0.x версий кажется. Работает, проблем не доставляет
> кроме каких-то особо странных случаев типа send/receiv'а из нешифрованного сорца в
> шифрованный дестинейшн.

А он это не чекает? Собссно btrfs fscrypt не сделал еще и потому что это странновато взаимодействует с мультиреференсами экстентов в _разных_ файлов, в fscrypt такое изначально не предусмотрели - для более простых фс делали. А совсем кастом они кажется не хотели, т.к. в принципе у fscrypt идея достаточно простая и как "менее параноидальное" шифрование вполне недурно смотрится.

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

235. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от аНОНИМ (?), 22-Июн-23, 18:32 
> Не спорю что сбитие автомобилем вертолета круто, но практическая польза в чем?

Отказ девайса это всё же немного другая ситуация, когда точно известно что данные там-то -- больше недоступны. И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их в принципе не сможет восстановить, а raid6 смог бы (если флипнулось только на 1 девайсе из N+2), но он этого не делает в принципе (я тоже проверял).
С другой стороны, я почитал старые крики btrfs-девелоперов о том что мол 'checksum on a checksum' (касательно хеша на блоки чётности) и то что они этого не сделали, потом посмотрел, что в openZFS всё чётко и изобрёл такой вот тест как в предыдущих мессагах описывал. Если openZFS выдюжило, то у меня 100% уверенность, что и любой случайный битфлип оно обнаружит и исправит. btrfs ниасилило -- ну значит и любой случайный битфлип может ниасилить, как раз из-за того, что не всё записанное на дисках рейда отхешено.

> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!

Вот уже начинаются пляски с бубном :) (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ вхлам). А openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок диска под линейный лог зарезервирован -- как раз быстро флашить синхронные записи подряд, чтоб диск бошками не ездил отписывая новую версию дерева каждый раз. В btrfs, говорят, тоже такой лог есть, но факт остаётся фактом -- там было *МЕДЛЕННО*.

> Зато менеджмент всего этого становтся просто адищем.

Если имеется в виду менеджмент снапшотов то в openZFS он да, немного геморный, но только лишь потому, что они решили абстрагироваться от простой модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее, надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).

> Я качал торенты и в зависимости от преаллокации, размера частей,

Во1 насколько я понял, преаллокации в btrfs как таковой нет, т.е. она может делать sparse файлы конечно же, но заранее место и положение на диске для последующей записи не резервирует в принципе.
Во2, не очень понял про кеш торрент-клиента, какой бы он ни был по размеру, если он кратно меньше чем весь качаемый торрент, то совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало, и он всё равно будет вынужден отписывать данные в файлы рандомно. И тут-то бтрфс и рассыпется на тысячи фрагментов, причём если в торренте много файлов, то кол-во фрагментов, репортируемых filefrag раза в 2 больше оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов, которые часто и по-чутьчуть дописываются, видно как сначала 4к кусочек добавился, потом ещё 4к, потом десяток последних кусочков по 4к рраз -- и в один запакованный кусок по 2-3 блока упихали. А вот на торрентах, особенно многофайловых, он примерно никак.

> Собссно btrfs fscrypt не сделал еще и потому

Я вот как-то на тот фскрипт пытался смотреть, и понял что без бутылки я там не разберусь. Даже какая-то утилита на go нашлась, которая его позволяет чуть проще менеджить. В то же время менеджмент шифрованных датасетов в openZFS примерно на уровне сложности luks -- ввёл пароль/ключ и оно появилось, вынес ключ -- обратно исчезло. Даже проще luksа, там ещё поверх расшифрованного псевдодевайса надо маунтить-размаунчивать, а openZFS само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.

> А он это не чекает?

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

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

240. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (240), 25-Июн-23, 03:03 
> Отказ девайса это всё же немного другая ситуация, когда точно известно что
> данные там-то -- больше недоступны.

Я просто не понимаю что вы тестировали и зачем - реально устройства ТАК не отказывают.

> И тогда даже raid5 как в mdraid справляется. Если данные битфлипнуты, raid5 их
> в принципе не сможет восстановить, а raid6 смог бы

В случае btrfs - сможет. В терминах RAID5 (минимальный пример): с1=a1^b1. Для a1 и b1 там чексум, отдельно, в метаданных, у метаданных может быть и иная схема, скажем raid1c3. Далее чекаем a1 и b1, если не сходится 1 из сум, XOR с parity и потом проверка по сумме еще раз. Сразу видим прокатило ли. Если померла парити, видно что a1^b1 != c1 хотя суммы верны, тогда c1 можно пересчитать из данных. Хранить и считать суммы блока c1 (парити) излишне.

> (если флипнулось только на 1 девайсе из N+2), но он этого не делает
> в принципе (я тоже проверял).

Btrfs может в отличие от обычного RAID делать более информированные решения из-за чексум.  Обычный RAID не имеет такого инфо, для RAID1 и RAID5 задник. Даже если мы видим несовпадения, неизвестно какая копия/блоки неверные. Чексумы позволяют это понять, улучшая свойства.

> 'checksum on a checksum' (касательно хеша на блоки чётности) и то
> что они этого не сделали,

Чексум на чексум проверяемый пересчетом из блоков данных не дает никакого нового знания, зато дает оверхед на счет и хранение. Хинт: чексумы блоков проверяют коректность данных, а парити считается из данных, можно сравнить посчитаное и сохраненное, поняв верен ли блок.

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

Я для себя предпочитаю чтобы ФС справлялась с реалистичными проблемами, а не тестами моделирующими ХЗ что: сторажи не отказывают вон так. А более реалистичные тесты на сыпучках (найденых btrfs'ом опять же) оно с должными схемами хранения переживает. Даже DUP - делает единичный проблемный девайс снова юзабельным, ценой ополовинивания. В древние времена он имел проблемы с repair т.к. не массовая штука. Но грю же - мы решаем проблемы совместными усилиями. В этом пойнт опенсорса.

>> 2) eatmydata apt dist-upgrade ... or whatever. И шел бы fsync нафиг!
> Вот уже начинаются пляски с бубном :)

Управление гипердвигателем лучше делать с иной семантикой чем ДВС, введя точные координаты в назначение. Личное телепание педальки и руля уже не актуально. И какой смысл бенчить реакцию на педальку, если я выкинул это действо совсем? Это еще быстрее. Сильно быстрее. Попробуйте, увидите.

При этом я имею инфо для полного, честного отката на known good, и даже время чтобы составить мнение - хочу я новое состояние или нафиг. На злобу дня, только что откатил неудачный апгрейд Deb12 -> Deb11. Железки на конкретной машине - взбрыкнули, разбираться прямща было не с руки, так что машина времени вернула как было - теперь можно НЕСПЕШНО пнуть причастных. В фоне. Пока все работает. А без снапшотов что б вы вообще делали? Бонусом writeable снапшотов, Deb12 на самом деле есть, и в writeable версии оного можно будет сделать тесты. Когда будет фикс.

> (и это с учётом ещё того, что тот самый dist-upgrade в виртуалке пофрагментирует образ

В пиковом случае дефраг есть. Что до fsync() его в последних нескольких ядрах разогнали в разы. Но я от этого в том кейсе ничего не выигрваю - в виде "а мы типа гипердрайв" я вообще не телепал руль и педальку. В этих терминах, весь dist upgrade - транзакция, уровня ФС. В виде подконтрольном мне. И я сам решаю потом, commit или rollback.

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

> openZFS искаропки синхронные записи выполняет быстро -- у неё маленький кусок
> диска под линейный лог зарезервирован --

В btrfs сие разогнали в разы последние пару ядер. Но как видите я просто пересмотрел что есть sync и точки начала-конца транзакции, это не костыль, это применение CS себе во благо. Работает намного круче глупого заучивания ритуалов.

> остаётся фактом -- там было *МЕДЛЕННО*.

Можете бенчмаркнуть с новыми кернелами типа 6.3 какого. Впрочем я с этого в вон том случае ничего не выиграю - вооооон то и так было супер быстрым. Даже пищет относительно последовательно. Inplace бы seek в патчимый регион делал, а cow это не надо и он с моим пересмотром семантики как раз свои сильные стороны выпятит, оформив записи куда ему там удобно и быстро. Да, я получаю полный журнал со скоростью безжурнальной фс.

> модели vfs->mountpoints. Тем не менее, в btrfs например сделать снапшот геморойнее,

Не вижу ничего геморного набрать btrfs sub snap <what> <where>.

> надо зачем-то корень монтировать (если в обычном состоянии замаунчены только сабвольюмы).

Не "надо" а "удобно делать так". Можно и иные варианты, просто уровень на 1 выше / с разными вариантами состояний вселенных, где мы можем путешествовать в ключевые точки пространства и времени - прикольная концепция. Логично что попадаем туда только после "сдвига измерений" (в более высокую абстракцию) содержащую в себе "все". Такой стиль понятен любому кто смотрел sci-fi и понимает концепцию ключевых точек, путешествий во времени и разветвления на мультивселенные с разным развитием событий. Это весьма буквальная реализация, writeable снапшоты тоже описываются этой идеей.

А так - subvolume при снапшоте не может содержать в себе subvolume (вместо него снапшотнется пустой дир): если сделать sub-in-sub, будет кольцевая зависимость экстентов друг на друга - и как это обрабатывать?! Не отменяет возможности снапшотнуть "что видишь" куда-то еще. Просто потом рулить менее удобно, а вон та абстракция "на уровень выше /" делает это удобным, логичным, и без "сдвига измерений" сложно снести снапшот нечаянно (по крайней мере файловыми операциями, типа F8 в миднайте на диру subvolume).

> Во1 насколько я понял, преаллокации в btrfs как таковой нет,

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

> Во2, не очень понял про кеш торрент-клиента, какой бы он ни был
> по размеру, если он кратно меньше чем весь качаемый торрент, то
> совпадений (когда будут иметься 2 соседних блока) будет пренебрежимо мало,

Может пребуферить большие сегменты и записывать их 1 операцией. При этом число фрагментов здорово снижается: 1 дело экстенты по 10 кил, другое по 10 мегз. Суть одна, а соотношения разые, второй случай = в 1024 раза меньше метаданных! И это не только про CoW но и про проблемы экстентных аллокаторов вообще. И вы еще не видели что XFS делает если это соотношение фиговое. Никогда не видали DVD-sized торент стираемый минутами? На забитый XFS его качните без преаллокации. Экстентный аллокатор предсказуемо слепит мелких экстентов, получит неудачное соотнощение данные-метаданные, будет тормозить. Это 1 из мест где печальные блочные аллокаторы могли бы хоть чем-то блеснуть но у ZFS CoW на забитом стораже не даст развернуться и как показал дизайнерский пул "от iZEN" - тоже "не очень", и дефрага нет.

> и он всё равно будет вынужден отписывать данные в файлы рандомно.

Чем крупнее экстент тем ниже число фрагментов и лучше соотношение данных и метаданных: быстрее парсинг и линейный доступ. Блочным дизайнам пофиг, там парсинг всегда в наихучшем варианте, с описанием всей аллокации блоков, от чего они и тормозные.

Солидный кеш позволяет клиенту писать готовые блоки большими непрерывными экстентами. Грю же знание CS улучшает жизнь, позволяя ОСМЫСЛЕННО подыграть дизайну ФС...

> И тут-то бтрфс и рассыпется на тысячи фрагментов,

Вопрос в размере фрагмента и соотношении data-metadata. Экстентный аллокатор эффективен если экстенты большие. Zfs пролетает, у него нет экстентов как таковых и оно не может в большой экстент, так что обречено жевать много метаданных на аллокации ВСЕГДА. Поэтому ZFS даже в проекте не конкурент САБЖУ на суперскоростных SSD где низкий оверхед наше все.

> оказывается, чем кусков торрента. autodefrag хорошо помогает для файлов типа логов,

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

> на торрентах, особенно многофайловых, он примерно никак.

Там скорее буфер клиента актуальнее. И многофайловые ... в торентах обычно БОЛЬШИЕ файлы. Для кучи мелочи торент не эффективен, лучше упаковать. Хотя-бы чтобы сжать имена файлов которые в таком виде заметный % от данных. Чем-то типа 7z - умеющим жать оглавление архива.

> Я вот как-то на тот фскрипт пытался смотреть, и понял что без
> бутылки я там не разберусь.

Именно. У этого дизайна - довольно много краевых случаев. Это плата за продвинутость. Извините, мелкий аэропорт изначально не предусматривал что межзвездный крейсер захочет запарковаться.

> шифрованных датасетов в openZFS примерно на уровне сложности luks --

...тогда профит в чем? Fscrypt интересен простотой в сетапе и использовани, но в именно btrfs из-за мультиреференсов на экстент, тот fscrypt не делан с идеей что на 1 экстент более 1 раза можно сослаться. И это как бы трабл.

> само. Жаль что в btrfs не пошли таким же путём как в openZFS, а связались с fscrypt.

У btrfs нет концепций из zfs, на самом фундаментальном уровне, связано с гибким аллокатором, и "файловой" природой RAID. Нет, никто не сдаст сильные стороны этого дизайна. Это весь пойнт его существования. Именно поэтому он nextgen и его просто менеджить. Крипто хорошо, но не ценой слома этой абстракции. Fscrypt в этом смысле наименее интрузивен, он не клещится с тем что хотел продвинутый аллокатор. Но в btrfs валидно 2 раза сослаться на 1 экстент как file1[10..20] и file2[30..40]. Btrfs на уровне дизайна волнует только чтобы блок был идентичного размера и содержимого, логическое размещение пофиг. А вот крипто обычно использует смещения для однозначного формирования nonce. И тут уже некие траблы. Нет, я не проектант запредельно крутых звездолетов и не выдам сходу хорошую логику на такой случай. Это хорошо работало для мелких самолетиков типа EXT4, а звездному крейсеру уже похуже. Но перспективнее вон того, где те понятия вообще не часть дизайна и вся идея дизайна это простое управление им а не жуткие костыли.

> ключа, которые пришлось шаманить нетривиальными способами. После создания уже диффы новых
> снапшотов вливаются на ура и без проблем (надо только "расшифровать" датасет
> на дестинейшене перед вливом при помощи ввода пароля).

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

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

173. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (173), 20-Июн-23, 18:42 
Чем больше снапшотов, тем сильнее btrfs тормозит. Число сильно ограничено...
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

177. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от аНОНИМ (?), 20-Июн-23, 18:51 
С какого кол-ва снапшотов, например, btrfs становится в 2 раза тормознее?
Ответить | Правка | Наверх | Cообщить модератору

187. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (186), 20-Июн-23, 19:54 
КО: справедливо для любой ФС со снапшотами. И не говорите, что ФС, созданная гениальными Сантехниками, не так. Может, только большее количество снапшотов тянет.
Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

200. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 21-Июн-23, 02:09 
В сабже автор довольно сурово уперся на эту тему. Не помню, но он кажется смог догнаться до миллиарда, чтоли, снапшотов. Не то чтобы это реально надо, но прошареный инженер строя лесопилку глядя на опыт предшественников все ж устроит алмазное напыление на зубьях, на случай если все-таки рельсу :). А если окажется мало то и парочкой индустриальных лазеров сдобрит. "Ухты@#$, так можно было?! Сказали о...е мужики"
Ответить | Правка | Наверх | Cообщить модератору

212. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (212), 21-Июн-23, 11:16 
> В сабже автор довольно сурово уперся на эту тему.

https://docs.kernel.org/filesystems/nilfs2.html

> There is no limit on the number of snapshots until the volume gets full.

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

226. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 21-Июн-23, 22:54 
1) Жесткий технический лимит на число снапшотов и импакт на перфоманс это 2 разные аспекта, не находите?
2) У конкретно nilfs есть много других проблем, главная из которых - он довольно заброшенный. Потому что не, он не то чтобы чем-то плох, но когда вопрос "чем лучше остальных?" - у него нет крутого и гибкого управления btrfs, а на 1 девайсе, или с "классическими" вариантами управления томами это все слишком канительно и кто так будет бодаться когда btrfs уже есть, а тут и сабж еще?
Ответить | Правка | Наверх | Cообщить модератору

14. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Аноним (14), 19-Июн-23, 11:53 
10 лет развивали, развивали... а потом решили пересесть на рустик и ещё 10 лет в мейнстрим это никто не возьмёт, потому что всё поменялось, опять всё фиксить... а потом надо будет опять фиксить фичи "как у ZFS и BTRFS" и перфоманс "чтобы ближе к ext4 чем к ZFS"
Ответить | Правка | Наверх | Cообщить модератору

20. Скрыто модератором  +/
Сообщение от Аноним (-), 19-Июн-23, 12:11 
Ответить | Правка | Наверх | Cообщить модератору

29. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Анонимусс (?), 19-Июн-23, 12:48 
10 лет btrfs развивали-развивали, а тольку практически никакого - как была глючным поделием, так и осталась. Ну ладно, не настолько глючным как 10 лет назад, но сильно лучше не стало.

Рустик уже в мейнстриме, первые дрова уже на подходе (ставлю на драйвер видяхи для яблока)
Чел наверное написал пару утилит и понял насколько раст лучше чем си, раз так написал.
И ему явно есть с чем сравнить - точно есть большой опыт написания кода на си))

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

47. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от аНОНИМ (?), 19-Июн-23, 14:42 
бтрфсу конечно не хватает некоторых фич, но других фич не хватает и openZFS. Но вот насчёт глючности я бы поспорил. Я даже специально взгромоздил btrfs на раздел с торрентами, работает цуко и не глючит :) На рутовых разделах она тоже у меня живёт счастливо и радует снапшотами.

Конечно, всплывает такая хрень как ужасная фрагментация (по самой сути рандомных записей в файлы при качании торрентов), но встроенный дефрагментатор своё дело делает.

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

55. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Витюшка (?), 19-Июн-23, 14:52 
Сильно лучше стало. Оно у Facebook на продакшн стоит.

Это тебе не васянские локалхосты от икспердов opennet.

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

72. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним_5 (?), 19-Июн-23, 15:45 
То что они стоит у ФБ не значит что подойдет для васянского локалхоста.
У ФБ ресурсов - redundancy, бекапы, люди - намного больше.
Ответить | Правка | Наверх | Cообщить модератору

121. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 20-Июн-23, 00:21 
> У ФБ ресурсов - redundancy, бекапы, люди - намного больше.

Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему. В этом месте интересы фэйсбука и локалхостов нехило совпадают.

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

220. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 21-Июн-23, 13:29 
> Тем не менее, даунтаймы и внезанпные глюки в юзерских данных и им тоже ни к чему.

им пофигу - это не их данные. Да, теряли, и не один раз. А чотакова, ты котиков сам же новых понавыложишь.

А вот потерять невосстановимо фотки умершего члена семьи у себя на локалхосте - это совсем другая история.

Так что нет, не совпадают даже приблизительно. Цель фейсбука - сделать максимально дешево и х-ево.
(рабы которые все это чинят - тоже максимально дешевые)

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

227. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (227), 21-Июн-23, 23:35 
> им пофигу - это не их данные. Да, теряли, и не один
> раз. А чотакова, ты котиков сам же новых понавыложишь.

А знаешь что, мистер умник? Ты похрани-ка такой объем данных - для такого числа юзерех - на чем там тебе удобно. Столько же лет. И мы посмотрим получится ли у тебя с твоими супертехнологиями вообще лучше если отмасштабировать до того же размера.

Понимаешь, чисто практически, если MTBF = 1 000 000 часов, и у тебя 1 девайс, ты скорее всего не доживешь до его отказа. Надежно типа. А если будет 1 000 000 девайсов по планете раскидано, "каждый час что-то ломается" может получиться. Надежно, типа? :)

Из вот этих соображений тестам "в масштабе" доверия несколько больше.

> А вот потерять невосстановимо фотки умершего члена семьи у себя на локалхосте
> - это совсем другая история.

Невосстановимо, в дизайне с недеструктивной записью и встроеной офлайн-читалкой и множественными точками входа для репарсинга - надо еще постараться, имхо. С более типичными файлухами если ситуация не идеальна - может хуже быть, у них запись же деструктивная и (мета)данных "есчо" чисто технически не остается, сразу и быстро, без возможности отменить или пересмотреть это вообще совсем. Ну и бэкапы не отменяли. Желательно в разных локациях. А то мало ли какие пожары, наводнения, химеры, тени, птички...

Я вон с ntfs твоего любимого testdisk+photorec вытаскивал недавно. Ну вот пролюбило оно имена файлов и аллокацию, что хочешь то и делай. Данные ессно на месте. К счастью оно не фрагментировано почти - а отсутствующие имена... чем крут линух? Можно накорябать сриптик, он пнет ffprobe и exiv2 после вон тех, позырит теги ... и через 5 минут оно лихо именует сотни тыщ фоточек и мувиков "как камера" - сгенерив имя по дате, из тегов. Через еще 5 минут все лихо переименовано и разложено лучше чем изначально :)

Но как ты уже понял, это - не заслуги нтфс. И не его штатного тулкита ФС. О которых в этой истории сложно сказать что-то хорошее.

> Цель фейсбука - сделать максимально дешево и х-ево.

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

> (рабы которые все это чинят - тоже максимально дешевые)

КМК по сравнению с тобой они - богатенькие буратины.

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

231. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 22-Июн-23, 11:12 
> Ты похрани-ка такой объем данных - для такого числа юзерех - на чем там тебе удобно.

мне - нахрен оно не надо, у меня другой бизнес, не слежка за всем миром.

> Столько же лет.

в смысле - сразу же половину прое..ть?

> получится ли у тебя с твоими супертехнологиями вообще лучше если отмасштабировать до того же
> размера.

а мне не надо того же размера. У меня совершенно другие задачи и вдобавок нет дешевых рабов (много жрут и гадят, а подвала нет, там бомбоубежище). И то что для мордокниги кажется приемлемым трейдофом - для меня недопустимо.

Я - не мордокнига, в этом и разница. Поэтому и никаких выводов в стиле "что хорошо мордокниге будет просто прекрасно и для меня". Нет, не будет.

"не все решения системных программистов подходят для прикладных" (с)

> Но как ты уже понял, это - не заслуги нтфс. И не его штатного тулкита ФС. О которых в этой
> истории сложно сказать что-то хорошее.

их заслуга - что мне за 25 лет существования ntfs и использования его в хвост и гриву - ни разу никакой фоторек использовать не пришлось и двоичным редактором ковыряться в своем диске тоже.
А вот про прекрасные файловые системы л@п4тых - я того же самого сказать не могу.

К счастью, с некоторых пор я использую их в стиле выкрасил и выбросил, никаких ценных данных на них не храня.

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

241. Скрыто модератором  +/
Сообщение от Аноним (-), 25-Июн-23, 03:18 
Ответить | Правка | Наверх | Cообщить модератору

209. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от bOOster (ok), 21-Июн-23, 08:39 
И главное - основной разработчик btrfs. Он то 100% в курсе как выпиливать данные из мертвого раздела, в отличии от шайки оголтелых...
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

232. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 22-Июн-23, 11:13 
> И главное - основной разработчик btrfs. Он то 100% в курсе как
> выпиливать данные из мертвого раздела, в отличии от шайки оголтелых...

или ему просто наплевать.
Тут, правда, у изрядной части шайки все так же - этой дешевой порнухи новой накачают.

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

27. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (212), 19-Июн-23, 12:45 
> Just because you made a painting with a $10k horsehair brush and golden paint does not necessarily make it great art.

бриллиантовый камент для любителей раста. Обычным людям это фсчудище и bcache на ноутах с NVME только для замедления процессора и деградации аккума.

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

31. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним_5 (?), 19-Июн-23, 12:56 
Бриллиантовый камент для любителей "бриллиантовых каментов":
"A good craftsman cares about his tools. Listen to woodworkers who get together, they'll be talking about their tools just as much as the actual work. We're interacting with these tools every day, and the quality of the tool very much affects the quality of the work."
Ответить | Правка | Наверх | Cообщить модератору

49. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Tron is Whistling (?), 19-Июн-23, 14:43 
Remember they won't use 10K horsehair brush for woodcutting because it's just pointless.
Ответить | Правка | Наверх | Cообщить модератору

32. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Аноним (32), 19-Июн-23, 13:01 
>теперь безумно писать код на языке Си, когда появился лучший вариант. Rust уже задействован в Bcachefs
>Раст необязателен

балаболили они. Так же, как другие по совершенно другому поводу балаболили не краснея (но всем уже тогда было всё понятно), что реестр - это только для защиты детей.

Предлагаю прекратить этот клоунский маскарад, официально дропнуть в linux все платформы, для которых Rust не поддерживается (но из исходников фактическую поддержку не выпиливать и тестирование продолжать, но кто эти платформы в энтерпрайзе испольеует - тот пусть и решает, что ему дешевле, Rust допилить, или самим эти платформы дропнуть, от энтузиастов всё гавно как всегда толку 0, поэтому их мнение веса не имеет, если только они не готовы скинуться деньгами в достаточном количестве на fulltime-команду), и начать переписывать само ядро на Rust.

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

37. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Анонин (?), 19-Июн-23, 13:32 
> от энтузиастов всё гавно

Не, ну чего ты так про энтузиастов, обидно ведь.

Вообще не понятна претензия к поддержке платформ. Ты собираешься развернуть эту файлуху на мк или на каком-то древнем железе? Ну значит ты просто не сможешь это сделать. И всё.
Вот какой платформы тебе не хватает в раст?

> и начать переписывать само ядро на Rust.

О, наконец-то до людей доходить начало!

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

43. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (32), 19-Июн-23, 14:23 
Не, Rust же i386 поддерживает, он даже древние микроконтроллеры без mmu поддерживает. Это с платформами без llvm у него проблемы.

>Вот какой платформы тебе не хватает в раст?

Мне лично всех хватает пока. Но другим людям может не хватать. Это очень обидно и унизительно, когда твоё оборудование выкидывают, а тебя пускают по миру с голой жопой и так лучше не делать. Но мир у нас злой и циничный. И не надо это маскировать. Чем это виднее, тем быстрее до людей дойдёт, что так жить не надо и тем быстрее он станет нормальным. Поэтому было бы намного лучше, если бы вместо всякого балабольства нам бы говорили всё как есть. Не "мы делаем это для вашего же блага", а "нам вредно ваше благо, но вы жалкие, и нашим действиям никак не можете помешать".

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

45. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Анонин (?), 19-Июн-23, 14:41 
Не увидел там балабольства.
Чел пишет "хочу раст, потому что не люблю дебажить код".
Он делает это для себя - чтобы ему легче было писать код.
И саму фс он не просто так пишет - или для себя, или на заказ, или из любви к искусству.
Плюс он считает, что смена языка сделает код более надежным, т.е пользователям тоже станет лучше.

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

> "нам вредно ваше благо, но вы жалкие, и нашим действиям никак не можете помешать".

Как-то слишком пафосно.
Тут скорее "мы делаем это для себя, а вы можете воспользоваться результатами НАШЕГО труда. Но если вам что-то не нравится - то или воспользуйтесь результатами еще чего-то труда, или вперед работать самим."

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

84. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (84), 19-Июн-23, 17:06 
> Не увидел там балабольства.

Балабольство у тех, кто заявляет, что Rust не будет обязательным, а не у автора файловой системы. Автор ФС - молодец, что делает исследования.

>Он делает это для себя - чтобы ему легче было писать код.

Вот пусть и держит тогда это out of tree. Без шансов найти широкое применение и всех подсадить на зависимость от Rustа. Как подсадили разрабы safetensors - теперь приходится ставить громадный растовый тулчейн и геморроиться с компиляцией только для того, чтобы pytorch мог прочитать сериализованные так модели.

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

92. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Анонин (?), 19-Июн-23, 17:34 
> Балабольство у тех, кто заявляет, что Rust не будет обязательным

Так раст и не обязательный! Просто не пользуйся этой ФС или всем что зависит от раста.

> Вот пусть и держит тогда это out of tree.

Охохо, ты будешь указывать разрабу и ментейнерам ядра что дедать?)) Самому не смешно?

Ну так не пользуйся safetensors - бери старые версии.
Или не пользуйся чужими сериализованными моделями.
Или вообще выкинь pytorch.

У тебя же куча возможностей. Еще раз - это всё делалось и делается не для тебя лично.

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

103. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (102), 19-Июн-23, 21:29 
А, понятно. Linux - для RedHat лично. Спасибо, что напомнили.
Ответить | Правка | Наверх | Cообщить модератору

223. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 21-Июн-23, 17:04 
> А, понятно. Linux - для RedHat лично. Спасибо, что напомнили.

ну зачем же ты так? Есть еще другие платиновые спонсоры.

Линукс для них - тоже.

А ты перепоклонись-ка двадцать раз и colour на color и обратно поисправляй в своем ненужном редхату и мордокниге патче, а потом все равно пойди с ним нахрен потому что он кому-то чем-то не понравился.

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

122. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 20-Июн-23, 00:24 
> Так раст и не обязательный! Просто не пользуйся этой ФС или всем
> что зависит от раста.

Актуальная реализация вообще на си. А про планы с хрустом - але, гараж, пока в кернеле инфраструктуры для этого толком еще нет даже. И даже для сишной версии инфраструктуру то только начали адаптировать совместными усилиями. Так что сперва будет версия на си. А когда-нибудь может и на хрусте появится. А почему бы и нет, особенно если к тому моменту GCC'шный бэкэнд хруста будет в форме для билдовки ядра?

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

146. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Sw00p aka Jerom (?), 20-Июн-23, 08:37 
>т.е пользователям тоже станет лучше.

Мне, как пользователю, нах не нужно неотлаженное гамно, х*як, х*як и так сойдет, пользователь отпишет свой комент

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

44. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (32), 19-Июн-23, 14:26 
>всё гавно

Опечатка, там было

>всё равно

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

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

36. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (36), 19-Июн-23, 13:29 
Ешьте дети ext4, будете здоровы! А прочий кaл оставьте корпоративным психам, они должны страдать.
Ответить | Правка | Наверх | Cообщить модератору

51. "Продвижение Bcachefs в состав ядра Linux"  –7 +/
Сообщение от pavlinux (ok), 19-Июн-23, 14:46 
ext/2/3/4 - cамые блевoтные ФС, - для девочек которым пофиг что ставить.
Точнее они даже не вдупляют различий, преимуществ  и отсутствие своих же требований.
Ответить | Правка | Наверх | Cообщить модератору

76. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от Аноним (6), 19-Июн-23, 15:51 
Это ты не хочешь понять что эти твои фичи модненьких ФС это маркетинговый буллшит. Блестящая упаковка за которой ничего нет.
Ответить | Правка | Наверх | Cообщить модератору

123. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 20-Июн-23, 00:28 
> Это ты не хочешь понять что эти твои фичи модненьких ФС это
> маркетинговый буллшит. Блестящая упаковка за которой ничего нет.

Ну да, замененный глючный проц, пару планок битой RAM, текучие SD/flash и глючные шнурки в коллекцию - маркетинговый булшит наверное, а не чексумы фс в деле, хехе :)

А вам из всего этого комп следовало бы свинтить, с вашим EXT4, посмотреть, заметите ли вы вообще подвох :))). Не, можете и таким железом пользоваться, типа сэкономили заодно. Какимнить геймерам сойдет наверное даже. Слетит система - переставят, впервой чтоли?!

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

83. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (83), 19-Июн-23, 17:06 
ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по дефолту.
Остальное либо под конкретную задачу, либо нестабильное, либо ограниченное.
Так что ты может и прав, но это тоже само по себе плюс.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

105. "Продвижение Bcachefs в состав ядра Linux"  +2 +/
Сообщение от Аноним (102), 19-Июн-23, 21:32 
Могу посоветовать использовать NTFS. Там, конечно, бывают неудаляемые файлы, и директории, в которых они лежат, которые chkdsk терпит и ничего плохого не видит, зато есть хекс-редакторы с поддержкой парсинга, которыми можно их структуру в $MFT инвалидировать
Ответить | Правка | Наверх | Cообщить модератору

109. "Продвижение Bcachefs в состав ядра Linux"  –2 +/
Сообщение от U202204161753 (?), 19-Июн-23, 22:07 
Да ладно ... И как воспроизвести?

  Бэкап готового "глюка" хоть есть?

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

157. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (15), 20-Июн-23, 12:08 
Я такое часто видел, но не не могу утверждать, по какой причине это происходит. Слишком рандомно возникает. Приходилось подмонтировать на запись с ntfs3g и удалять в ней, а это ещё хуже, потому что неизвестно, как она после неё будет работать и когда ей станет совсем плохо. Не совсем понимаю какие бекапы ты рассчитываешь увидеть, тебе отправить многотерабайтный дамп где-то там посыпавшейся ntfs, что ты с ним собираешься делать? И главное, зачем мне хранить эти дампы.

Всё гораздо интереснее когда файлы исчезают, повреждаются, или вся ntfs разваливается. И такое было. Тут хотя бы есть определённая закономерность, все фатальные повреждения случались в результате автоматического запуска chkdsk, которая уже автоматически всё разносила (я уверен до неё данные были целыми).

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

178. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от U202204161753 (?), 20-Июн-23, 18:58 
} многотерабайтный дамп где-то там посыпавшейся ntfs

Можно восстановить в VM.
На динамический .vhd / .vhdx

Удалить всё остальное кроме повреждённого каталога.

Вот со сжатием файла .vhd[x] есть неясности: надо чтобы глюк не был затёрт "байтом 0"

(
   Я-то разрушенный диск с ReFS сохранил.

   Надо же на чём-то тестировать утилиты.
)


--

} chkdsk

Да, эта утилита меняет данные зачастую и без ключа "исправить".

Чаще всего видел файлы нулевого размера.


P.S. ОЗУ хоть с ECC ?

Если без, то не битое?

P.P.S.

NTFS весьма надёжная FS.
При глобальных же сбоях - просто разворачивал последнюю ежечасную резервную копию.

Или реверсировал зеркало на Starwind HA.

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

194. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (194), 20-Июн-23, 22:41 
Бэкапа нет, как и диска чтобы его хранить. Я - админ локалхоста. Проблемный диск - самый большой в системе.
Ответить | Правка | Наверх | Cообщить модератору

236. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от pavlinux (ok), 24-Июн-23, 00:19 
> ext4 динственная фс, которую несмотря на все её недостатки, могу советовать по дефолту.

Ти кто, пилять, xyета Анонимная, советовать он может...  Тебе имя своё стадно писать.... аналлитики, йопт. Сцк.... ржууу  DDD

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

90. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Kuromi (ok), 19-Июн-23, 17:18 
На самом деле на пользовательском уровне отличия очень даже очевидны. ext2 без журнала и может рассыпаться от неудачной пропажи жлектричества, ext3 медленная (по сравнению с ext2), дико долго удаляет файлы и fsck там нешустрый, в ext4 эти проблемы пофиксили, поэтому почти никакого резона сейчас использовать ext2\3 нет вообще.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

38. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (39), 19-Июн-23, 13:47 
> По производительности Bcachefs опережает Btrfs и другие ФС на базе механизма Copy-on-Write, и демонстрирует скорость работы, близкую к Ext4 и XFS.

Ага, конечно, в перспективе разве что

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

40. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (40), 19-Июн-23, 14:01 
>Из планов на будущее упоминается желание использовать при разработке Bcachefs язык Rust. По мнению автора Bcachefs он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант. Rust уже задействован в Bcachefs в реализации некоторых утилит, запускаемых в пространстве пользователя. Более того, вынашивается идея постепенно полностью переписать Bcachefs на Rust, так как использование этого языка существенно экономит время на отладку.

супер, пройдет еще с десяток лет до принятия в ядро, пока он там все перепишет...

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

54. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Анонус (?), 19-Июн-23, 14:49 
Поэтому он сначала отправит в ядро, а потом начнет переписывать.
Ответить | Правка | Наверх | Cообщить модератору

78. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (6), 19-Июн-23, 15:52 
Сначала его отправят как Шишкина, а потом он скажет что его притесняют.
Ответить | Правка | Наверх | Cообщить модератору

53. "Продвижение Bcachefs в состав ядра Linux"  +3 +/
Сообщение от pavlinux (ok), 19-Июн-23, 14:48 
> надёжности и масштабируемости

Кэш - это временная свалка, для быстрого доступа.
Нахуа помойке снапшоты и резервное копирование? :D

Более того, порядок доступа, очередь к кэшу - это динамическое состояние.
Если после сбоя поднять сервер и востановить кэш из снапшота, то запрашивающие
клиенты уже ушли, нахер нужен снимок кэша часовой давности? ИТшные дол6оящеры.  

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

60. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от _hide_ (ok), 19-Июн-23, 15:00 
Когда у тебя помойка под петабайт, а её сброс приведёт к отказу в обслуживании (реальное железо просто не выдаст нужно производительности для восстановления). Так что холодный старт как понятие отсутствует и кэш уже давно не кеш, а операционные данные, валидность которых проверяется как можно реже.
Ответить | Правка | Наверх | Cообщить модератору

87. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от n00by (ok), 19-Июн-23, 17:13 
> Если после сбоя поднять сервер и востановить кэш из снапшота,

При записи на ФС данные идут на быстрый (твердотельный) накопитель, откуда фоном переносятся в хранилище (НЖМД). Первый в данном случае назван кешем. Восстанавливать его не от куда.

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

147. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Sw00p aka Jerom (?), 20-Июн-23, 08:47 
DRAM->SSD->HDD
Ответить | Правка | Наверх | Cообщить модератору

56. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Unnamed Player (?), 19-Июн-23, 14:52 
>В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.

Автор путает CoW и RoW?

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

58. "Продвижение Bcachefs в состав ядра Linux"  –1 +/
Сообщение от pavlinux (ok), 19-Июн-23, 14:55 
>>В Bcachefs используется механизм Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния.
> Автор путает CoW и RoW?

А ты ешь ,кушаешь или жрёшь? :D

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

61. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Unnamed Player (?), 19-Июн-23, 15:05 
Реализация в корне отлична.
Ответить | Правка | Наверх | Cообщить модератору

70. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от pavlinux (ok), 19-Июн-23, 15:42 
> Реализация в корне отлична.

CoW - это абстрактная хрень, нюансы зависят от авторов.
Кто-то FIFO называет CoW :)  C одного конца Copy, с другого Write

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

202. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 21-Июн-23, 02:20 
> CoW - это абстрактная хрень, нюансы зависят от авторов.

Однако у них есть и ряд типовых общих свойств. Например использование ресурса на хранение только дельты от оригигнала. И это хоть RCU vs RAM хоть qcow vs снапшот, хоть btrfs и reflink относительно оригинала. Эта идея останется во всех трех случаях, хоть детали реализации и драматически разные. Собственно это и есть пойнт для возни с такими технологиями. Оверсел и оверкомит ласкает слух. Иногда даже мне. Если я на 4-терабайтной хранилке разложил пяток "копий" 3-терабайтного образа в разных стадиях эксперимента по выуживанию из него данных  - я конечно "оверсельнул" себе 15 псевдо-терабайтов при всего 4 реальных, но это ж катит в силу природы файлов :)

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

57. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (57), 19-Июн-23, 14:53 
Чем отличается от lvmcache + ext4 ? Файловая система в курсе что кешировано, а что нет?
Ответить | Правка | Наверх | Cообщить модератору

203. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (-), 21-Июн-23, 02:20 
> Чем отличается от lvmcache + ext4 ?

Нормальным менеджментом стоража в стиле btrfs вместо всей этой замшелой и кривой камасутры.

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

64. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от keydon (ok), 19-Июн-23, 15:21 
> Rust уже задействован в Bcachefs
> По мнению автора Bcachefs он любит программировать, а не отлаживать код,

Дальше не читал. Автор может и дальше пользоваться своей ФС. Еще одна недописанная и заброшенная в будущем ФС в ядре не нужна, тем более если тащит за собой раст.

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

66. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноний (?), 19-Июн-23, 15:28 
Спасибо, но я лучше reiser5 подожду.
Ответить | Правка | Наверх | Cообщить модератору

96. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (96), 19-Июн-23, 18:03 
Кстати, а когда выйдет Ганс райзер? Я реально жду новый РайзерФС от ганса.
Ответить | Правка | Наверх | Cообщить модератору

100. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (100), 19-Июн-23, 19:53 
Следующая попытка прошения помилования в 2026
Ответить | Правка | Наверх | Cообщить модератору

106. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (102), 19-Июн-23, 21:33 
Ему же вроде в 23 должны были дать.
Ответить | Правка | Наверх | Cообщить модератору

107. "Продвижение Bcachefs в состав ядра Linux"  –3 +/
Сообщение от Аноним (102), 19-Июн-23, 21:45 
Живым не выйдет. Он проявил гордыню, не продемонстрировал покорность, посмел отклонить первое предложение Суверена. Ну тогда до него довели, что чтобы его обвинить и казнить им железобетонных доказательств не надо, достаточно их личной убеждённости представителей Суверена, что это он сделал. Суверену нужно, чтобы все знали - с Сувереном шутки плохи.
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

189. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 20-Июн-23, 20:18 
Гордыня предшествует падению. Не зря так говорят.

Если с вами вообще тима работать совместно не хочет, и вы не понимаете что реюзабельные фичи надо вывешивать для всех caller'ов - кина не будет, тусите в своей пещере сами по себе. И вот сидит гражданин в своей пещере, сделав 0 доведенных до ума, юзабельных файлух. Рассказывает всем как надо было. Пруфом... ээ... сказки про белого бычка, отсыл к CS, сказ что я умный, все раки. А со стороны - очередной старый академбрюзга, бесполезный и не от мира сего.

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

234. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (212), 22-Июн-23, 12:35 
> И вот сидит гражданин в своей пещере, сделав 0 доведенных до ума, юзабельных файлух. Рассказывает всем как надо было.

а ты с ним сидел чтоли ?

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

95. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от Аноним (96), 19-Июн-23, 18:02 
>Из планов на будущее упоминается желание использовать при разработке Bcachefs язык Rust.

И этот вляпался.

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

180. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Neon (??), 20-Июн-23, 19:04 
Модно, стильно, молодежно))). Иначе грантик не дадут
Ответить | Правка | Наверх | Cообщить модератору

101. "Продвижение Bcachefs в состав ядра Linux"  +1 +/
Сообщение от fuggy (ok), 19-Июн-23, 21:19 
Интересно что они там такое хотят блочное кешировать. Во-вторых, есть кеш ОС, если кеш самого диска, которым управляет контроллер диска. А тут целая ФС только для кеширования.
Сейчас большие HDD имеют кеш сравнимый с небольшим SSD. Ещё есть гибридные HDD, которые и являются по сути встроенный SSD для кеширования без всяких специальных ФС.
Ответить | Правка | Наверх | Cообщить модератору

108. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (104), 19-Июн-23, 21:51 
> Сейчас большие HDD имеют кеш сравнимый с небольшим SSD. Ещё есть гибридные HDD, которые и являются по сути встроенный SSD для кешировани

При этом и те, и другие — консьюмерский отстой, которым большие операторы не пользуются.

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

136. "Продвижение Bcachefs в состав ядра Linux"  –2 +/
Сообщение от Аноним (136), 20-Июн-23, 04:01 
Сейчас уже и некоторые SSD с гигантским кэшем (на сотни гигов).
Вот только этот кэш сильно отличается и от кэша ОС и от кэша ФС в ОЗУ и управлять им условно не получится (в теории через отправку команд или изменение прошивки, на практике никак) и фактически считается характеристикой ssd и можно его даже и не рассматривать.
Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

210. "Продвижение Bcachefs в состав ядра Linux"  +/
Сообщение от bOOster (ok), 21-Июн-23, 08:46 
И че толку от этого кэша если интерфейс по факту SAS/SATA?
Ответить | Правка | Наверх | Cообщить модератору

143. "Работа по включению Bcachefs в состав ядра Linux"  –2 +/
Сообщение от нах. (?), 20-Июн-23, 06:49 
Что-то там включают-выключают в ядро, а может просто починить повышенную нагрузку на CPU при передвижении USB-Mouse? Да ну нет, бред какой-то. Сук, я 15 лет наблюдаю этот глюк, скажете виноваты иксы, а мне пох, мне пришлось купить мышку с PS/S, чтобы избавиться от этого, вот тебе и линукс.
Ответить | Правка | Наверх | Cообщить модератору

145. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от vbcnthfkmnth123 (ok), 20-Июн-23, 08:35 
На Linux-libre этот глюк тоже наблюдается?
Ответить | Правка | Наверх | Cообщить модератору

148. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (148), 20-Июн-23, 09:33 
Чего это она повышенная мышка же хорошо двигается, быстро. Почему бы не загрузить этим процессор. А то что там у аналоговых PS/2 что-то там меньше, так и двигается она хуже. Не так активно и самозабвенно.
Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

181. "Работа по включению Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Neon (??), 20-Июн-23, 19:06 
Это какой дохлый комп нужно иметь, чтобы USB-Mouse - давала повышенную нагрузку на CPU ?!))) На первопне что ли ? Или на 386 ?)))
Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

144. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (144), 20-Июн-23, 07:43 
> По мнению автора Bcachefs, он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант.

А по русски написать сложно было?

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

149. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (148), 20-Июн-23, 09:33 
Нажимай исправить и пиши, что сложно?
Ответить | Правка | Наверх | Cообщить модератору

150. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Пряник (?), 20-Июн-23, 09:54 
> обновлённый набор патчей

Я, конечно, понимаю, что это скорее всего перевод, но этот акцент на обновлении патчей подразумевает, что все "в теме" и знают, что старая версия не зашла, а это обновлённая и уж точно всё будет гуд.

Либо текст реально достали из каких-то "внутренних" переписок.

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

152. "Работа по включению Bcachefs в состав ядра Linux"  +2 +/
Сообщение от Пряник (?), 20-Июн-23, 10:19 
Вот уже напрягает "стабилизация реализации снапшотов". Что там стабилизировать? Снапшоты должны просто работать, как в ZFS - снапшот это просто метаданные, то есть сохранённые адреса блоков ZFS. Даже на словах просто и понятно. Ломаться нечему, ZFS просто не подтвердит никакую запись данных в себе, пока корректно не считает записанный блок. А в этом Bcachefs какие-то "срезы" снапшотов.

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

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

166. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 20-Июн-23, 16:06 
> Вот уже напрягает "стабилизация реализации снапшотов". Что там стабилизировать?

_запись_

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

Оно и действительно совершенно контринтуитивно.

В bcache по задумке все действительно красиво. Вопрос только в том, когда ж оно будет - работать.
И не попадем ли мы все в рай гораздо раньше.

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

190. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (190), 20-Июн-23, 20:27 
В btrfs оно тоже красиво и интуитивно. Большую часть дизайна Кент слизал оттуда, постаравшись обойти опробованные btrfs'ными лбами грабли. Нормальный подход так то.
Ответить | Правка | Наверх | Cообщить модератору

193. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 20-Июн-23, 22:35 
> В btrfs оно тоже красиво и интуитивно.

вот вообще ни разу.

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

204. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 21-Июн-23, 02:25 
> вот вообще ни разу.

Да ну ладно тебе. Если виртуализатором с снапшотами хоть раз в жизни пользовался то и эти снапшоты в общем то логичны и понятны. А "one level above /" это так в моем стиле. Клево убунтуи это придумали.

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

219. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 21-Июн-23, 13:24 
хинт - не все виртуализаторы - бредовые поделки на базе все той же единственноверной фс.

А так у некоторых не будем покзаывать пальцем виртуализаторов все интуитивненько - "хотите вернуться на этот вот снапшот? Ок? Точно ок? Ваше текущее состояние и все вообще что вы с тех пор понаделали - сейчас превратится в тыкву!"
Что в целом вполне логично, где его хранить-то в системе где снапшот - сущность неизменная?

Нет, отдельно сохранить еще одно состояние конечно можно - но тут ты уже сам себе создаешь вермишель и сам как хочешь так и распутывай потом.

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

229. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 22-Июн-23, 00:12 
> же единственноверной фс.

Это о чем?! Я пользовался вмварью, гиперви, kvm... и в конечном итоге, логика CoW дисков-в-файле у них всех достаточно похожая. CoW диски-в-файле вообше ни на какой фс не основаны, они на блочном уровне работают как таковые.

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

> состояние и все вообще что вы с тех пор понаделали -
> сейчас превратится в тыкву!"

Это вполне типовое поведение виртуализаторов: если надо текущее состояние сохранить - вон там создание снапошта. Иначе оно только подумайте - и правда продолбается после отката на вон тот снапшот. И так по-моему все вышеперечисленные работают. Их снапшоты аналогичны "read only" снапшотам btrfs. Writeable - возможность продолжить с этой точки и запомнить. По своему забавно - альтернативные истории растут под своими лэйблами.

> Что в целом вполне логично, где его хранить-то в системе где снапшот - сущность неизменная?

Большинство sci-fi где есть multiverse с разными вариантами развития событий и машины времени с тобой круто не согласны. В btrfs по-моему наиболее точная и полная реализация этого. И это круто. Можно завести несколько параллельных вселенных, похожих но разных, эволюционировать их, эти так, эти иначе, потом send вообще в вооон ту виртуалочку сделать, допустим - опа и это уже template для виртуалок вот такого типа. А вон то - эдакого. System integration @ level 80 это как-то так. ИМХО это в разы быстрее и круче всего что ты мог по теме.

> Нет, отдельно сохранить еще одно состояние конечно можно - но тут ты
> уже сам себе создаешь вермишель и сам как хочешь так и распутывай потом.

Снапшоты в btrfs могут быть как RW так и RO. Де факто пропертю RO на снапшот можно установить и снять постфактум и "обычными" методами они станут RO или RW - уж как хотелось. Это не только контролируемый time travel в мультивселенных - но и очень хорошо и гранулярно контролируемый, так что типовые траблы досаждавшие путешественникам во времени могут и не быть проблемой вот тут. Это по желанию.

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

199. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от fidoman (ok), 21-Июн-23, 02:09 
снепшоты это история fs, как может быть "интуитивной" запись в них?
может быть кому-то прикольно иметь автоклон для снепшотов - 2 в 1, унитаз с функцией биде, но не все оценят кмк
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

205. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (-), 21-Июн-23, 02:34 
> снепшоты это история fs, как может быть "интуитивной" запись в них?

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

> может быть кому-то прикольно иметь автоклон для снепшотов - 2 в 1,
> унитаз с функцией биде, но не все оценят кмк

Мультивселенную и машину времени для путешествия в ключевые точки (снапшоты) на самом деле. Это круче любого биде. Золоченый биде такая ерунда vs godlike powers, право...

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

242. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от fidoman (ok), 07-Июл-23, 14:54 
Удачи потом это мержить.
Ответить | Правка | Наверх | Cообщить модератору

211. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от bOOster (ok), 21-Июн-23, 08:51 
Че за бред? Snapshot с записью? Отлично что ZFS проектировали не придурки, а люди четко представляющие смысл и цели решения...
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

230. "Работа по включению Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Аноним (-), 22-Июн-23, 00:25 
> Че за бред? Snapshot с записью? Отлично что ZFS проектировали не придурки,
> а люди четко представляющие смысл и цели решения...

Btrfs умеет и readonly снапшоты, более того RO/RW снапшота можно менять через родной тул фс, изменением property у снапшота, если вдруг в энном случае передумали.

Как отсутствие выбора/фичи может быть фичой - я не допираю. Типа вы лучше меня знаете как мне снапшот хотелось? В любом случае, попробуйте FAT, там вообще фич нихрена, наверное это очень круто :)

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

161. "Работа по включению Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Минона (ok), 20-Июн-23, 14:22 
> вынашивается идея постепенно полностью переписать Bcachefs на Rust

Rust спасёт мир! ✌😤

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

165. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от пох. (?), 20-Июн-23, 16:02 
от bcachefs? Ну не факт. Пока это только идея, а в ведро того гляди уже включат.
Ответить | Правка | Наверх | Cообщить модератору

182. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Neon (??), 20-Июн-23, 19:07 
Ага. Соберет всех неадекватов в одном месте)))
Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

213. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (212), 21-Июн-23, 11:35 
> Rust спасёт мир!

из компилятора раст сделают SDK с ограничениями как для андроида и все формально открытые проекты где используется раст станут собственностью корпораций - никакой форк уже не спасёт

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

216. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Минона (ok), 21-Июн-23, 12:38 
> все формально открытые проекты где используется раст станут собственностью корпораций

Они и без раста собственность корпораций.

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

218. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (212), 21-Июн-23, 12:52 
> Они и без раста собственность корпораций.

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

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

169. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от xsignal (ok), 20-Июн-23, 18:07 
Растификация подсистем ядра. Начали с драйверов, теперь - ФС, потом - планировщик, система управления памятью, сетевая, и - оба на! - а ядро-то тю-тю - в руках растаманов, а те, кто стоял у истоков - уже и не при делах)
Ответить | Правка | Наверх | Cообщить модератору

208. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от pashev.ru (?), 21-Июн-23, 08:10 
> По мнению автора Bcachefs он любит программировать, а не отлаживать код, и теперь безумно писать код на языке Си, когда появился лучший вариант.

По мнению автора Bcachefs, который любит программировать, а не отлаживать код, было бы безумиеи писать код на языке Си теперь, после появления лучшего варианта.


Фух.... Отдебажил как смог.

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

214. "Работа по включению Bcachefs в состав ядра Linux"  +/
Сообщение от Аноним (214), 21-Июн-23, 11:53 
>Целью разработки Bcachefs является достижение уровня XFS в производительности

А достижения безгеморройности ext4 нет в планах?

Кстати, может, всё-таки Reiser4?

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

217. "Работа по включению Bcachefs в состав ядра Linux"  –1 +/
Сообщение от Минона (ok), 21-Июн-23, 12:42 
>>Целью разработки Bcachefs является достижение уровня XFS в производительности
> А достижения безгеморройности ext4 нет в планах?

Уверен что в ней нет геморроя?

> Кстати, может, всё-таки Reiser4?

А почему не 5?

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

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

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




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

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