The OpenNET Project / Index page

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



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

Оглавление

Разработчики ядра Linux обсуждают возможность удаления ReiserFS, opennews (??), 23-Фев-22, (0) [смотреть все]

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


3. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +18 +/
Сообщение от Аноним (3), 23-Фев-22, 20:04 
Да дело даже не в журналировании.

Когда появилась reiserfs была в основном ext2 - с безумным временем на e2fsck. Reiser проверялся в секунды.

Плюс, reiser умел паковать мелкие файлы и значительно уменьшать занимаемое место - в 2022 это уже никому не надо, потому что storage дешёвый.

// b.

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

50. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +8 +/
Сообщение от rm2email (?), 23-Фев-22, 22:04 
> Reiser проверялся в секунды.

Ну только, поговаривают, если вам не повезло, и на ReiserFS у вас хранился образ другого раздела ReiserFS в виде файла-образа, сохранённого dd, то fsck мог вам сделать монстра-франкенштейна, сшив из двух этих ФС одну.

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

69. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +2 +/
Сообщение от Аноним (69), 23-Фев-22, 23:47 
Да он походу и в других может, похоже валидация довольно слабая и "мы вам сделали спагетти из ваших данных, но это не баг". Можете купить коммерческие услуги восстановления у namesys, если они это еще продают. Круто же, зачем чинить fsck если это новых клиентов приводит... в отдел data recovery =). Они явно смотрели скруджа, серию где соленые печеньки нашару, а если вас сушняк долбит - вот чудный лимонад, всего по баксу за стакан :)
Ответить | Правка | Наверх | Cообщить модератору

95. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +8 +/
Сообщение от Аноним (95), 24-Фев-22, 01:40 
> fsck мог вам сделать монстра-франкенштейна, сшив из двух этих ФС одну.

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

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

97. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  –3 +/
Сообщение от Аноним (-), 24-Фев-22, 01:53 
1) Им это сильно реже требуется, если пользоваться btrfs с использованием головного мозга.
2) С них бывает реально выцепить данные офлайн читалкой без монтирования.

Остальные в таких ситуациях как правило еще хуже, поскольку не имеют запасных парашютов на такие оказии и если fsck сделал не то что хотелось - ну, блин, упс. Конечно есть способы с ним подружиться, положив _образ_ на btrfs, сделав рефлинк и прогнав fsck на нем уже... но это уже data recovery как бы.

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

104. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +5 +/
Сообщение от i (??), 24-Фев-22, 03:00 
> если пользоваться btrfs с использованием головного мозга

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

> С них бывает реально выцепить

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

> Остальные в таких ситуациях как правило еще хуже

Хуже бтрфс не встречал.

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

107. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +2 +/
Сообщение от Аноним (-), 24-Фев-22, 03:22 
> А че бы не хранить данные на голом диске, просто помнить смещения файлов, заодно и память прокачается.

Круто, FAT изобрели. Только есть нюансы. Файлы могут дозаписывать, а свободное место вот прямо тут - может быть, а может нет. И эффективно обтяпать одно только это уже становится интересной проблемой. А так то если разобраться, в ФС нет никакой черной магии.

Btrfs в этом интересен
1) Чексумами, так что мы знаем корректно блок прочелся или нам дрянь сгрузили/железо сбоит.
2) Гибким управлением пространством. Можно доткнуть диск без запар с размерами, выравниванием и проч и получить +N места. Удобно. А можно его и вынуть, если место на удвигание данных с изымаемого девайса есть.
3) Недеструктивная запись и снапшоты. Поэтому с одной стороны оно довольно неплохо переживает крахи, с другой можно рулить железку почти как VM - а CoW делает возможным множественные ссылки на одни блоки, это эффективно.

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

Ну это уже какая-то экзотика. Может кто-то сильно резвый время комитов транзакций в полчаса ввинтил? Шаловливые ручки штука такая...

>> Остальные в таких ситуациях как правило еще хуже
> Хуже бтрфс не встречал.

А в каких ситуациях и с кем сравнивалось? Вон тот btrfs например прекрасно живет на сыпучей флешке, если DUP использовать. Матерится, но - все читается. Удачи так вообще с чем-нибудь еще, оно там развалится в момент.

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

215. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 24-Фев-22, 20:28 
> Может кто-то сильно резвый время комитов т

Диск по юсб, 4тб, 3.5" вынутый из коробки с новыми серверными винтами, за минуту до начала копирования отформатированный в дефолт, сбой юсб, или свет моргнул, мне до звезды факт есть факт, несколько часов копирования, а результат 0.

> Вон тот btrfs например прекрасно живет на сыпучей флешке, если DUP использовать. Матерится, но - все читается.

Плавали, знаем, года полтора пытался бтрфс на хранилище дома юсбовом опять же, 100% времени оно синхронизировалось.

> 2) Гибким управлением пространством

Ну давай, удиви меня, у тебя 2 диска, несколько разделов, условно важные в зеркале, и не важные в linear, (Это решика на своей гибкой)  и тут тебе принесли кучу данных, которые надо скопировать себе, а потом перезалить на источник, ну логично удалить зеркала с нетаких уж и важных разделов, поюзать место, а потом ресильверить обратно, ну..я готов удивляться.


> 3) Недеструктивная запись и снапшоты.

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

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

> А в каких ситуациях и с кем сравнивалось?

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

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

221. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +1 +/
Сообщение от Аноним (-), 24-Фев-22, 21:56 
> Диск по юсб, 4тб, 3.5" вынутый из коробки с новыми серверными винтами,
> за минуту до начала копирования отформатированный в дефолт, сбой юсб, или
> свет моргнул, мне до звезды факт есть факт, несколько часов копирования, а результат 0.

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

> Плавали, знаем, года полтора пытался бтрфс на хранилище дома юсбовом опять же,
> 100% времени оно синхронизировалось.

Плавали, знаем, у таких потом оказывается какой-нибудь перегретый чипарь в usb коробке, про@#$%ывающий половину команд. Или винч которому например питания не хватило (для серверного винта в коробке вообще не удивительно) - так что винч вообще с ума сходит. И мегаодмин которое дмесг не читает и поэтому не знает какой там трешак творился пока оно "файло копировало". А чо, гуй же рисовал?!!!111

> ну..я готов удивляться.

Ты по моему готов фигурно по#%^%ться. C чисто практической точки зрения:
1) на btrfs на...й не надо разделы. От них только сложности.
2) можно рестрайп на другой уровень, как полный так и частичный - ему нормально если половина данных SINGLE, а половина RAID-1. Прекрасно жрет полуконверченое комбо, у меня питалово слетало при рестрайпе (попробуй так с твоим райдом и похвастай как тебе оно?). Так что экстренно выкроить эн места ребалансом в другой уровень - можно, внезапно.
3) Можно пнуть ребаланс чтобы форсировать конверсию целиком (если не доедет до конца не страшно, можно возобновить или стопнуть).
4) Есть soft-режим, когда операция завершается сразу, изменение будет применено только к новым записям. Так даже можно извратиться - и СМЕНИТЬ СХЕМУ ХРАНЕНИЯ ВОН ТЕМ ФАЙЛАМ. Пофайлово, гуле. А слабо так на твоем райде? Ну а чо, если я знаю inner working механики, я его могу довольно интересно изогнуть :)
5) Все это будет довольно ненапряжной и фоновой серией команд. Файлы останутся доступны в ходе этой операции.

Так что можно временно ребаланс data, RAID1 -> (SINGLE, soft) потом файлманагером подвинуть "неценные" файлы, они сдуются вдвое (SINGLE же) и как места станет достаточно - ну и нормально. Акуле, зная механику можно ее очень осмысленно пилотировать куда надо. Это закат солнца вручную компенсирующий неумение аллокатора это выбирать самому (вообще, его хотят научить такому) но работает же, и нигде не вылезает за допущения механики, данный дизайн сам по себе позволяет произвольную смесь RAIDов, хоть пофайлово выбираемо в принципе.

Бонусом, если при большом перетрясе что-то будет не идеально и у нас все же хватало ума medatada=dup всегда и везде, ну, э, что ваш RAID сделает если под метаданными ФС бэд при активном двигании обнаружится? А, смачный бдыщ файлухи? Потому что там даже неизвестно какая копия райда верная, если это не IO ERROR а прочлось что-то? Так SSD, флехи и проч особенно любят делать, видимо считая что если FEC не справился, лучше отгрузать "что есть" а не "io error" :)

