The OpenNET Project / Index page

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



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

Оглавление

Релиз ядра Linux 6.7, opennews (?), 08-Янв-24, (0) [смотреть все]

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


87. "Релиз ядра Linux 6.7"  +3 +/
Сообщение от Аноним (87), 08-Янв-24, 15:44 
> В общем в этом релизе файлухи были в ударе.

зачем они нужны, ext4 всё равно лучший выбор.

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

89. "Релиз ядра Linux 6.7"  +5 +/
Сообщение от DEF (?), 08-Янв-24, 15:51 
Для средних умов - да.
Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз ядра Linux 6.7"  +1 +/
Сообщение от Аноним (96), 08-Янв-24, 16:09 
И правильно. А гении пусть сидят и данные из бекапов восстанавливают.
Ответить | Правка | Наверх | Cообщить модератору

98. "Релиз ядра Linux 6.7"  +4 +/
Сообщение от DEF (?), 08-Янв-24, 16:20 
Данные из бэкапов ты тоже будешь восстанавливать. Если эти бэкапы у тебя, конечно же, будут.
Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз ядра Linux 6.7"  +3 +/
Сообщение от Аноним (-), 08-Янв-24, 16:34 
> И правильно. А гении пусть сидят и данные из бекапов восстанавливают.

Вообще-то это я скорее таким как ты их ext4 выковыриваю. Они до последнего уверены что там все ЗБС - поттому что ext4 на все похрен, и никаких сообщений нет, даже если накопитель стал гнать труху или железо глючит. Но вы же понимаете что в таких вопросах везение имеет свойство - заканчиваться? В какой-то момент юзер таки собирает свой джекпот. А вот бэкапы у юзеров EXT4 понятное дело обычно в том же состоянии что и ФС. Почему-то.

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

129. "Релиз ядра Linux 6.7"  –2 +/
Сообщение от Аноним (129), 08-Янв-24, 17:50 
>накопитель стал гнать труху или железо глючит

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

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

151. "Релиз ядра Linux 6.7"  –2 +/
Сообщение от Аноним (151), 08-Янв-24, 18:22 
> тотальный булшит, твои китайские флэшки не считаются -- их применение уже показательно.

Энтерпрайзные SSD тоже так умеют, проверено любителями bcache (не того который fs).

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

161. "Релиз ядра Linux 6.7"  –1 +/
Сообщение от Аноним (129), 08-Янв-24, 18:31 
Из энтерпрайзных "настоящих" ссд существует только интел. У него смарт тоже врёт? Может, это подделка была?
Ответить | Правка | Наверх | Cообщить модератору

209. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 08-Янв-24, 20:40 
> Из энтерпрайзных "настоящих" ссд существует только интел.
> У него смарт тоже врёт? Может, это подделка была?

Для меня это были юзеры (точнее, вероятно, админы, с энтерпрайзными то сетапами) встреченые на просторах интернета с проблемой "резко и внзапно сдохла ФС, наповал, что бы это могло быть?!?". Общего у всех них был - вот - bcache.

А навел на эту мысль btrfs'ник - у которого ФС "чего-то" орала в лог про csum error... corrected. Ему и сказали - чувак, меняй свой SSD вотпрямща. Иначе амба будет, как вооон тем! Заодно и тупые вопросы зачем ФС чексуммы сразу как-то вот отваливаются.

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

259. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 09-Янв-24, 01:29 
> зачем ФС чексуммы сразу как-то вот отваливаются

чтобы ентерпрайзом на аликспресс затариваться

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

334. "Релиз ядра Linux 6.7"  +/
Сообщение от specter (ok), 09-Янв-24, 18:52 
>>> Заодно и тупые вопросы зачем ФС чексуммы сразу как-то вот отваливаются.

Так в ext4 чексуммы тоже есть, вроде как

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

339. "Релиз ядра Linux 6.7"  +1 +/
Сообщение от Аноним (151), 09-Янв-24, 20:50 
>> Заодно и тупые вопросы зачем ФС чексуммы сразу как-то вот отваливаются.
> Так в ext4 чексуммы тоже есть, вроде как

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

На мой вкус это идеальный классический случай "too little and too late". Поздняк дорого

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

292. "Релиз ядра Linux 6.7"  –1 +/
Сообщение от IdeaFix (ok), 09-Янв-24, 06:30 
Интел давно не продаёт SSD и что удивительно, никогда их не производил - только ОЕМ. Оптан тут особняком стоит. На фейл с D3-4*10 я попадал лично.
Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

302. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (129), 09-Янв-24, 08:43 
Одно другому не мешает.
Ответить | Правка | Наверх | Cообщить модератору

310. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 11:52 
> Интел давно не продаёт SSD и что удивительно, никогда их не производил
> - только ОЕМ. Оптан тут особняком стоит. На фейл с D3-4*10
> я попадал лично.

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

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

316. "Релиз ядра Linux 6.7"  +/
Сообщение от IdeaFix (ok), 09-Янв-24, 12:33 
> Когда-то у интеля были SSD именно с их собственным контроллером. Но это
> было давно. И интел много лет назад взял моду менять контроллеры
> и проч без предупреждения. Под маркой интеля что угодно может быть.

У интеля и рейд-контроллеры были "с их собственным контроллером", верно? Или это был таки LSI?:) А потом еще у полмира рейд контроллеры были Intel GC80303 :)

Факт остаётся фактом, интел никогда не производил NAND SSD, которые продавал под собственным брендом. И под маркой интеля чего угодно быть не может - только SiliconMotion или лицензированные контроллеры под собственным брендом.

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

326. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 15:06 
> У интеля и рейд-контроллеры были "с их собственным контроллером", верно? Или это
> был таки LSI?:) А потом еще у полмира рейд контроллеры были Intel GC80303 :)

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

> Факт остаётся фактом, интел никогда не производил NAND SSD, которые продавал под
> собственным брендом.

Ммм... я что-то припоминаю про SATA SSD 300-й или 320-й чтоли серий которые вроде именно интелы были, в смысле, контроллер вот именно от интел. А 500-я серия и дальше - уже совсем другие чипсеты. Я что-то путаю?

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

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

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

