The OpenNET Project / Index page

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



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

Оглавление

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

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


30. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +3 +/
Сообщение от пох. (?), 23-Фев-22, 20:53 
> И что? Оно сломалось?

ДА. stable api nonsense ломал и ломает что попало.
А автор сидит пожизненно и не бежит срочно переписывать на более модные и новые апи или как-то учиться обходиться вообще без.

> Слышали про "Работает - не трогай"? Это идеально подходит к миру софта.

вот и сиди на своем 2.6.16
Правда, оно не работает с современным железом.

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

81. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  –1 +/
Сообщение от Аноним (-), 24-Фев-22, 00:27 
> ДА. stable api nonsense ломал и ломает что попало.

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

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

Новые модные апи имеют тенденцию нефиогово подразгонять IO что стало довольно актуально. Почему-то.

> Правда, оно не работает с современным железом.

Ну, не работает NVME диск - вы и мозги не придете грызть. Поставите механический IDEшный, хватит с вас. Можно подумать кому-то надо вам IOPSы насильно улучшать.

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

87. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +1 +/
Сообщение от Hck3r (?), 24-Фев-22, 00:52 
Читали тред в твиттере чуваков, которые Линукс на маковский чип М1 портируют, которые нашли хаки в МакОСи чтобы «винты» эпловские быстро работали?
Убирают проверки.. и выигрывают на этом :)
Ответить | Правка | Наверх | Cообщить модератору

90. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 01:20 
> Читали тред в твиттере чуваков, которые Линукс на маковский чип М1 портируют,
> которые нашли хаки в МакОСи чтобы «винты» эпловские быстро работали?
> Убирают проверки.. и выигрывают на этом :)

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

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

126. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +2 +/
Сообщение от bOOster (ok), 24-Фев-22, 06:21 
Ну да, какое откровение, признавать что в Linux долгосрочное планирование/проектирование архитектуры системы отсутствует от слова совсем.
Под девиз - "Раз,два - кружева. Три, четыре - прицепили.", -"мы наш мы новый мир построим, кто был ничем - тот станет всем."
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

173. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  –2 +/
Сообщение от Аноним (-), 24-Фев-22, 15:08 
Довольно мудрый инженерный принцип гласит что проблемы стоит решать по мере их поступления. В этом есть своя мудрость. Попытки делать излишне концептуально, общо, предугадывать вдолгую и проч имеют свойство проваливаться, когда наступившее будушее оказывается не таким как его себе представляли, в концепции и абстракции не лезет, а что теперь делать - вообще не понятно.

В этом плане эмпирический и итеративный подход может оказаться лучше. Еще несколько лет назад по сути ни 1 ФС не занималась проблемой что стораж оказывается может быть такой быстрый что CPU не успевает данные готовить. Традиционно сторажи сильно отставали от CPU. А тут, вот, производители SSD с цепи сорвались, людям надоело тормозное IO - и они сделали IO которое не тормозное!

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

194. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от bOOster (ok), 24-Фев-22, 16:50 
> Довольно мудрый инженерный принцип гласит что проблемы стоит решать по мере их
> поступления. В этом есть своя мудрость. Попытки делать излишне концептуально, общо,
> предугадывать вдолгую и проч имеют свойство проваливаться, когда наступившее будушее оказывается
> не таким как его себе представляли, в концепции и абстракции не
> лезет, а что теперь делать - вообще не понятно.

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

> В этом плане эмпирический и итеративный подход может оказаться лучше. Еще несколько
> лет назад по сути ни 1 ФС не занималась проблемой что
> стораж оказывается может быть такой быстрый что CPU не успевает данные
> готовить. Традиционно сторажи сильно отставали от CPU. А тут, вот, производители
> SSD с цепи сорвались, людям надоело тормозное IO - и они
> сделали IO которое не тормозное!