> Бэкап - акт трусости, жил без этого, и както научились данные структурировать,

Смотрите, дети: это будущий клиент data recovery лабы! :D. Он, просто пока еще не знает сколько это ему стоить будет, если его файлы ему нужны.

> сколько лет обещат поддержку сабволумов.

Чо? Сабволумы в бтрфс есть .... с момента ее создания?! А виртуалку логично апдейтить 1 раз в template и из него рефлинками заново VM развернуть, займет мизер времени.

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

Я наверное тупой но не понял о чем это. У кого были ресурсы? И чего нету? У бтрфсников сабволумы есть. Более того - без них не было бы снапшотов, технически снапшот то же что и subvolume. Точка входа. Иерархия с shared блоками. Крутой вариант директории. Редхат вообще btrfs активно не разрабатывал. И так то от них свалил даже Басик, последний из грандов. Он терь тоже бтрфс пилит, хоть и раздражает редхатными (анти)паттернами малость но вообще адекватный крутой тип, редхат просто дурно на девовскую психику влияет. А что там за брахмапутры в редхате xfs пилят пусть пох расскажет :)

>> А в каких ситуациях и с кем сравнивалось?
> Выжигание рака ионизирующим излучением - это очень плохой способ лечения,

А софистика - плохой способ ведения дискуссии.

> - сырая глюкота, спустя многие годы деланья не знаю чего,

Да нормальная она. Даже уже для довольно странных вещей. И про глюкоту рассказывают обычно какие-то, хм, очень характерные эксперты. Которые такое ощущение что даже на картинке его если и видели, то в 2.6.какомтамего.

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

А у меня нет особых оснований редхату верить. Хотя бы потому что его уже больше нет, ибм его съел. ИБМ вообще довольно странная фирма с своими приколами. А доверять в вопросах блочно-фсных дел я буду все же мировым именам, которые делом доказали уровень. И я не знаю вроде бы уже никого такого в редхате на данный момент. Все видные фигуры блочно-ФСных дел оттуда как-то устранились. А в безымянных саппортов и их помощь с сложными блочно-ФСовыми делами я не верю, сорян. Если там у кого контракт на сапорт с редгадом они пусть и взаимодействуют с брахмапутрами. Мне такое и нашару то не надо, я с экспертами тусить люблю, это делает меня умнее и мощнее.

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

237. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от i (??), 25-Фев-22, 05:27 
> можно рестрайп на другой уровень, как полный так и частичный

В мануале бтрфс это есть? что вообще за поток сознания, такое ощущение, что мы говорим о разных вещах,.. читать списки рассылок, и выковыривать какието фичи из каких-то левых источников, ну, занимайтесь, мне не интересно.

> Сабволумы в бтрфс есть

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

> оказывается какой-нибудь перегретый чипарь в usb коробке

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

> Смотрите, дети: это будущий клиент data recovery лабы

ванга? ручку позолотить?

за 20 лет практики никогда ничего не терял, 1 раз музло пропало, 60Гб в 2014 кажись, винт умер, ну ок, бывает.

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

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

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

238. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от i (??), 25-Фев-22, 05:32 
>  выковыривать какието фичи из каких-то левых источников, ну, занимайтесь, мне не интересно.

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

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

248. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  –1 +/
Сообщение от Аноним (-), 25-Фев-22, 15:53 
> Когдато очень давно, я занимался портированием сабжа для новых ядер, лет 15-20
> назад, я был студентом и райзер вглядел очень круто, но я наигрался.
> теперь у меня другие игрушки, и возня с фс более не занимает.

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

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

254. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 25-Фев-22, 19:07 
> квалификацией эникея

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

> а играть теперь будем мы

А это отвага чистой воды

Ну так вперед на барикады, или убьетесь или поумнеете.

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

259. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 26-Фев-22, 16:56 
> строить догадки основываясь ниначем - это слабоумие.

Вы достаточно на форуме высказались для некоторых экстраполяций. И это, два ника - раздвоение личности? Или попытка выглядеть за двоих? Дело в том что 2 дуболома не убедительнее чем 1.