332. "Релиз ядра Linux 6.7"  +/
Сообщение от IdeaFix (ok), 09-Янв-24, 17:32 
X25 и пр диски "первого" поколения (хмм... а ведь до DC 3500 получается первое поколение?) на PC29AS21, который лицензирован не известно у кого, но не факт что свой. Начало потребительской пятисотки - сандфорс, конец потребительской 5хх и 6хх серии - силиконмоушен. И если посмотреть сколько в мире продавалось кингстонов на PC29AS21 и в каком регионе интелы на PC29AS21 производились, то реально может оказаться всё достаточно просто. Изначально X25 так и были кеширующими SSD (вспоминаем адаптек QZ пятой серии), и их логика без сжатия и с мелким драм кешем вписывалась туда. А когда стало понятно что рынок нетбуков и им подобных несколько шире рынка адаптеков 5xxxQZ и им подобных, интел в мгновение ока превратился из фирмы в лейбу.

А сейчас под маркой интеля не бывает ничего. Интел уже очень давно (годы) не производит и достаточно давно не поддерживает nand ssd, произведенные под брендом интел.

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

226. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (226), 08-Янв-24, 22:29 
А ваш btrfs может прекрасно и полностью отличном диске/железе, так сказать на ровном месте накрытся. И как вам популярно объяснил Шишкин это by design
Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

311. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 11:54 
> А ваш btrfs может прекрасно и полностью отличном диске/железе, так сказать на
> ровном месте накрытся. И как вам популярно объяснил Шишкин это by design

Шишкин много говорит и мало делает, а когда все же делает - это синтетические corner case, которые на практике не встречаются. Поэтому ценность этого знания - как и творений шишкина - на уровне "пройдите в лес, под елку".


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

229. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (229), 08-Янв-24, 22:43 
Товарищи, вы не могли бы лаяться более аргументированно? Но сжато, конечно )
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

330. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 16:03 
> Товарищи, вы не могли бы лаяться более аргументированно? Но сжато, конечно )

TL;DR: каждый кулик хвалит свое болото. Зачастую даже не пробовав то что ругают или пробовав сто лет назад. Некоторые откровенно луддитствуют с EXT4 - хотя это архаичный кусок помета мамонта.

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

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

499. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (499), 11-Мрт-24, 23:09 
Вот за что любят русскоговорящих на планете - за их отзывчивость 😁
Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз ядра Linux 6.7"  +1 +/
Сообщение от Аноним (-), 08-Янв-24, 16:32 
>> В общем в этом релизе файлухи были в ударе.
> зачем они нужны, ext4 всё равно лучший выбор.

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

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

130. "Релиз ядра Linux 6.7"  +1 +/
Сообщение от Аноним (129), 08-Янв-24, 17:52 
чем сложнее, тем больше проблем, и тем ниже вероятность успешного их решения.
Ответить | Правка | Наверх | Cообщить модератору

153. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 08-Янв-24, 18:23 
> чем сложнее, тем больше проблем, и тем ниже вероятность успешного их решения.

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

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

163. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (129), 08-Янв-24, 18:33 
У ext4 есть хэширование метаданных. Надо просто не игнорить логи и настроить проверку смарта.
Ответить | Правка | Наверх | Cообщить модератору

210. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 08-Янв-24, 20:50 
> У ext4 есть хэширование метаданных. Надо просто не игнорить логи и настроить

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

> проверку смарта.

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

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

496. "Релиз ядра Linux 6.7"  +/
Сообщение от IdeaFix (ok), 29-Янв-24, 15:18 
>> чем сложнее, тем больше проблем, и тем ниже вероятность успешного их решения.
> Порой таки простота хуже воровства. И когда вопрос о чексумах в ФС
> - это именно тот случай. Вы узнаете о глюках железа и
> системного софта последним, когда все уже совсем в хлам.

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

Там что-то кто-то про дизайн и чексуммы говорил? Ну ок... как говорил лет 20 назад один мой знакомый, конечно же у слаквари есть пакетный менеджер и зависимости... только отслеживать их нужно вручную :)

Вот с ZFS так же... чексуммы, чексуммы... а с кешем что? И заметьте, я не говорю что ZFS плохая файловая система. И я не говорю о том что к ней на термоклей присабачено всякое, без чего она не вывозит от слова совсем (ну не было гвоздей - посадили на термоклей). Не говорю о некоторых проблемах синхронизации разваленного зеркала у которого в каждой из половинок поделали что-то. Про серьезные баги, регулярно встречающиеся в каждой из "эталонных реализаций", про моду луддитство типа "а я сижу на пуле версии X, и на XX не пойду". Зачем об этом говорить?

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

132. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 08-Янв-24, 17:55 
> без удобного расширения места подтыканием девайса

а смысл подтыкать в ту же фс, чтоб жисть мёдом не казалась когда один из них сдохнет ?

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

150. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 08-Янв-24, 18:21 
>> без удобного расширения места подтыканием девайса
> а смысл подтыкать в ту же фс, чтоб жисть мёдом не казалась
> когда один из них сдохнет ?

Если это RAID1 какой был - ну я заменю сдохшего и дело с концом. Или урежу доступое место. А вот прозрачно и без канители расширять RAID'ы используя те девайс(ы) которые есть - без траха мозга их размерами и прочим - это очень удобно и круто.

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

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

205. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 08-Янв-24, 20:18 
> Если это RAID1 какой был - ну я заменю сдохшего и дело с концом.

зачем он на ноутах ? у меня старый диск evo 860 перекочевал на новый ноут c nvme вторым диском и просто монтируется в хомяке и питание не пропадает внезапно на ноутах, может вам просто попробовать современными компьютерами пользоваться ?

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

256. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 00:55 
> зачем он на ноутах ? у меня старый диск evo 860 перекочевал
> на новый ноут c nvme вторым диском и просто монтируется в
> хомяке и питание не пропадает внезапно на ноутах, может вам просто
> попробовать современными компьютерами пользоваться ?

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

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

268. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 09-Янв-24, 02:26 
> На ноуте лично мне DUP пригодился

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

> какой-то случайный бэд под метаданными. Было всего 1 раз

на ext4 не было бы никаких бэдов

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

314. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 12:18 
>> На ноуте лично мне DUP пригодился
> я не понял чем - диск в два раза меньше стал и
> ресурс в 10 раз быстрей расходуется

Тем что я не пошел реинсталить ОС на ровном месте после разлета метаданных под фс, лол. Ресурс в сучае SSD расходуется быстрее примерно вдвое, логично. Хотя сжатие может и отыграть кой-что.

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