20 лет назад была сформирована файловая система FreeBSD 5.0 как она сейчас есть - в основном GEOM, и о чудо она до сих пор актуальна, в рабочем состоянии ДЛЯ ЛЮБЫХ носителей в том числе и SSD, конечно минорно модернизируется но ей уже 20 лет и никто не жалуется, система работает.
И, например, разработчики решения, обсуждаемые в другой теме о TrueNAS SCALE говорят об этом. В кратце "Нам не нужно рвать ..опу чтобы поддерживать версию для FreeBSD в актуальном состоянии, чего нельзя сказать о Linux - и они ожидают что максимально потраченное (SPENT) время будет именно на проект для Linux". Тут обращу внимание на глагол EFFORTS SPENT - обычно он означает потраченные усилия в пустую.  

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

208. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 19:26 
> Это не инженерный принцип, это принцип неудачника.

Мощное обоснование, но глядя на то чем стали Торвальдс и его операционка, а чем Таненбаум и его операционка, я, пожалуй, потусую с "неудачниками". Мне так больше нравится.

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

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

> 20 лет назад была сформирована файловая система FreeBSD 5.0 как она сейчас
> есть - в основном GEOM, и о чудо она до сих пор актуальна,

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

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

> в рабочем состоянии ДЛЯ ЛЮБЫХ носителей в том числе и SSD, конечно минорно
> модернизируется но ей уже 20 лет и никто не жалуется, система работает.

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

> - и они ожидают что максимально потраченное (SPENT) время будет именно на проект для Linux".

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

> Тут обращу внимание на глагол EFFORTS SPENT - обычно он означает потраченные усилия в пустую.

Двойка за знание инглиша. Он означает лишь потраченные усилия (ресурсы) но ничего не говорит о том какой эффект это возымело. Может быть что угодно от EPIC FAIL до EPIC WIN.

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

214. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от bOOster (ok), 24-Фев-22, 20:15 
>> Это не инженерный принцип, это принцип неудачника.
> Мощное обоснование, но глядя на то чем стали Торвальдс и его операционка,
> а чем Таненбаум и его операционка, я, пожалуй, потусую с "неудачниками".
> Мне так больше нравится.

Ну точно, 3.5% это выдающееся достижение и конечно не сравнится даже с 9.5% для той же MacOSX c FreeBSD изначально. И не нужно говорить что Macosx это не FreeBSD, это не так, снаружи они отличаются, но внутри - все очень даже похоже. К чему это я, а да - Джобс прагматик и изучал системы прежде чем делать свой NextStep и присоединяться к неудачникам во время ковыряния в "помойном ведре" он очень не хотел.

>[оверквотинг удален]
> Кому она актуальна - тот пускай этим и пользуется. Я для себя
> btrfs предпочитаю. Потому что вон там он делает вон те выводки
> систем надежнее. А вот тут я снапошотиками щелкаю, как будто это
> виртуалочка, только оно железка. А тут, вот, выводочек виртуалок гигов так
> на эн клонируется "мгновенно". А вон там я могу без запары
> еще пару дисков подоткнуть и мне еще эн места прибавляется. Удобно,
> ниипет. А еще я знаю где живые девы этой штуки обитают,
> и если лыжи все же оказываются на асфальте, это довольно быстро
> и эффективно решаемо. Можете ли вы похвастать тем же - интересно,
> да.

Ты забыл что btrfs это просто жалкое поделие, жалкая копия на текущий момент по сравнению с ZFS которая была спроектирована Sun Microsystems с оглядкой на свой многодесятилетний опыт и в котором они заглядывали весьма далеко вперед планируя ее.
> Работать можно по разному. Я не хочу работать с эффективностью 20-летней давности,
> с тех пор было придумано много эффективных технологий.

Если что, то операционной системе ZFS с которой пытаются скопировать твой идеал btrfs уже 18 лет. Ты не знал? Так что ты даже до эффективности 18 летней давности со своей корявой в целом и не пригодной для продуктива - btrfs не дорос.. :)))


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

225. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от Аноним (-), 24-Фев-22, 23:32 
> Ну точно, 3.5% это выдающееся достижение и конечно не сравнится даже с
> 9.5% для той же MacOSX c FreeBSD изначально.