> А это отвага чистой воды

Совсем уж без этого мы бы FAT16 до сих пор пользовались. ЗАТОНАДЕЖНО!!!111

> Ну так вперед на барикады, или убьетесь или поумнеете.

ОТОЖ. Пока вроде all systems operational, так что...

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

263. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 27-Фев-22, 04:46 
У вас и достаточнометр есть? однако

> Или попытка выглядеть

Так вышло, ваше мнение яйца не стоит выединого

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

265. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 22:09 
> Так вышло, ваше мнение яйца не стоит выединого

Чего-чего? У вас кончился единый? :)

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

245. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 25-Фев-22, 14:05 
> В мануале бтрфс это есть? что вообще за поток сознания, такое ощущение,
> что мы говорим о разных вещах,.. читать списки рассылок, и выковыривать
> какието фичи из каких-то левых источников, ну, занимайтесь, мне не интересно.

А мне не интересно заниматься сложным, склонным к урыванию данных порно с разделами и рестрайпом райдов. Занимает уйму времени, стремная и неудобная операция, с кучей дурных ограничений. Технологии эпохи MSDOS.

В любом случае я сказал как сделать сравнимый фокус btrfs'ной механикой. Технически оно попроще и поприятнее чем у вас, да и операции менее стремные в целом, пожалуй.

И вы таки не расскажете что будет с вашим райдом если при рестрайпе питание слетит? Я вот с бтр потестил случайно. На удивление культурно оказалось.

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

Это такие очень мощные и клевые CoW-папочки. А если имелось в виду сделать подобие блочного уровня из этого - нафига? Чтобы простой и приятный менеджмент ФС стал опять вон тем миндфаком с разделами, выравниваниями и сложным ресайзом? Ну спасибо.

> У меня сейчас на столе рабочем лежит с десяток винтов с разными
> проблемами, которые вынули из ceph,

Это прекрасно, но не про конкретную коробку, винч и как это работало на практике. А диагностика вида "толи усб отпал, толи свет мигнул, виноват точно бтрфс" - доверия не внушает. По общему уровню анализа проблемы.

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

Круто, кроме того что я не понимаю пойнт этих сведений. Это не про тот конфиг и не про то что там случилось.

> железо сбойное, к ext никаких претензий.

Зато к нему кой-какие претензии у меня, когда системы после 1-2 рандомных бэдов полный unbootable и это становится моей проблемой. Он довольно легко мрет при небольших повреждениях, и это может быть для меня проблемой.

> А вот бтр на нулячем диске, в идеальных условиях потерял
> данные, опять же выяснять обстоятельства, мне не интересно.

Что-то почему-то сдохло но виноват бтр, выяснять не будем. Оок!

> ванга? ручку позолотить?

Лучше придержи золотишко - датареки жадные.

> за 20 лет практики никогда ничего не терял, 1 раз музло пропало,
> 60Гб в 2014 кажись, винт умер, ну ок, бывает.

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

> гдето сжатие использую, на лог сервере - красота, но бтру даже
> с зеркалами я чтото ценное не доверю.

Хызы, ворочает мои рабочие проекты. Это не отменяет бэкапов. Не потому что btrfs, а потому что случаи разные бывают. Ну вон пыхнет питальник и пожжет все диски сразу, допустим. Тогда чего?

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

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

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

256. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 25-Фев-22, 20:50 
> В любом случае я сказал как сделать сравнимый фокус btrfs'ной

Я бы не сказал, что сказал

> если при рестрайпе питание слетит

Не слетит, там много аккумов

> Это такие очень мощные и клевые CoW-папочки

Оверлайфс это заменяет, костыльно, но из слоистой фс тоже можно извлечь профит.

> А диагностика вида "толи усб

в 100500 раз, - аппаратура впорядке, значит косяк в ПО, и то что он вылез на пустом месте о чем-то да говорит.

> Что-то почему-то сдохло но виноват бтр,

Не что-то, а бтр, не почемуто, а в типовом кейсе.

> выяснять не будем. Оок!

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

> А более умный народ так то за рабочие проекты кошелек готов открыть серьезно

фейспалм, продолбать данные = более умные, ты серьезно?