Heavy lifting, складирование сотен гигз и проч я на десктопе делаю с большой удобной клавой, большим и качественным IPS монитором и удобной мышой, несколькими здорованными хардами и проч. Так видео смотреть куда кайфовее и воротить ломовые объемы работ - эффективнее. А на ноуте я не делаю столько записей чтобы меня это вообще парило. Что мне там в ломовых объемах записывать постоянно?

>> какой-то случайный бэд под метаданными. Было всего 1 раз
> на ext4 не было бы никаких бэдов

Да неужели? У него особый, уличный теорвер? А те господа с развалившимся ext4 - мой глюк? Более того - на самом концептуальном уровне мне не нравится идея получить лишь репорт про CRC error в метаданных. Получил я его - и дальше например ЧТО?! Это ж не self heal как вон там...

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

318. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 09-Янв-24, 12:57 
> Тем что я не пошел реинсталить ОС на ровном месте после разлета метаданных под фс, лол.

так у тебя ошибка диска из-за того что твоя "спасающая" фс его разносит в хлам

> Ресурс в сучае SSD расходуется быстрее примерно вдвое, логично.

а земля плоская, лол, посмотри иccледования

https://arxiv.org/pdf/1707.08514.pdf

Write Amplification у btrfs в 5-8 раз больше чем у ext4. Кроме этого использование в два раза больше данных усиливает износ - контроллер диска в фоне выравнивает износ и переписывает редко используемые данные в горячие блоки для замены - чем меньше свободных блоков тем чаще ему надо перезаписывать данные.

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

328. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 09-Янв-24, 15:39 
> так у тебя ошибка диска из-за того что твоя "спасающая" фс его
> разносит в хлам

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

>> Ресурс в сучае SSD расходуется быстрее примерно вдвое, логично.
> а земля плоская, лол, посмотри иccледования
> https://arxiv.org/pdf/1707.08514.pdf

Посмотрел. Хрень с индусами, с кучей бесполезной воды. Какой из этого вывод? Очередные индусы хреначили свой master thesis или что там, как обычно написали много "умных" слов. Ни о чем. Я на подобное по части электроники уже насмотрелся и знаю ценность такого материала. ИМХО: нафиг с такой экспертизой, я в ЭТОМ не нуждаюсь.

> Write Amplification у btrfs в 5-8 раз больше чем у ext4.

Предпочитаю верить своим глазам - и статистике накопителей. И, знаете, вот там - все прилично. В плане wearout и оставшихся циклов. Так что вы и читайте свои индусские пасквили, пользуясь EXT4, если вам оно надо. Я это делать не буду. Предпочитаю более продвинутые технологии - и объективное знание состояние данных+метаданных. ПО ВСЕЙ ЮЗАЕМОЙ ПЛОЩАДИ, а не....

> Кроме этого использование в два раза больше данных усиливает износ

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

Так что лично я на EXT4 в принципе назад не собираюсь. Вот хоть как. И очень рад что кент за образец btrfs взял, так что и у него интересная штука получилась. С похожими замашками. И мне совершенно пофиг сколько в очередном мастертезисе очередные индусы про кента напишут, я пущу и его штуку в моих конфигах и сам посмотрю скорость протирания VS устраивает ли меня тренд. Это работет лучше чем выслушивание экспертов с опеннета с EXT4.

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

331. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 09-Янв-24, 16:56 
> Агаблин, в сбоях железок ФС виновата.

а как вы хотел, поддержку TRIM не зря добавили во все ФС - их проектировали ещё во времена HDD

> Предпочитаю более продвинутые технологии

вам подсунули старые обдристаные треники, а новые технологии это другие типы памяти типа nvram и эти доисторические ФС для них не актуальны

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

340. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 09-Янв-24, 21:14 
>> Агаблин, в сбоях железок ФС виновата.
> а как вы хотел, поддержку TRIM не зря добавили во все ФС

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

> - их проектировали ещё во времена HDD

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

>> Предпочитаю более продвинутые технологии
> вам подсунули старые обдристаные треники, а новые технологии это другие
> типы памяти типа nvram и эти доисторические ФС для них не актуальны

Ну вот когда эти новые типы памяти появятся на полках магазинов по суперцене, в виде девайсов, и это пойдет в массы, в эксплуатацию - тогда будет разговор. А так то NAND в целом сейчас Г конечно. Но вы ж хотели дохреналион терабайтов, быстрое, за 5 копеек?! Бойтесь своих желаний - они выполняются. Но поскольку все в этом мире tradeoff - вот вам QLC сыпящийся после ...цать циклов с мизерными ячейками, утекающими заряд, что при нужде различать 16 уровней заряда - достаточно фатально и там чуть не регенерация как DRAM уже нужна иной раз.

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

349. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (87), 09-Янв-24, 22:58 
> Ну вот когда эти новые типы памяти появятся

на брендовых ноутах btrfs и zfs только чтобы диски портить, проц тормозить и батарею деградировать ну DUP ещё чтобы деньги за полдиска выкидывать. f2fs были мысли попробовать но руки не доходят - ext4 диски не портит и надёжно летает.

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

352. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 09-Янв-24, 23:16 
> на брендовых ноутах btrfs и zfs только чтобы диски портить, проц тормозить

1) У меня вполне брендовый ноут. Это никак не отменяет теорвер VS накопители. Но вы кажется не в курсе.
2) Не надо ставить ZFS и Btrfs в один ряд. Btrfs юзается совершенно ненапряжно и на вид отличить ФС с ним от ext4 еще ухитриться надо. Не, гигазы рамы он не жрет. Живет даже на тощих виртуалках, одноплатниках и даже - роутере с 64 мегами. До кучи. Just because I can. ZFS до этого всего - как пехом до китая.

> и батарею деградировать ну DUP ещё чтобы деньги за полдиска выкидывать.

Намного лучше если у меня "в поле" хренакнется ноут, ага. И между прочим что я там записывать буду? Пару фирмварин отребилдую? Ух да, МакЛауд таки сможет протереть такими темпами SSD. А я столько не проживу. И акум так то - стареет даже если его на полочку положить. Алсо, 7 часов типовой активности для немолодого ака - по моему ЗБС. С момента покупки осталось добрых 90% емкости еще.

> f2fs были мысли попробовать но руки не доходят - ext4 диски не портит и надёжно летает.

Я уже имел с его надежностью возможность скататься в перди к кастомеру в режиме аврала когда 1 разовый бэд под EXT4 урыл систему в одноплатнике. Вот вы такой "надежностью" и наслаждайтесь! А мне такое счастье нафиг нужно.

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

337. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 09-Янв-24, 20:17 
>зачем они нужны, ext4 всё равно лучший выбор.

С нынешними объемами дисков уже не лучший выбор.Насчет контрольной суммы для данных не буду дискутировать, благо это вопрос денег- есть диски с усиленной контрольной суммой и кодами восстановления.
Но городить LVM для того чтобы изменить количество инод как то не очень.Хотя ари для сброса кол-ва инод было написано,но фичу так и не доделали,как и сжатие данных. А допустим нет у тебя на ноутбуке жёсткого диска только Флэш память - зонирование,отложенная запись, кэш и т.д вообще грустно,благо лишь Трим потдерживается.

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

353. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 09-Янв-24, 23:25 
> Хотя ари для сброса кол-ва инод было написано,но фичу так и не доделали,как и сжатие данных.

Видимо желающих гальванизировать ЗАВЕДОМО НЕПЕРСПЕКТИВНЫЙ дизайн, из которого давно выжато все что можно и даже больше - немного. Копаться в окаменелых кишках чуть ли не потомка FFS - это файлушнику надо конкретно некромансией увлекаться.

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

370. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 10-Янв-24, 07:47 
>дизайн, из которого давно выжато все что можно и даже больше - >немного.

Были желающие,но в продакшен не пошло.COW и читал 2 или 3 реализации. Один проект по динамическим инодам, реализаци с сжатием тоже до фига было. Но по разным причинам не пошло в основную сетку,в основном из за слома совместимости.

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

381. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 10-Янв-24, 12:24 
>>дизайн, из которого давно выжато все что можно и даже больше - немного.
> Были желающие,но в продакшен не пошло.

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

> COW и читал 2 или 3 реализации.
> Один проект по динамическим инодам, реализаци с сжатием тоже до фига
> было. Но по разным причинам не пошло в основную сетку, в основном
> из за слома совместимости.

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

А вон то - пример как просадить много времени с голимым результатом. Ради чего? Чтобы попсовым названием прикрыть хреновые технические свойства?

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

416. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 10-Янв-24, 21:12 
> Натягивать сову на глобус - не очень хорошая идея. Проверено XFSниками, от
> которых аж майнтайнер сдриснул.

Это сейчас очевидно что натягивание.Я помню на Райзера с его 4 столько вылили -особенно за слом классики VFS=LVM+MD+ФС . А не все хорошо оказывается когда посмотришь на исходники - надежность ext с применением LVM и MD обеспечивалось костылями, иногда жестко приваренными именно для этих режимов.Заинтересовал меня подробности одного диспута -оказывается с LVM количество инод под EXT4 можно увеличить- человек указал на системный вызов и самопальные исходники утилиты,без увеличение места можно было сбросить кэш с инодами и увеличить место резерва под них. . Кто то тогда еще в диспуте  проболтался что гугл тестировал с динамическими инодами,но так и осталось не доделанным. Я посмотрел на исходники ext4  а там оказывается костылей под логические тома с рэйдами не меряно . Куча специальных атрибутов,принудительные барьеры и т.д.

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

425. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 11-Янв-24, 00:00 
>> которых аж майнтайнер сдриснул.
> Это сейчас очевидно что натягивание. Я помню на Райзера с его 4 столько
> вылили -особенно за слом классики VFS=LVM+MD+ФС.

Вообще-то как вы могли видеть - на btrfs'ников поскрипели, но те смогли крепко аргументировать в одном месте, подвинуться в другом, резонно ожидая того же и от майнтайнеров - и оно было взято в майнлайн.

А потом пришел Кент. Он тоже смог. С одной стороны из-за btrfs вопросов меньше, с другой ему было сложнее, он склонен считать себя умной клавой. Но - он в отличие от Шишкина смог взять эффект под контроль, после того как ему жестко объяснили что кернел здоровая штука, и есть еще проблемы общей инфраструктуры, реюза кода, майнтенанса, и проч. Их standalone автору ФС не видно, но могут утопить кернел если топик игнорить. В этом месте приходится стыковать интересы и совместно нацеливаться компромисс, чтобы проект в целом все же мог существовать. VFS не лучшая подсистема на свете. У нее много легасипроблем. Но это не изменится завтра. Попытки резко все до основанья, и затем - сломают кернел как проект годный для продакшна. Сборка авто во время гонки имеет особенности. А авто которое совсем не ездит - никому не надо.

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

> А не все хорошо оказывается когда посмотришь на исходники - надежность ext
> с применением LVM и MD обеспечивалось костылями, иногда жестко приваренными
> именно для этих режимов.

Называя вещи своими именами вон то - ужастик в администрировании. Извините, но управление в btrfs на голову круче. Кент общую идею правильной аллокации места тоже уловил. И доразвил, скрестив с кешированием. Это по идее может устранить траблы bcache с тем что при кончине кеша (имеющего свойство протираться под нагрузкой) ФС часто наступает хана. Когда ФС явно трекает статус реплик по накопителям - это шоу сможет быть куда вменяемее, имхо.

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

> Заинтересовал меня подробности одного диспута -оказывается с LVM количество
> инод под EXT4 можно увеличить

Я, конечно, рад что вы смогли примотать к деревянному биплану пороховой фейерверк и получить "хрена, почти истребитель!" - но у меня звездолет с гипердрайвом уже, достижение воображение не поражает. У EXT4 дохрена и иных дурацких технических проблем. Некоторые немного подконопатили типа чексум на журнал - эталонный "too little and too late".

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

Для начала EXT4 прямо на уровне структуры - ничего интересного. И приделать туда что-то реально годное - типа чексум на все данные и метаданные, сжатие и проч - довольно душно, по сути наполовину новая ФС будет. С серьезным сломом совместимости и кучей компромиссов. Эволюция FFS-like дошла до логичного финала в EXT4. И дальше ту линию гнуть все душнее, при все более хреновом результате.