1) Я не понимаю пойнт этого аргумента. Сферические проценты в вакууме должны мне греть душу? И даже, вроде, пох оценивал линуксоидов в 8-10%, чтоли, они просто технически продвинутые и срезают или меняют юзерагент, юзают адблокеры и проч. Или я с кем то путаю.
2) Макось - у эппла. Я не акционер фирмы и никогда не буду им: мне нравится культура кооперации и коллаборации, а не потребления и п0нта. Это не мой путь.
3) Фрибсд и ее процесс дева меня не возбуждают. Мне не нравятся отношения master-slave с проприетарщиками. Особенно в роли slave. Примерно туда же и как там его, дарвин, чтоли.
4) Чисто технически для меня лучше всего модульный конструктор. Из него я соберу все что мне будет нужно. Для себя и окружающих, for fun and profit. Линукс - оно. Позволяет сделать что задумано, не мешается в процессе. А целостная операционка где кто-то знает лучше что мне "нужно" - создает мне массу проблем. Я лучше знаю что мне надо в системном образе и почему. Когда кто-то пытается стоять на этом пути это создает мне неудобства и раздражает.

> И не нужно говорить что Macosx это не FreeBSD, это не так, снаружи они
> отличаются, но внутри - все очень даже похоже.

Внутри это очень разные вещи и ядро макоси - основано на Darwin. Это не является полностью опенсорсным и достаточно гибким для меня и того что я хочу уметь, и я предпочту не иметь никаких дел с фирмой практикующей DRM, secureboot, аппстор и прочие загородки. Такие "благодетели" на мою бошку мне не нужны. И лучшее что я могу это развидеть это. Мои системы подчиняются мне. Я системшик, по другому мне не катит.

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

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

> Ты забыл что btrfs это просто жалкое поделие, жалкая копия на текущий
> момент по сравнению с ZFS которая была спроектирована Sun Microsystems с
> оглядкой на свой многодесятилетний опыт и в котором они заглядывали весьма
> далеко вперед планируя ее.

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

> Если что, то операционной системе ZFS с которой пытаются скопировать твой идеал
> btrfs уже 18 лет. Ты не знал?

А рефлинки она так и не умеет вроде. Что довольно тупо для COW, но, вот, однако. И управление девайсами в бтрфс мне нравится. Взял да воткнул что есть. Без мыла в ж с поиском "точно такого же" или складированием запаса, пусть энтерпрайзники так #%^тся.

> Так что ты даже до эффективности 18 летней давности со своей корявой в целом и
> не пригодной для продуктива - btrfs не дорос.. :)))

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

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

195. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от bOOster (ok), 24-Фев-22, 16:50 
> Довольно мудрый инженерный принцип гласит что проблемы стоит решать по мере их
> поступления. В этом есть своя мудрость. Попытки делать излишне концептуально, общо,
> предугадывать вдолгую и проч имеют свойство проваливаться, когда наступившее будушее оказывается
> не таким как его себе представляли, в концепции и абстракции не
> лезет, а что теперь делать - вообще не понятно.

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

> В этом плане эмпирический и итеративный подход может оказаться лучше. Еще несколько
> лет назад по сути ни 1 ФС не занималась проблемой что
> стораж оказывается может быть такой быстрый что CPU не успевает данные
> готовить. Традиционно сторажи сильно отставали от CPU. А тут, вот, производители
> SSD с цепи сорвались, людям надоело тормозное IO - и они
> сделали IO которое не тормозное!

20 лет назад была сформирована файловая система FreeBSD 5.0 как она сейчас есть - в основном GEOM, и о чудо она до сих пор актуальна, в рабочем состоянии ДЛЯ ЛЮБЫХ носителей в том числе и SSD, конечно минорно модернизируется но ей уже 20 лет и никто не жалуется, система работает.
И, например, разработчики решения, обсуждаемые в другой теме о TrueNAS SCALE говорят об этом. В кратце "Нам не нужно рвать ..опу чтобы поддерживать версию для FreeBSD в актуальном состоянии, чего нельзя сказать о Linux - и они ожидают что максимально потраченное (SPENT) время будет именно на проект для Linux". Тут обращу внимание на глагол EFFORTS SPENT - обычно он означает потраченные усилия в пустую.  

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

199. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от пох. (?), 24-Фев-22, 16:57 
> Довольно мудрый инженерный принцип гласит что проблемы стоит решать по мере их
> поступления.

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

> лет назад по сути ни 1 ФС не занималась проблемой что
> стораж оказывается может быть такой быстрый что CPU не успевает данные

потому что ежу понятно что не нужно в такие стораджи лезть с традиционными fs (а если уж лезешь - не рассчитывать на максимум производительности)

> готовить. Традиционно сторажи сильно отставали от CPU. А тут, вот, производители
> SSD с цепи сорвались, людям надоело тормозное IO - и они
> сделали IO которое не тормозное!

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

Теперь оно одинаково хреново работает и на spinning rust (который от нас никуда не денется потому что супернанофлэши по прежнему супермалоемки) и на флэшах мапящихся напрямую на адресное пространство. Так победим!

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

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

Изначально у кучки студаков не было такого знания вообще. Они делали ad-hoc. А потом... потом у него был жирный плюс: не особо мешался если переделать хочется.

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

> потому что ежу понятно что не нужно в такие стораджи лезть с
> традиционными fs (а если уж лезешь - не рассчитывать на максимум производительности)

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

> ни разу. Они срезали сразу кучу углов, чтобы получить "нетормозное" - и
> внезапно оказалось, ну кто бы мог подумать, что традиционные fs специально
> оптимизированные для совсем другого железа, для этого не совсем подходят.

Они просто деланы в эпоху когда CPU был много быстрее IO поэтому по оверхеду на стороне CPU не очень парились. А тут, вот, быстрое IO завезли - стало парить.

И вон тот Кент - он так то сразу прочухал, мол, а что если сделать как бтр, только еще быстрее, чтоб оверхеда меньше?! Btrfs то не может сильно поменять формат - старый все равно жрать надо, совсем разные форматы парсить это как 2 драйвера в одном, поэтому сильно переиграть - проблемно. Хотя "v2" экстентов - вон он. Просто менее радикальный.

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

Мир довольно сложная штука а у решений есть как плюсы так и минусы. Из очевидных плюсов, от вон того курса выиграют не только узкоспециализированные чуваки но и остальные, прибавляет желающих со всеми этим по...ся. Я бы не помог им загасить пару багов если бы это было только на энтерпрайзной мегахне за $XXXXX которой у меня не оказалось под рукой. И такой экзот обречен быть довольно паршиво протестированым. Вам впервой чтоли, на энтерпрайз кастомерах ключевые подсистемы затестите, с вас станется. Не будете же вы все ворклоады эмулировать и все странные вещи которые юзеры вытворяют опробовать, право? Значит их найдут вон те энтерпрайзные кастомеры. Это по своему мило, но они вас за это почему-то очень хотят послать потом.

> Теперь оно одинаково хреново работает и на spinning rust (который от нас
> никуда не денется потому что супернанофлэши по прежнему супермалоемки) и на
> флэшах мапящихся напрямую на адресное пространство. Так победим!

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

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

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

216. "Разработчики ядра Linux обсуждают возможность удаления Reise..."  +/
Сообщение от пох. (?), 24-Фев-22, 20:29 
> Попробуй так с вон теми, с этим их геомом и чего там у них.

у них там вот - geom. Понадобился - запилили. А до того не было никакого геома.

И возможно не будет упирания в проц на модных nvme кстати (благо там все гораздо примитивнее, никакого пятикратного копирования буфера в памяти туда-сюда). Ну да, zfs на нем не взлетит, ну так и не была предназначена.

> Или эффективные технологии вообще совсем не про них?

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

> Или девайс без заморочек подоткнуть как в btrfs - чо, концептуалы, смогете? Идея так то крутая