> Ну вон пыхнет питальник и пожжет все диски сразу,

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

> И выбирая между долботней самому или более сложной жизнью у аллокатора и механики ФС

Чем больше внедорожник, тем дальше бежать за трактором, идеальный алгоритм, который на 100% гарантирует что ты не потеряешь данные , это не иметь данных. а уж в какую сторону грести, чтобы иметь и не потерять - каждый сам выбирает, я не заморачивался на дисках, после того как электрики однажды ночью сожгли комп, я заморачивался на "бесперебойку", и это работает, - 4 часа держит, и это только половина батареек.

> склонным к урыванию данных порно с разделами и рестрайпом райдов

порно?

> Занимает уйму времени
> стремная и неудобная операция
> с кучей дурных ограничений.
> Технологии эпохи MSDOS.

lvm то?

нет, нет, нет и нет

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

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

260. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 26-Фев-22, 18:05 
> Я бы не сказал, что сказал

Тем не менее, оно сработает. Но если хочется покривляться и рассказать какие все лохи то конечно.

> Не слетит, там много аккумов

Мелко плаваете - надо резервные генераторы требовать. В обязаловку, со всех. Иначе недостаточно энтерпрайзно. А я буду считать что если работает и без этого, то это плюс технологии. Ну например вон той пачке дисков на рестрайп аккумуляторов многовато надо, такая инсталляция не бесплатная совсем.

> Оверлайфс это заменяет, костыльно, но из слоистой фс тоже можно извлечь профит.

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

Ну там например трахотня редгада с транзакциями в пакетнике. А можно вот вместо этого оверинженернутого порева снапшот сделать перед операцией. Куда радикальнее, проще, быстрее и лучше работает. Не разваливаясь как редгатские базы пакетника. В смысле, откат снапшота и разваленую базу заодно обратно вернет, даже если ей и настал пиндык. А без этого юзеры редгада познают всю прелесть их вебманков кодивших пакетник на своей шкуре когда база разлетается и оно ни вперед, ни назад. Чудо технологии - созданы для поха и вас :)

> в 100500 раз, - аппаратура впорядке,

Пруфов данного заявления или какой либо диагностики предоставлено не было, зато сделаны далеко идущие выводы, неизвестно на чем. Делать такие выводы можно хотя-бы дмесг зазырив после инцидента, как и счетчики read/write errors, btrfs по этой части злопамятный, подсвечивает гадов, если знать куда смотреть, удобно так то, глюкожелеза поотловилось... :)

> значит косяк в ПО, и то что он вылез на пустом месте о чем-то да говорит.

Никаких анализов, доказательств, примем на веру что железо исправное, обвиним софт. Круто, да.

> Не что-то, а бтр, не почемуто, а в типовом кейсе.

Изначальное описание на вот это вот - не сильно на именно это похоже. А более технических деталей предоставлено не было.

> А что выяснять? перекомпилировать модуль ядра в режиме полной отладки и 2
> месяца разгребать логи, мне за это не платят.

1) Что железо и правда - исправное. Ну, не факт это. Я тоже думал что некоторыые вещи исправные, пока CSUM error at XXX в репу не получал.
2) Снятие скелетона структуры ФС без включения данных не требует дебажных фич, а все кому интересно смогут пофтыкать на это и попробовать понять в чем было дело.

> фейспалм, продолбать данные = более умные, ты серьезно?

И на старуху бывает проруха. Сущствование датарекавери лаб намекает что шит хэпенс.

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

FAIL, лолка! Я не только учебники читал, уже умею дизайнить подобные вещицы слегка, с выбором топологии, обсчетом, подбором компонентов и проч. Могу краш курс дать про азы, типовые топологии и проч, но это такой мет бисера... =)

А кто там чо не пожжот - вон фирменный, кондовый, красава. А дыру в чипсете таки сделал. Взял да и дал 8 вольт в дежурку. Одно деграднуло, второе сработало частично, предохранителем, вот, чипсет 200-баксовой мамки стал. Шыт хэпенс.

> Чем больше внедорожник, тем дальше бежать за трактором, идеальный алгоритм, который на
> 100% гарантирует что ты не потеряешь данные , это не иметь данных.

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

> и это работает, - 4 часа держит, и это только половина батареек.

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