Иногда в софтострое наступает момент когда новые знания и опыт приводят к мысли что переписать эту функциональность с ноля - и быстрее, и лучше результат, чем пытаться вытянуть неподходящий старый дизайн до упора. Это досадно, но так бывает. В случае btrfs какого - возможность расширения предусмотрели сразу, ее не надо на скотч приляпывать. И bcachefs - тоже. Так что btrfs'ники - вот - могут добавить bg_tree, и никто даже и не заметит. Ну, кернелы до 6.1 будут его RO маунтить, если оно есть - потому что в compat флагах так для фичи указано. А можно и совсем фичу снести ибо по сути это кеш/индекс для block group ускоряющий монтирование до небес. И - вот - могут просто взять и просто добавить это. И никому не мешает. А в ext4... ээ... даже более хаотичный Кент усвоил что оставить в дизайне место на ненапряжное расширение в будущем - полнейший мастхэв.

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

382. "Релиз ядра Linux 6.7"  +/
Сообщение от EULA (?), 10-Янв-24, 12:34 
И когда в Ext4 появились снапшоты, сжатие, подтома, мультидевайсинг без LVM и mdraid?
ACL - не всем нужно. Особенно, если домена AD нет.
Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

418. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 10-Янв-24, 21:34 
> И когда в Ext4 появились снапшоты, сжатие, подтома, мультидевайсинг без LVM и
> mdraid?
> ACL - не всем нужно. Особенно, если домена AD нет.

В ветке Аланна (только не помню какого -рентгенолог или анестезиолог) - точно было сжатие для ext3-4.Был проект NEXT4 -это COW для ext4 .Также был анологичный проект ext4dev. Также надстройка похожея на  LVM -проект veeamsnap.
Субтом (не подтом ) и мультидевайсинг с какой то версии ядра,насчет мультидевайсинга кстати не уверен что не выкинули обратно,там был специфичный модуль ядра и кучам жалоб на глюки (по сути дела сетевой драйвер раид).


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

426. "Релиз ядра Linux 6.7"  +/
Сообщение от EULA (?), 11-Янв-24, 06:04 
> не подтом

Приставка "суб" переводится как "ниже", "внутри" "под", поэтому вполне допустимо переводить subvolume как "подтом".
> В ветке Аланна...

Левые проекты и персональные ветки это даже не заявка на дорожную карту. Так ведь можно считать проект времен Fedora 4, в котором авторы грозились заменить ядро NT ядром Linux, как свершившийся факт

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

427. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 11-Янв-24, 07:54 
В общем в терминологии не буду заморачиваться, с какой то версии ядра появилось вложенное монтирование для ext4,можно даже внутрь не пустых каталогов монтировать.

>Левые проекты

Ну ветка  Алана  (Кох ?)  была достаточно популярна.Он как майнтейнер многим  технологиям дал свет через свою ветку ядра.Сейчас отошёл от дел по возрасту.

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

428. "Релиз ядра Linux 6.7"  +/
Сообщение от EULA (?), 11-Янв-24, 08:10 
Монтирование внутрь каталогов через bind можно для всех ФС.

Hached B-Tree в EXT4 появилось только в 2019 году. Однако, это не полноценное B-Tree, которое позволяет использовать подтома, так как нет возможности использовать одни и те же индексы для разных ветвей. И таки для B-Tree данных все еще не работают ACL.

> Он как майнтейнер многим  технологиям дал свет через свою ветку ядра

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

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

432. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 11-Янв-24, 10:47 
> Hached B-Tree в EXT4 появилось только в 2019 году.

Кккаааакооой btree?!?

> Однако, это не полноценное B-Tree, которое позволяет использовать подтома,
> так как нет возможности использовать одни и те же индексы для разных ветвей.

Ишь чего захотели. Может вам еще из этого антика полноценный CoW?

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

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

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

433. "Релиз ядра Linux 6.7"  +/
Сообщение от EULA (?), 11-Янв-24, 11:13 
> Кккаааакооой btree?!?

Тот, который позволяет использовать каталоги, как тома для монтирования.

> Может вам еще из этого антика полноценный CoW?

Это вы мне доказываете, что так сделать можно.

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

И как это отменяет тот факт, что куча технологий, которые Алан делал, были заброшены?

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

438. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 11-Янв-24, 13:10 
>> Кккаааакооой btree?!?
> Тот, который позволяет использовать каталоги, как тома для монтирования.

Просто опечатка у вас прикольная. Достойный ответ "индусскому коту"! Хоть и не политкорректный.

> Это вы мне доказываете, что так сделать можно.

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

> И как это отменяет тот факт, что куча технологий, которые Алан делал, были заброшены?

Да никак. Просто врядли оно в таком виде кому-то сильно надо. Но некоторые походу сперва кодят, а потом задумываются "а надо ли?" и "если да, то как и почему?". Так тоже можно, но это работает "не очень". Особенно для ФС.

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

434. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 11-Янв-24, 11:48 
> В ветке Аланна (только не помню какого -рентгенолог или анестезиолог) - точно
> было сжатие для ext3-4.

Сжатие в ФС несколько более сложный топик чем может показаться. С ним были особенности и btrfs, и в bcachefs, а в ext4... он вообще для этого не делался.

> Был проект NEXT4 -это COW для ext4 .Также был анологичный проект ext4dev.
> Также надстройка похожея на LVM -проект veeamsnap.

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

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

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

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

437. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 11-Янв-24, 12:38 
>в ext4... он вообще для этого не делался

Делался.По крайней мере планировалось.Есть официальный документ описание ари ext3-4.Так там есть в атрибутах файла тип сжатый.Правда ари не предусматривает выбор  алгоритма сжатия.

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

439. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 11-Янв-24, 13:24 
>>в ext4... он вообще для этого не делался
> Делался.По крайней мере планировалось.Есть официальный документ описание ари ext3-4.
> Так там есть в атрибутах файла тип сжатый.
> Правда ари не предусматривает выбор алгоритма сжатия.

Атрибут - пожалуй самое простое что касается сжатия. А вот несколько менее простых топиков:
- А как мы определяем что экстент вообще сжатый?
- А что если при сжатии экстент стал больше оригинала? Заскипать сжатие для номинально сжатого файла - можно?
- И таки каким алгоритмом или алгоритмами жать? Не, 1 размер всем таки плохая идея, имхо.
- А что с compat, если в старых версиях сжатия не было? Как это обыгрывается в ФС где сжатия изначально не было? Особенно в EXT4 - у него на уровне структур вообще есть какие-то внятные маркеры для реализаций будущих расширений? И если да то где оно и как устроено? У btrfs и bcachefs этот аспект описан на видном месте и тупых вопросов не вызывает.
- А вот например дефрагер сжатые экстенты сожрет? Особенно старые версии, понятия не имеющие что так можно было?
- А что если пишут - вот - интенсивно? Как избежать полного якоря по скорости на этом и ухода латенси ФС в стратосферу? У EXT4 есть инфраструктура для дефернутых/асинхронных джобов?
- А если избежать - окей, а как избегается unbound использование ресурсов если продолжают писать быстрее чем сжатие вкалывает? У кента с этим - определенные проблемы, например.

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

443. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 11-Янв-24, 20:58 
>- у него на уровне структур вообще есть какие-то внятные маркеры для реализаций будущих расширений? И если да то где оно и как устроено?

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

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

445. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 11-Янв-24, 21:28 
>>- у него на уровне структур вообще есть какие-то внятные маркеры для реализаций будущих расширений? И если да то где оно и как устроено?
> Есть система флагов в inode позволяющие различать формат инодов.Есть также структура -глобальная
> таблица установленных флагов и блокирующих атрибутов если сломана совместимость.Правда
> как утилиты и ядро взаимодействуют с этими атрибутами в доках я
> не чего не нашел :-(

Ага нашел -есть 2 флага .Один из них - s_feature_compat
описывает совместимые флаги непонимание которых ядром не приводит к остановке работы:
- Наличие журнала
- Поддержка расширенных атрибутов
и другие

2-й это s_feature_incompat
Набор флагов, непонимание которых ядром или процедурой проверки приводит к остановке:
- Сжатие
- Директория записи типов файла
- Файловая система требует восстановления
- Группы мета-блоков
- Файлы использую экстенты
- Индексные дескрипторы могут быть использованы для больших расширенных атрибутов
- Данные в каталоге
и другие

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

446. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 11-Янв-24, 21:39 
> Есть система флагов в inode позволяющие различать формат инодов.

А например на фазе монтирования кернел про EXT4 знает - могет он зацепить ЭТО с новой фичой, или нет? Как это обыгрывается? Если на каждый incompat заворачивать все на уровне "это типа новая ФС" - юзеры с такого пути апгрейда взвоют.

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

> Есть также структура -глобальная таблица установленных флагов и блокирующих атрибутов
> если сломана совместимость.

Как оно в английских терминах и где это описано?

> Правда как утилиты и ядро взаимодействуют
> с этими атрибутами в доках я не чего не нашел :-(

А есть какие-то примеры как это реально работает на практике? Я просто EXT4 уже несколько лет как плотно не мониторю...

Просто у btrfs и bcachefs - есть структуры для описания compat, там флаги/структуры описывающие может ли энное ядро с его умениями зацепить воон то, будет ли это R/O или R/W и все такое. И еще там структуры описывающие тип чексуммы, алго сжатия, ... с самого начала заложены, опять же.

На примере фичи "bg_tree" (kernel >= 6.1) в btrfs: технически это +1 индекс (дерево). Ускоряет монтирование и проч. Поэтому в описании compat прописан так что старые кернелы могут ФС с новой фичой цеплять, как RO. Те кернелы "задним числом" (на уровне правил рюхания compat) в курсе, что хотя они не знают фичу, имеют зацепляит сие как RO. Им не надо уметь понимать тот индекс - монтирование будет дольше, но в целом совместимый формат. RW зарублен, потому что старые кернелы не умеют апдейт - при записи дерево станет рассинхронизированым (в принципе это можно было бы даже и фиксить ребилдом дерева, но...). Как-то так выглядит готовность ФС к расширению "всерьез". Т.е. механизм обеспечиваюший interop насколько возможно, и взаимодействие скажем старого кернела с новой файлухой если/насколько возможно.

Соответственно внедрять фичи в не очень хаотичном виде - реально, и этим пользуются. Кент имея пример перед глазами ессно его тоже учел.

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

448. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 12-Янв-24, 03:37 
>Как оно в английских терминах и где это описано?

Я нашел по русскому документу -описание АРИ и структур ext3-4.
Нужно будет расшарю перевод дипломный проект.Оригинал https://www.kernel.org/doc/html/latest/filesystems/ext4/glob...

По документам нашел описание флагов совместимости

Один из них - s_feature_compat
описывает совместимые флаги непонимание которых ядром не приводит к остановке работы:
- Наличие журнала
- Поддержка расширенных атрибутов
и другие

2-й это s_feature_incompat
Набор флагов, непонимание которых ядром или процедурой проверки приводит к остановке:
- Сжатие
- Директория записи типов файла
- Файловая система требует восстановления
- Группы мета-блоков
- Файлы использую экстенты
- Индексные дескрипторы могут быть использованы для больших расширенных атрибутов
- Данные в каталоге
и другие

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

459. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 13-Янв-24, 16:03 
> Я нашел по русскому документу -описание АРИ и структур ext3-4.
> Нужно будет расшарю перевод дипломный проект.

Мне сорца+доки хватит имхо.

> Оригинал https://www.kernel.org/doc/html/latest/filesystems/ext4/glob...

Вполне ок для меня. Ну и вот там структура супера. Что мне в ней не нравится? Много легаси и прибитых на гвозди вещей. И не густо того что бывает реально важно на практике (e.g. compat VS алго чексум/сжатия).

Для сравнения можно суперы btrfs и bcachefs посмотреть. Они не прибивают на гвозди алго, в супере и рядом как максимум "дайджест" incompat фич, но например можно сжать ту диру LZO, а эту zstd. И это работает. Дефолтный алго 1 ессно.

Кент доразвил идею: можно быстро сжать скоростным, типа LZ4, а cold идущий на медленный стораж - в фоне, плотным, eg zstd. Дефолтов бы два: "фронт" и "бэк". Это должно хорошо работать на ФС где запись burst'ами. Так writer видит перфоманс SSD+LZ4 а остальное в фоне, асинхронно, и не его проблемы.

> Один из них - s_feature_compat

Кажется нашел что искал, там и RO флаги есть, т.е. джентльменский минимум в наличии. Интересно с каких версий кернелов. Если древних, то в принципе старикан не так плох в этом аспекте.

> описывает совместимые флаги непонимание которых ядром не приводит к остановке работы:

Еще есть s_feature_ro_compat - если он рюхается, особенно старыми кернелами, можно как btrfsники с bg_tree делать.

> - Сжатие

У btrfs incompat это некий дайджест, сжатие более вербозно рулится. Т.е. изначально умело lzo и zlib -> новое алго zstd incompat, соответственно. Но у экстентов свое поле типа сжатия и алго может быть более 1. Кент умеет нечто сравнимое.

> - Файловая система требует восстановления

Вот это вот в автопилотных применениях (сервера, эмбедед) гарантирует сотни ненависти. Это то что "should never happen" при эксплуатации. EXT4 слишком часто требует к себе мануального внимания. И это его жирный минус. Туда же и lost+found. Хомяки про это все равно не знают, попробовавшие более продвинутые дизайны это ненавидят. "Lost+found is a hallmark of legacy".

> - Файлы использую экстенты

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

На мой вкус у EXT4 есть проблема как у XFS, где "XFSv4 VS майнтайнер". Т.е. легаси код, который никто не хочет чинить, в котором куча проблем, но который нельзя выкинуть и fuzzing боты делают мозг - и имеют свой пойнт, но желающих за дидами возить их гуано тоннами мало.

...в этом месте более новые дизайны типа btrfs и bcachefs получают некий пойнт. Наслоений легаси меньше, не надо EXT2 уметь, блин. И прчие XFSv4, ага!

С XFS фейл вышел. Мол у вас старый формат, он устарел, а новый - пересозданием ФС. Ну я и пересоздал там - btrfs, раз такая фигня :). У этих пути миграции адекватнее обычно.

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

461. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 13-Янв-24, 23:05 
> На мой вкус у EXT4 есть проблема как у XFS, где "XFSv4
> VS майнтайнер". Т.е. легаси код, который никто не хочет чинить, в

Ну было бы желание. Кто мешал сделать к примеру переход на ext5,с отказом от древностей ?  Скажем отказавшись от инодов ,сделав адресацию по типу битового поля или дерева.Да нечего в принципе. В принципе и конвертор btrfs хороший выход,наверно так и сделали,чтобы не изобретать ext5.Правда маленькая проблема-его сейчас не кто не поддерживает :-(  Технологии Парогон по конвертации непохожих файловых систем похоже это сейчас остатки прошлой цивилизации.....Интересно как же сделали под офтопик конвертер ntfs-btrfs?

>EXT4 слишком часто требует к себе мануального внимания. И это его жирный минус. Туда же и lost+found.

Я не знаю что лучше -не требующийся внимание BTRFS.Или требующийся обслуживания EXT4. А то очень непонятно что делать на BTRFS когда crc ошибок не было,механика исправна,данные и метаданные целые -но BTRFS error (device sdb3): cleaner transaction attach returned -30
BTRFS error (device sdb3): open_ctree failed.
Всего лишь ноутбук не проснулся.А особенность прошивки ноутбука что когда есть питание от розетки и не закрыта крышка (сон по команде или клавиша,т.е софтово)-он сразу не засыпает пока кэш не освободиться  и файловые операции  не завершаться,может и по 5 минут в сон не уходить. Смотришь R-studio -данные целые,метаданные тоже,что этой гадине нужно XЗ .Не ремонтируеться штатными утилитами,а купить R-studio - санкции, утилита говорила что может починить ФС в полной версии с удалением 3 блоков (какие то очень маленькие файлы ) по 64 кб с починкой метаданных :-(
Так что иногда лучше пару файловых кусков в Lost положить, чем час сидеть с бэкапа разворачиваться :-(


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

462. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 14-Янв-24, 01:32 
>Смотришь R-studio -

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

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

464. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (151), 14-Янв-24, 14:33 
> Ну было бы желание.

Я не понимаю почему оно должно образоваться. Аналогично с XFS. Сдриснувший майнтайнер и скорость запиловки scrub - намекают.

> Кто мешал сделать к примеру переход на ext5,с отказом от древностей ?

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

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

1) В *nix inode крепко вбиты в апи. Проблема не они, а левый лимит на их число.
2) Битмапы аллокации были до экстентов. Метить регион экстентом оказалось быстрее в большинстве нагрузок. Новые дизайны и перешли на экстенты.
3) История с экстентами повторяется с cow и ко. Zfs был первым, btrfs вторым, bcachefs теперь. Даже MS попытался ReFS. "Too little and too late"? Кто им доктор?

> Да нечего в принципе.

Что это должно дать? И почему это - хорошо?

> В принципе и конвертор btrfs хороший выход,наверно так и сделали,
> чтобы не изобретать ext5.Правда маленькая проблема-его сейчас не кто не поддерживает :-(

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

> Интересно  как же сделали под офтопик конвертер ntfs-btrfs?

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

> Я не знаю что лучше -не требующийся внимание BTRFS.Или требующийся обслуживания EXT4.

Лично я не хочу выколупывать файло из lost+found, гонять оффлайн fsck с дауном систем на это время, и заниматься обслугой компов вместо того чтобы они просто работали. Особенно на эмбедовке и серверах, впрочем и на десктопе/ноуте тоже.

> cleaner transaction attach returned -30
> BTRFS error (device sdb3): open_ctree failed.

Возможно это тот случай когда zero log поможет, или usebackuproots. Однако...
1) Это все насколько (не)актуально для текущего релиза майлайна?
2) Если это ну вот реально есть - с последним релизом кернела и тулсов - это стоит показать девам до того как резко дергаться.
3) При этом нехило бы детали типа кернела, точных сообщений, подробностей как это вообще случилось, ...

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

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