сразу как только btrfs смогет в raid6 не превращаемый в кашу сам по себе, без всяких на ходу девайс. Потому что у них там zfs именно в такой позе чаще всего используется. Ну, где надо на ходу (а правда очень надо-то?) - там приходится nway-mirror. Новый n-way - да, можешь на ходу подоткнуть. (Always have been) Насчет отключить - учоные спорят. Поскольку "экспедиции неизменно заканчиваются катастрофой", владельцы реальных пулов их отстреливают на подходах.

А так-то теоретически фича уже почти допилена (да, опять iX). Только вот ТОЙ zfs лично я пользоваться не планирую - это будет код еще более омерзительный.

> Из очевидных плюсов, от вон того курса выиграют не только узкоспециализированные чуваки но и
> остальные

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

Не, ну кто понастроил хранилок на голом linoopsе сам конечно виноват. Я пока не вижу проблем с теми экспериментальными бриками что на ntfs. (3g, конечно, у меня не linux-next ведро) Вероятно это и будет моей fs будущего. refs я как-то пока побаиваюсь, в виду отсутствия систематических знаний и опыта применения десятилетиями.

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

ну вон там полный интернет восторгов от чувака, померявшего zfs без компресси и с zstd.
Я даже не видел смысла комментировать что дорогой чувак, все бы хорошо, если бы ты хоть немного знал СКОЛЬКО у тебя в системе там изуродовано под ту компрессию. И становится просто неэффективно если ее выключить.

Тем более что пользы от этого знания - никакой. compressed arc и abd scatter я могу отключить (и отключаю, поскольку знаю про deadlock), но это только по верхам. Там перепахано столько, что это уже не исправить. Только наслаждаться.

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

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

Да они много чего странного делают. Вопрос в том зачем все это великолепие мне и что оно такого ценного даст кроме гемора и RTFMов. Для себя я решил что хочу менеджить девайсы btrfs'ном стиле, вон, Кенту идея тоже вштырила, правильный кент.

> И возможно не будет упирания в проц на модных nvme кстати (благо
> там все гораздо примитивнее, никакого пятикратного копирования буфера в памяти туда-сюда).

1) Это не та штука где джентльменам верят на слово.
2) Можете показать как вы те MIOPS/Core натянули, желательно с сабмитом хотя-бы бенча в фороникс для сравнения. А лучше если они на тех железках затестят.
3) Заодно можете рассказать как все это ваше хозяйство отетется к ситуации когда протертый или сдуревший SSDшник резко выгрузил какой-то трэшак размером с eraseblock под метаданные ФС...

> Ну да, zfs на нем не взлетит, ну так и не была предназначена.

И чего на нем юзать? Вон то ufs? Данунафиг. Если мне захочется потр@$%^ься с чем-то крутым и новым, это будет bcachefs. Потому что это будущее. А ufs - прошлое. Окаменелое.

> это не эффективная технология, а костыль для докера в докере коекакеров.

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

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

Зато это понятие имею я и без этой фичи мне как-то уже не айс.

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

Оно как бы да, но вообще довольно странно уметь COW но при этом не уметь это. Это лишь частный случай COW. Дьявольски логичный. И более потребный в применении чем онлайн дедуп дико жрущий ресурсы.

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

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

> Новый n-way - да, можешь на ходу подоткнуть. (Always have been)

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

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

А я так с btrfs делал, нифига ему не было.

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

Судя по активным комитам в чертову кучу всего - быстрые SSD'шники все же берут свое...

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

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

> если бы ты хоть немного знал СКОЛЬКО у тебя в системе там изуродовано под ту
> компрессию. И становится просто неэффективно если ее выключить.

А в btrfs для него ничего особо не уродовали вроде, просто i++'й алго, из апи линухкернела берется. А так алго хорошее. Особенно на x86-64.

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

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

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

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

тебе - низачем. Продолжай петь песни про швятую btrfs.

> Это не та штука где джентльменам верят на слово.

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

> Можете показать как вы те MIOPS/Core натянули, желательно с сабмитом хотя-бы бенча в фороникс

лолшта?

> для сравнения

с их высосанными из пальца псевдотестами? У меня в жизни есть других задач.