> порно?

А как еще назвать все эти танцы вокруг разделов, выравниваний, размеров и проч?

>> Технологии эпохи MSDOS.
> lvm то?

И он в частности. По многим аспектам, особенно управлению всем этим.

> во всяком случае не стремнее бтр, а ограничений куда меньше,

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

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

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

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

262. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 27-Фев-22, 04:38 
> Тем не менее, оно сработает.

Просто слова

> Но если хочется покривляться и рассказать какие все лохи то конечно.

А вы чем занимаетесь? с оборотами типа "у таких как вы"

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

> А как еще назвать все эти танцы вокруг разделов, выравниваний, размеров и проч?

Я вообще беспонятия о чем вы говорите, какие выравнивания.

> Сущствование датарекавери лаб намекает что шит хэпенс.

Эмм, существуют больнички, сушествуют сервисные центры по ремонту тех или иных категорий, ничто не вечно.

> Пруфов данного заявления или какой либо диагностики предоставлено не было, зато сделаны далеко идущие выводы

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

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

266. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 22:20 
> Просто слова

Их несложно проверить.

> А вы чем занимаетесь? с оборотами типа "у таких как вы"

Капитаню.

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

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

> Я вообще беспонятия о чем вы говорите, какие выравнивания.

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

> Эмм, существуют больнички, сушествуют сервисные центры по ремонту тех или иных категорий,
> ничто не вечно.

Оно как бы да, но вот именно дата рекавери за свои услуги - дерут. А куда вы денетесь с подводной лодки? Попробуете сэкономить - распращаетесь с данными навсегда.

> Ты купил на рынке семки, грыз и тебе попалась щепка, ты пожал
> плечами и сказал коллегам на работе что у той бабке на рынке семки так себе,

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

> не проверял ежеминутно целостность пакета. ну и как к этому относится?
> тем более тут все анонимы, и отличить сильно буйных от умеренных проблематично.

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

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

142. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +1 +/
Сообщение от kusb (?), 24-Фев-22, 10:28 
Уже думал об этом. Но если файл один, то можно просто записывать его на раздел или устройство cat > устройство
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

162. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 13:34 
> Уже думал об этом. Но если файл один, то можно просто записывать
> его на раздел или устройство cat > устройство

Так то блочное устройство - типа файл, но когда файл всего один это ... довольно ограниченный сценарий. Некоторые так и делают, типа некоторых БД. Но админить это потом несколько неудобно.

Даже бэкап этого сделать и не лохануться - уже интересно станет. А дифференциальный бэкап и быстро, без скана по всей площади - слабо?! Или вы однажды познаете всю прелесть скана вон тех 100500 терабайтов при тупом подходе.

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

144. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +1 +/
Сообщение от Аноним (144), 24-Фев-22, 10:59 
>А бывает льешь на бтрфс файло, чтобы сеть не грузить подключив по юсб, херак, и 2тб волшебным образом исчезло.

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

>Хуже бтрфс не встречал

Прокладку поменяй - между табуреткой и монитором.

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

163. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 13:35 
> Так размонтировать надо для начала, а потом уже усб-диск выдергивать.

Если этот чудак делал имнено это - слет одного файла не так уж плохо. Так и вся флеха может сдохнуть. Вплоть до таблиц трансляции, после чего она либо дохлая, либо очень интересно выглядящие файлы выдает. Как живые, только с содержимым что-то очень сильно не то.

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

212. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 24-Фев-22, 20:03 
в 2022 году фс умирает от того что ее не отмонтировали, это нормально?

там четко было написано что диск по юсб, свет моргнул и питание пропало, неужели не очевидно, что 2тб льются не 5 мин

в любом случае, - поменяй прокладку, это моветон.

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

220. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 21:13 
> в 2022 году фс умирает от того что ее не отмонтировали, это нормально?

1) Где тот субъект сказал что у него ФС умерла?
2) При сдергивании флешки без размонтирования умереть могут даже внутренние таблицы трансляции этой дряни. После чего там вообще что угодно может быть, от красивой зебры из файлов где блоки перемешаны как будто файлы засунули в блендер, до трупика который не определяется или детектится в сервисном режиме контроллера. Кто виноват что фирмварь встроеного контролера и FTL в 2022 столь же дрянные как много лет назад? Ну, вы ж все равно покупаете :)