И я не понимаю что вообще с ОС надо сделать чтобы кеш 5 минут скидывать. Это само по себе довольно подозрительное обстоятельство. А ext4 хороший видимо потому что плевал на data corruption кривым хардваром? :)

> Смотришь R-studio -данные целые,метаданные тоже,что этой гадине нужно XЗ .

Некие constraints профачились и оно видит что состояние не то что задумано.

> Не ремонтируеться штатными утилитами,а купить R-studio - санкции, утилита говорила что может
> починить ФС в полной версии с удалением 3 блоков (какие то
> очень маленькие файлы ) по 64 кб с починкой метаданных :-(

На правах идеи zero log и (если не прокатило) usebackuproots может и без всяких R-Studio прокатить, да и офлайн читалка в "btrfs" встроена как "btrfs restore". Однако до этих маневров лучше спросить девов (в рассылке или ирц). Ну или образ снять, если есть куда и попробовать вон то на нем. Это все ессно про btrfs, если это не он был - упс, сами изучайте как это тогда.

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

Это какая-то довольно нетипичная ситуация (учитывая мизерный объем диагностики и данных о конфиге более подробно сложно сказать). И КМК при таком масштабе урона это вероятно идет дальше чем пара файлов в lost+found, просто ext4 на все похрен. И кстати журнал чексумами они обложили вот благодаря любителям юзать сыкотное железо - попытки реплеить рушеный журнал убивали тома в хлам, что логично. Но региона данных благодать не коснулась...

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

465. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 14-Янв-24, 21:44 
>С ним сейчас есть большие траблы?

Да, есть одна проблема. По результатам конвертации том в 50% случаев не монтируется ,хорошо хоть откат работает. Т.е честно говоря не осилили разработчики конвертацию.До этого давно года 3 назад нашли баг,разобрались наконец то почему конвертированные тома в течении года разваливались.
>И я не понимаю что вообще с ОС надо сделать чтобы кеш 5 минут скидывать.

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

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

485. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 23-Янв-24, 07:03 
> Да, есть одна проблема. По результатам конвертации том в 50% случаев не
> монтируется ,хорошо хоть откат работает.

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

Если кому приспичит проверять, вкатывать rc1 не стоит, там вкатили потенциально интрузивный рефактор. Какую-то мадам и Торвальдса (он походу тоэе btrfs юзает) зашибло фаллаутом, при том они смогли в резкий и быстрый бисект и то что отпало уже пофикшено, так что трабл существовал буквально считанные дни. Но я рекомедую дать пару -rc на debounce до экспериментов, если кто не хардкорный дев.

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

> Т.е честно говоря не осилили разработчики конвертацию.

Не совсем так. Оно, как бы это сказать, "pushes [design] to weird extremes". Такое структурирование ФС никогда кроме этой конверсии не встречается - и потому протестировано сильно меньше. Ну и порой натыкается на какие-то странные краевые случаи которые больше никогда и нигде не встречаются. С одной стороны это назойливо. С другой это технически-валидный формат, и оно должно жрать сие, так что починка в целом улучшает код.

> До этого давно года 3 назад нашли баг,разобрались наконец то почему
> конвертированные тома в течении года разваливались.

Припоминаю такое. И в вон том -rc приехал какой-то фикс странного бага который только конверченые тома вызывали. У меня просто таких ФС нету и "реалистичных" ФС которые модно было бы затестить - у меня ext4 уже не осталось.

>>И я не понимаю что вообще с ОС надо сделать чтобы кеш 5 минут скидывать.
> А вы в htop не смотрели что у btrfs куча фоновых утилит
> висит- может фоновая дефрагментация,балансировка или проверка работать -не ?

Балансировку надо явно запускать. Автодефраг вроже ничего ужасного не делает, да и наглухо опционален. А куча ядерных тредов и воркеров сейчас у всех ФС есть. И у XFS, и даже EXT4 вроде. Кернел смог в крутые штуки, типа асинхронщины и дефернутых джобов и даст мастеркласс даже какому яваскрипту по части продвинутых концепций.

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

Пять минут - не есть норм время шатдауна. Может вы наставили какой-то фоновой гадости которая лучше вас знает как ЗБС? Не, конечно, виндус висту и из линя можно сделать. Но даже так - фс рушиться все же не должна, и если это случается - где-то в системной механике сидит нехилый баг или data corruption.

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

444. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 11-Янв-24, 21:09 
>- А что если при сжатии экстент стал больше оригинала? Заскипать сжатие для номинально сжатого файла - можно?

Вот описание в ари -флаги индексного дискриптора:(я привожу насчёт сжатия только)

-сжатый файл
-черновое сжатие
-файл содержит сжатые кластера
-не сжимать файл
-ошибка сжатия

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

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

447. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 11-Янв-24, 21:54 
> Вот описание в ари -флаги индексного дискриптора:(я привожу насчёт сжатия только)
> -сжатый файл
> -черновое сжатие
> -файл содержит сжатые кластера
> -не сжимать файл
> -ошибка сжатия

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

И вот у меня допустим кернел 6.1 - он сможет зацепить это? С какими ограничениями? А вот кернел 6.7. Он сможет это зацепить? С какими ограничениями? А вот kernel.next - он сможет? Как это определяется для FS vs Kernel более глобально?

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

> Так что вывод: думали над этим разработчики.
> Разве что не придусмотрели выбор алгоритмов сжатия...

А более high-level решения о compat и его уровне - скажем на этапе попытки монтирования - там есть? И как это вообще есть? Еще мне чисто по человечески интересно, если это структуры фс, зачем там запоминать "ошибку сжатия" может требоваться? И какая бы реакция софта если ему это дать предполагается?

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

449. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 12-Янв-24, 03:47 
>Ну вот допустим сделали там сжатие файлов. Каким алго?

Вот атрибутов для каким архиватором сжато нет :-(
Раньше я уже писал что нашел какие флаги совместимости:s_feature_compat
описывает совместимые флаги непонимание которых ядром не приводит к остановке работы.
2-й это s_feature_incompat
Набор флагов, непонимание которых ядром или процедурой проверки приводит к остановке:
- Сжатие
- Директория записи типов файла
- Файловая система требует восстановления
- Группы мета-блоков
- Файлы использую экстенты
- Индексные дескрипторы могут быть использованы для больших расширенных атрибутов
- Данные в каталоге
и другие

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

460. "Релиз ядра Linux 6.7"  +/
Сообщение от Аноним (-), 13-Янв-24, 16:25 
> Вот атрибутов для каким архиватором сжато нет :-(

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

> Раньше я уже писал что нашел какие флаги совместимости:

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

В btrfs например завести плюс-минус дерево с индексом "чего-нибудь" само по себе вообще не проблема. Лимит в основном 1) способность старого парсера это игнорить/юзать и 2) не будет ли рассинхрон (если будет, это RO mount). Скажем у них есть "extent tree v2", он должен быть заметно быстрее но вот его старый парсер совсем не прожует и это именно полный incompat. Оно нацелено на устранение проблем перфоманса всплывших при эксплуатации. Т.к. это именно полный incompat они и не спешат его выкатывать "по мелочи" как дефолт, я так понимаю постараются максимизировать решение известных проблем до того как сломать совместимость. Но технически части в коде уже есть.

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

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

450. "Релиз ядра Linux 6.7"  +/
Сообщение от maximnik0 (?), 12-Янв-24, 03:58 
> Во всяком случае я не припоминаю примеров как бы это могло выглядеть.

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

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

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

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




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

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