> Заодно можете рассказать как все это ваше хозяйство отетется к ситуации когда протертый или
> сдуревший SSDшник резко выгрузил какой-то трэшак размером с eraseblock под метаданные ФС...

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

> А еще я не хочу делать мозг размерами, выравниваниями и прочим.

ну значит получи свой 128x write amplification вместо 32 который у твоей любимой fs есть всегда.

> А я так с btrfs делал, нифига ему не было.

это потому что ценного там у тебя нет ничего. А было бы - ты бы так не делал.
Прекрасно понимая что может и не повезти.

> Судя по активным комитам в чертову кучу всего - быстрые SSD'шники все же берут свое...

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

> А в btrfs для него ничего особо не уродовали вроде

так она урод от рождения.
Да, в том числе - намертво завязанный на косяки одного вечнокривого ведра с его stable nonsense.

Собственно, zfs уже пришла к тому же самому. Поэтому очень конечно хорошо что при отключении сжатия все начинает тормозить, но мне бы вернуть ту, прежнюю.

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

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

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

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

Оно как бы да, но все же.

> лолшта?

Ну того. Посмотреть синтетику на тему оверхеда.

> с их высосанными из пальца псевдотестами? У меня в жизни есть других задач.

Да axboe вроде налег на нормальный кейс, минимизацию оверхеда и разгон достижимых IOPS. Понятно что синтетика, но от такой активности понемногу выиграет наверное почти все.

> у меня нет таких ssdшников и не будет.

Тебе вендырье докладывать будет чего там их фирмваре вытворять умеет?

> Вероятнее всего они либо только в сферическом вакууме вообще существуют, либо это
> те самые, за которыми проц не успевает - "могу и 1000 знаков, но такая хеpня,
> такая хеpня получается..."

Часть протерлись, часть с сглючившим фирмваре наверное. Одна из фич btrfs - из за чексум они по крайней мере помогают понять что за нахрен. С другими фс вычислить глючного гада сложнее, диагностика и проявление сильно варьируется смотря куда попало. В бтрфс оно может выглядеть как внезапный CSUM ERROR на каком-нибудь блоке, не так уж редко даже с метаданными (там DUP бывает, тогда CORRECTED и пациент еще побегает).

> ну значит получи свой 128x write amplification вместо 32 который у твоей любимой fs есть всегда.

Откуда в cow по типа btrfs с delalloc и не слишком частыми коммитами такой фактор? Хотя если по 1 байту и fsync делать, там наверное и больше можно, но кто так делает? Сам по себе cow более-менее придерживаюший и группирующий записи довольно удобная для FTL штука. И чисто статистически оно довольно недурно смотрится вроде. Ну да, он пожирнее EXT4 немного, но на типовых вещах разница выглядит не ужасно. Вполне вменяемое поведение в обычных ситуациях.

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

1) Ценное таки забэкапано. Снапшоты, райды и проч не замена бэкапа.
2) "Свою" механику и ее свойства и лимиты нехило знать. И лучше обломаться в контролируемом окружении на чем-то умеренно ценном чем когда оно тебя эвона как, со всей дури, в ценном боевом окружении, когда оно меньше всего надо.

> Прекрасно понимая что может и не повезти.

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

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

Всемирный заговор по улучшению линуха? Ну, ок, наконец то полезный заговор к которому я присоединюсь :)

> так она урод от рождения.

Я бы сказал наоборот.

> Да, в том числе - намертво завязанный на косяки одного вечнокривого ведра с его stable nonsense.

Не, надо было сделать генерик выб#$%дка неизвестно зачем испортив параметры и фичи. Тем не менее, в винде кто-то драйвер даже накорябал. Не то чтобы полный и проч, но там у них вообще кактусы, ReFS хомякам майки так то поперекрыли, а уровень технологий из 90х все же нравится не всем.

> Собственно, zfs уже пришла к тому же самому. Поэтому очень конечно хорошо
> что при отключении сжатия все начинает тормозить, но мне бы вернуть ту, прежнюю.

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

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

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

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




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

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