> там четко было написано что диск по юсб, свет моргнул и питание
> пропало, неужели не очевидно, что 2тб льются не 5 мин

Совершенно ничего не говорит о характере разрушений. Вон юзер $100 у дата рекавери оставил недавно, сдернул флешку. А она - упс, совсем тыква. ФС? Фат обычный. Только ФС похрен, если трансляция слетела, ни одна ФС не готова к перетасовке блоков наобум, это beyond design для любой.

> в любом случае, - поменяй прокладку, это моветон.

По-моему он прав. Но можете и не менять, лабы по дата рекавери тоже жрать хотят.

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

243. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 25-Фев-22, 12:57 
> При сдергивании флешки без размонтирования умереть могут даже внутренние таблицы трансляции этой дряни

Даже метеорит может на голову упасть, так что теперь в каске ходить?

> По-моему он прав.

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

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

246. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 25-Фев-22, 14:25 
> Даже метеорит может на голову упасть, так что теперь в каске ходить?

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

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

Кто и где говорил про "умерла ФС"? Вроде речь шла что какой-то файл продолбался, при мутных обстоятельствах, на которые мы диагностику не увидим из-за высокого профессионализма спеца, зато "логичный" вывод что виноват совершенно точно бтрфс. Мне в этой логике кое-что кажется странным.

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

253. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 25-Фев-22, 18:53 
> Вроде речь шла что какой-то файл

Нет.

> з-за высокого профессионализма спеца

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

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

267. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 01-Мрт-22, 22:22 
> пох..ма, но ваша отвага защищать грааль, даже "при мутных обстоятельствах, " достойна
> какойнибудь премии, дарвина)

Эта отвага распостряняется чуть дальше и приводит к активному экстерминатусу багов. Мне так больше нравится.

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

177. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 15:30 
> А че бы не хранить данные на голом диске, просто помнить смещения
> файлов, заодно и память прокачается.

Попробуй этот номер для 500 000 000 файлов сделать для разнообразия. И как тебе парсинг 500 000 000 записей чтобы даже вообще просто найти нужный файл? :)

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

211. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 24-Фев-22, 20:00 
https://ru.wikipedia.org/wiki/%D0%A1%D0%...

Попробуй научиться понимать человеческую речь

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

222. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 22:06 
Если это была попытка потроллить то получилось довольно бездарно.
Ответить | Правка | Наверх | Cообщить модератору

244. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 25-Фев-22, 13:00 
Воспринимать очевидную чушь серьезно - это дар?

>  Если это была попытка потроллить то получилось довольно бездарно.

Не тебе судить

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

255. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 25-Фев-22, 19:07 
> Воспринимать очевидную чушь серьезно - это дар?

Вам виднее: от вас тут вообще ни 1 полезного или информативного сообщения.

> Не тебе судить

Надо же, у троллины подгорело от непризнания таланта.

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

257. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от fg (??), 25-Фев-22, 20:55 
> Надо же, у троллины подгорело от непризнания таланта.

Ох, да если бы

> Вам виднее: от вас тут вообще ни 1 полезного или информативного сообщения.

А ты, блин, информативнометр сертифицированный не иначе

Грех на вентилятор не накинуть

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

57. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +7 +/
Сообщение от Аноним (-), 23-Фев-22, 23:02 
> Плюс, reiser умел паковать мелкие файлы и значительно уменьшать занимаемое место -
> в 2022 это уже никому не надо, потому что storage дешёвый.

На SSD с их ценой за гиг это и сейчас не лишне. К тому же немедленно прочесть файло сразу при лукапе "прям тут" может быть быстрее, чем еще куда-то за тем блоком отдельно соваться, так блок уже в page cache может висеть, а если это что-то отдельное, за ним надо отдельно слазить еще. Так что некоторые типа btrfs и сейчас это делают. Хорошо работает с кучей мелочи.

А так рейзер еще умеет своим fsck разносить диски вдрызг и вместо починки - ВОТ ВАМ СЮРПРИЗ. Notabug - подумал Штир^W Шишкин.

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

72. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +3 +/
Сообщение от Аноним (72), 23-Фев-22, 23:53 
Сколько раз приходилось при починке перестраивать дерево, всегда успешно. Ни одного разнесения вдрызг не зафиксировано.
Ответить | Правка | Наверх | Cообщить модератору

78. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 00:14 
> Сколько раз приходилось при починке перестраивать дерево, всегда успешно. Ни одного разнесения
> вдрызг не зафиксировано.

Авторы amule имели немного другой testimonial на этот счет. Озвученый довольно громко и публично. И они такие не одни на виду.

Типичная картина - Readonly FS -> fsck -> F$CK IT!!!!1111. Может бэды какие вылезают а оно ну вообще совсем никак если метаданные попорчены "неожиданным" образом, или черт их знает. Факт в том что на этот случай запасного плана вообще нет - и он иногда, таки, наступает. А сейчас как-то в целом придумано ряд фокусов чтобы такие фокусы несколько меньше имели мозг. Типа DUP метаданных в btrfs даже на 1-дисковой конфиге, так что даже если какое-то г случится, во всяком случае хотя-бы метаданные будут живые и урон будет весьма лимитирован а восстановление полным или почти полным, по числу бэдов. Шанс что бэд накроет 2 логические копии одного смещения в 2 физических адресах довольно маленький, и это явно лучше чем просто раздристаная ФС на первом бэдсекторе. Тем более что ссдшники очень любят так прикалываться. Х вам радости с скорости если потом при первом отклонении от идеала фаталити норовит вылезти?

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

65. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +3 +/
Сообщение от Аноним (72), 23-Фев-22, 23:37 
>Плюс, reiser умел паковать мелкие файлы и значительно уменьшать занимаемое место - в 2022 это уже никому не надо, потому что storage дешёвый.

Вот за это я её везде и использую. И что, что storage дешёвый, зачем тратить его бездарно?

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

180. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Всем Анонимам Аноним (?), 24-Фев-22, 15:48 
во-первых, вообще-то другие файловые системы тоже это могут уже.
во-вторых, "необдуманная оптимизация - корень всего зла"
Ответить | Правка | Наверх | Cообщить модератору

127. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +7 +/
Сообщение от Тот_Самый_Анонимус (?), 24-Фев-22, 06:37 
>в 2022 это уже никому не надо, потому что storage дешёвый

Аргумент мyдаков. Оптимизации на то и оптимизации, что позволяют обойтись без лишних ресурсов. Ну а то, что что-то сегодня дешёво, не говорит о том что так будет вечно. Эра дешёвых энергоресурсов заканчивается, и такие дешёвые понторезы, которые «могут себе позволить в 2022 году» будут идти на спад.

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

128. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от tty0 (?), 24-Фев-22, 08:50 
Почему сразу мудаки, вроде вероятно, рациональное использование дисков и памяти вообще отрицательно скажутся на доходах индивида. Может он продавка или программист, работающий с данными и прекрасно понимает, что хорошо не писать код не сможет. Это называется мудрость.
Ответить | Правка | Наверх | Cообщить модератору

149. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (149), 24-Фев-22, 12:41 
>Почему сразу

Потому что.

>рациональное использование дисков и памяти вообще отрицательно скажутся на доходах индивида

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

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

164. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 13:40 
Варианты разные бывают. Иногда и чисто технические. Скажем на современных быстрых сторажах - вам круто будет, если вы сэкономили крохи места, зато получили скорость записи в четверть от того что скоростное устройство умело, например? Ну там лишние действия CPU по сбору крох, вот, все нагнули в несколько раз. Это абстрактно и может и не быть именно таким tradeoff, просто иллюстрация что это - возможно.

Ну да, вам с дедушкиной берданкой^W винчестером может и похрен. А вон тому датацентру?

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

239. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +1 +/
Сообщение от Тот_Самый_Анонимус (?), 25-Фев-22, 07:31 
> Почему сразу мудаки

Хм... Давайте подумаем.

>отрицательно скажутся на доходах индивида.

Да вот почему. Вы приводите аргумент наркоторговцев: их волнует только свой доход, а то, что этим наносится вред обществу, не волнует совсем.

Так что «му» это мyдачество, а не мудрость.

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

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

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




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

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