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

"В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering)"	+/–
Сообщение от opennews (??), 26-Май-20, 14:08
Эдуард Шишкин анонсировал новые возможности, развиваемые в рамках проекта Reiser5. Reiser5 представляет собой существенно переработанный вариант файловой системы ReiserFS, в котором на уровне файловой системы, а не блочного устройства, реализована поддержка параллельно масштабируемых логических томов, позволяющая эффективно распределять данные по логическому тому... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53027
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+13 +/–
Сообщение от Аноним (1), 26-Май-20, 14:08
Когда в ядро?
Ответить | Правка | Наверх | Cообщить модератору

	3. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+8 +/–
	Сообщение от Страдивариус (?), 26-Май-20, 14:11
	Когда Райзера выпустят, не раньше)
	Ответить | Правка | Наверх | Cообщить модератору

	4. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (1), 26-Май-20, 14:24
	А его не отпустили разве из-за коронавируса? Где-то пробегало вроде.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от llolik (ok), 26-Май-20, 14:53
	> Где-то пробегало вроде. В шутках на первое апреля
	Ответить | Правка | Наверх | Cообщить модератору

	19. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+18 +/–
	Сообщение от бублички (?), 26-Май-20, 15:07
	выгнали из тюрьмы, за плохое поведение
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	52. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Kuromi (ok), 26-Май-20, 18:19
	клацанием по клавиатуре сокамерникам спать мешал...
	Ответить | Правка | Наверх | Cообщить модератору

	53. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Май-20, 18:27
	Ему комп не дают (хотя он вроде просил), поэтому он ботает физику.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от evgeniy (??), 27-Май-20, 18:18
	Пусть пишет на туалетной бумаге, потом перенесет
	Ответить | Правка | Наверх | Cообщить модератору

	51. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от pda (?), 26-Май-20, 18:10
	У него было слушание в марте об условно-досрочном. Насколько я помню не выпустили.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	54. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 26-Май-20, 18:28
	Выпустят когда будет уже пенсионного возраста.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (-), 26-Май-20, 15:08
	> Когда в ядро? Когда шишкин бэкпортирует. В майнлайн ему врядли светит - не командный игрок.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	153. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Аноним (153), 27-Май-20, 15:59
	> В майнлайн ему врядли светит - не командный игрок. А команда-то где, с которой надо "играть"? Я пока вижу только сборище толстяков, которые лишь сидят и ждут, когда какой-нить голодный академик с нулевым ЧСВ не придёт, и не починит им всё, пока они улыбаются на кернел саммитах.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (161), 27-Май-20, 18:00
	> А команда-то где, с которой надо "играть"? Очевидно, в майнлайне. > Я пока вижу только сборище толстяков, которые лишь сидят и ждут, когда какой-нить > голодный академик с нулевым ЧСВ не придёт, и не починит им всё, пока они улыбаются на кернел саммитах. Ага. А в перерывах между улыбками на саммитах они код пишут. И довольно дофига судя по git log и размеру .git :) При том академики живут в каком-то своем мире. Виртуальном. Иногда настолько что они даже как видим не в курсе чего уже придумали коллеги по цеху и с помпой преподносят изобретенное колесо. А тут оказывается что какой-то скунс уже это изобрел год назад. Ну не заговор ли это против академиков?!
	Ответить | Правка | Наверх | Cообщить модератору

2. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
Сообщение от Аноним (2), 26-Май-20, 14:10
Лучше cкажите, код переписали для соответствия требованиям к стилю в ядре Linux и избавились от дублирующих примитивов? Или как раньше нет шансов на включение в винильное ядро?
Ответить | Правка | Наверх | Cообщить модератору

	6. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+12 +/–
	Сообщение от sfdsf (?), 26-Май-20, 14:27
	Вылезайте из криокамеры, эти все детские придирки были устранены еще при Райзере (до того как он в тюрьму сел). Код не принимали в свое время из-за личной неприязни (привет Коливасу).
	Ответить | Правка | Наверх | Cообщить модератору

	7. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (7), 26-Май-20, 14:30
	Коливас -- отвратительный сверхтоксичный человек, и код его глючный и безграмотный. Так что не удивительно. Но вот ведь, запихнули в ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (1), 26-Май-20, 14:48
	А кто там факами размахивает не токсичный что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+3 +/–
	Сообщение от Аноним (7), 26-Май-20, 14:52
	> А кто там факами размахивает не токсичный что ли? Факами размахивает истеричка, истеричка -- не обязательно токсичный. Да и впрочем достижения там не в пример больше.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (21), 26-Май-20, 15:12
	> Коливас -- отвратительный сверхтоксичный человек Умные люди все со своими тараканами в голове. Иногда эти тараканы устраивают крестовые походы друг на друга, по поводу и без. Насчет сверх - да не факт. Между делом, Коливас таки снискал себе приличную известность, накодив один из самых крутых майнеров биткоина, используемый легионом народа, а также пул и еще много всякого вокруг. Так что в целом он в софтостроении отличная от нуля величина. Но с ядерщиками у него как-то не задалось.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	25. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
	Сообщение от Аноним (1), 26-Май-20, 15:19
	А ты пробовал туда патч отправить? Тот ещё квест и без всяких гарантий. Если ЧСВ отлично от нуля, то рано или поздно устанешь от этого процесса. Можешь конечно там жить в рассылке и стать "своим", но проще у себя пропатчить и забыть.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+3 +/–
	Сообщение от Аноним (30), 26-Май-20, 15:38
	А что сложного? Я отправлял, чуть ли не через пару часов Мортон взял в ветку next, ну а через пару недель перезаложит в ветку Линус. Никаких сложностей не заметил.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (39), 26-Май-20, 16:17
	> А что сложного? Я отправлял, чуть ли не через пару часов Мортон взял в ветку next Кодинг стайл поправлял, или ошибки в комментсах фиксил?
	Ответить | Правка | Наверх | Cообщить модератору

	81. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+4 +/–
	Сообщение от fghj (?), 26-Май-20, 21:58
	> Кодинг стайл поправлял, или ошибки в комментсах фиксил? Последний раз поправил работу с FIFO контролерра клавиатуры, которая приводила к "подвисанию" клавы до перезагрузки. В предпоследний раз проблему с запросом прерывания, которая при хитром наборе параметров могла привести к непрерывной волне прерываний которые не подтверждали, что приводило к невозможности процессору заснуть. И в первом случае (все это было несколько лет назад) пришлось пнуть мантейнера один раз чтобы мой патч двинулся дальше, а в остальном никаких проблем не было.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (99), 27-Май-20, 08:44
	> Кодинг стайл поправлял, или ошибки в комментсах фиксил? Я вот например константы подрихтовал. Вопрос в том где они были и что за константы...
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	98. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (99), 27-Май-20, 08:40
	> А ты пробовал туда патч отправить? Да. Правда немного смухлевав через знакомого майнтайнера :) > Тот ещё квест и без всяких гарантий. А кто и какие гарантии в этом мире кому-то вообще дает? И как насчет попробовать это действо для других более менее живых операционок? Для сравнения, так сказать? Блин, в винде я даже не смог убедить MS пофиксить явные баги. О том чтобы патч прислать речь не шла в принципе! Там для начала доораться до кого-то кому вообще не пофигу - целый квест. А потом скорее всего расскажут почему именно вы не получите этот фикс. Но вы можете подождать пару лет, и мы так и быть, исправим это в новой версии ОС. За отдельные деньги. А пока жуйте что дали. > Если ЧСВ отлично от нуля, то рано или поздно устанешь от этого процесса. Скорее, если ЧСВ перевесило здравый смысл, понимание того что тебе никто ничего не должен и желание повы...ться было важнее результата. А что, где-то в операционках разработчики щелкают каблуками, вопят "yes sir!" и принимают все подряд от кого угодно без разбора? Это где же это такое есть, уже прямо интересно? > но проще у себя пропатчить и забыть. У меня "свои" патчи только те которые заведомо не возьмут, да и не должны были. Ну, блин, извини, я и сам не хочу чтобы допустим совсем ничего не рубящий хомяк дудел своей вафельницей без лимитов на мощность на левой частоте, даже не задумываясь о том кому это может мешать. Однако у себя я все это могу и пропатчить.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	62. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Anonymous Coward (?), 26-Май-20, 19:40
	А в действительности... всё не так как на самом деле!! (c) Всё в порядке у Коливаса с ядерщиками (с теми самыми что планировщик в mainline пилят), на одном IRC канале сидят, за жизнь толкуют. И отношения дружеские.  Инфа из первых рук. :)
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	89. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (89), 27-Май-20, 02:56
	> Код не принимали в свое время из-за того, что Ганс отказался продолжать поддерживать reiser3 и вместо этого переключился на разработку следующей версии без обратной совместимости. Линус сказал, что поддерживать зоопарк чужих файловых систем вместо их разработчиков ему в рог не впёрлось и что больше от этого разработчика в основной код ядра он ничего принимать не будет.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	100. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (99), 27-Май-20, 08:48
	> зоопарк чужих файловых систем вместо их разработчиков ему в рог не > впёрлось и что больше от этого разработчика в основной код ядра > он ничего принимать не будет. Ну так эта ситуация ставит Торвальдса в позу. С одной стороны он обещал что юзермод не ломают. С другой, reiser3 никто не майнтайнит и его стало быть надо выкинуть, прокатив пользователей с этим обещанием. Потому что иначе это станет якорем для остальных подсистем. ...а когда тебе предлагают навалить вторую порцию такого "счастья" это почему-то может и не выглядеть таким уж заманчивым предложением с точки зрения общей координации проекта.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Sluggard (ok), 26-Май-20, 14:35
	Ты путаешь ReiserFS и Reiser4. Первая давно в ядре, но и у второй ещё 10 лет назад всё причесали вроде, поищи интервью с Шишкиным.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	13. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
	Сообщение от Аноним (1), 26-Май-20, 14:49
	>Первая давно в ядре Только повыкидвали из основных дистров. Так просто не поставить.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+3 +/–
	Сообщение от Аноним (21), 26-Май-20, 15:14
	Что значит повыкидыввали? Модули ядра есть, пакеты с утилсами есть. А то что просто не поставить - ну, знаете, может быть дистроклепателям не очень хочется объясняться перед юзерами почему fsck том разнес в хламину так что оттуда вообще теперь ничего вытащить невозможно, "но вы можете доплатить Namesys за услуги по дата рекавери"? Вообще, идея сделать фс а потом барыжить дата рекавери с нее достаточно интересна :)
	Ответить | Правка | Наверх | Cообщить модератору

	27. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (1), 26-Май-20, 15:24
	Тебя прям послушаешь, кроме ext4 вообще ничего лучше не оставлять. Все файловые системы могут накрыться медным тазом даже без fsck. Впрочем, стоны были слышны исключительно в сторону reiserfs3, результат чего мы сейчас и наблюдаем. И пофиг, что в ядре оно торчит и вполне сносно работает.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (29), 26-Май-20, 15:28
	> Тебя прям послушаешь, кроме ext4 вообще ничего лучше не оставлять. Плохо слушаешь - это любитель смуз^W БТРФС (которая у него 5 лет уже вот-вот совсем почти скоро готова и захватит мир - фейсбук и миллионы его подопытных хомячков не дадут соврать и прочее в том же духе).
	Ответить | Правка | Наверх | Cообщить модератору

	102. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (102), 27-Май-20, 08:59
	> Плохо слушаешь - это любитель смуз^W БТРФС (которая у него 5 лет По-моему больше. И кроме миллионов фэйсбучных хомячков я и сам его потестил в разных ситуациях, вон даже на системе с битой RAM погонял, пох спросил чего будет, мне стало интересно. Получилось в общем то много чего. Кроме собственно убиения данных, они остались более-менее корректны даже в настолько идиотском случае. Основным достижением стали матюки на CSUM ERROR, corrected в лог. И кстати RAID в чистом виде с такой ситуацией справляться не обязан. Даже если мы видим что данные не совпадают, в обычном RAID мы понятия не имеем какая копия верна. А вот с чексумами это уже интереснее.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (85), 27-Май-20, 00:29
	На моей памяти reiser3 - единственное, что фатально накрывалось медным тазом без фатальных хардварных сбоев. Это, правда, было 14 лет назад, но тот день надолго запомнился.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	101. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (102), 27-Май-20, 08:56
	> Тебя прям послушаешь, кроме ext4 вообще ничего лучше не оставлять. Я себе btrfs в основном оставил. В нем кстати fsck ... нечто не используемое в нормальных ситуациях. Поскольку это CoW, ему при крахе fsck не надо. Достаточно отбросить незавершенные остатки и дело в шляпе - старое состояние вполне валидно. А то что из него новое не получилось - на то и крах. > Все файловые системы могут накрыться медным тазом даже без fsck. Но чем реже это случается и чем лучше утилиты с этим справляются - тем лучше. А вот полная недоступность данных таки grave bug для ФС. > Впрочем, стоны были слышны исключительно в сторону reiserfs3, Так это единственный рейзер взятый в майнлайн и потому дошедший более-менее до юзерей. И его fsck вполне умеет убивать тома при попытке "починки". Некоторые из этих закидонов к тому же "known issue". > результат чего мы сейчас и наблюдаем. И пофиг, что в ядре оно торчит и вполне сносно работает. Оно как бы торчит в ядре, но как бы при таком отношении к тулкиту ФС стремновато в использовании. А идея разработчика рекаверить данные за бабки вызывает подозрения на почве того что влепить пару багов в код при такой модели отношений становится финансово выгодно.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	31. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (39), 26-Май-20, 15:46
	> "но вы можете доплатить Namesys за услуги по дата рекавери" Они деньги брали за вытаскивание данных с неработающенго железа (напр. с бэдами). Или для тебя это тоже нужно бесплатно делать?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	104. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (102), 27-Май-20, 09:05
	> Они деньги брали за вытаскивание данных с неработающенго железа (напр. с бэдами). Пардон, но довольно типовой (анти)паттерн reiser3: 1) Крах. 2) Unable to mount... на уровне ос 3) fsck 4) Полная вермишель из тома как результат этого деяния. 5) "FUCK YOU REISER!!!" (testimonials) > Или для тебя это тоже нужно бесплатно делать? Я даже соглашусь насчет бэдов, но вышеупомянутый антипаттерн случался и на вполне исправном железе. И с таким антипаттерном не так уж важно насколько быстра ФС и какие у нее есть клевые фичи, если есть измеримый шанс получить вот это, вот так.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 30-Май-20, 10:42
	p.s. кстати возможность получить большинство данных малой кровью даже если были бэды - для ФС явно в плюс :). У ext4 fsck тома не убивает и обычно вытягивает даже довольно побитые сторажи до чего-то моунтабельного и большинство данных все же достать можно. В btrfs если все совсем плохо - есть offline reader прямо в тулките, им можно вычитать файло на другой носитель вообще неразрушающе и без монтирования, накрайнях опробовав еще и разные точки входа. ...а чего делать в reiserfs если он перестал маунтиться, а fsck оказался бесполезен, а то и вовсе все урыл? Ну, кроме как идти платить namesys, конечно. Что довольно странная идея - платить фирме за их баги.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 30-Май-20, 11:35
	> ...а чего делать в reiserfs если он перестал маунтиться, а fsck оказался > бесполезен, а то и вовсе все урыл? Ну, кроме как идти > платить namesys, конечно. Что довольно странная идея - платить фирме за > их баги. Платить надо было за вытаскивание данных с побитого железа. Во всех остальных случаях пользователь получал свой восстановленных раздел (или патч для reiserfsck) бесплатно. Мне, по крайней мере, так  починили лет 15 назад. Железо было работающее, fsck глючил - рапортовал, что ФС, которая не хотела монтироваться, консистент.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (248), 30-Май-20, 21:01
	> Платить надо было за вытаскивание данных с побитого железа. Ну вот лично я c ext4 допустим могу вынуть данные и без всего этго. Даже с основательно убитых дисков, используя вычитывание правильным софтом типа ddrescue/myrescue/whdd/... :P. Ну вот как-то после поэтапной минимизации бэдов fsck был всегда в состоянии починить это до худо-бедно моунтабельного. Без томов превращенных в крошево. А в btrfs я в пиковом случае вообще достану самое нужное и без монтирования, офлайн читалкой. > Во всех остальных случаях пользователь получал свой восстановленных раздел > (или патч для reiserfsck) бесплатно. Ну это еще куда ни шло. Однако см выше. > Мне, по крайней мере, так  починили лет 15 назад. Железо было работающее, > fsck глючил - рапортовал, что ФС, которая не хотела монтироваться, консистент. Собственно, в этом вся и проблема - fsck у них какой-то очень стремный получился. Он либо ничерта не чинит, либо вообще убивает том (я на такие оказии страхуюсь, мухлюя с cp --reflink на бтрфсном стораже, неплохая страховка от факапов - и дьявольски эффективная по месту и времени).
	Ответить | Правка | Наверх | Cообщить модератору

	35. Скрыто модератором	–7 +/–
	Сообщение от Аноним (35), 26-Май-20, 16:10
	Тоесть линуксячьи файловые системы всё время ломаются и даже fsck уничтожает данные? Не удивительно что линуксом пользуются 1% сумашедших мазохистов.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	45. Скрыто модератором	–6 +/–
	Сообщение от Аноним (45), 26-Май-20, 17:36
	Вы только сейчас это поняли? Все эти линуксоиды больны шизофренией, ведь они считают себя ЭЛИТКОЙ мира, потому что пользуются линуксом, а всех остальных людей - даунами. Уже из-за одного этого линуксоидам можно поставить диагноз - шизофрения.
	Ответить | Правка | Наверх | Cообщить модератору

	61. Скрыто модератором	+/–
	Сообщение от Аноним (7), 26-Май-20, 19:27
	>потому что пользуются линуксом, а всех остальных людей - даунами А разве это не так? Почему объективная оценка является отклонением для тебя, может быть это с тобой что-то неладно? (:
	Ответить | Правка | Наверх | Cообщить модератору

	63. Скрыто модератором	+/–
	Сообщение от Аноним (63), 26-Май-20, 19:41
	Нет это просто линуксоиды - шизофреникики. Ведь делить людей по увроню интеллекта на основе того, какой они ос пользуются - бред. Допустим у нас есть гениальный инженер, но из-за того, что у линукса нет нужного ему софта для работы, он вынужден пользоваться windows. Или допустим использование windows - политика компании, где этот инженер работает. Делает ли все это этого гениального инженера дауном? Нет, он просто использует ос как инструмент и все. Даунами и шизофрениками со стороны скорее выглядят линуксоиды, раз делят людей по такому принципу, и превращая ос, которой они пользуются из инструмента, на уровень бога. Да, даже по теории вероятности, найдётся человек, умнее линуксоидов в несколько раз и который вообще не пользуется Linux. Вы - линуксоиды просто смешны и жалки со стороны. Всего хорошего.
	Ответить | Правка | Наверх | Cообщить модератору

	67. Скрыто модератором	+1 +/–
	Сообщение от Аноним (7), 26-Май-20, 19:57
	Это вряд ли, линукс сейчас есть у всех, а то и по пять штук. Хейтить его могут только ненормальные (те самые идиоты). Но вообще, адаптироваться к жизни в социуме могут и люди с лишними хромосомами, так что кто чем там пользуется не показатель, в принципе. А вот отрицание очевидных превосходств линукса, это явный звоночек (я часто вижу такие пассажи на разных форумах).
	Ответить | Правка | Наверх | Cообщить модератору

	113. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Май-20, 09:39
	> (я часто вижу такие пассажи на разных форумах). Ну так developers, developers удрапали в линухи, и даже MS скупил гитхаб и все полюбили гит, просто потому что остальное по сравнению с ним оказалось не очень. А майкрософт с горя WSL делает, чтобы ну хоть кто-то способный код писать винды использовал, они ж в чистом виде крайне враждебны к эффективности и автоматизации, будучи совершенно домохозяечной штукой. А с чего такая досада? Приходится выкидывать море знаний, признавая что "эти крaсноглазики" и технически лучше оснащены и на уровне парадигм и методов разработки обставили. И понятно что перспектива слить знания за годы в трэш, нужда менять привычки, взгляды и все такое - обидно и досадно %). Как-так, вчера шипели что опенсорц кал, а сегодня MS скупил гитхаб?!
	Ответить | Правка | Наверх | Cообщить модератору

	205. Скрыто модератором	+/–
	Сообщение от Аноним (205), 29-Май-20, 02:00
	> они ж в чистом виде крайне враждебны к эффективности и автоматизации, будучи совершенно домохозяечной штукой. И что там у нас опенсорс может предложить по автоматизации простых рабочих мест? Начиная с домена и прозрачной авторизации и заканчивая ПО для совместной работы и всяких вкс-ок? Края то видеть надо. Развелось локалхостиковых админов затирающих про эффективность.
	Ответить | Правка | Наверх | Cообщить модератору

	207. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Май-20, 07:09
	> И что там у нас опенсорс может предложить по автоматизации простых рабочих мест? Да все что угодно. Достаточно нанять несколько толковых парней и они все нарулят. Как и везде. > Начиная с домена и прозрачной авторизации и заканчивая ПО для > совместной работы и всяких вкс-ок? Это случайно не вы к предопределенным тендерам техзадания пишете для госов? Там где только одна марка автомобиля подходит под требования? > Края то видеть надо. Развелось локалхостиковых админов затирающих про эффективность. Этот локалхостовый админ умеет быть Enterprise Administrator, наруливать Exchange и даже делал пару раз advanced recovery АДу. ...и именно поэтому этот локадхостовый админ знает, что 1) Групповые политики - фикция. Иллюзия контроля. Если они кому-то не нравятся, на них можно элементарно ... забить :) 2) Централизованная аутентификация - это тот случай когда рожа просит кирпича. Поимение одного контроллера домена означает поимение вообще всех машин в этом домене. Стоит ли говорить что это очень привлекательниые мишени для "тематических" хакеров? 3) Авторизация как в винде - очень интересная штука. Если ее не кешировать, заколебет диалогами логина. А если кешировать - то кто угодно может в общем то спереть эти кренделя и от них приколоться, по большому счету. 4) Особенно интересно попросить админа сделать что-то подрихтовать. После этого у обладателя машины в два счета будут права админа, например. В лучшем случае энтерпрайзного даже. 5) И кстати comodohacker на практике показал как все это работает. Трахнув компанию настолько что той только и осталось что заявление о банкротстве подать. А что еще делать, если вообще все компы разломаны, в количестве нескольких сотен? :) Но да, в маркетинговых буклетиках для туповатых манагеров и тех кого они окучивают все это конечно не пишут :)
	Ответить | Правка | Наверх | Cообщить модератору

	221. Скрыто модератором	+/–
	Сообщение от Аноним (221), 29-Май-20, 11:35
	> Да все что угодно. Достаточно нанять несколько толковых парней и они все нарулят. Как и везде. Понятно, нет ничего. Или как раньше говорилось "у нас есть такие приборы, но мы вам их не покажем". > Это случайно не вы к предопределенным тендерам техзадания пишете для госов? Там где только одна марка автомобиля подходит под требования? Ага, только не для госов. Потому что закон о тендерах полное Г. И пользуясь тем что измеряется один параметр - цена решения - всякие чушки типа тебя пытаются впарить барахло. Ну те что тут про точку росы рассказывали и как надо дома, для экономии, температуру крутить зимой. И прочий бредок не имеющий отношения к реалиям. Таким как ты напишешь про карьерную работу, так они тачку с электромоторчиком на малинке притаранят - а что возит же. А что не мазы-камазы - ну так свозите несколько раз на нашем смузихлебном решении. Вот для ограждения пользователей от именно таких решений и уменьшения стоимости решения за весь срок его эксплуатации - приходится, да. > Этот локалхостовый админ умеет быть Enterprise Administrator, наруливать Exchange и даже делал пару раз advanced recovery АДу. Хехе полечи, полечи какой ты энтер прайс админ. Покажи мне крупную не ИТ конторку что сидит вплоть до последнего пользюка на линухе. Естественно без централизованной авторизации и управления. Это же так удобно. Да собственно по дальнейшим твоим 5 пунктам и понятно что ты рядом лежал с теми кто решал.
	Ответить | Правка | Наверх | Cообщить модератору

	115. Скрыто модератором	+/–
	Сообщение от псевдонимус (?), 27-Май-20, 09:42
	>Линукс есть у всех У тебя галлюцинации.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	183. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Май-20, 08:20
	> У тебя галлюцинации. Да ну ладно, в карман посмотри.
	Ответить | Правка | Наверх | Cообщить модератору

	206. Скрыто модератором	+/–
	Сообщение от Аноним (205), 29-Май-20, 02:01
	Там я вижу андроид а никак не линух. И мне от ядрышка в смарте 3.хз.что-то.там ни тепло ни холодно.
	Ответить | Правка | Наверх | Cообщить модератору

	208. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Май-20, 07:13
	> Там я вижу андроид а никак не линух. Тогда посмотри определение что такое линух :). А то что там юзермод другой - ну так хомячью которое надо доить и разводить и юзермод под стать. Блин, таким даже и из классического линя могут вон убунту с телеметрией запилить, ежели клювами хлопать и такие диверсии в свой адрес проглатывать.
	Ответить | Правка | Наверх | Cообщить модератору

	222. Скрыто модератором	+/–
	Сообщение от Аноним (221), 29-Май-20, 11:44
	Что-то ты в недогадливого играешь. Мне совершенно плевать если бы там была винда, или иос, или фряха. Как пользовался функциями смартфончика, так и пользовался. И линукс это спокойно пережил - не много то там с мира мобилок втащили.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	93. Скрыто модератором	+1 +/–
	Сообщение от Tifereth (ok), 27-Май-20, 07:09
	Пф. Настолько толсто, что уже просто глупо. Покажите нам хоть одного реального пользователя Linux, который действительно ненавидит другие ОС. IRL.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	111. Скрыто модератором	+6 +/–
	Сообщение от zzz (??), 27-Май-20, 09:26
	Заходишь в любую новость, посвященную *BSD - и вот они, милые линуксоиды.
	Ответить | Правка | Наверх | Cообщить модератору

	114. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Май-20, 09:41
	> Заходишь в любую новость, посвященную *BSD - и вот они, милые линуксоиды. Ну, вообще, пользователи BSD эту бодягу первые начали :P. Чисто технически - Linux появился позже. И таки если раскопать древние конференции - можно найти немало этого самого. Блин, я даже в "письменном" виде это видел - парни оставляли друг другу колкости на _бумажном_ bulletin board'е :)
	Ответить | Правка | Наверх | Cообщить модератору

	163. Скрыто модератором	+1 +/–
	Сообщение от Школьник (ok), 27-Май-20, 18:12
	Если они и начали первые (в чем лично у меня есть большие сомнения), то пользователи линукса давно и успешно догнали и с большим отрывом перегнали.
	Ответить | Правка | Наверх | Cообщить модератору

	184. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Май-20, 08:21
	> Если они и начали первые (в чем лично у меня есть большие сомнения), В те стародавние времена они издевались над юзерами ходившего под стол пингвина. Тем было нечего ответить... > то пользователи линукса давно и успешно догнали и с большим отрывом перегнали. "...а потом Вовочка вырос и урезал марьванне зарплату"
	Ответить | Правка | Наверх | Cообщить модератору

	193. Скрыто модератором	+3 +/–
	Сообщение от Аноним (-), 28-Май-20, 11:23
	>> Если они и начали первые (в чем лично у меня есть большие сомнения), > В те стародавние времена они издевались над юзерами ходившего под стол пингвина. Тем было нечего ответить... Скромно умалчиваем, что юзеры ходившего под стол пингвина вели себя примерно так же, как сейчас растоманы и прочие смузихлебы на опеннете ... >> то пользователи линукса давно и успешно догнали и с большим отрывом перегнали. > "...а потом Вовочка вырос и урезал марьванне зарплату" Скорее, научились фантазировать и отождествлять себя с платиновыми партнерами и прочими IBM. Современный, отписывающийся с умным видом в БСДшных новостях линуксоид, к становлению и разработке пингвинчика причастность имеет околонулевую (маечка с пингвинчиком да отправленный бубунтой автоматический крешрепорт на такое не тянут).
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	209. Скрыто модератором	+/–
	Сообщение от Аноним (209), 29-Май-20, 07:31
	> Скромно умалчиваем, что юзеры ходившего под стол пингвина вели себя примерно так > же, как сейчас растоманы и прочие смузихлебы на опеннете ... Возможно, но они тогда имели некий пойнт: BSD были совсем не от мира сего. А пингвин окучивал их задачи. На каком-нибудь дешманском попсовом i386, который даже у студней есть, а не расово верном энтерпрайзном RISC где студню надо сначала почки продать. Собственно Торвальдс так и сказал - если бы бсды работали на его компе, он бы и не пошел линух кодить вообще. > Скорее, научились фантазировать и отождествлять себя с платиновыми партнерами и прочими IBM. В те времена толстым котам было пофиг на эту мышиную возню. А вот когда оказалось что студень настроен рещительно и дерзко, обставляет академов на раз и проч - тут они уже заинтересовались. > Современный, отписывающийся с умным видом в БСДшных новостях линуксоид, к становлению и > разработке пингвинчика причастность имеет околонулевую (маечка с пингвинчиком да отправленный > бyбyнтой автоматический крешрепорт на такое не тянут). На тысченку ламеров десяток изучит систему всерьез, станет с ней на ты, половина из них решит что пора творить чудеса. И запилит что-нибудь годное, в системе или на ее основе. Так что совсем без пользователей в системе тоже плохо. Получается какой-нибудь реактос в виртуалочке, где даже девы этим пользоваться потом не хотят. А в bds традиционно рассказывают что есть серверные системы и десктопные. Игноря что девам удобнее прототипить на десктопе, и чем там похожее на продакшн тем лучше. И да, сколько процентов из https://developers.redhat.com/blog/2018/10/22/introduction-t.../ умеют "серверные системы" например? Там кстати нет самого навороченого :)
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	223. Скрыто модератором	+1 +/–
	Сообщение от Аноним (223), 29-Май-20, 12:55
	>> Скромно умалчиваем, что юзеры ходившего под стол пингвина вели себя примерно так >> же, как сейчас растоманы и прочие смузихлебы на опеннете ... > Возможно, но они тогда имели некий пойнт: BSD были совсем не от > мира сего. А пингвин окучивал их задачи. На каком-нибудь дешманском попсовом > i386, который даже у студней есть, а не расово верном энтерпрайзном RISC где студню надо сначала почки продать. В моей реальности Линус сам писал в "Just for Fun", как будучи "студнем" в не самой бедной стране, долго "облизывался" на "дешманский попсовый i386" за 18000 финнских марок ($3500, на сегодняшие - около $7000). И в итоге, подкопив деньжат, купил в кредит. Но то ведь какой-то Линус с его прохладными былинами и выдумками -- а тут целый аноним опеннета лапшу^W рассказывает, как оно было на самом деле! Да и разница между выходом _портированной_ BSD386 и 0.1 версией пингвинчика - что-то около полугода. А заваливаться в бсдшные юзергруппы с криками "Rust^W Линукс рулит! БСДы - замшелый отстой!" пингвиноиды начали значительно позже. Так что "пойнт" существовует разве что в фантазиях некоторых анонимных линуксоидов опеннета. >>>> то пользователи линукса давно и успешно догнали и с большим отрывом перегнали. >>> "...а потом Вовочка вырос и урезал марьванне зарплату" >> Скорее, научились фантазировать и отождествлять себя с платиновыми партнерами и прочими IBM. > В те времена толстым котам было пофиг на эту мышиную возню. А > вот когда оказалось что студень настроен рещительно и дерзко, обставляет академов на раз и проч - тут они уже заинтересовались. А в огороде бузина? >> Современный, отписывающийся с умным видом в БСДшных новостях линуксоид, к становлению и >> разработке пингвинчика причастность имеет околонулевую (маечка с пингвинчиком да отправленный >> бyбyнтой автоматический крешрепорт на такое не тянут). > На тысченку ламеров десяток изучит систему всерьез, станет с ней на ты,  половина из них решит что пора творить чудеса. И запилит что-нибудь годное, в системе или на ее основе. Так что совсем без пользователей в системе тоже плохо. А, ну если так, тогда да -- это полностью оправдывает регулярное вываливание "линуксоидами" в БСДшных новостях тонн глупостей, помоев и просто высказанных с умным и гордым видом "фи". > Получается какой-нибудь реактос в виртуалочке, где > даже девы этим пользоваться потом не хотят. А в bds традиционно рассказывают что есть серверные системы и десктопные. Игноря что девам удобнее прототипить на десктопе, и чем там похожее на продакшн тем лучше. Скорее, получаются очередные, не менее традиционные прохладные былины опеннета: https://developers.redhat.com/blog/2020/02/12/podman-for-mac.../ > Senior Solutions Architect, Red Hat >  My daily laptop is a MacBook Pro, which is great unless you want to dual boot into Linux and develop on containers. https://www.linux.com/news/30-linux-kernel-developers-30-wee.../ > 30 Linux Kernel Developers In 30 Weeks: Chuck Lever > I run Mac OS on my desktop and do Linux kernel development in a virtualized environment. Mac OS offers ease-of-use along with a strong set of productivity tools. One productivity tool I use extensively is Evernote. https://itsfoss.com/linux-foundation-head-uses-macos/ > Linux Foundation Head Calls 2017 'Year of the Linux Desktop'… While Running Apple's macOS Himself Тут zzz все правильно подметил -- "ставящие оборзевших БСДунов на место", убежденные "Линуксоиды" с 25-летним стажем, видевшие винду с маком только на картинке через плечо, объявляются почему-то исключительно в БСДшных новостях. А стоит глянуть в соседнии новости об улучшении WSL https://www.opennet.dev/openforum/vsluhforumID3/120679.html так и диву даешься, откуда там столько "нелинускоидов" со знанием дела отписываются о проблемах под разными версиями WSL и дают друг-другу советы по более лучшей интеграции и работе "любимой ОС" под виндовс ))
	Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

	177. Скрыто модератором	+/–
	Сообщение от Аноним (177), 28-Май-20, 02:49
	>> Заходишь в любую новость, посвященную *BSD - и вот они, милые линуксоиды. > Ну, вообще, пользователи BSD эту бодягу первые начали :P. Чисто технически - > Linux появился позже. И таки если раскопать древние конференции - можно > найти немало этого самого. Чисто технически - основная часть отписывающихся _сейчас_ линуксоидов тогда пешком под стол ходила и ни о каких БСД или линуксах слыхом не слихивала.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	185. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Май-20, 08:26
	> Чисто технически - основная часть отписывающихся _сейчас_ линуксоидов тогда пешком под > стол ходила и ни о каких БСД или линуксах слыхом не слихивала. Глядя на рассказы про память поколений и все такое - "годков через 50 приползайте" :)
	Ответить | Правка | Наверх | Cообщить модератору

	194. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Май-20, 12:08
	> Покажите нам хоть одного реального пользователя Linux, который действительно ненавидит > другие ОС. IRL. Я вот винды не люблю. Хоть и умею ими рулить. Мерзотный у них вендор, всегда свои проблемы спихивает на других. Так что денег заплати, да потом еще с их проблемами сам как хочешь так и  долбайся, саппорт бесполезен чуть более чем полностью с любой проблемой сложнее протирки мыши. А чтобы баг починили вообще неизвечтно что должно произойти. Незачет.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	69. Скрыто модератором	–1 +/–
	Сообщение от Аноним (35), 26-Май-20, 20:00
	Точно, посадить шизиков в дурку и кормить галлоперидолом
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	105. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Май-20, 09:09
	> Точно, посадить шизиков в дурку и кормить галлоперидолом Есть уверенность что не попадете в их число? А то данный тред довольно богат материалом для психологов и психиатров.
	Ответить | Правка | Наверх | Cообщить модератору

	79. Скрыто модератором	+2 +/–
	Сообщение от пох. (?), 26-Май-20, 21:32
	> Уже из-за одного этого линуксоидам можно поставить диагноз - шизофрения. ЧСВ over 100 - это не шизофрения, неча дорогое место в психушке занимать. Лечится обычной поркой.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	129. Скрыто модератором	+/–
	Сообщение от Аноним (129), 27-Май-20, 12:30
	Тебе-то уже поставили?
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	34. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (35), 26-Май-20, 16:00
	В Вашем воображении, разве что cat /proc/filesystems  | grep reiser reiserfs cat /etc/os-release NAME="Ubuntu" VERSION="20.04 LTS (Focal Fossa)"
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	77. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
	Сообщение от Аноним (1), 26-Май-20, 20:38
	Из морозильника вылезай уже https://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDM Ему про дистрибутив, а он про ведро всё талдычет.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+3 +/–
	Сообщение от Аноним (35), 26-Май-20, 22:31
	Тормоз, в последней ubuntu reiserfs не удалили, а ты ссылку 2013 года кидаешь. Мозги совсем в студень превратились?
	Ответить | Правка | Наверх | Cообщить модератору

5. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
Сообщение от Аноним (5), 26-Май-20, 14:24
Я правильно понимаю, что разработчики reiser реализовали то, что уже умеет bcache и dm-cache?
Ответить | Правка | Наверх | Cообщить модератору

	10. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
	Сообщение от Аноним (153), 26-Май-20, 14:38
	То, что они реализовали, bcache и dm-cache в принципе уметь не может.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
	Сообщение от Минона (ok), 26-Май-20, 14:50
	они реализовали zlog из ZFS
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	23. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (21), 26-Май-20, 15:15
	Судя по описанию - нечто явно круче чем это.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от zfs (??), 26-Май-20, 19:54
	да, мы-то не смогли додуматься ВРУЧНУЮ zil по крону сбрасывать.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:43
	> да, мы-то не смогли додуматься ВРУЧНУЮ zil по крону сбрасывать. Ну так в этом половина смысла - девайс всегда расчищен и всегда готов к новому burst. А менеджить подобные вещи из cron... спасибо, но нет. Сопли и скотч в файловой системе все же не заканчиваются чем-то хорошим.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (129), 27-Май-20, 12:39
	Ну так нужно понимать, что Шишкин в одно лицо пилит. У него не 100500 рук. Reiser5 даже не betta ещё.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	18. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
	Сообщение от Аноним (153), 26-Май-20, 15:01
	> уже умеет bcache и dm-cache А как тебе bcache dm-cache узнают, что это пики IO-load, которые надо на прокси-диск отправить? Такое только файловая система знает.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	75. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 26-Май-20, 20:21
	> А как тебе bcache dm-cache узнают, что это пики IO-load, которые надо на прокси-диск отправить? а как fs о них узнает? Никак, в смысле - постфактум только.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 02:34
	а как fs о них узнает? Непосредственно. Кто, как не ФС знает, что это новый логический блок? А в block layer передаются безликие запросы ввода-вывода. bcache  и dm-cache ничего не знают от слова совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Crazy Alex (ok), 27-Май-20, 10:07
	А пик IO-load - это что, по вашему, как не большой объём ввода-вывода?
	Ответить | Правка | Наверх | Cообщить модератору

9. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (9), 26-Май-20, 14:35
>Эдуард Шишкин анонсировал Ну а толку то, оно же не в ядре. А Шишкину западло заниматся багами.
Ответить | Правка | Наверх | Cообщить модератору

	11. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (153), 26-Май-20, 14:40
	> Ну а толку то, оно же не в ядре Ну и что? ZFS тоже не в ядре.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (21), 26-Май-20, 15:16
	Ну так он и является в лине куском головняка. За что и умрет.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
	Сообщение от Заноним (?), 26-Май-20, 15:52
	> Ну так он и является в лине куском головняка. За что и > умрет. Детсад какой-то. ZFS в linux работает без всякого "головняка". Да zfs скорее всего умрёт в linux, но не раньше, чем btrfs окончательно достигнет аналогичной функциональности и надёжности.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (7), 26-Май-20, 19:18
	>zfz >inux >надёжность Тем временем btrfs уже 10 лет стоит на всех хомячковых насах и дисковых полках от synology.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
	Сообщение от пох. (?), 26-Май-20, 19:58
	это тех самых, которые сейчас у всех немножечко майнят? Ну да, стоит (в хомячковых, с полками - это пока больше фантазии). Вы думаете, это от того что synology так уж заботит судьба ваших даных?
	Ответить | Правка | Наверх | Cообщить модератору

	117. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:47
	> это тех самых, которые сейчас у всех немножечко майнят? Как насчет пруфца этого громкого заявления? И эт, майнеру пофиг на файловую систему, так кто как это к btrfs относится? :P > Ну да, стоит (в хомячковых, с полками - это пока больше фантазии). > Вы думаете, это от того что synology так уж заботит судьба ваших даных? Пох, ну тебе ли не знать что "as is" пишут все? Можно подумать, кто-то прямо берет под козырек и идет возмещать хомячкам (или НеХомячкам) ущерб, сколь-нибудь отражающий фактическую ценность данных.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 28-Май-20, 22:18
	> Как насчет пруфца этого громкого заявления? https://lmgtfy.com/?q=synology+vulnerability&s=b что там последнее...в смысле, крайнее - фотостейшн не только показывает бесполезные свалки васянских картинок, но еще иногда исполняет колянский код? Простите, я немного отстал от модных веяний, поэтому не слежу за их последними достижениями. Потому что они никогда не последние. К качеству протухта это относится, и серьезности разработки. > Пох, ну тебе ли не знать что "as is" пишут все? тогда какой смысл ссылаться на synology? Слепили из того что валялось на дороге, затобешплатное, взять, взять! (ну и вообще-то не все, некоторые пишут SLA) Почему именно btrfs? Возможно просто потому что нанятый дЭффехтивный ничего другого не знал. Они вообще-то специалисты по пехепе. С другой стороны - вон, васяны из шитгейта слепили на ext4, вроде ну уж совсем окончательно готового для продакшн - тут в "статьях" целая дет/фективная история как потом это чинить. Неожиданно, не так чтоб и просто. Кстати, вот, не самое показательное, но лень искать, а специально я такое не коллекционирую - проблемы нигр е6омых слониками меня не колебут. Это просто случайно сохранилось: https://tinyurl.com/y786w9yy да идите вы нах с _такими_ проблемами на совершенно пустом месте.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (212), 29-Май-20, 09:18
	> https://lmgtfy.com/?q=synology+vulnerability&s=b Пох открыл для себя базу CVE? :) > Потому что они никогда не последние. Ты прав, Пох: безопаснее всего выключенный компьютер. Если так гуглить, майнерами обвешано все что угодно, от твоего десктопа до цыски. База CVE - на все вкусы. > К качеству протухта это относится, и серьезности разработки. Мне это можно не втирать: я знаю как сие работает "изнутри" :P. > тогда какой смысл ссылаться на synology? Слепили из того что валялось на > дороге, затобешплатное, взять, взять! (ну и вообще-то не все, некоторые пишут SLA) SLA или что, но я ни разу не встрчеал чтобы кто-то возместил полную стоимость профаканых данных. Теоретически наверное это возможно. Практически... пару примеров сможешь? Интересно же. > Почему именно btrfs? Возможно просто потому что нанятый дЭффехтивный ничего другого не знал. Да потому что линух который они УЖЕ юзали, оказывается это умеет. Оно уже есть, задачи в общем то решает. > Они вообще-то специалисты по пехепе. Кроме пыха, git log | grep synology.com в майнлайне почему-то дает некий выхлоп, намекающий что они это реально юзают и даже починили известные им грабли ;) > С другой стороны - вон, васяны из шитгейта слепили на ext4, вроде > ну уж совсем окончательно готового для продакшн - тут в "статьях" > целая дет/фективная история как потом это чинить. Неожиданно, не так чтоб и просто. Ext4? Ну не, это ты сам в продакшн ставь. После возни с btrfs я пришел к выводу что early warnings мне все-таки нравятся, да и управление у него приятное. А чексумы позволяют ему чиниться с RAID намного осмысленнее и парировать куда больше дурных взбрыков. > просто случайно сохранилось: Как известно, не ошибается тот кто ничего не делает :P. А вот конкретно та фирма - еще и изволит комитить исправления. Много ли твоих фаворитов могут похвастаться тем что прислали апстриму фиксы всего что нашли? Или все как всегда - солярис никто юзать не хочет, в бзд ошметки, в линухе оно внебрачное, а куды бедному крестьянину податься да вообще ктулху его знает. И тот всего лишь жрать хочет. > да идите вы нах с _такими_ проблемами на совершенно пустом месте. Не, ну кому и отвал rootfs наверное катит. Или ты хочешь сказать что какие-нибудь снапшоты ОС позволяющие при крупном системном факапе быстро вернуть все взад - глупости? :) Или вон кернелпаник который никто изучать не будет. Ядерщики так отправят всех в пешее эротическое с tainted kernel, к бабке не ходи.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (129), 27-Май-20, 12:45
	>это тех самых, которые сейчас у всех немножечко майнят? Сравнение про ФС и про майнинг, это, как про тёплое и мокрое.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	80. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (80), 26-Май-20, 21:32
	>zfz >inux >надёжность Как говорится, выберите любые 2!
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	125. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Аноним (125), 27-Май-20, 10:59
	А в чем выражается ненадежность ZFS на Linux? На моем домашнем насе переехал с фряхи на дебиан ради привычного окружения, за год не видел пока никаких проблем. Что ожидает?
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	127. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (7), 27-Май-20, 11:31
	> А в чем выражается ненадежность ZFS на Linux? На моем домашнем насе > переехал с фряхи на дебиан ради привычного окружения, за год не > видел пока никаких проблем. Что ожидает? Я знаю только о ненадёжности на эксбсд: на домашних подкраватных полках она рассыпалась только в путь и пользователи много плакали потом. Вот вам и парити. Бтрфс впрочем тоже имеет проблемы в этом режиме, но они хотя бы не скрывают того. А тут предлагаете совершенно чужеродную фс (не то чтобы она не чужеродная за пределами солярки была, но и в солярке тоже сыпалась) без нормального тестирования использовать. Данные это святое, если они будут уничтожены, точно также могут пострадать и рабочие данные, и бэкапы, поэтому брать модную шляпу из-за секундного вау эффекта будет несколько неосмотрительно (на тебе и хотят потестировать). Я тоже не видел проблем с xfs, но когда мне сказали, я нашёл занулённые файлы (было уже поздно).
	Ответить | Правка | Наверх | Cообщить модератору

	136. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (125), 27-Май-20, 13:29
	Что подразумеваешь под "эксбсд"? Использование на системах, отличных от *bsd, или наоборот? Или ещё какой режим ZFS? > на тебе и хотят потестировать А я и не против. Все равно бекапы ещё и на внешний винт копируются. Хотя сколько не искал про недостатки, находил только обратное, мол, ZFS уже production-ready при условии, что используется подходящее под ФС железо. Например, >8GB ECC RAM, минимум два ядра 64-разрядного процессора, железный дисковый контроллер при наличии только в режиме HBA, и т.д. Можешь пример плача пользователей привести?
	Ответить | Правка | Наверх | Cообщить модератору

	106. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:14
	> Детсад какой-то. ZFS в linux работает без всякого "головняка". Не считая того что тут мистер пох таки спалил контору, когда оно при апдейте ядра таки отпало походу. Особенно круто если так с системным сторажем, гули. А, ну да, зачем нам снапшоты системы и прочие глупости? :) > аналогичной функциональности У него на уровне дизайна есть и кое-что за пределами этой функциональности. Типа нормального отношения к смеси уровней райдов и возможности это все на лету переигрывать. > и надёжности. Я подсовывал оному довольно дурацкие ситуации. И имею заметить что он выживает на карте памяти где EXT4 за пару недель становится полной тыквой, например.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	202. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 28-Май-20, 22:26
	> Не считая того что тут мистер пох таки спалил контору, когда оно при апдейте ядра таки отпало > походу. ну так передавайте привет альтернативно-одаренным разработчикам бубунточки - на все деньги Косм...запрещенного элемента не сумевшими банальное автоматизированное тестирование выкладываемых в шта6ильную версию обновлений, не говоря уже о банальной организации процесса, без всяких сложных технических ходов, просто не подпускающей улучшаек к официальным репо не в статусе "пре-альфа для поиграться". Что им помешает точно так же завтра вам и монолитное ведро сломать ? И да, это общее качество разработки линуксов, а не какие-то особенно криворукие макаки - просто в этот раз повезло именно этим. Завтра вам прямо в ваше любимое ведро в _очередной_ раз влепят "silent filesystem corruption". Но это же несчитается, как вы не понимаете, это же другое! Ага.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (213), 29-Май-20, 09:31
	> процесса, без всяких сложных технических ходов, просто не подпускающей улучшаек к > официальным репо не в статусе "пре-альфа для поиграться". Блин, пох, я тебе сразу сказал что все это будет работать так. И убунта тут не при чем. Если ты бегаешь по минному полю, твой шанс подорваться на мине почему-то существенно возрастает. > Что им помешает точно так же завтра вам и монолитное ведро сломать ? То что они не суются туда без хорошей необходимости. А до них это релизит слаженная и компетентная команда. > И да, это общее качество разработки линуксов, а не какие-то особенно криворукие > макаки - просто в этот раз повезло именно этим. Я бы сказал что именно отпадение именно модуля, именно встроенной в ядро ФС ... я тупо ни разу не видел. Вообще за все время. К этому нет предпосылок. > Завтра вам прямо в ваше любимое ведро в _очередной_ раз влепят "silent > filesystem corruption". Но это же несчитается, как вы не понимаете, это > же другое! Ага. Вот такой вариант всегда возможен. В случае btrfs я как минимум увижу CSUM ERROR, и в лучшем случае даже с уточнением corrected. А после этого я займусь вопросом "какого черта?". И найду этот ответ, так или иначе.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (213), 29-Май-20, 09:32
	p.s. еще кстати могут влепить прямо в железо, так намного прикольнее. И даже вроде бы популярнее чем в ядре :)
	Ответить | Правка | Наверх | Cообщить модератору

26. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
Сообщение от Аноним (26), 26-Май-20, 15:22
> В основу реализованного метода легло простое наблюдение, что на практике запись на диск не ведётся постоянно, а кривая нагрузки ввода-вывода имеет форму пиков. В промежутке между такими "пиками" всегда имеется возможность сбросить данные с прокси-диска, переписав в фоновом режиме все данные (или же только часть) в основное, "медленное" хранилище. Таким образом, прокси-диск всегда готов к приёму новой порции данных. Шишкин переизобрел SSHD?
Ответить | Правка | Наверх | Cообщить модератору

	37. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–5 +/–
	Сообщение от Аноним (35), 26-Май-20, 16:13
	Такими темпами в линуксе все те возможности которые давно есть в ntfs появятся лет через 20
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
	Сообщение от Аноним (35), 26-Май-20, 16:15
	позорище, в 2020 линуксоиды изобрели ReadyBoost
	Ответить | Правка | Наверх | Cообщить модератору

	73. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
	Сообщение от пох. (?), 26-Май-20, 20:19
	не линуксоиды, а один отщепенец, не идущий строем в ногу. В линухе readyboost как не было, так и нет. Это слишком сырая технология, лет через десять можно будет скопировать - как раз станет никому не нужна. А мы пока вручную будем prefetch заполнять при загрузке, надежно, на века.
	Ответить | Правка | Наверх | Cообщить модератору

33. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
Сообщение от Аноним (33), 26-Май-20, 15:54
Т.е. по сути просто реализована поддержка кэширования записи на быстрый диск?
Ответить | Правка | Наверх | Cообщить модератору

	36. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (39), 26-Май-20, 16:11
	> Т.е. по сути просто реализована поддержка кэширования записи на быстрый диск? Нет там никакого кэширования. Там миграция. Кэширование - это "и там и тут". Миграция - это "или там, или тут".
	Ответить | Правка | Наверх | Cообщить модератору

	56. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (56), 26-Май-20, 18:50
	Кеширование бывает разное. И да, это тоже оно.
	Ответить | Правка | Наверх | Cообщить модератору

40. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–2 +/–
Сообщение от Аноним (40), 26-Май-20, 16:42
Выглядит здорово, спасибо разработчику. Я видел в продаже диски с высокоскоростной малой частью и обычной прочей - похоже Рейзер очень хорошо подойдёт для таких дисков. Также, буду благодарен за сравнение Рейзер5 с ехт4, бтрфс и зфс.
Ответить | Правка | Наверх | Cообщить модератору

	70. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
	Сообщение от пох. (?), 26-Май-20, 20:05
	на самом деле ровно наоборот - с дико тормозной основной частью (ибо smr) и slc (вроде бы) кэшем. То есть Шишкин именно их и скосплеил. Правда, пока приходится вручную этот кэш переписывать, но обещают кернельный тред ;-) > Также, буду благодарен за сравнение Рейзер5 с ехт4, бтрфс и зфс. какой смысл сравнивать экспериментальную fs используемую только своим автором  и его друзьями, половина которых - воображаемые, и промышленные решения? Даже если она в миллион раз лучше (что очень маловероятно - скорее окажется слегка получше на специфических задачах - как и все остальные) - никто не гарантирует от мгновенного превращения ее в тыкву из-за редковозникающего бага, не появившегося у автора. Про остальных трех мы хотя бы знаем, примерно, когда и каким образом они превращаются в тыквы, и чего точно делать не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Андрей (??), 28-Май-20, 04:23
	> Про остальных трех мы хотя бы знаем, примерно, когда и каким образом они превращаются в тыквы, и чего точно делать не надо. Ну, с btrfs понятно. А какой блэклист для операций у ZFS? Но особенно инетересно об ext4.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 28-Май-20, 22:50
	> Ну, с btrfs понятно. я вот там выше ссылку кинул - это тебе вот точно "понятно"? Хотя на фоне внезапно-исчерпания места для метаданных при полупустом диске - конечно, семечки. > А какой блэклист для операций у ZFS? прежде всего - resilvering. Прежде чем его запускать - заведи резервный генератор, и убедись что соляры в бочке достаточно и она точно не паленая. (память с ecc и не сбоит, вентиляторы процессоров почищены и заменены и т д) То есть по наблюдаемым успехам - это наиболее стремная и ведущая к невосстановимым пулам ситуация. За что боролись, блжад?! Ну вот, да. Доверия raidz у меня нынче нет. А при обычной работе - не использовать линукс, не использовать compressed arc, отключать scatter. Ну и, разумеется, избегать 85% заполнения. В ext4 проблемы десятилетней давности, к счастью, успешно порешали костылями и подпорками. (Новых модных ее фич я избегаю, чего и всем советую) Осталась главная - неэффективность на современных объемах. Ну и зависимость от внешнего механизма фейловера, будь то md или аппаратный raid6, как велит нам редгад. Впрочем, редгад велит использовать xfs - и это жжж неспроста.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (215), 29-Май-20, 09:42
	> Хотя на фоне внезапно-исчерпания места для метаданных при полупустом диске - конечно, семечки. Хорошая у поха криокамера, с ядром 2.6.18, там поди и солярис еще живой и веселый :). А вот конкретно это пролечили довольно много лет назад, сделав небольшой "золотой запас" на совсем уж пиковые случаи. Кстати, в hammerfs, чтоли, какие-то подобные грабли обпрыгивали. > прежде всего - resilvering. А я таки в btrfs покрешил конверсию уровня RAID, что даже интереснее. Ну, он после ребута отскребся и дальше поехал, как ни в чем не бывало. А ему похрен, он и с смесью block groups разных уровней нормально живет. Туда же и прочие обломы ребаланса (там конверсия схемы хранения - частный случай ребаланса). > То есть по наблюдаемым успехам - это наиболее стремная и ведущая > к невосстановимым пулам ситуация. За что боролись, блжад?! Какие юморные парни ZFS оказывается пишут :D > В ext4 проблемы десятилетней давности, к счастью, успешно порешали костылями и подпорками. ...но на integrity данных он сам по себе все ж кладет и что железо дурит не подскажет. И ежели RAID под ним сдуреет иначе нежели полным вылетом одного из девайсов - тогда наверное придется вспомнить где у вас бэкапы. > Впрочем, редгад велит использовать xfs - и это жжж неспроста. Конечно! Это единственное что редгад смог подобрать из всеми забытого. Ну не JFS же ему было, право?! А более ценный мех и без них при делах. В btrfs инициативу перехватили заклятые друзья из зюзи, для начала :D. Видимо, это не совсем удобный сценарий для шапочки...
	Ответить | Правка | Наверх | Cообщить модератору

	90. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 03:02
	> Также, буду благодарен за сравнение Рейзер5 с ехт4, бтрфс и зфс. Тут особо нечего сравнивать. Создай прокси-девайс из рамдиска и добавь его. Скорее всего, все данные будут падать на этот рамдиск, как и было обещано. Остальные ФС так не могут. Вот теперь и прикинь, кто быстрее.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	107. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:16
	> Тут особо нечего сравнивать. Создай прокси-девайс из рамдиска и добавь его. Какой сложный и извратный способ изобрести кэширование файловой системы. Правда это умел еще smartdrv в MSDOS, блин, но велосипед, конечно, зачотный.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (129), 27-Май-20, 12:59
	А smartdrv в MSDOS это не про сжатый диск?
	Ответить | Правка | Наверх | Cообщить модератору

	141. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от СеменСеменыч777 (?), 27-Май-20, 14:31
	сжатый диск в MS DOS это Stacker.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 14:35
	> А smartdrv в MSDOS это не про сжатый диск? Нет, это кэш отложенной записи, многократно разгонявший скорость записи на винч. Про сжатие DoubleSpace и DriveSpace (dblspace и drvspace) были. В линухе вроде даже была поддержка, которую если не ошибаюсь, не так давно выкинули как раз - т.к. походу юзеров этого на глобусе тупо не осталось.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	200. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от СеменСеменыч777 (?), 28-Май-20, 19:32
	оказывается, там были разборки такие: https://en.wikipedia.org/wiki/Stacker_(disk_compression)#Microsoft_lawsuit
	Ответить | Правка | Наверх | Cообщить модератору

	138. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 13:42
	> Какой сложный и извратный способ изобрести кэширование файловой системы. А чего сложного в "volume.reiser4 -x DEV MNT"? Если у тебя ФС на медленных дисках, то какое-то телодвижение сделать по-любому придётся, чтобы пристегнуть быстрый диск. Сам он не пристегнётся по мановению волшебной палочки.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	143. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 14:37
	> А чего сложного в "volume.reiser4 -x DEV MNT"? Я просто к тому что вообще, в нормальной ситуации, RAM и так будет поюзана дисковым буфером ;). А оформить это нечто как RAM-диск - это чтобы его никак нельзя отобрать было, типа на манер ZFS? > Если у тебя ФС на медленных дисках, то какое-то телодвижение сделать по-любому > придётся, чтобы пристегнуть быстрый диск. Реверанс был сугубо про RAM диск и пойнт этого начинания. Если это какой-то иной диск, то это совсем другой вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 16:06
	> Реверанс был сугубо про RAM диск и пойнт этого начинания. Если это какой-то иной диск, то это совсем другой вопрос. Изначальный вопрос был про тестирование. Для этого достаточно обойтись лишь рамдиском. Для серьёзных целей, разумеется, придётся прикупить память на батарейках.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от microsoft (?), 28-Май-20, 22:54
	Вообще-то мы уже давно умеем кэшировать на ssd/nvme (и даже на pram, но это неточно). https://www.starwindsoftware.com/blog/why-you-should-conside... - похоже, это и послужило источником вдохновения мистеру Шишкину? Но, обратите внимание -  у нас fs не превратится в тыкву, если отвалится один ssd. А вы так можете?
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	122. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от anonymous (??), 27-Май-20, 10:08
	Для других ФС использовать bcache?) А вообще и без кэша было бы интересно посмотреть.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	173. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от ОЛЕГ (?), 27-Май-20, 21:29
	Bcache крайне несоветую! как-то ради прикола Снял кешовый ssd проверил- живого места нет, а вся система говорила что все ок Т.е что там итого записалось хз Под базой реплики юзал, благо не бой...
	Ответить | Правка | Наверх | Cообщить модератору

41. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
Сообщение от kusb (?), 26-Май-20, 16:53
А можно вопрос, ну или несколько? Почему файловые системы такие сложные и почему они могут так интересно и своеобразно терять данные? По моему даже те, на которые запись не велась уже давно. Я воображаю себе файловую систему, как "tar "архиватор"", ну или как "cat "file1 >> file2" плюс заголовок вместе с блоками." Но читая новости складывается впечатление, что создать современную файловую систему это прямо-таки ужас как сложно. И ещё вопрос: Зачем этот уровень внутри файловой системы, а не блочного устройства? Тот же Интернет разнесён похожим образом на уровни, а тут они вместе. Так бы все фс можно было использовать таким способом. Будет хуже? Где?
Ответить | Правка | Наверх | Cообщить модератору

	42. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+3 +/–
	Сообщение от Thony (?), 26-Май-20, 17:19
	Проблема не в том, чтобы создать [какую-то] файловую систему, проблема в том, чтобы создать _эффективную_ файловую систему. Нагрузки на диски бывают самые разнообразные, с самими разнообразными шаблонами, требования к фичам тоже. В итоге, каждая ФС выбирает свои приоритеты.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (7), 26-Май-20, 17:29
	Потому что с ext4 слишком скучно жить. Людям подавай ков, волюмы, отсутствие ограничений, присущих "простым" вариантам хранения, сжатие,  и всё остальное вроде упаковки хвостов. А сабж хранит данные по принципу дерева, а это несколько отличающийся вариант хранения информации. У него есть свои недостатки. Насколько я знаю, у всех подобных систем есть проблемы с балансировкой, распуханием, и саморазрушением.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	108. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:19
	> я знаю, у всех подобных систем есть проблемы с балансировкой, распуханием, > и саморазрушением. А у ext4 есть просто пофигизм в отношении к данным. Ему плевать что с ними случится. Если винч отгрузит какую-то труху или RAM дурит, или что еще - вы это узнаете только когда файлы почему-то превратятся в тыкву, если не вся ФС. А то вон у юзерей с ntfs все выглядело ЗБС. До момента когда он перестал монтироваться и scandisk не смог его починить, так что те ощутили себя почти клиентами namesys'а. Ну правда бабки за приседания срубил я а не namesys. А как вам идея если бы MS за бабки предложил сделать это самое? :)
	Ответить | Правка | Наверх | Cообщить модератору

	124. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (7), 27-Май-20, 10:52
	> А у ext4 есть просто пофигизм в отношении к данным. Ему плевать > что с ними случится. Если винч отгрузит какую-то труху или RAM > дурит, или что еще - вы это узнаете только когда файлы > почему-то превратятся в тыкву, если не вся ФС. Это в любой фс так (ну во всяком случае в btrfs не лучше, хотя там всё подписано, а не только метаданные).
	Ответить | Правка | Наверх | Cообщить модератору

	144. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 14:45
	> Это в любой фс так Это сильно не соответствует действительности. Я проверял. Ext4 вообще для начала большинство народа без полного журнала юзает - и при этом консистентность данных вообще не гарантируется. Потому что писать все данные сперва в журнал, потом в ФС дабы иметь возможность завершить или откатить транзакцию - убивает скорость записи минимум вдвое. А вот CoW этим не страдает - в первом приближении можно рассматривать CoW как "один сплощной журнал" для понимания в чем прикол. Правда этот наглый алгоритмический чит воздается странными свойствами и специфичным набором технических "особенностей", скажем так. > (ну во всяком случае в btrfs не лучше, Таки лучше. С схемой DUP выживает на карте где ext4 быстро превращается в тыкву. Ну да, емкости половина и чинит CSUM ERROR иногда. Но теорвер забавная штука - если его в свою сторону развернуть. Шанс что бэды попадут под обе копии блоков, одинаково - весьма маргинальный. > хотя там всё подписано, а не только метаданные). И таки если есть откуда чинить - он таки при ошибке чексум и чинит. А ext4 в этом плане пофигистичен, он даже с RAID не поймет какая из копий блока верная, например. Поэтому и исправить не сможет при всем желании. А таки self heal у файлухи это довольно прикольно и в результате ФС может выдержать немало странных мытарств.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (7), 27-Май-20, 15:27
	А если неоткуда, btrfs рассыпается и теряет все данные, даже если там один бит флипнут. Никакого доверия ей быть не может, она делает что хочет сама. Ext4 не в пример более устойчивая, при повреждениях теряется только часть повреждённого файла. У тебя кстати тоже не совсем правда, в ext4 есть инлайнинг, и данные могут хранится прямо в журнале (бонусом повышение производительности). Вроде тот парниша проверял тогда, что с случится при повреждении журнала в такой ситуации, и btrfs рассыпалась самой первой (без возможности восстановления вовсе). Reiserfs (3) второй, и ext4 оказалась самой устойчивой к повреждениям. Ей вообще пофиг, что там записано что-то другое. Судя по этому, видимо чексумминг не был включен. Неконсистентность в ext4 подразумевает что вместо новой копии файла, fsck найдёт только старую. Без fsck будет просто куча мусора и "потерянных" блоков (с диска они никуда не денутся, и в случае рекавери они будут на месте). Если fsck после повреждения не прогнать, на выбор или нарастание урона, либо блоки будут помечены "грязными" и с ними ничего не случится. Но зависимые блоки изменятся со временем. Пс. рейд никакого отношения к ext4 не имеет, это разные уровни. В zfs и btrfs просто впихнули всё в кучу.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 16:15
	> А если неоткуда, ...то чего вы ожидали? Однако даже на единичном механическом диске оно кладет metadata с схемой хранения DUP по дефолту. Разок спасло меня от случайного бэда на лаптопном винче, попавшего по счастью в метаданные. А в случае EXT4 если бэд под метаданные попадет... > btrfs рассыпается и теряет все данные, даже если там один бит флипнут. Скорее EXT4 так делает. Не имеет механизмов обнаружения таких проблем, не говоря о парировании. Так что если btrfs в такой ситуации имеет шансы, особенно если к этому заранее подготовиться (=DUP для данных и метаданных), то ext4 становится тыквой. И я имел очень так себе прецедент на ремотной железке в автопилоте. Не понравилось. Выводы были сделаны. И нет, если что - даже fsck не поможет если стораж реально подвел и libc6 не читается. При этом система тупо не взлетит. А с btrfs оно таки вытаскивает там и тут из второй копии, show goes on. И в целом это куда как более diehard может быть. Таки заменить EXT4 на btrfs с схемой DUP сильно подняло надежность забавного выводка железок (ARMовские одноплатники). И early warning о сыпучем носителе (или проблемном железе) задолго до того как это вообще создаст видимые проблемы - таки тоже хорошо. > Никакого доверия ей быть не может, она делает что хочет сама. Она буркнет "CSUM ERROR" в лог ядра и вытащит блок из второй копии. Не забыв перезаписать проблемный - "self heal". Клево, кстати, работает, очень помогая беспилотным системам которым никто не может уделить внимание здесь и сейчас. Удачи так с EXT4. А фанатизм это круто, но только не когда ты подрываешься чинить железку, в свое время и за свой счет. > Ext4 не в пример более устойчивая, при повреждениях теряется только часть повреждённого файла. Ога, если повреждение не попало в метаданные. А если попало - ну, блин, тоже фак. И файлы тоже бывают разные. Ну вот не грузится система без libc6, хоть тресни. И дальше радости то с того что это 1 файл? Система при этом вообще совсем тыква. > У тебя кстати тоже не совсем правда, В смысле? > в ext4 есть инлайнинг, и данные могут хранится прямо в > журнале (бонусом повышение производительности). Вообще-то inline это не про журнал, а про хранение прямо в метаданных ФС, если файл мелкий. Позволяет не делать лишнее обращение из региона метаданных в регион с данными, ускоряя работу с мелкими файлами и до некоторой степени уменьшая slack. Так умеет и btrfs и ext4 по состоянию на сейчас. > Вроде тот парниша проверял тогда, что с случится при повреждении журнала в такой ситуации, У btrfs понятие журналирования ... нечто специфичное. Это CoW и в целом там все здорово иначе. > и btrfs рассыпалась самой первой (без возможности восстановления вовсе). У нее есть на самый крайний случай offline вычитывалка без монтирования, парсер прямо в тулсе "btrfs". Так что там можно довольно круто потрепыхаться даже в совсем тухлых случаях. На манер коммерческих тулсов для вычитывания ntfs, только сразу частью тулкита ФС. И нет, для ext4 такой штуки нет. Во всяком случае в штатных тулсах. Правда там fsck неплохо справляется. Но только до известных пределов. > Reiserfs (3) второй, и ext4 оказалась самой устойчивой к повреждениям. > Ей вообще пофиг, что там записано что-то другое. Угу, только когда libc6 не прочелся с системного стоража - системе малость не пофигу, она работать не может при этом :) > Судя по этому, видимо чексумминг не был включен. Неконсистентность > в ext4 подразумевает что вместо новой копии файла, fsck найдёт только старую. Поскольку обычно EXT4 юзают с журналом только метаданных, ничему не противоречит получить полуперезаписанный файл состоящий из нового начала и старого хвоста. По метаданным это консистентно, однако то что программы смогут работать с таким файлом - ниоткуда не следует. В классическом дизайне для журналирования данных надо писать данные дважды, что тормозно. Весь пойнт CoW в том что он это обходит нахальным жульничеством - у него по сути только журнал и есть, а область с данными в которую коммитят - ее нет. Взамен возникает нужда в GC который будет подбирать старые блоки, иначе место таки закончится. > нарастание урона, либо блоки будут помечены "грязными" и с ними ничего > не случится. Но зависимые блоки изменятся со временем. Спасибо, но я на своем окороке не так давно познакомился с развалом EXT4 на сыпучем носителе. И даже то что там что-то читалось было слабым утешением для системы которая не может загрузиться. Особенно учитывая что это был армовский одноплатник. > Пс. рейд никакого отношения к ext4 не имеет, это разные уровни. В > zfs и btrfs просто впихнули всё в кучу. Btrfs вполне можно засунуть даже на единичную SD карточку с схемой DUP. Не то чтобы с EXT4 совсем нельзя сколхозить эквивалент, но RAID придется мануально создавать на паре разделов самому и чексум все равно не будет так что толку мало.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (7), 27-Май-20, 16:37
	Обычно цель всё же не живучесть и способность загрузиться на убитой флешке, достигаемая многократным дублированием, а возможность выцепить данные при повреждении. Чтобы часть файла оказалось старой и всё было перемешено, я с таким не сталкивался если честно, хотя использую data=writeback всегда. Такая вероятность имеется при повреждении метаданных из-за отключённых барьеров. Я думаю, каждый может убедится, создав файл с btrfs и записав в него данные, после чего внеся изменения в hex редакторе в один из файлов попытаться выцепить остальные. Ничего не получится, всё дерево рассыпается и ошмётки никак не собрать. Выглядит опасно и непредсказуемо.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 18:24
	> Обычно цель всё же не живучесть и способность загрузиться на убитой флешке, Как по мне - это вполне хорошая и правильная цель, экономящая немало нервных клеток. И вообще Early Warning задолго до факапа - это хорошо и правильно. > достигаемая многократным дублированием, а возможность выцепить данные при повреждении. В этом плане EXT4 довольно неплох. Однако btrfs с его тулкитом офлайн вычитывания на мой вкус выглядит нормально. > Чтобы часть файла оказалось старой и всё было перемешено, я с таким не сталкивался > если честно, хотя использую data=writeback всегда. Половина прог таки на этой почве зеа...сь от предъяв юзерей и сделали фееричные костыли "safe" перезпписи файлов, с записью в новый файл и переименованием. Но это такие костылищи... и они конечно же не везде и вообще это круто когда половина по сути семантики ФС в результате выпихнута на апликухи. > Такая вероятность имеется при повреждении метаданных из-за отключённых барьеров. Метаданные могут повредиться и просто потому что стораж так решил. Чексумы как минимум сообщат нам об этом. Независимо от того решило ли фирмваре сообщить наверх IO ERROR или просто выдало наружу какую-то труху (бывает и так и сяк). И это довольно полезно. Потому что потуги парсить откровенную труху ни к чему хорошему не приводят. > Я думаю, каждый может убедится, создав файл с btrfs и записав в него данные, после > чего внеся изменения в hex редакторе в один из файлов попытаться выцепить остальные. Я нечто такое пробовал, для inline файла. Ничего ужасного. Для активного файла вопит про CSUM ERROR, для стертого варианта вообще до балды (GC при подгребании видимо уже не парится такими мелочами). > Ничего не получится, всё дерево рассыпается и ошмётки никак > не собрать. Выглядит опасно и непредсказуемо. Страшные сказки это здорово. Но если мы об этом, хексэдитором можно и просто суперблоки затереть - и попробуй чего-нибудь оттуда потом извлечь так по простому. Кстати самый крутой "real world" дестрой btrfs который я встречал - флеха тупо повисла при записи. Видимо на уровне контроллера. При передергивании она ... профакала 2 из 3 суперблоков btrfs. Однако сие довольно просто чинится и таки 3-я копия выжила. Я думаю что контроллер потерял запись eraseblock-а, встряв в середине операции. Это типично несколько мегов профаканых данных. Хотя может и хуже оказаться - если оно таблицы трансляции апдейтило, карта/флеха рассыпется в адский паззл.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 26-Май-20, 17:41
	> Зачем этот уровень внутри файловой системы, а не блочного устройства? У блочного уровня плохая масштабируемость. Вот тут подробно разжёвываются недостатки блочного уровня: https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Ba...
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	109. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:24
	Весьма кривая дока сомнительной компетентности: 1) Толком не учитывает существование btrfs 2) Не объясняет что btrfs-у мешает раскидывать запросы на эн девайсов 3) Не в курсе что btrfs таки aware of какие там девайсы и где. Итого: господин Эдуард поломался посмотреть вокруг на то что уже есть и что оно делает - но объявил что там есть фатальный недостаток. Офигенно.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 09:26
	4) Да, очень хотелось бы понимать что гражданин Шишкин обозвал в btrfs "своим блочным уровнем". Вроде бы там нет ничего похожего на это. Как максимум там есть своя адресация, но это нечто иное и оно может учитывать девайсы в процессе.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 12:45
	Для того, чтобы понять эту доку, надо как минимум владеть английским языком. У btrfs O(1)-аллокатор есть? Фибер-страйпинг есть? Параллельное масштабирование она может? Поддержка прокси-диска есть? Ничего этого там нет!
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	146. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (99), 27-Май-20, 15:01
	> Для того, чтобы понять эту доку, надо как минимум владеть английским языком. А я и владею. И претензии были к конкретно вон тем заявлениям про "блочный уровень" vs "btrfs" в той вике, не надо передергивать. > У btrfs O(1)-аллокатор есть? O(1) довольно абстрактно и не является достоинством без подтверждения бенчами. По 10 секунд на каждую операцию при любых условиях - это тоже O(1), но радости с него будет мало. > Фибер-страйпинг есть? Если перевести терминологию - то как я понимаю, по фактическим действиям там будет (или может быть реализовано) нечто сравнимое по смыслу, плюс-минус. > Параллельное масштабирование она может? Я не вижу что принципиально мешает btrfs'у раскидывать блоки в случае RAID сразу на несколько устройств (равно как и читать). Насколько хорошо и полно это реализовано - отдельный вопрос. 1) Btrfs знает какие устройства есть. 2) Btrfs оперирует не просто тупым raw разделом/девайсом а аллоцирует "block groups" имеющие тот или иной уровень RAID и работает в этих терминах. 3) Возможно иметь смесь block groups с разными уровнями RAID. Теоретически оно могло бы хоть пофайлово раздавать решать кому какой уровень RAID дать. 4) Собственно online конверсия уровней так и работает - block groups перегоняются из одного типа в другой. Если в середине этого процесса все покрешится - ну, оно при ребуте продолжит перегонять block groups с места где фигакнулось. Свободное место оно при этом вообще не трогает, в отличие от блочного RAID. Насколько я понимаю, в переводе с рейзеровского на бтрфсный то что те называют logical volumes в терминах btrfs может быть представлено как "набор block groups с энным уровнем RAID". > Поддержка прокси-диска есть? Ничего этого там нет! Вот прокси-диска - да, нету. Хотя утвоерждение что это принципиально нереализуемо как мне кажется будет излишне храбрым. Там все довольно гибко изначально было задумано. ...и основная проблема на самом деле в том чтобы все эти суперкомбо убедить корректно взаимодействовать потом, однако :)
	Ответить | Правка | Наверх | Cообщить модератору

	156. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 16:26
	> Вот прокси-диска - да, нету Вот когда будет - приходи, поговорим! Это топик посвящён _существующим_ фичам reiser5, т.е. тем, которые можно потрогать руками, протестировать.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 18:30
	Народ сослался на вику, я нашел в ней явную кривизну и несоответствия. Nothing more, nothing less.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 23:10
	> O(1) довольно абстрактно O(1) - это довольно конкретно. Процесс берёт одну нужную маленькую карту свободных блоков, а не шароёбится по единственной здоровой в поисках свободного места (особенно, если его там осталось мало) > и не является достоинством без подтверждения бенчами. если ты их не видел, то это не значит, что их нет > По 10 секунд на каждую операцию при любых условиях - это тоже O(1), но радости с него будет мало Словесный понос. Тебя никто не заставляет гробить 10 секунд на каждую операцию.
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	186. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 28-Май-20, 09:01
	> O(1) - это довольно конкретно. Это абстрактное заявление, ничего не говорящее сколько операций в единицу времени своротит ФС в энной ситуации и как это соотносится с другими. > Процесс берёт одну нужную маленькую карту свободных > блоков, а не шароёбится по единственной здоровой в поисках свободного места Кто ж сейчас так делает то в современных ФС? Они все уже придумали на этот счет те или иные улучшения, с терабайтными дисками у них выбора не было. > (особенно, если его там осталось мало) Когда его мало - там самой большой проблемой будет, имхо, 1) Фрагментация 2) Общий оверхед работы с метаданными: фрагментов будет дофига. > если ты их не видел, то это не значит, что их нет Ну так покажите? Впрочем, никто не спорит что слетать на экспериментальном, гиперзвуковом, суборбитальном - круто. Но проблема в том что вероятность вернуться одним куском - далеко не единица. И поэтому вундервафля занимает почетное место в музее после пары полетов. Если, конечно, осталось что поместить в музей. А народ в целом ползуется скучными авиалайнерами [и очень нервно реагирует на авиапросишествия]. > Тебя никто не заставляет гробить 10 секунд на каждую операцию. Ну так в том и вопрос - а кто-то проверял как все это будет под реальными нагрузками? Ну и лично я не понимаю как при мелкой тиме, alienated кернелтиме и таком замахе планируется достичь хоть какой-то намек на надежность. Даже у менее навернутого reiser3, который даже замайнлайнили это было "не очень". Оказалось еще тулкит ФС роялит, а с ним швах и фикс шваха путем объявления фатальных багов "known issue".
	Ответить | Правка | Наверх | Cообщить модератору

	196. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 28-Май-20, 13:17
	> Это абстрактное заявление, ничего не говорящее сколько операций в единицу времени своротит ФС в энной ситуации и как это соотносится с другими. Иди, расскажи Молнару и Торвальдсу, что их O(1)-планировшщик "ничего не говорит, сколько операций в единицу времени своротит в энной ситуации и как это соотносится с другими".
	Ответить | Правка | Наверх | Cообщить модератору

	216. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (215), 29-Май-20, 09:47
	> Иди, расскажи Молнару и Торвальдсу, что их O(1)-планировшщик "ничего не говорит, сколько > операций в единицу времени своротит в энной ситуации и как это > соотносится с другими". Эм... это им успешно рассказывают форониксы, коливасы и прочие гентушники :)
	Ответить | Правка | Наверх | Cообщить модератору

	219. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 29-Май-20, 10:24
	> Эм... это им успешно рассказывают форониксы, коливасы и прочие гентушники :) И ты туда же иди, куда их посылают :)
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 13:34
	> Не объясняет что btrfs-у мешает раскидывать запросы на эн девайсов btrfs - это тот же RAID, который уже имеется на block layer. Т.е. запросы там раскидываются на уровне трансляций дисковых адресов. В Reiser5 всё совсем по-другому. Запросу сначала назначается диск, на который он будет записан (назначает пользователь, либо автоматически - алгоритмом фибер-страйпинга). А уже только после это ФС выделяет адрес на том диске.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	147. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (99), 27-Май-20, 15:10
	> btrfs - это тот же RAID, который уже имеется на block layer. Абсолютно не тот же. Btrfs на свободном месте девайса аллоцирует "block group" (некий кус блоков). Каждый block group имеет схему хранения ассоциированную с ним. Как делается RAID1 в терминах btrfs? ФС видит что хотят записать вот это с схемой RAID1. Как это обеспечивается: одна копия блоков идет в block group с подходящей схемой на один девайс, вторая копия идет на другую block group в каком-либо из других устройств, лишь бы там было достаточно места для этого. Поэтому в btrfs вполне валидно например воткнуть допустим 3 винча на терабайт и в итоге получить 1.5 Tb RAID-1 где все блоки хранятся на 2 устройствах - и вылет ни 1 из устройств не фатален. > Т.е. запросы там раскидываются на уровне трансляций дисковых адресов. Запросы там таки оперируют в терминах девайсов и смещений на них и в этом процессе btrfs вполне себе aware куда это и как пойдет. Настолько что при конверсии уровней и прочем он не кантует пустое место, в отличие от блочного RAID. Поэтому можно довольно быстро сконвертить схему хранения огромного стоража... если он относительно пустой :). Настоящий блочный RAID не владеет деталями аллокации и будет конвертить по всей площади. > В Reiser5 всё совсем по-другому. Запросу сначала назначается диск, на который он будет > записан (назначает пользователь, либо автоматически - алгоритмом фибер-страйпинга). > А уже только после это ФС выделяет адрес на том диске. Внезапно, btrfs примерно то же самое делает.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (148), 27-Май-20, 15:13
	p.s. в btrfs устройствам не обязательно быть одного размера - при втыкании девайса это просто место куда можно класть block groups по указанным правилам. Очень удобно менеджить в отличие от блочного RAID - добавить девайс с +X места или даже изъять с -X места вполне себе ненапряжно и относительно быстро. Если на девайсе данных не было так и его ремув почти моментальный. Удачи так с блочным RAID который надо по всей площади перестраивать.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 16:29
	> Толком не учитывает существование btrfs Есть встречное мнение, что btrfs-разрабы не учли существование reiser4.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	167. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (167), 27-Май-20, 18:39
	> Есть встречное мнение, что btrfs-разрабы не учли существование reiser4. Возможно. А там есть какие-то уникальные фичи, принципиально недостижимые в btrfs? Например, какие? Шишкин в своей критике обычно упирал на теоретические синтетические кейсы, что ничего не говорит о перфомансе или user visible фичах. Впрочем btrfs мы лю не за это, а за удобный, логичный и дружелюбный менеджмент, за early warnings о надвигающихся факапах, за то что можно быть более или менее уверенным что если прочлось - то это то что записали, а не что-то иное. Что достаточно актуально если данные начинают исчисляться в терабайтах.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 17:33
	> Толком не учитывает существование btrfs Шишкин сказал, что для реализации своих идей относительно логических томов он рассматривал все существующие на тот момент ФС, и что проще всего это оказалось сделать в Reiser4 (вовсе не потому, что он маинтейнер - просто так совпало). По поводу btrfs он сказал, что её разработчики пошли по пути упрощений, которые оказались недопустимыми. Во-первых, потерялась пресловутая гибкость. Для эффективного распараллеливания основное дерево-хранилище должно обладать фичей, называемой "liquid records". В btrfs же её нет и не предвидится. Во-вторых, Шишкин сказал, что занимается только серьёзным софтом, а в btrfs непривилегированный пользователь в состоянии провести DDOS-атаку на свободное место на разделе (в частности, это то, почему её не взяли в Red Hat).
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	168. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 18:57
	> все существующие на тот момент ФС, и что проще всего это > оказалось сделать в Reiser4 (вовсе не потому, что он маинтейнер - Каждый первый програмер именно так говорит. Однако зубоскальство про NIH имеет определенный пойнт :P > пошли по пути упрощений, которые оказались недопустимыми. Ее даже так отлаживали дофига и больше. И до сих пор реализовано и близко не все что тот дизайн кишок имеет предложить на самом деле. Самое очевидное: - Они утверждают что в именно btrfs можно сделать RAID56 без write hole. - Этот дизайн нормально отнесется к идее что уровень RAID разный для разных файлов (дир, subvolume'ов). Оно уже сейчас ОК с существованием разных типов block groups одновременно. Просто нет аллокатора который был бы настолько сумасшедший и инфраструктуры управления подобнымми штуками. > Во-первых, потерялась пресловутая гибкость. Да вроде наоборот, структуры с солидным заделом на будущее. Гибкое по аллокации, удобный менеджмент задуман сразу на этапе дизайна, etc. И вроде более-менее получилось. > Для эффективного распараллеливания основное дерево-хранилище должно обладать > фичей, называемой "liquid records". А я то думал что для эффективного распараллеливания надо стараться пулять блоки сразу в эн устройств. Что они называют "liquid records"? > В btrfs же её нет и не предвидится. Что сие по физическому/логическому смыслу? Возможно там есть что-то сравнимое? Или можно обойтись и без этого? > Во-вторых, Шишкин сказал, что занимается только серьёзным софтом, а в btrfs > непривилегированный пользователь в состоянии провести DDOS-атаку > на свободное место на разделе Может, все-таки, DoS? А то Distributed атака такого плана находится за пределами моего воображения :P. Ну и вообще, с ФС можно сделать довольно много странных вещей. Например: я однажды имея сугубо юзерские права положил общесистемный перфоманс EXT4 до состояния плинтуса. И даже снос всех моих данных с хоста уже ничего не поменял. Тоже в общем то DoS по большому счету. > (в частности, это то, почему её не взяли в Red Hat). Вообще-то история немного не такая. Ее изначально взяли, в экспериментальном режиме. Но тем временем из RH как-то подразбежались в другие фирмы разработчики ФС и блочного уровня, как я понимаю в RH тупо нет ни 1 кадра который бы в этом разбирался. Ну и да, заклятые друзья из SuSE за это дело уцепились быстрее RH и вот у них разработчиков этой штуки есть. И они ей пользуются. А редхат то пиндел, конечно, на конкурента.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 19:41
	> И вроде более-менее получилось Ну вот, у тебя есть шанс доказать это, реализовав прокси-диск в btrfs ))
	Ответить | Правка | Наверх | Cообщить модератору

	170. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 27-Май-20, 20:42
	> я однажды имея сугубо юзерские права положил общесистемный перфоманс EXT4 до состояния плинтуса. И даже снос всех моих данных с хоста уже ничего не поменял. Тоже в общем то DoS по большому счету. Это не иначе, как заговор академиков против честных разработчиков ядра Линукс!
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	189. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (-), 28-Май-20, 09:17
	> Это не иначе, как заговор академиков против честных разработчиков ядра Линукс! На самом деле этот фокус можно повторить с любой ФС. Если кто думает что разработчики имеют хоть какой-то шанс предусмотреть все выходки юзерей в всех мыслимых конфигурациях - напрасно. Так что козырять такими же вещами - хороший способ ощутить себя в шкуре мозилы корп козырявшей безопасностью браузера. Ну им over 9000 vuln'ов и нашли.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 27-Май-20, 20:49
	> Вообще-то история немного не такая. Ее изначально взяли, в экспериментальном режиме. Но тем временем из RH как-то подразбежались в другие фирмы разработчики ФС и блочного уровня Ясное дело, подразбежались! Их там заставляли из btrfs энтерпрайз делать, а в шапке стандарты очень высокие! Это тебе не Суся какая-нить с анбрейкабл Орацлом.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	188. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Аноним (-), 28-Май-20, 09:15
	> шапке стандарты очень высокие! Особенно заметно на редхатовском пакетном менеджере - хуже я просто не знаю. Сейчас даже уже фрибсд что-то более вменяемое сделали. Факин лол!
	Ответить | Правка | Наверх | Cообщить модератору

	255. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от _ (??), 05-Июн-20, 19:43
	Вообще то ВНЕЗАПНО - во фряхе лучший пакетный мэнэджер, из всего что есть на сегодняшний день :) PS:  Эххx ... но ей уже даже это не поможет. IMHO :(
	Ответить | Правка | Наверх | Cообщить модератору

	172. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 27-Май-20, 20:56
	> А я то думал что для эффективного распараллеливания надо стараться пулять блоки сразу в эн устройств С тобой всё ясно, иди изучай матчасть!
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	190. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 28-Май-20, 09:23
	> С тобой всё ясно, иди изучай матчасть! Так там на вики вот прямо так и написано. В начале. Потом там еще совершенно ушибленное формльное определение идет, однако оно сформулировано так что само себе противоречит. Автырю оного нехило бы прочитать что он написал, взять словарик английского языка и проверить значение слов. А то там прямо какой-то #define true false //have a nice debug session! (автырь переколпачивает или странно юзает значения половины слов).
	Ответить | Правка | Наверх | Cообщить модератору

	199. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 28-Май-20, 18:02
	Всё там чётко и без противоречий. Иди учи английский.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (215), 29-Май-20, 09:50
	> Всё там чётко и без противоречий. Особенно определение, противоречащее смыслу английских слов в нем :D > Иди учи английский. Походу это таки не мне надо. Потому что чтобы дать то определение - надо конкретно хряпнуть упорина. Или если это была попытка маркетинга - надо было маркетолога позвать, он бы придумал как назвать хрен редькой менее горбато.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 29-Май-20, 11:12
	> Особенно определение, противоречащее смыслу английских слов в нем :D И какому же слову в нём, как вы изволили выразиться, оно противоречит? Слово в студию!!!
	Ответить | Правка | Наверх | Cообщить модератору

	232. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 29-Май-20, 22:27
	> Слово в студию!!! Parallel. Определение Parellel scaling out там просто эпик какой-то, из формального определения вообще не понятно каким боком из него следует параллельность какая-то вообще. Что означает "saves" автор статьи тоже походу не вдупляет и использует сие ... логически некорректно. C parallel это вообще довольно сложно стыковать. Видимо, более подходящих слов в инглише автор не придумал, хоть они и есть.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 30-Май-20, 00:49
	> Parallel. Определение Parallel scaling out там просто эпик какой-то, из формального определения вообще не понятно каким боком из него следует параллельность какая-то вообще. В той статье из вики есть предыстория (Previous Art), из которой становится понятно, почему "parallel". Понятие это пришло от сетевых параллельных ФС таких, как GPFS и Lustre. Определение непротиворечиво, придраться там не к чему. Под него подходят как минимум три ФС: GPFS, Lustre и Reiser5. > Что означает "saves" автор статьи тоже походу не вдупляет и использует сие ... логически некорректно. Saves - глагол (3 лицо, ед. число). Означает сохранение (непотерю) [ресурсов]. Что тут некорректного? Как будет на английском: "подсистема сохраняет ресурсы"? Очевидно, "subsystem saves resources". > C parallel это вообще довольно сложно стыковать. Видимо, более подходящих слов в инглише автор не придумал, хоть они и есть. А как сетевые параллельные ФС стыкуются с пареллельностью? Точно так же и ты стыкуй. > Видимо, более подходящих слов в инглише автор не придумал, хоть они и есть. Это вопрос к тому, кто лет тридцать назад назвал некоторые сетевые ФС параллельными. Кому-то, может и сложно стыковать. На мой взгляд аналогия очень даже прослеживается (в той же статье есть пример с дождём и вёдрами).
	Ответить | Правка | Наверх | Cообщить модератору

	236. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 30-Май-20, 08:59
	> В той статье из вики есть предыстория (Previous Art), из которой становится > понятно, почему "parallel". Ну да. Там это написано более логично. Однако определить "parallel" через "saves" это достаточно оригинально. Потому что параллелизм в определении не фигурирует. И как максимум - очень неявно где-то "подразумевается". А в той части другой косяк: технически некорректные заявления для как минимум btrfs. Автор не въехал, что колесо не-блочного RAID изобрели до него. Или попытался присвоить чужие достижения. При том что отличный от block-level подход к RAID в btrfs много лет - и даже не факт что придумали это они. > Понятие это пришло от сетевых параллельных ФС таких, > как GPFS и Lustre. Определение непротиворечиво, придраться там не к чему. Оно просто выглядит достаточно бессмысленным набором слов. При сильном желании, понять что на самом деле имеется в виду можно, если прочитать вступление. Но тот индийский математик все же вспоминается. > Под него подходят как минимум три ФС: GPFS, Lustre и Reiser5. Если перевести тот набор слов с reiserfs'ного на английский, под него как я понимаю и btrfs или уже подходит, или технически может подходить. В том плане что это может жрать меньше суммарного бандвиза чем тупой блочный подход. > Saves - глагол (3 лицо, ед. число). Означает сохранение (непотерю) [ресурсов]. Что > тут некорректного? Некорректно при этом педалировать параллельность, потому что из всего того набора слов какая-либо параллельность вообще не следует. А если идея в bandwidth saving, может это как-то так и обозвать? > "subsystem saves resources". Это все хорошо, но при чем тут "parallel"? Являющийся центральным моментом определения. Этот момент в определении не раскрыт. В преамбуле да, сколько угодно. > А как сетевые параллельные ФС стыкуются с пареллельностью? Точно так же и ты стыкуй. И все же определение параллельности где параллельность ниоткуда не следует - это странно, господа. > даже прослеживается (в той же статье есть пример с дождём и вёдрами). При сильном желании понять можно. И пардон, сетевыми штуками я если интересовался, то это "не совсем ФС" в привычном понимании. Скорее "распределенными структурами".
	Ответить | Правка | Наверх | Cообщить модератору

	244. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 30-Май-20, 13:14
	> При том что отличный от block-level подход к RAID в btrfs много лет Не нужно путать "block-level" и "block layer". "block layer" - этот подсистема OS. "block-level" относится к методу агрегирования малых реальных дисков в один большой, виртуальный. Все стандартные уровни RAID (за исключением зеркал, и экзотических 2 и 3) - они block-level. Вот, читай: https://en.wikipedia.org/wiki/Standard_RAID_levels. Все нестандартные - тоже block-level. Пожалуйста: https://en.wikipedia.org/wiki/Non-standard_RAID_levels B reiser5 нет RAID и вообще не будет (кроме зеркал). Там даже JBOD нет. Агрегация устройств в Reiser5 происходит по типу сетевых ФС. Шишкин сказал: "RAID - это технология, место которой только на block layer. Не нужно это тащить в файловую систему!"
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	245. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 30-Май-20, 14:22
	> Некорректно при этом педалировать параллельность, потому что из всего того набора слов какая-либо параллельность вообще не следует. А если идея в bandwidth saving, может это как-то так и обозвать? В классической логике очень даже корректно. Почитай определение параллельности, данное Лобачевским  - будешь сильно удивлён :) А потом, у него параллельные прямые (какой ужас) пересекаются!!! И, ничего, живём с этим уже вторую сотню лет :)
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	247. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (247), 30-Май-20, 17:11
	> В классической логике очень даже корректно. Почитай определение параллельности, данное > Лобачевским  - будешь сильно удивлён :) А потом, у него > параллельные прямые (какой ужас) пересекаются!!! И, ничего, живём с этим уже > вторую сотню лет :) Параллельные прямые у Лобачевского пересекаются это что-то новое. Очень желаю увидеть этот текст от Лобачевского. Так понимаю остальные знания, которыми ты тут делишься, такого же типа?
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	249. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 30-Май-20, 22:56
	> Параллельные прямые у Лобачевского пересекаются это что-то новое. Хорошо, не у него (а обидно!). Ключевое слово "пересекаются". С этим нет вопросов?
	Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

	251. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (251), 31-Май-20, 00:05
	>> Параллельные прямые у Лобачевского пересекаются это что-то новое. > Хорошо, не у него (а обидно!). Ключевое слово "пересекаются". С этим нет > вопросов? Даже как то странно взрослым людям напоминать что это определение параллельных. Они ни в одной геометрии не пересекаются.
	Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

	252. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 31-Май-20, 03:16
	> Даже как то странно взрослым людям напоминать что это определение параллельных. Они ни в одной геометрии не пересекаются. Ох ты ж господи! :) "Пресекаются прямые, евклидовы части которых параллельны" - так лучше звучит? Если ты такой щепетильный, может устроим разбор фразы "определение, противоречащее смыслу английских слов в нем"? А то я деликатно не стал придираться. А с неё весь сыр-бор и начался...
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	253. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (253), 31-Май-20, 11:02
	>> Даже как то странно взрослым людям напоминать что это определение параллельных. Они > ни в одной геометрии не пересекаются. > Ох ты ж господи! :) > "Пресекаются прямые, евклидовы части которых параллельны" - так лучше звучит? > Если ты такой щепетильный, может устроим разбор фразы "определение, противоречащее смыслу > английских слов в нем"? А то я деликатно не стал придираться. > А с неё весь сыр-бор и начался... Это ты к другому анониму иди за английский язык тереть. Мне достаточно того что я увидел.
	Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

	234. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 30-Май-20, 02:26
	> Что означает "saves" автор статьи тоже походу не вдупляет и использует сие ... логически некорректно. C parallel это вообще довольно сложно стыковать. То есть, тебе непонятно, почему Шишкин определяет параллельность через сохранение ресурсов? Это уже к нему обращайся! Только перед тем, как будешь с ним спорить, хочу предупредить: он математик, доктор наук и хорошо понимает, о чём говорит! :)
	Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

	235. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 30-Май-20, 08:02
	> он математик, доктор наук и хорошо понимает, о чём говорит! :) По нему ... заметно. И это может быть и работает для какой-нибудь абстрактной математики, или накрайняк теоретической физики какой. Но даже там стараются упаковывать слова в логичном и непротиворечивом виде, используя устоявшиеся термины по возможности, дабы другие могли понять суть и на сглючить при этом. А иначе это начинает напоминать старинную историю с индийским математиком, который вроде бы допер до совершенно нетривиальных вещей, не имея формального образования. Проблема в том что из-за всего этого он был решительно неспособен объяснить суть своих открытий окружающим. И только Лейбницу, чтоли, стало любопытно что все-таки за нах и после долгих мытарств он наконец смог вообще одуплить чего имеется в виду. Вот читая эту вику я невольно вспомнил ту историю.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 30-Май-20, 11:16
	> Проблема в том что из-за всего этого он был решительно неспособен объяснить суть своих открытий окружающим. Объяснять суть своих открытий окружающим - это решительно не дело учёных. Для этого есть популяризаторы науки. Совмещать приятное с полезным могут только единицы. Такие как Джинс, Фейнман, Хокинг. Вот Эйнштейн никому ничего не объяснял :)
	Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

	175. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 22:50
	> Ее изначально взяли, в экспериментальном режиме. Но тем временем из RH как-то подразбежались в другие фирмы разработчики ФС и блочного уровня, как я понимаю в RH тупо нет ни 1 кадра который бы в этом разбирался Ну, детский сад какой-то чесслово! "Разработчики не разбежались" не есть критерий того, что экпериментальная фича успешно прошла "technical preview" в Red Hat. Название "technical preview" само за себя говорит. А что будет, если разработчики разбегутся после того, как её возьмут в продакшн? Не задавались таким вопросом? А жаль!
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	187. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 28-Май-20, 09:10
	> "Разработчики не разбежались" не есть критерий того, что экпериментальная фича успешно > прошла "technical preview" в Red Hat. Название "technical preview" само за > себя говорит. А что будет, если разработчики разбегутся после того, как > её возьмут в продакшн? Не задавались таким вопросом? А жаль! Зато у редхата проходит preview тормозной глючный пихонокрап, вплоть до пакетного менеджера дохнущего жестокой смертью с харакири базе пакетов. После чего система становится малость тыквой. Но это ничего, картонный макет пакетного менеджера в системе их не напрягает. Пардон, релизиться >10 лет к ряду с калом вместо пакетного менеджера - не больно какой стандарт качества.
	Ответить | Правка | Наверх | Cообщить модератору

43. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
Сообщение от Thony (?), 26-Май-20, 17:23
Идея с прокси-диском в составе тома прикольная, но, к примеру, что если некоторые файлы мне хочется постоянно иметь в быстром доступе? Поди придумает атрибуты для каталога?
Ответить | Правка | Наверх | Cообщить модератору

	47. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от Нолекс (?), 26-Май-20, 17:43
	Хранить на отдельном томе без прокси не вариант?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 26-Май-20, 17:55
	> что если некоторые файлы мне хочется постоянно иметь в быстром доступе? Я так понимаю, что с этим проблем не возникнет. Присвой им максимально высокое значение "температуры", и сканнер не будет их трогать. Шишкин говорил, что нет пока алгоритмов для определения критической температуры, всё что ниже которой выгоняется с прокси.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

50. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Eric Hartman (?), 26-Май-20, 17:55
Есть у неё какие-нибудь плюшки для SSD?
Ответить | Правка | Наверх | Cообщить модератору

	149. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (148), 27-Май-20, 15:15
	> Есть у неё какие-нибудь плюшки для SSD? Ну вот плюшка юзать SSD для затыкания амбразуры^W^W обеспечения быстрой записи по всей площади большого диска.
	Ответить | Правка | Наверх | Cообщить модератору

55. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
Сообщение от Аноним (55), 26-Май-20, 18:34
Уже есть zfs, bcache и lvmcache
Ответить | Правка | Наверх | Cообщить модератору

	71. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–1 +/–
	Сообщение от пох. (?), 26-Май-20, 20:13
	и само количество половинчатых решений ничуть ведь не намекает вам, что все три варианта - в лучшем случае УГ, а в более реалистичной трактовке - еще и опасное для данных УГ. Вот кокретно про zfs есть совершено четкая информация от разработчиков, неоднократно ими озвучивавшаяся - что l2 нужно использовать только в одном-единственном случае - кончились слоты оперативной памяти, а working set хотя и больше, но конечен. zil нужно использовать примерно никогда, все попытки его использования, обычно - от непонимания, как он работает, и только ухудшают дело. Тут хотя бы попытка подойти к делу с другой стороны. Не факт что удачная, но по крайней мере это интересный эксперимент.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 09:28
	Во всяком случае, общая идея не выглядит чем-то идиотским. Но вот в упомянутой вике гражданин Шишкин конкретно протупил походу. Ему видимо не говорили что из своей кельи иногда стоит высовывать нос и смотреть вокруг. И тогда окажется что половину колес уже изобрели, или что они работают не так как тот себе возомнил :)
	Ответить | Правка | Наверх | Cообщить модератору

57. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+3 +/–
Сообщение от Аноним (57), 26-Май-20, 18:59
>Data Tiering [trollmode] Теперь тиринг еще и в ФС! Бесплатно и без смс! [/trollmode]
Ответить | Правка | Наверх | Cообщить модератору

	118. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (-), 27-Май-20, 09:51
	> [trollmode] Теперь тиринг еще и в ФС! Бесплатно и без смс! [/trollmode] Английский язык иногда бывает забавным. Не стоит путать friend и fiend... :)
	Ответить | Правка | Наверх | Cообщить модератору

64. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (64), 26-Май-20, 19:53
Ждём поддержку райзер5 в ядре.
Ответить | Правка | Наверх | Cообщить модератору

65. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (64), 26-Май-20, 19:54
Интересно, почему Эдуард не переименовывает проект?
Ответить | Правка | Наверх | Cообщить модератору

	74. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+5 +/–
	Сообщение от Михрютка (ok), 26-Май-20, 20:19
	он боится, что shishkinfs русские будут писать на опеннете сиськинфс, а американцы на каком-нибудь реддите - shitkinfs
	Ответить | Правка | Наверх | Cообщить модератору

	76. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (64), 26-Май-20, 20:32
	Но ведь я уже сейчас могу написать срайзерфс...
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (88), 27-Май-20, 02:40
	Потому что она все ещё во многом основана на идеях и реализации ее изначального автора. А алгоритмы и код не становятся хуже (или лучше) от не относящихся к программированию поступков их автора.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

78. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от gogo (?), 26-Май-20, 20:49
Квест  - убей мой ССД ) Очевидно, что тут ССД отправляется на амбразуру обреченный, это суть данного метода. Но как-то жаль его....
Ответить | Правка | Наверх | Cообщить модератору

	84. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от пох. (?), 27-Май-20, 00:16
	ты всегда можешь вставить его в рамочку и просто на него любоваться, если жаль. Правда, придется подвести к ней питание - от висения на стене в рамочке выключенными - современные поделки умирают гораздо быстрее, чем от использования по назначению. Но судьба абсолютно любого ssd независимо от использования - умереть в помойке. Ну и типа, вообще-то бывает и так: Recommended: Cache drives should have high write endurance: at least 3 drive-writes-per-day (DWPD) or at least 4 terabytes written (TBW) per day что для enterprise-grade железки ни разу не удивительно. Это требования microsoft, если что.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 27-Май-20, 09:53
	> Правда, придется подвести к ней питание - от висения на стене в > рамочке выключенными - современные поделки умирают гораздо быстрее, Ну а фигли, из мелких ячеек заряд утекает. И флеш превращается... превращается флеш... в подобие динамической оперативки, которой тоже регенерацию, дескать, подавай.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от kusb (?), 27-Май-20, 12:46
	А ссд может быть средством для долговременного хранения данных более надёжным, чем магнитный диск? Диски же сыпятся, а тут может быть достаточно доставать раз в какое-то время, проводить регенерацию и снова ложить обратно. И с учётом этих мер всё дольше, чем диск. Или флешку вместо ссд.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+2 +/–
	Сообщение от Аноним (151), 27-Май-20, 15:29
	> А ссд может быть средством для долговременного хранения данных более надёжным, чем  магнитный диск? Какой-нибудь старый SLC наверное может. Но и цена за гигабайт там под стать. А так всем емкость подавай, вагон, и за копье. Расплатой за это становится очень хлипкий флеш с мелкими ячейками, где пытаются различать аж несколько уровней на ячейку, чтобы еще больше лезло. Поскольку ячейки от циклов стирания-записи "разбалтываются" (в английской wikipedia есть подробное описание эффектов), а заряда в мелкой ячейке не так уж много, в какой-то момент начинаются ошибки. Заряд либо утекает либо при чтении неверно трактуется уровень вольтажа. И все это совершенно крейсерское состояние дел, высокоплотный TLC может начать активно сыпаться через всего то ~100 циклов. До определенного порога ошибки чтения парирует FEC. Однако если он не выдюжил тот процент сбоев который образовался - упс. И понятно что большой процент кристалла под вспомогательные данные FEC отдавать всех опять же душит жаба. Там и еще более интересные эффекты есть. При _чтении_ активность чипа может вызывать небольшую утечку заряда ("read disturbance"). Современные контроллеры SSD это могут до некоторой степени учитывать. Откуда и совет поха подвести к рамке питалово :). Ведь выключенный контроллер недееспособен и не сможет регенерацию прогнать. > Диски же сыпятся, С другой стороны, намагниченность с течением времени пропадать все же не склонна. И поэтому поставленный в рамку _выключенный_ (чтобы не было износа) винч с бэкапами в принципе в этой рамке довольно долго может болтаться без особых потерь данных. Сыпятся они все же в основном при работе - механика все же изнашивается, иногда пылинки от этого могут сесть на поверхность а не в фильтр, etc. Однако головы не касаются блина а гидродинамические моторчики "почти вечные". Вон красавец, 110 000 часов на 7200, и хоть бы что. > а тут может быть достаточно доставать раз в какое-то время, проводить регенерацию > и снова ложить обратно. В принципе вариант. Но если это прошляпить... эм... > И с учётом этих мер всё дольше, чем диск. Или флешку вместо ссд. Можно подумать в флешках NAND другой... в SSD контроллеры умнее, в флехах и прочих картах памяти он может вообще игнорить такие проблемы как класс или реагировать очень странно.
	Ответить | Правка | Наверх | Cообщить модератору

86. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
Сообщение от Аноним (86), 27-Май-20, 01:54
Не перевелись ещё гении на земле Русской, коим Эдуард и является!
Ответить | Правка | Наверх | Cообщить модератору

91. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от iCat (ok), 27-Май-20, 04:54
Хм-м-м... А как поведёт себя подобная система в случае непрекращающегося потока изменений? Предположим - высоконагруженная база данных, или, там, "видеопоток"?
Ответить | Правка | Наверх | Cообщить модератору

	92. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (92), 27-Май-20, 06:55
	Там же написано > В случае отсутствия свободного места на прокси-диске все данные автоматически записываются в основное хранилище
	Ответить | Правка | Наверх | Cообщить модератору

94. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (94), 27-Май-20, 07:31
Свободу разрабам!
Ответить | Правка | Наверх | Cообщить модератору

95. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (95), 27-Май-20, 07:40
Ни ку-ку себе. Вапще бомба.)
Ответить | Правка | Наверх | Cообщить модератору

96. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (95), 27-Май-20, 07:43
> Квест  - убей мой ССД ) Весь инет пестрит комментами в стиле - ха, проблема, куплю новый. Неужели не ваш случай?)
Ответить | Правка | Наверх | Cообщить модератору

	103. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 27-Май-20, 09:04
	> > Квест  - убей мой ССД ) > Весь инет пестрит комментами в стиле - ха, проблема, куплю новый. Неужели > не ваш случай?) а вот это как раз вопрос отдельный - наш ли это случай, или заодно придется заново скачать весь прон, оказавшийся в том "прокси". Или не в том прокси, а на всей fs сразу. zfs решает этот вопрос обязательностью mirroring zil (в смысле - никак не решает, если не было зеркала - твой пул превратился в тыкву, с чем поздравляем - но миррорить таки можно), для arc2 зеркало необязательно но крайне желательно, потому что просто так удалить его тоже не получится (ну и оно таки дает 2x на чтение, а запись там не играет большой роли, она асинхронная во время тихое) корпорация, которая зла - тоже велит ставить минимум два...невнятно...сервера. про поделки bcache/dm-cache - ждем местных экспертов, они все знают - на лоре вычитали.
	Ответить | Правка | Наверх | Cообщить модератору

97. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	–3 +/–
Сообщение от Аноним (95), 27-Май-20, 08:04
> Когда Райзера выпустят, не раньше) Пущай сидит этот подонок и сдохнет от спида коронного!
Ответить | Правка | Наверх | Cообщить модератору

123. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от Аноним (95), 27-Май-20, 10:14
> Да идеи то у него и тех кто рядом бывают неплохие. Но вот реализация... как обычно у россиян, своим путем и этот путь почему-то всегда ведет в один и тот же пункт, начинающийся на Ж :\ Вылезайте на свет божий, иначе так и не увидите, что ошибаетесь.Техологии идут в каждый дом, кто виноват, что вы сидите в Ж :\
Ответить | Правка | Наверх | Cообщить модератору

126. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от YetAnotherOnanym (ok), 27-Май-20, 11:11
> Добавление прокси-диска в логический том не сопровождается какой-либо перебалансировкой данных, а его удаление происходит точно так же, как и удаление обычного диска Как это согласуется с тем, что на этом диске by design находятся данные, которых пока нет ни на одном другом диске?
Ответить | Правка | Наверх | Cообщить модератору

	135. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 27-Май-20, 13:19
	> на этом диске by design находятся данные, которых пока нет ни на одном другом диске? сам-то понял, что сказал?
	Ответить | Правка | Наверх | Cообщить модератору

	140. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от YetAnotherOnanym (ok), 27-Май-20, 14:31
	> сам-то понял, что сказал? Я - да, а ты?
	Ответить | Правка | Наверх | Cообщить модератору

139. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от all_glory_to_the_hypnotoad (ok), 27-Май-20, 14:03
> На данном же этапе ответственность за очистку возлагается на пользователя. Сброс данных с прокси-диска в основное хранилище производится простым вызовом утилиты... Офигеть технологии, всё как всегда - через задницу. Если учесть, что под быстый диск будут выделять твёрдотельные накопители, то неплохо было бы все данные кодировать избыточно на несколько разных быстрых дисков и сбрасывать на медленные как можно быстрее. В предлагаемой архитектуре вся ФС может сдохнуть от частичной деградации быстрого диска с SSD. Т.е. должен быть не просто сборос по крону, а специальный следящий за нагрузкой менеджер с приоритетами для метаданных.
Ответить | Правка | Наверх | Cообщить модератору

	158. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (158), 27-Май-20, 16:37
	> Офигеть технологии, всё как всегда - через задницу. Не, ну блин, это все же честно обозначено как preview технологии. И предъявлять при этом что-то довольно странно. > данные кодировать избыточно на несколько разных быстрых дисков и сбрасывать на > медленные как можно быстрее. Один маленький нюанс: минимальная конфига получится стоимостью как самолет. > В предлагаемой архитектуре вся ФС может сдохнуть > от частичной деградации быстрого диска с SSD. А вот как эта штука с деградацией разбирается я не совсем понял. В теории вроде может записывать более 1 копии или RAID-like кодирование. На практике это ускорит кончину кэш-диска. > Т.е. должен быть не просто сборос по крону, а специальный следящий за > нагрузкой менеджер с приоритетами для метаданных. Походу unimplemented пока.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 28-Май-20, 03:45
	> Не, ну блин, это все же честно обозначено как preview технологии. И предъявлять при этом что-то довольно странно. У этой технологии вроде как обозначен план развития и сделать хорошо в него не входит. Типа реализуем идею, которой 100 лет в обед, и посмотрим что делать дальше - так не работает. Надёжность технологии из-за SSD нужно продумывать сразу. > Один маленький нюанс: минимальная конфига получится стоимостью как самолет. Это всего лишь 2-3 SSD/NVMe, доступно многим любителям. > А вот как эта штука с деградацией разбирается я не совсем понял. В теории вроде может записывать более 1 копии или RAID-like кодирование. И с поблочными контрольными суммами (на каждые N KiB данных), просто RAID или копии будет мало.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (39), 27-Май-20, 18:09
	Т.е. должен быть не просто сборос по крону, а специальный следящий за нагрузкой менеджер с приоритетами для метаданных. Сказали же: менеджер будет после достижения бета-стабильности. Было из-за чего визг поднимать. Просто так легче отлаживать.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	179. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 28-Май-20, 03:48
	Может быть, но есть подозрение что это будет чуточку продвинутый запуск предлагаемой команды по крону, а не полноценный планировшик перекачки. В тексте указано, что `быстрый` диск для ФС выглядит как обычный, а для планировщика нужно ещё прицеплять некоторвые метаданные или даже иначе использовать дисковое пр-во.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 28-Май-20, 12:34
	> не полноценный планировшик перекачки У тебя каша в голове. Зачем для очистки что-то планировать? На таргете создали копию, после этого удалили объект на исходном диске.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 28-Май-20, 14:22
	Конечный носитель может быть занят другим IO и если делать без планирования, то произойдёт размен отзывчивости ФС на быстрые burst write-ы. Для ФC честная отзывчивость (задержки) намного важнее быстрой записи. Т.е. где нужна быстрая запись приложения и так в состоянии нагородить свой лог.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (153), 28-Май-20, 15:36
	> Конечный носитель может быть занят другим IO и если делать без планирования, то произойдёт размен отзывчивости ФС на быстрые burst write-ы. Для ФC честная отзывчивость (задержки) намного важнее быстрой записи. Т.е. где нужна быстрая запись приложения и так в состоянии нагородить свой лог. Тебе по ходу лечиться нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (230), 29-Май-20, 18:30
	> Конечный носитель может быть занят другим IO В той стратегии, что тут анонсирована, приложения напрямик не него не пишут. Только читают.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от Аноним (-), 30-Май-20, 10:21
	> В той стратегии, что тут анонсирована, приложения напрямик не него не пишут. > Только читают. Тупишь, тезка. У господина теоретика там походу допущение что в целом IO - относительно idle, но иногда вспердывает большим объемом данных. И вот в таком допущении - этот всплеск данных всегда попадает на быстрый носитель, уже готовый к этому, потому что предыдущее выжато на медленные диски во время idle. И выгрыш, как я понимаю, вот в таком сценарии. А если это непрерывная интенсивная нагрузка - тогда ой.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (231), 29-Май-20, 19:25
	Дело говорит. Только зачем мета-данные для планирования? Для этого нужна другая системная информация. С этой точки зрения диски равноправны.
	Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

	228. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 29-Май-20, 16:22
	гы/гы - угадай, на что напоролась ms, сделав аналогичную хрень в виде mirror+ec ;-) У них все честно, никакого ручного переписывания.
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	254. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Crazy Alex (ok), 04-Июн-20, 11:04
	Зачем такие извращения? Хочется дублирования - собери RAID и используй полученное устройство. А так - ну выдаст ошибку кэширующий диск - записать на основной.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

180. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
Сообщение от хотел спросить (?), 28-Май-20, 04:00
сначала создаётся новый файл, который содержит изменённые данные; потом этот новый файл записывается на диск при помощи fsync(2); после этого новый файл переименовывается в старый, что автоматически освобождает блоки, занятые старыми данными. что за бред? я таких СУБД не знаю...
Ответить | Правка | Наверх | Cообщить модератору

	191. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (191), 28-Май-20, 09:23
	mysql trx 1
	Ответить | Правка | Наверх | Cообщить модератору

	211. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 29-Май-20, 08:48
	+ sqlite в дефолтной (без WAL) конфигурации. С WAL есть, э...особенности, поэтому по умолчанию он выключен - для тех кто о них не в курсе, лучше чтобы его не было.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (192), 28-Май-20, 09:54
	> что за бред? я таких СУБД не знаю... Это не СУБД, это костыль под названием "безопасная перезапись файлов" на стороне программ, для ФС не умеющих в нормальное полноценное журналирование. Иначе при крахе в момент записи можно получить наполовину старый, наполовину новый файл. Который вовсе не обязан читаться программами. А СУБД в силу таких свойств некоторых ФС с горя научились делать журналирование просто на своей стороне целиком.
	Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

	210. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 29-Май-20, 08:46
	> для ФС не умеющих в нормальное полноценное журналирование для всех. > Иначе при крахе в момент записи можно получить наполовину старый, наполовину новый файл. как журналирование от этого поможет? В лучшем случае оно позволит избежать последствий reordering, когда мы писали-писали, решили что дописали, и поставили себе пометку transaction finished. Но головки стояли близко к журналу транзакций, и далеко от данных - поэтому система оптимизировала запись, первым записав что поближе, и тут ой, kernel panic. journaled fs при этом не пометит запись состоявшейся уже на своем уровне - и при накате журнала запишет и данные, и метку заново, приведя все в консистентное состояние. Но ценой потерь производительности на двойное (четверное) перезаписывание одного и того же. Поэтому никто с journal=data и не хочет иметь дел. Вот журналирующая CoW или log-structured (что совсем не то же самое) fs - поможет. Но опять же такой потерей производительности именно для субд - что все наизобретали костылей и подпорок, чтобы этот CoW для них выключать или хотя бы свести к минимуму. При этом очевидный костыль вида полностью отключить внутреннее журналирование и direct io вместе с ним, и надеяться в этом на шибкопродвинутую fs - в случае как минимум mysql(innodb)+zfs не работает, данные первращаются в тыкву. Причины никому неизвестны и разбираться - героев не нашлось.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 29-Май-20, 10:20
	> для всех. На CoW получить старое состояние файла в случае "не прокатило" в принципе можно и без такой порнографии. Но тут смотря что программы делали. > как журналирование от этого поможет? Если журналить данные - можно либо завершить ту запись, либо отбросить, смотря успело ли намерение попасть в журнал. А если только метаданные журналились - вот тут уже без шансов, потребных данных просто нет нигде. И будет файл с обломаной на середине записью, понятно насколько юзабельный. > В лучшем случае оно позволит избежать последствий reordering, когда мы писали-писали, решили > что дописали, и поставили себе пометку transaction finished. Если в момент краха запись обрубилась на середине - без журналирования данных это вообще совсем невозможно сделать чем-то консистентным применительно к данным. А в cow что, просто проигнорил последние потуги - и вот вам ваш файл, хоть и старый, но по крайней мере, читаемый и понимаемый. > Но головки стояли близко к журналу транзакций, и далеко от данных - поэтому система > оптимизировала запись, первым записав что поближе, и тут ой, kernel panic. Ну во первых, если мухлевать в журналировании - то какой с него потом толк? Во вторых, случае CoW все будет несколько иначе. Там по сути достаточно отбросить то что не получилось, старое состояние не испорчено и будет просто немного более старое но корректное представление. Ясен фиг это все с точностью до сисколов конкретными прогами, идиотничать можно всегда. Но вот видимо это самое и вынуждает СУБД делать себе логику журналирования самим, целиком, от и до. Их такой расклад явно не устроит же. > journaled fs при этом не пометит запись состоявшейся уже на своем уровне > - и при накате журнала запишет и данные, и метку заново, приведя все в консистентное состояние. Есть только 1 нюанс: писать данные сперва в журнал, потом в основную область означает ДВЕ записи данных. Скорость записи получается никакой. Поэтому этим режимом в EXT4 редко пользуются. А любимый шапкин XFS так, вроде, до сих пор не умеет. Зато умеет нули к файлам дописывать, походу. И таки до сих пор кажись какие-то остатки этого есть, я такой файлик видел, он не протерт конечно, но хвост из лишних нулей веселый :D. > Поэтому никто с journal=data и не хочет иметь дел. Блин спасибо кэп. Собственно поэтому CoW и придумали. > Вот журналирующая CoW или log-structured (что совсем не то же самое) fs - поможет. Вероятно, есть бесконечное количество способов сделать одно и то же по общему смыслу. > Но опять же такой потерей производительности именно для субд > - что все наизобретали костылей и подпорок, чтобы этот CoW для > них выключать или хотя бы свести к минимуму. Потому что в результате получается нечто типа "двойного журналирования", логика тамошнего журнала на CoW неудобно кладется и фрагментами забивается все просто в хлам. И вариантов в общем то два: либо попросить CoW отвалить и оставить файл "in place" (btrfs так умеет), либо отдать ФС журналирование (но где для этого стандартная семантика и сисколы?). Собственно оракл с самого начала и хотел in-place файлы в btrfs (nodatacow) для своих баз, чего ж еще. > - в случае как минимум mysql(innodb)+zfs не работает, данные первращаются в > тыкву. Причины никому неизвестны и разбираться - героев не нашлось. Думаю что они не полностью корректно смогли изобразить файлухой журнал. Это не просто и подразумевает кучу допущений, при том что удобного и стандартного способа пока вроде бы и нету. Хоть я и не понимаю чему противоречит next-gen семантика под CoW, позволяющая явно запрашивать у ФС услуги журналирования в желаемом виде (впрочем, ниоткуда не следует что ФС это хорошо сделает для БД, СУБД может позволить себе больше специализации).
	Ответить | Правка | Наверх | Cообщить модератору

	225. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 29-Май-20, 13:47
	> На CoW получить старое состояние файла в случае "не прокатило" в принципе можно и без такой порнографии. Но тут смотря что программы делали. CoW это метод оптимизации использования носителя, он не избавляет от необходимости делать новый файл с последующей подменой. Тем более для общего случая CoW вреден т.к. новый файл может измениться радикально для CoW. >  И будет файл с обломаной на середине записью, понятно насколько юзабельный. Это может быть в любом случае, нельзя изменить любой файл за один write(...) с логом в ФС.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (-), 30-Май-20, 09:20
	> CoW это метод оптимизации использования носителя, он не избавляет от необходимости делать > новый файл с последующей подменой. А вообще мог бы. В том плане что либо программа завершает запись и получает файл в новом состоянии, либо файл остается в его предыдущем виде. И это как раз эквивалент полного журналирования. Только без тормозов от двукратной записи. > Тем более для общего случая CoW вреден т.к. новый файл может измениться радикально для CoW. Это неверное утверждение. CoW - "другой по свойствам". При "радикальном изменении" это не такая уж проблема: в лучшем случае файл быренько 1 куском выжмется в новый extent, желательно непрерывный. На него "переназначат указатели" со старого, грубо говоря, и дело в шляпе. Это само по себе и быстро, и не имеет причин плохо работать, и совсем не портит предыдущий вариант файла на случай если что-то все же пошло не так. Так что это полный журнал со скоростью записи как без журнала вообще. Всегда есть и прошлый вид на который можно отмотать и новый. А когда-нибудь потом GC, конечно, освободит неиспользуемые блоки старого вида файла, чтобы место не кончилось. Реальные проблемы для CoW являет именно случай типа СУБД, с мелким inplace патчингом кусочков. В долговременном плане при активной записи это ведет к куче мелких фрагментиков делаемых "сбоку" по всему диску и огромному объему метаданных для описания этого. Поэтому оракл и хотел отключку CoW - для своих баз, они получат in-place представление, cow не будет фрагменты фигачить, а журнал оно себе само и делало по жизни. > Это может быть в любом случае, нельзя изменить любой файл за один > write(...) с логом в ФС. В случае CoW все иначе. Старое состояние уже есть, его не надо делать и на него можно вернуться, просто игноря вон те изменения. Write() записывает блоки куда-то в сторону - и не портит старое состояние. Если все это получилось, метаданные апдейтятся чтобы указывать уже на новые блоки (это быстро). Конкретно btrfs делает этот номер еще и с самими метаданными, поэтому в нем то же самое касается и метаданных. В случае краха достаточно забить на свежезаписанные куски - и ВНЕЗАПНО получается предыдущее состояние и данных и метаданных. Логически корректное. А то что это журналинг с совсем другого бока - ух ты, а так можно было.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 30-Май-20, 16:14
	Не мог бы. Даже для такого варианта в ФС нужно заводить какой-нибудь теневой inode для удержания нового состояния, но в отличие от файла для работы с 'тенью' нужны отельные сущности внутри ФС и API. Хватит графоманить.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 29-Май-20, 16:11
	> На CoW получить старое состояние файла в случае "не прокатило" вопрос что такое старое состояние в случае begin; set sum=sum-b where id='c'; set sum=sum+b where id='d'; commit; выполнившегося примерно на 2/3. И не останешься ли ты при этом без денег, при том что d их так и не получил. fs при этом консистентна, предположим. Файл читается (то есть внутри не появилась пачка нулей просто так, потому что блок распределили а записать его не успели - это вот то от чего гарантирует CoW и не помогает журнал только метаданных). Просто вторая операция недовыполнилась и CoW остановилась на полдороге. > Если журналить данные - можно либо завершить ту запись, fs ничего не знает о "той" или "не той". Вот сколько в том примере выше записей? Без знания структуры файла и насколько далеко в нем лежат нужные куски? Правильный ответ - а хз! fs можно что-то подсказать только сделав fsync - но это медленно. > Есть только 1 нюанс: писать данные сперва в журнал, потом в основную область означает ДВЕ > записи данных. да. Причем первая запись еще и синхронная, с ожиданием подтверждения. И любая обеспечивающая транзакционную целостность субд - так и делает. double write, fsync. CoW в ней при этом может и не быть, данные могут заменяться in-place, индексы могут при крэше портиться и требовать хитрых процедур восстановления, но вот лог транзакции сохраняется целиком и она не подтвердится пока не будет сохранена. А для fs это просто lseek/write/lseek/write - и она не знает, это одна транзакция или две разные. Или половина одной, и сейчас еще два таких приедут. Вообще в другой файл, потому что у нас sharding ;-) > Думаю что они не полностью корректно смогли изобразить файлухой журнал. там идея что оно при нормальной эксплуатации глючит. Без крэшей - просто данные портятся. А хз почему. Вероятнее всего проблема где-то в mysql, этот режим работы просто никто не тестирует. Поэтому идея sqlite с rename (который почти всегда атомарный) на самом деле не так уж ужасно плоха, пока записей не слишком много. Гарантированно работает в любой системе вплоть до msdos.
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	238. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (215), 30-Май-20, 10:08
	> begin; set sum=sum-b where id='c'; set sum=sum+b where id='d'; commit; выполнившегося примерно По логике вещей: старое состояние - то что было до begin. Новое - то что должно стать после commit. Если удалось закрыть commit - все получают что прописано. Если не удалось, все возвращается в вид как было до этого - и должно быть переделано еще раз на других уровнях. В этом вроде бы весь пойнт транзакционной модели - и само по себе это может быть уложено в логику CoW. Другое дело что не факт что general purpose CoW будет сильно оптимален для конкретного кейса в вон той СУБД, но вообще, вывесить семантику CoW юзермоду более явно таки напрашивается, а дальше пусть они сами смотрят, ОК им оно или все-же свой самопал лучше. > fs при этом консистентна, предположим. Файл читается (то есть внутри не появилась > пачка нулей просто так, потому что блок распределили а записать его > не успели - это вот то от чего гарантирует CoW CoW сам по себе может гарантировать, что либо тот write завершен полностью как задумано, либо откачен целиком как будто его никогда не было. А так что он на середине встрял и в этот момент все фигакнулось - в CoW по логике при нормальной реализации исключено. А в ext4 без полного журнала есть файл где write дошел до середины, все упало - и после краха у ФС нет данных ни чтобы обломаную запись откатить, ни чтобы ее доделать. На то и журнал только метаданных. Оно при этом логически консистентно по описанию файла в метаданных, но содержимое файла некорректное и программы совершенно не обязаны его понять. Удачи декодировать жыпег состоящий из старой и новой половинки. Скорее всего получишь характерный вид: полфоты + инопланетный пейзаж на второй половине, или даже "decode error". > и не помогает журнал только метаданных). А при чем тут CoW? Это описание для обычного in-place патчинга. > Просто вторая операция недовыполнилась и CoW остановилась на полдороге. Если операций несколько - это уже другой вопрос. А если одна - атомарный подход все же возможен. И вот тут оно не может на полдороги встрять - незавершенная запись будет просто отброшена. И наверное лучше получить либо старый, либо новый жыпег, а не похабное нечто с половиной нового и трэшом от decode error в второй половине. > fs ничего не знает о "той" или "не той". Почему, для 1 сискола - знает. А если программа делала 20 сисколов ... эм... чего я там говорил про API для вывешивания CoW семантики? Ну, в общем, логично было бы вывесить им условные "transaction_begin()" и "transaction_commit()" чтобы они не изобретали подобные велики через задний проход с дикими костылями. На CoW это можно нормально сделать. > fs можно что-то подсказать только сделав fsync - но это медленно. Это сравнительно медленно, НО гарантирует целостность. А все это + записать 2 раза, в журнал и основную область крупные объемы еще медленнее. > да. Причем первая запись еще и синхронная, с ожиданием подтверждения. Абстракция такая. > И любая обеспечивающая транзакционную целостность субд - так и делает. Версионирующие и т.п. штуки могут до какой-то степени обойти этот момент используя CoW. Как минимум, им не надо сохранять данные которые они меняют чтобы иметь возможность откатиться. > восстановления, но вот лог транзакции сохраняется целиком и она не подтвердится > пока не будет сохранена. Смотря кто и что понимает под "логом транзакции". Формальное намерение чего хотели сделать - одно. Все перетряхиваемые "блоки" (rows, columns, ...) - совсем другое. У CoW техник их плюс в том что не надо париться насчет старого состояния, оно остается "нахаляву" и на него можно вернуться. А вот если это in place, там уже про халяву речь не пойдет, придется явно писать undo для всего что вообще затронуто. Ну или как это откатывать, just in case? > А для fs это просто lseek/write/lseek/write - и она не знает, это > одна транзакция или две разные. Да я намекал что из CoW можно сравнимую семантику нативно вывесить программам, не для СУБД, а вообще, для файловых операций. Забив на те адовы эрзац костыли с переименовкой и проч. Ну то-есть, пакетный манагер мог бы как-то так: transaction_begin(); write(file1); write(file2); write(file3); transaction_commit(); ...и при этом у нас либо система с старым пакетом, либо система с новым пакетом, но никогда не система с полураспакованным пакетом. В принципе, снапшотами + хуками пакетника даже можно изобразить такую семантику. Но нативный апи в ос был бы определенно надежнее, быстрее и лучше чем самопальные костыли. > этот режим работы просто никто не тестирует. Вполне вероятно. Потому что по состоянию на сейчас это как-то довольно экзотично звучит. > Поэтому идея sqlite с rename (который почти всегда атомарный) на самом деле > не так уж ужасно плоха, Да это не только их идея. Так вроде даже transmission файло пишет. Потому что юзеры заколебали "вай-вай, статус торента профакался при крахе!!!111". Однако сие приводит к куче журнальной логики и костылей в каждой уважающей себя апликухе и странным результатам у тех кому было впадлу столько чудес самим кодить или они просто не парились. > Гарантированно работает в любой системе вплоть до msdos. А также гарантирует дофейхоа побочного кода не относящегося в общем то к делу. Это сойдет для СУБД, но когда этим начинает заниматься даже качалка торентов или офисный пакет - это, наверное, уже перебор и по хорошему надо выкинуть скелеты из шкафов пересмотреть семантику операций.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 30-Май-20, 12:21
	> По логике вещей: старое состояние - то что было до begin. Новое - то что должно стать после > commit. Если удалось закрыть commit проблема в том, что файловая система про это ничего не знает. Для нее (если бд просто косплеит sed, не добавляя собственные костыли и подпорки) это два последовательных write в разные места файла. (или двух разных, это тоже неизвестно) Она не знает - будет за ними еще третий или четвертый, отдельны они от тех или их надо выполнять все сразу. Может только подождать их, на всякий случай, задержав операцию - если только специально не мешать. Она может их переупорядочить, записав сначала второй потому что уже работала с соседним сектором по другой задаче. Ни cow, ни журнал тут не помогут - они работают на уровне блоков. Для "обычной" работы с файлами на это можно наплевать, просто гарантировать консистентность fs (не файла) при любых условиях, и файла - после подтвержденного закрытия или при работе в append-only mode. (если мы потеряли или повредили редактируемый файл - это то чего и следовало ожидать, ничего страшного в этом нет) Но для БД это фатально. Единственный вариант - выносить транзакции на уровень fs. Но в posix такого не предусмотрено.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от Аноним (250), 30-Май-20, 22:58
	> проблема в том, что файловая система про это ничего не знает. Ну вот я не вижу причин по которым нельзя было бы информировать ее немного больше - сделав апи за пределами классического, под семантику CoW. Ну и я не понимаю переклин на БД. У них в конечном итоге свой журнал есть. Однако требовать от каждой программы того же самого все же бред. > Ни cow, ни журнал тут не помогут - они работают на уровне блоков. В конечном итоге все работает на уровне блоков. По другому блочные устройства просто не понимают. > повредили редактируемый файл - это то чего и следовало ожидать, ничего > страшного в этом нет) Ага, только он читаться чего доброго перестанет если программа не вкостылила явно "safe rewrite" с переименованием. > Единственный вариант - выносить транзакции на уровень fs. Но в posix такого > не предусмотрено. Ну да. Однако на cow семантика позволяющая его юзать для чего-то такого - напрашивается.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 29-Май-20, 13:40
	Это не для СУБД. Простая задача: нужно вставить строчку в текстовый конфиг не испортив конфиг при всех возможных сценариях работы вставки. Для in-place операции нужно переписать часть файла - от вставляемой строчки и до конца. Если операция оборвётся до завершения, то файл может остаться в невалидном состоянии. Единственное решение это написать рядом новый файл и подменить им старый. Практически никакие форматы данных не поддерживают атомарные in-place изменения, известные исключения это записть в конец лога и файлы данных СУБД. Ниакие фичи ФС (журналирование данных, CoW...) не решают проблему, некоторые пользователи выше написали кучу ерунды на этот счёт.
	Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

	227. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от пох. (?), 29-Май-20, 16:18
	> Практически никакие форматы данных не поддерживают атомарные in-place изменения, известные > исключения это записть в конец лога и файлы данных СУБД. у СУБД ровно те же проблемы. Ей не надо переписывать весь файл, но ей надо изменить его сразу в нескольких местах (и еще пяток других файлов, если индексы лежат где-то отдельно). Причем, в отличие от конфига, места для второй копии этого файла может вообще не быть на диске. Фичи fs тут не то что не решают проблему, а создают новые.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 29-Май-20, 17:33
	У полноценной СУБД с in-place модификацией такой проблемы нет ибо форматы файлов данных и протокол использования позволяют определить и откатить неполные изменения. Есть СУБД без in-place операций с пеписыванием файлов данных, для этого всего лишь достаточно делать мн-во небольших файлов. По сути в СУБД первого типа тоже нет in-place модификаций, внутри всё равно делают копии кусков данных с заменой ссылок на новые блоки.
	Ответить | Правка | Наверх | Cообщить модератору

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

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