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

"Релиз ядра Linux 6.7"	+/–
Сообщение от opennews (?), 08-Янв-24, 10:27
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.7. Среди наиболее заметных изменений: интеграция ФС Bcachefs, прекращение поддержки архитектуры Itanium, возможность работы Nouvea с прошивками GSP-R, поддержка TLS-шифрования в NVMe-TCP, возможность использования исключений в BPF, поддержка  futex в io_uring, оптимизация производительности планировщика fq (Fair Queuing), поддержка расширения TCP-AO (TCP Authentication Option) и возможность ограничения сетевых соединений в механизме защиты Landlock... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60398
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Релиз ядра Linux 6.7"	–2 +/–
Сообщение от DEF (?), 08-Янв-24, 10:27
>В Btrfs добавлена новая структура данных "stripe tree", подходящая для логического маппинга экстентов в ситуациях, когда физических маппинг не совпадает на разных устройствах. А вот это круто. Наконец-то проблема с RAID 5/6 в BTRFS будет наконец-то решена.
Ответить | Правка | Наверх | Cообщить модератору

	71. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 15:21
	> А вот это круто. Наконец-то проблема с RAID 5/6 в BTRFS будет > наконец-то решена. Там еще вроде оптимизации какие-то были, а еще bcachefs. В общем в этом релизе файлухи были в ударе. И это хорошо. Всегда бы так. Btrfs'ники кстати неплохо оптимизации пилят. С bg_tree btrfs маунтится быстрее ext4 и bcachefs, а xfs вообще слоупок. Прикольная ачивка :)
	Ответить | Правка | Наверх | Cообщить модератору

	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ообщить модератору

	154. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 08-Янв-24, 18:24
	btrfs больше не нужна, её закопает bcachefs
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	265. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Денис Попов (?), 09-Янв-24, 02:16
	Придется долго ложкой яму копать.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (252), 09-Янв-24, 00:45
	>проблема с RAID 5/6 в BTRFS будет наконец-то решена Но нет.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	299. "Релиз ядра Linux 6.7"	+/–
	Сообщение от DEF (?), 09-Янв-24, 07:26
	Но да.
	Ответить | Правка | Наверх | Cообщить модератору

2. "Релиз ядра Linux 6.7"	+21 +/–
Сообщение от Аноним (2), 08-Янв-24, 10:32
Очень рад за создателя BcacheFS. 9 лет пилил от зародыша до апстрима. https://www.opennet.dev/opennews/art.shtml?num=42839
Ответить | Правка | Наверх | Cообщить модератору

	3. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (3), 08-Янв-24, 10:41
	Если там не раздутый бегемот как Btrfs и не окаменевшее ископаемое как ZFS то можно даже попробовать на чем-то некритичном.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Релиз ядра Linux 6.7"	–5 +/–
	Сообщение от Аноним (5), 08-Янв-24, 11:11
	Не вижу проблем применения ни btrfs ни с ZFS. Продакшен же давно
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Релиз ядра Linux 6.7"	+5 +/–
	Сообщение от Аноним (9), 08-Янв-24, 11:37
	Продакш не спасает от потери данных.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 08-Янв-24, 18:32
	В продакшене данные, которые жалко потерять, хранят в специальных СУБД с распределёнными избыточным хранением и бэкапами. А утеря хоста вообще ничем особенным не является, хост просто выкидывается и переподнимается где-нибудь ещё
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (3), 08-Янв-24, 12:40
	Вопрос не в применении, вопрос в эргономичности. В BTRFS даже точное свободное место нельзя посмотреть без костылей.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	34. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 13:17
	Сижу на этом с 6.7-rc1 и впечатления пока что только положительные. Есть минусы, но по сравнению с btrfs и zfs они просто ничтожны.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Релиз ядра Linux 6.7"	+/–
	Сообщение от оно ним (?), 08-Янв-24, 13:49
	Что за минусы-то, хоть бы рассказал.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Релиз ядра Linux 6.7"	+5 +/–
	Сообщение от Аноним (34), 08-Янв-24, 15:12
	Сетап - для хомяка ноутбучный SMR на терабайт, в качестве кэша - Kingston UV400 га 240 гигабайт. Сжатие - lz4 в бэкграунде. Ну т.е. ссд в качестве writeback кэша, во время ребаланса происходит сжатие данных и запись на бэкграунд HDD. Минусы - то, что тулзы местами недоделанные. Например, если смотреть rebalance status - то нихрена непонятно, сколько ему еще ребалансить. Нельзя вызвать ребаланс самому или изменить триггеры, вызывающие ребаланс. Это не мешает, но я хочу, например, делать ребаланс чаще. Так же, например, изменение таргета для метаданных не заставляет при очередном ребалансе метаданные переносить с носителя на выбранный полностью, приходится лапками мув данных запускать. Мелочи, в общем. RAID5/6 использовать не рекомендуется пока, насколько я понял, а так же _нельзя_ использовать erasure coding - ибо нестабильно. А вымораживает меня то, что оно не дает винту стопнуть шпиндель - раз в секунду что-то читается, или журналы сбрасываются. Я пока не понял, можно ли журнал убрать с HDD. Жить не мешает, но т.к. все нужные данные обычно в кэше (там обычный LRU) - мне хочется, чтобы хард стопался через минут так 5 неактивности, а вот хрен то там. Подозреваю, в следующих релизах поправят. Если погуглить - есть жалобы на nocow - мол, корраптит файлы - вот это жирный косяк, но вроде по последним коммитам что-то в этом направлении было сделано в rc7). Есть жалобы, что девайс не всегда получается вывести из массива, но тут я не тестил - и, в общем, понятно, что это будет исправляться - вроде как в linux-next там на эту тему тоже что-то заброшено. Есть косяк, что если смотреть rebalance_status из sysfs - оно IO считает в каких-то странных единицах, ошибка в выводе времени отображения ожидания ребаланса (200 секунд отображаются как 200 минут, а 3600 секунд - как 3600 часов) - но, я так понимаю, Кенту на это начхать пока что, да оно и не важно. Пережило с десяток отключений питания, нормально работает в гибернации (я использую для хомяка, корень у меня на другом SSD). Восстановление после сбоя бывает длительным, но пока ничего не потерялось. Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd висла, поэтому на корень я бы это тоже ставить не стал. Почему оно лучше чем btrfs - так это я свободное место могу нормально видеть, там зарезервировано, кстати, в дефолте 8%. Собственно, сжатие тоже как-то странную статистику показывает, но то, что у меня на 200 гиг раздел свободнее чем планировалось - таки да. uncompressed:         nr extents:             3684626         size:                   507 GiB compressed:         nr extents:             3724187         compressed size:        216 GiB         uncompressed size:      448 GiB incompressible:         nr extents:             10889179         size:                   622 GiB В общем, при наличии бэкапа - мне нравится. Без бэкапа я бы тыкать не стал как минимум до следующего LTS.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 08-Янв-24, 16:29
	> Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd > висла, поэтому на корень я бы это тоже ставить не стал. Вероятно дело в том что большая часть тулсов/либ в вашей системе еще не знает этот тип ФС. Оно также не маунтится mount'ом без явного указания -t bcachefs, автодетект не срабатывает. Но в виртуалке на рутфс - пашет. Даже с системдой. В этом случае в командлайне ядра тип ФС стоит указывать. Т.е. как-то типа root=/dev/vdb rootfstype=bcachefs (это часть командлайна ядра). > Почему оно лучше чем btrfs - так это я свободное место могу > нормально видеть, там зарезервировано, кстати, в дефолте 8%. 1) Уже убрали вроде этот резерв как слишком радикальный... 2) В силу специфики ФС оно тоже может видеть свободное место несколько специфично. Это обратная сторона медали продвинутой аллокации, фич типа сжатия/многодисковых схем/etc. > Собственно, сжатие тоже как-то странную статистику показывает, но то, что у меня на 200 > гиг раздел свободнее чем планировалось - таки да. Да вообще оно работает. Вон на виртуалках чартерными рейсами пашет. Но некие аномалии все же вылезли. > В общем, при наличии бэкапа - мне нравится. Без бэкапа я бы > тыкать не стал как минимум до следующего LTS. Люди делятся на 2 типа - те кто еще не делает бэкапы и те кто уже делает.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Qq (?), 08-Янв-24, 16:33
	> Люди делятся на 2 типа - те кто еще не делает бэкапы и те кто уже делает. 3, есть те кто проверяет целостность бекапов
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 16:36
	> 3, есть те кто проверяет целостность бекапов Теперь еще расскажите как вы это делаете для всех файлов бэкапа, что там реально то что должно быть и вас никто не подвел... :)
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 17:11
	Целостность бэкапов это не проверка файлов в них. Это проверка того, что архивы могут быть распакованы. А проверка файлов делается, внезапно, восстановлением из бэкапа и сверкой атрибутов файлов и их хеш-сумм.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 17:37
	> Целостность бэкапов это не проверка файлов в них. Это проверка того, что > архивы могут быть распакованы. А проверка файлов делается, внезапно, восстановлением из > бэкапа и сверкой атрибутов файлов и их хеш-сумм. Самое интересное что все это никак не гарантирует что та БД работает, фоточка открывается, видео играется, ... :)
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 18:26
	Не гарантирует. Но вероятность составляет ~1*10^-400. Насколько это мало - можешь сам представить.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 09-Янв-24, 00:58
	> Не гарантирует. Но вероятность составляет ~1*10^-400. Насколько это мало - можешь сам > представить. Размечтался, плюшевый. Реально господа с гнилыми бэкапами попадаются регулярно.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	111. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 16:44
	>большая часть тулсов/либ в вашей системе еще не знает этот тип ФС. Manjaro unstable? bcachefs-tools из aur? Сомневаюсь ). >не маунтится mount'ом без явного указания -t bcachefs, автодетект не срабатывает. Это правда. Но оно не маунтилось у меня при задании сего действа в fstab (начинал с одного диска). >В этом случае в командлайне ядра тип ФС стоит указывать. Ну у меня оно поверх luks, так что, может, я с коммандлайном ядра обгадился. Возможно. Родное шифрование я там тыкать пока что не захотел, смигрирую потом когда-нибудь. >1) Уже убрали вроде этот резерв как слишком радикальный... Можно на лету поменять, это резерв для GC. Может и убрали, но у меня создана ФС была, когда он еще был. Мне не мешает. > оно тоже может видеть свободное место несколько специфично Не совсем. Здесь оно показывает только еще не выделенное пространство. Под что оно будет выделено - под btree или data - это уже не важно. Размеры файлов, каталогов показывает без учета сжатия родными утилитами, df показывает то же, что и в bcache fs usage, чего в BTRFS нет. Собственно, если там написано что свободно 210 гигабайт - то уж как минимум 209 гигабайт я туда запихаю... С btrfs это не гарантировано. В bcachefs в этом смысле алгоритмы намного продуманнее. > Но некие аномалии все же вылезли. Наверное, вы тыкали ZSTD. Там были грабли, при том вплоть до потери данных (повреждало файлы). Я почему-то посмотрев тесты и почитав ишью и багтрекеры решил, что lz4 спасёт отца русской демократии. >2 типа - те кто еще не делает бэкапы и те кто уже делает. На 4. Есть еще те, кто верифицирует бэкапы и те, кто тестирует восстановление из них (и я щас не про целостность архивов).
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	131. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 17:52
	>>большая часть тулсов/либ в вашей системе еще не знает этот тип ФС. > Manjaro unstable? bcachefs-tools из aur? Сомневаюсь ). Да я даже из git автыря их билданул. А coreutils'ам и системде вы уже объяснили что такую ФС завезли? И они отрелизились новыми версиями с явным саппортом типа ФС? Да даже кернелу надо явно тип ФС тыкать, если это рутфс, иначе - ну вот таки не могет он его зацепить. >>не маунтится mount'ом без явного указания -t bcachefs, автодетект не срабатывает. > Это правда. Но оно не маунтилось у меня при задании сего действа > в fstab (начинал с одного диска). Ну вот где-то автодетект еще не допилен. Однако я бутанул VM с таким рутфс, так что на рутфс он сам по себе - работает. А, если кто хотел прям оттуда читать кернел и проч - ну, бутлоадеры тоже пока еще врядли кто заапдейтил уметь читать bcachefs. Для btrfs grub это умеет, и сие довольно круто: можно бутануть СНАПШОТ по сути голыми руками, отыграв назад аж одним бутлоадером из всех системных тулсов. Мне такой рекавери системы нравится, почти как VM :) > Ну у меня оно поверх luks, так что, может, я с коммандлайном > ядра обгадился. Возможно. Родное шифрование я там тыкать пока что не > захотел, смигрирую потом когда-нибудь. Ну вот это уже довольно продвинутое комбо, я не смотрел как оно такое будет. > Можно на лету поменять, это резерв для GC. Может и убрали, но > у меня создана ФС была, когда он еще был. Мне не мешает. Просто я довольно плотно смотрел изменения в этой штуке, продвинутые файлухи - это мне интересно. А упрямый независимый кодер, гнувший свою линию почти 10 лет - по своему прикольно. Будущее должно принадлежать вот таким. > Не совсем. Здесь оно показывает только еще не выделенное пространство. Под что > оно будет выделено - под btree или data - это уже не важно. Намекаю: например, GC - это фоновая активность, кроме случаев когда конкретно приперло так что иначе совсем никак. Он когда-то что-то выцепит, но в общем случае не прямо вотпрямща. И это вероятно примерно одинаково что у btrfs что у bcachefs. Соответственно в счетчик free допустим удаление чего-то может попасть не сразу - дергать GC на каждый пшик неоптимальная идея, это делают только если с свободным местом совсем душняк но это крайне субоптимальный режим. > Размеры файлов, каталогов показывает без учета сжатия родными утилитами, > df показывает то же, что и в bcache fs usage, чего в BTRFS нет. И все же - есть некая "асинхронность" и "неизвестные факторы". > Собственно, если там написано что свободно 210 гигабайт > - то уж как минимум 209 гигабайт я туда запихаю... Оптимизм это хорошо. Попробуйте создавать файлы 0 байтов. Миллионами. В какой-то момент у вас кончится место - при формальной аллокации 0 байтов :P. Сколько и чего вы там записали? :) > С btrfs это не гарантировано. В bcachefs в этом смысле алгоритмы намного > продуманнее. Оно на самом деле никогда не гарантировано на 100%. А так bcache самый поздний из дизайнов - и потому учел грабли предшественников. Btrfs-ники впрочем свои грабли тоже учитывать умеют. >> Но некие аномалии все же вылезли. > Наверное, вы тыкали ZSTD. Там были грабли, при том вплоть до потери > данных (повреждало файлы). Портить не портились - но RAM на мелкой VM в какой-то момент выжрало весь. Btrfs этим не страдает, соответственно. > Я почему-то посмотрев тесты и почитав ишью и > багтрекеры решил, что lz4 спасёт отца русской демократии. Вопрос в том не заменило ли это частый баг на редкий и более сложно провоцируемый... > На 4. Есть еще те, кто верифицирует бэкапы и те, кто тестирует > восстановление из них (и я щас не про целостность архивов). Ну вот блин, оверинженерия. Уже из 2 типов 4 отрастили :)
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 18:46
	>А coreutils'ам и системде вы уже объяснили что такую ФС завезли? Ну у меня не рутФС, но кент как-то разрабатывает и молчит, что там какие-то патчи этим утилитам нужны? Значитк ак минимум у него все работает. Так что тут не факт. В чем там дело на самом деле лично у меня не хватает понимания сказать. >Для btrfs grub это умеет, и сие довольно круто Это очень хорошая фича и прям в некоторых случаях даже маст хэв. Но имеем что имеем. >Ну вот это уже довольно продвинутое комбо, я не смотрел как оно такое будет. Не согласен. luks сам по себе предоставляет блочные девайсы, на которых и развернут bcachefs, для которого это просто диски. Но да, к проблемам с монтированием оно отношение иметь может ). Но для ФС это не комбо - она по сути работает как задумывалось. >Намекаю: например, GC - это фоновая активность, кроме случаев когда конкретно приперло так что иначе совсем никак. Объясняю: в btrfs бывали случаи, что она показывает, что свободного места еще дохуха, а запись на нее или любое действие (в т.ч. и ребаланс) - ENOSPC. В bcachefs это немного по другому реализовано: оно берет тупо пустые buckets и сообщает их объем. Т.е. оно может показать свободным меньше места, чем есть на самом деле (потому что GC еще не отработал), а вот показать свободное место, когда его нету - не может. Вообще. Никак. >И все же - есть некая "асинхронность" и "неизвестные факторы". Да, но реализовано иначе и часть проблем не присутствует. >Оптимизм это хорошо. Попробуйте создавать файлы 0 байтов. Миллионами. В какой-то момент у вас кончится место - при формальной аллокации 0 байтов :P. Сколько и чего вы там записали? :)   btree:                    8.86 GiB           21838      1.80 GiB это у меня сейчас. При вашем подходе будет расти btree, а свободное место в ФС будет таять. Это как иноды в ext. Но да, формулировка моего оптимизма не корректна, учту ). >Btrfs-ники впрочем свои грабли тоже учитывать умеют. Все могут учитывать. Я не говорю что btrfs совсем уж кусок того самого. Он кое-в чем не плох. >Портить не портились - но RAM на мелкой VM в какой-то момент выжрало весь. Btrfs этим не страдает, соответственно. Ну да, у меня 32G RAM, а вы тестировали в "стесненной среде обитания". Боюсь, на голом железе такая проблема никогда не была бы найдена, только специальное тестирование в виртуалках такие баги позволяет отловить. >Вопрос в том не заменило ли это частый баг на редкий и более сложно провоцируемый... lz4 у него там очень давно был запилен и т.к. это дефолтный алгоритм - я думаю, это маловероятно. А вот zstd по настоящему нормально тестить стали только в майнлайне. >Ну вот блин, оверинженерия. Уже из 2 типов 4 отрастили :) Ну вот лично я ко всем категориям принадлежал. Сначала у меня небыло бэкапов. Потом оказалось, что они не распаковываются. В следующий раз распаковалось, но файлы оказались битые. Теперь проверяется не только консистентность, но и распаковка в виртуальную среду.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	260. Скрыто модератором	+/–
	Сообщение от Аноним (-), 09-Янв-24, 01:45
	> Ну у меня не рутФС, но кент как-то разрабатывает и молчит, что > там какие-то патчи этим утилитам нужны? Значитк ак минимум у него все работает. Ну как, если подкостылить с явным указанием типа ФС - работает. Но автодетект, натурально, пролеатет. Что в тулсах, что в ядре при цеплянии как рутфс. Видимо эту штуку еще не все и не везде детектят. Допилят со временем. > на самом деле лично у меня не хватает понимания сказать. Ну я вот как минимум заметил что автодетект этой штуки пока софт не умеет, требуется явное указание типа ФС везде. Мне похрен, я его и так все время указывал для скорости операций, ибо автодетект пытается маунтить как разные ФС, это дольше. Не люблю медленную загрузку. >>Для btrfs grub это умеет, и сие довольно круто > Это очень хорошая фича и прям в некоторых случаях даже маст хэв. Мне понравилось. Если бутлоадер может читать фс, в снапшоте может быть например кернел и initrd, и тогда рекавери - "довольно точный", почти как в VM. Можно, вот, грохнуть пакетником пакет с кернелом - и - отыграть назад! Машина времени это хорошо и правильно. > с монтированием оно отношение иметь может ). Но для ФС это > не комбо - она по сути работает как задумывалось. Для ФС то да, а вот где-то на стыках интеграция может и отъехать. > Объясняю: в btrfs бывали случаи, что она показывает, что свободного места еще > дохуха, а запись на нее или любое действие (в т.ч. и ребаланс) - ENOSPC. Это возможно в некоторых весьма специфичных ситуациях, но в основном с старыми ядрами. В новых запилили global reserve на совсем пиковые случаи, и теперь даже штука с фэйсбук на ENOSPC не натыкается по сути, с их то парком серверов. А с Кентом если я правильно помню историю его патчей, он отменил тот немеряный маневровый резерв, и за это познал... тадам... вариант этсамого для себя :). Но он там бойко чинил в -rc так что загасил то что было у него и тех кто на это нарвался. > В bcachefs это немного по другому реализовано: оно берет тупо пустые buckets > и сообщает их объем. Это однако в такой штуке не обязано соответствовать фактически записаному объему данных. Скажем, оотношение данные-метаданные заранее знать нельзя. Все становится еще прикольнее если вспомнить что число копий данных и метаданных совпадать не обязано. И вот откуда бы это соотношение заранее знать? Как я уже сказал в предельном случае можно ФС забить под ноль одними метаданными, с формальной аллокацией 0 байтов на данные. Даже совсем классические. Ацтой типа EXT4 правда может быстрее нарваться на лимит инодов, номерков дедуле мало. > GC еще не отработал), а вот показать свободное место, когда его > нету - не может. Вообще. Никак. Оптимизм это хорошо. Но реализм лучше. > Да, но реализовано иначе и часть проблем не присутствует. А таки кентушка кажется познал радость ENOSPC в процессе -rc :) > это у меня сейчас. При вашем подходе будет расти btree, а свободное > место в ФС будет таять. Это как иноды в ext. Но да, формулировка моего > оптимизма не корректна, учту ). У EXT будет и место на метаданные жраться, и можно нарваться на нехватку инодов. Если бы ее не было - на ФС с динамической аллокацией инодов можно нарваться на то что метаданные сожрут все место. Потому что на хранение сведений о каждом файле что-то тратится, даже если он 0 байтов. Это кроме всего прочего гарантирует что data/metadata ratio - заранее неизвестен. И наверное когда вы спрашиваете df сколько места, вы врядли имеете хоть какое-то представление сколько у вас при этом могло бы быть метаданных. В лучшем смысле вы позырили суммарный объем данных в источнике, но это ничего не говорит о вон том аспекте. > Все могут учитывать. Я не говорю что btrfs совсем уж кусок того > самого. Он кое-в чем не плох. Мне понравилось как они bg_tree забацали, монтироваться быстро стал. И монтирование у него прикольнее, с автосканом девайсов. Bcache так вроде не умеет для многодисковых и надо явно все девайсы прописывать, как я понял. > Ну да, у меня 32G RAM, а вы тестировали в "стесненной среде обитания". Ну так на воркстейшне рамы есть, но если я буду каждой VM выдавать дохрена, она как раз и кончится, думаете у меня 1 вм? Вот я например тут болтаю с вами - а это тоже VM :). Другая ессно. > Боюсь, на голом железе такая проблема никогда не была бы > найдена, только специальное тестирование в виртуалках такие баги позволяет отловить. Голое железо разное бывает... скажем мелкие одноплатники с кредитку размером, у некоторых опаративы 256-512 мег всего. Зато и стоят 10 баксов за "это типа тоже комп с линухом" :). Btrfs там нашел свое примение, с ним загрузочный SD/eMMC заметно надежнее. Ибо разовый случайный бэд не ведет к разлету железки и претензиям - а то экстренному визиту к черту на куличики. А вот с EXT4 был неприятный опыт такого плана. Оказывается если бэд под libc6 - ОС резко и внезапно превращается в тыкву. Без намека на предупреждение. > алгоритм - я думаю, это маловероятно. А вот zstd по настоящему > нормально тестить стали только в майнлайне. Там вроде какие-то отличия есть в том как оно запилено. Для zstd какой-то дефер, чтоли - может на этом себя наело. Я подозреваю что записывал быстрее чем оно паковать успевало и возможно оно unbound allocation и так можно  в принципе где угодно налететь. > Ну вот лично я ко всем категориям принадлежал. Сначала у меня небыло > бэкапов. Потом оказалось, что они не распаковываются. В следующий раз распаковалось, > но файлы оказались битые. Теперь проверяется не только консистентность, но и > распаковка в виртуальную среду. А я ... самые ценные штуки я бэкапал ... по моему всегда. Еще в стародавние времена я развлекался диск-докторами и чем там. И уже тогда починил паре типов ФС - и вынул их продолбаные курасчи, проекты и что там еще. Это показало мне что бэкапать так то попроще в целом :)
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 15:15
	Сетап - для хомяка ноутбучный SMR на терабайт, в качестве кэша - Kingston UV400 га 240 гигабайт. Сжатие - lz4 в бэкграунде. Ну т.е. ссд в качестве writeback кэша, во время ребаланса происходит сжатие данных и запись на бэкграунд HDD. Минусы - то, что тулзы местами недоделанные. Например, если смотреть rebalance status - то нихрена непонятно, сколько ему еще ребалансить. Нельзя вызвать ребаланс самому или изменить триггеры, вызывающие ребаланс. Это не мешает, но я хочу, например, делать ребаланс чаще. Так же, например, изменение таргета для метаданных не заставляет при очередном ребалансе метаданные переносить с носителя на выбранный полностью, приходится лапками мув данных запускать. Мелочи, в общем. RAID5/6 использовать не рекомендуется пока, насколько я понял, а так же _нельзя_ использовать erasure coding - ибо нестабильно. А вымораживает меня то, что оно не дает винту стопнуть шпиндель - раз в секунду что-то читается, или журналы сбрасываются. Я пока не понял, можно ли журнал убрать с HDD. Жить не мешает, но т.к. все нужные данные обычно в кэше (там обычный LRU) - мне хочется, чтобы хард стопался через минут так 5 неактивности, а вот хрен то там. Подозреваю, в следующих релизах поправят. Если погуглить - есть жалобы на nocow - мол, корраптит файлы - вот это жирный косяк, но вроде по последним коммитам что-то в этом направлении было сделано в rc7). Есть жалобы, что девайс не всегда получается вывести из массива, но тут я не тестил - и, в общем, понятно, что это будет исправляться - вроде как в linux-next там на эту тему тоже что-то заброшено. Есть косяк, что если смотреть rebalance_status из sysfs - оно IO считает в каких-то странных единицах, ошибка в выводе времени отображения ожидания ребаланса (200 секунд отображаются как 200 минут, а 3600 секунд - как 3600 часов) - но, я так понимаю, Кенту на это начхать пока что, да оно и не важно. Пережило с десяток отключений питания, нормально работает в гибернации (я использую для хомяка, корень у меня на другом SSD). Восстановление после сбоя бывает длительным, но пока ничего не потерялось. Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd висла, поэтому на корень я бы это тоже ставить не стал. Почему оно лучше чем btrfs - так это я свободное место могу нормально видеть, там зарезервировано, кстати, в дефолте 8%. По сравнению с ZFS - мне не нужен дикий ARC, который к linux VFS сбоку. И ни одна из них не умеет кэшить на SSD - есть просто bcache, который создает грабли с саспендом и гибернацией, есть LVM-cache, который настроить не просто (там считать надо) и с которым можно огрести неиллюзорные грабли. Собственно, сжатие тоже как-то странную статистику показывает, но то, что у меня на 200 гиг раздел свободнее чем планировалось - таки да. uncompressed:         nr extents:             3684626         size:                   507 GiB compressed:         nr extents:             3724187         compressed size:        216 GiB         uncompressed size:      448 GiB incompressible:         nr extents:             10889179         size:                   622 GiB В общем, при наличии бэкапа - мне нравится. Без бэкапа я бы тыкать не стал как минимум до следующего LTS.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	75. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 15:26
	> Сижу на этом с 6.7-rc1 и впечатления пока что только положительные. > Есть минусы, но по сравнению с btrfs и zfs они просто ничтожны. Как говорится храбрым поем мы славу. А я пару багов вот собрал - так что на основных системах спасиб но что-то не хочется. Кой-что уже починено, но... сыровата она пока.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	81. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 15:32
	Естесно, что сыровата. У меня юзкейс примерно такой же, какой был бы на bcache (не fs), поэтому я особо париться не стал. Снепшоты мне нахрен не нужны, сабвольюмы тоже, nocow я не использовал (вот тут повезло). У меня, если что, бэкап припасён и делается раз в час всего, что мне надо - как бы пересоздать раздел и вытащить все из бэкапа - дело 10 минут и я знаю, на что иду. Так что про храбрость тут эт ты зря. Я ее использую потому, что тесты показали, а практика подтвердила - что оно мне жизнь упростило и волосы стали мягкими и шелковистыми. В бизнесовый прод это тащить, естесно, рано.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 16:40
	> Естесно, что сыровата. У меня юзкейс примерно такой же, какой был бы > на bcache (не fs), поэтому я особо париться не стал. Ну вот если кто юзал bcache, bcachefs это логичная для их пожеланий штука. Ибо это оно - но таки с filesystem-aware дизайном, что выглядит намного более удачной идеей. Моя проблема с этим всем? Судя по багам я не уверен насколько безопасно там гонять на продвинутых комбо. Там и в базовых есть приколы. Но не фатальные. И покамикадзить - можно, с пониманием что EXPERIMENTAL никого ни к чему не обязывал. > и вытащить все из бэкапа - дело 10 минут и я > знаю, на что иду. Так что про храбрость тут эт ты зря. Тогда возможно у вас много времени или данные не сильно ценные. А бэкап раз в час это круто. А сколько бэкапов и за какое время вы храните? Это полные бэкапы? Или некие дифференциальные? > Я ее использую потому, что тесты показали, а практика подтвердила > - что оно мне жизнь упростило и волосы стали мягкими и > шелковистыми. В бизнесовый прод это тащить, естесно, рано. Было бы нехило указать в чем именно жизнь проще стала :). Но вообще - файлуха интересная, баги - чинят, и довольно бодро. А Кенту всяческие респекты за упорство. Таки - дожал.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (34), 08-Янв-24, 17:06
	>гонять на продвинутых комбо. Кому-то это придется делать, так или иначе. Я уверен, что если всякие комбинации строить - оно отыквится очень быстро. И включение этого дела в майнлайн, я надеюсь, даст возможность желающим протестить и выкатить багрепорты. Главное, чтобы люди понимали, что это "для энтузиастов". >Тогда возможно у вас много времени или данные не сильно ценные. А бэкап раз в час это круто. А сколько бэкапов и за какое время вы храните? Это полные бэкапы? Или некие дифференциальные? В машину подрублена флэшка на 128 гиг, реально нужных данных - около 80 гигабайт (включая ~/.local, ~/.config и вот это всё. Музыка хранится на своем Nextcloud, Игрушки и скачанная сторрентов развлекуха и сериалы за важные данные не считаю. Бэкап делается borgbackup (рекомендую граф. оболочку vorta). Оно же и верифицирует. Т.к. мои нужные данные менются не то, чтобы целиком и полностью (пет-проекты, рабочие проекты, документы). Все данные, естесно, дублируются в NextCloud, а репозитории хранятся не только на локальной машинке, но и на сервере. Длинный только первый бэкап, потом оно клонирует только изменения (по сути подерживает репозиторий). Это не инкрементальные бэкапы в чистом виде. Подобным механизмом обладает и Proxmox Backup Server. По факту данные каждый раз дедуплицируются, получается. Надо мало места. Если случится звяздец - просто mkfs /home && mkdir /home/user && chown && chmod, а дальше пинаем боргбэкап из консольки и идем пить кофе. Т.к. флэшка USB3 и довольно быстрая на чтение - данные поднимутся минут за 10 и можно будет работать с абсолютно того же места, попутно перекачивая всякую развлекуху с торрентов. Потеряю максимум час работы, на практике меньше, буду расстроен, но ничего критичного. Проблема только в том, что надо иногда бэкапить саму флэшку на всякий случай и лапками контролировать состояние бэкапа иногда. >Было бы нехило указать в чем именно жизнь проще стала У меня у ноутбуке два SSD по 256 гиг и один HDD SMR на терабайт. На один SSD положил корень с ext4, из второго SSD и HDD собрал бутерброд с bcachefs... Жизнь стала проще в том, что всякие проектики, всё что мне нужно для работы находится в пределах одной ФС лежат теперь на SSD, профили браузеров, настройки часто используемого софта, диски виртуальных машин (и не полностью, а только используемыми частями) - все это в кэше хранится, а всякая хрень лежит на HDD, которую тыкаешь раз месяц. Да, кэш при обращении немножко подмывается, но SSD достаточно большой. Да и сжатие... При таком сетапе в ФС влезает примерно 1,1 терабайта, но хранится на ней сейчас уже терабайт и свободно при этом 200 гиг ещё. И всё в одной точке монтирования. >файлуха интересная, баги - чинят, и довольно бодро. если она сможет то, что заявлено со временем - она похоронит и btrfs и ZoL. Так что долгой жизни Кенту и жену не убивать. Да и пока что она обладает несколько более простым дизайном, насколько я понимаю, чем BTRFS и ZFS и если код не превратится в блоатварь - всё будет прекрасно (я надеюсь).
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 18:05
	>>гонять на продвинутых комбо. > Кому-то это придется делать, так или иначе. ... > Главное, чтобы люди понимали, что это "для энтузиастов". Ну вот мне - любопытно как оно будет на некоторых из моих кейсов. И как оно VS btrfs. И проч. > В машину подрублена флэшка на 128 гиг, реально нужных данных - около > 80 гигабайт (включая ~/.local, ~/.config и вот это всё. Такие флешки довольно сыкотные штуки. Я бэкапаюсь на (физически отключаемый после бэкапа) винч. Так даже пых питальника, крутой сбой или саботаж системы типа dd в блочный девайс и проч не страшен. > на своем Nextcloud, Игрушки и скачанная сторрентов развлекуха и сериалы за > важные данные не считаю. Это можно и перекачать. > и Proxmox Backup Server. По факту данные каждый раз дедуплицируются, получается. > Надо мало места. Дедупликация в бэкапах имеет свои траблы - при отклонении от идеала будет ой. Это же касается и длинных цепочек дифференциальных бэкапов. > в том, что надо иногда бэкапить саму флэшку на всякий случай > и лапками контролировать состояние бэкапа иногда. Ну вот да. Доверия USB флешкам, скажем прямо, немного. > только используемыми частями) - все это в кэше хранится, а всякая > хрень лежит на HDD, которую тыкаешь раз месяц. Да, кэш при > обращении немножко подмывается, но SSD достаточно большой. Да и сжатие... При > таком сетапе в ФС влезает примерно 1,1 терабайта, но хранится на > ней сейчас уже терабайт и свободно при этом 200 гиг ещё. > И всё в одной точке монтирования. По своему прикольно. Я пока в такие продвинутости не лазил, у меня btrfs с снапшотами на корне и там где вы будете пить кофе, я за минуту бутлоадером в старое состояние вернусь - и если это не разрушение блочного девайса, "как будто ничего не было". Я так разок отыграл на 1 компе неудачный апгрейд дебиана. Не понравилось как работает - ну и вернул за пару минут прошлую версию системы "в виде как было", 1 в 1. > если она сможет то, что заявлено со временем - она похоронит и btrfs и ZoL. Не уверен насчет btrfs - местами он имхо получше продуман, да и у них свои тузы в рукаве есть. А ZoL туда и дорога, я о out of tree уродах скучать не буду. Однако возможность многодевайсовых иерархий - это клево. > Так что долгой жизни Кенту и жену не убивать. Да и пока что она обладает несколько > более простым дизайном, насколько я понимаю, чем BTRFS и ZFS и если код не > превратится в блоатварь - всё будет прекрасно (я надеюсь). Пока код конечно заметно компактнее, но там и ряда фич нет. А пока все прикрутят, заоптимизят, зафиксят, ... ну блин, у меня самого иногда мелкая прога порой становится довольно увесистой такой штукой, почти на отдельный проект. А тут ФС целая.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 18:57
	> Ну вот мне - любопытно как оно будет на некоторых из моих кейсов. И как оно VS btrfs. И проч. Смотря для чего. Сжатие - огонь, оно вроде даже лучше чем у бэтра. Есть кэширование - что явно лучше чем у бэтра. Лично у меня ведет себя прекрасно. Всё остальное - хуже, инфа сотка. >Такие флешки довольно сыкотные штуки. Я бэкапаюсь на (физически отключаемый после бэкапа) винч. Ну поэтому флэшку тоже приходится бэкапить. А винт я ронял со стола со всеми вытекающими. SSD технически - та же флэшка. Так что так вот и живем. >Дедупликация в бэкапах имеет свои траблы - при отклонении от идеала будет ой. Это же касается и длинных цепочек дифференциальных бэкапов. Поэтому верификация и делается. Это фактически возможность распаковки проверяется. У меня - раз в неделю. >, у меня btrfs с снапшотами на корне и там где вы будете пить кофе, я за минуту бутлоадером в старое состояние вернусь А если "ФС быканет"? Не вернетесь. Снепшот -не бэкап, bcachefs тоже снепшоты умеет. Но, я боюсь, например, при порче суперблоков - снепшоты не жильцы. > местами он имхо получше продуман, да и у них свои тузы в рукаве есть. Одного поля ягоды. Просто bcachefs сможет очень таки не хило использоваться в файлопомойках, NAS, да и просто на десктопах, где 20 Тб SMR винт и приправлен терабайтным SSD. Это просто удобно и простой способ поднять отзывчивость хранилищ. Остальные фичи - такие же как и btrfs/zfs. Ну будет btrfs развиваться параллельно, никто его не выкинет просто так, а надобность в ZFS она отпадёт. BTRFS просто менее надежен By Design чем тот же ZFS. Если Bcachefs получит возможности btrfs и надежность zfs - он сожрет их обе когда-нибудь, вместе с ext4, lvm, luks, mdadm. Но вряд ли это случится в ближайшие 20 лет.
	Ответить | Правка | Наверх | Cообщить модератору

	264. Скрыто модератором	+/–
	Сообщение от Аноним (-), 09-Янв-24, 02:14
	> Смотря для чего. Сжатие - огонь, оно вроде даже лучше чем у бэтра. В сжатии нет универсального "лучше" как правило. Лучше для кого, по какому критерию? А zstd там и там есть например, и чего, zstd лучше чем zstd тогда? Это как? > Есть кэширование - что явно лучше чем у бэтра. Это прикольная фича. Но вот нету DUP, как я понимаю. Это трабл для 1-дисковых конфиг. > Лично у меня ведет себя прекрасно. Всё остальное - хуже, инфа сотка. Да я сам его погонял. В целом - оно даже работает и вот так сразу и фатально не убилось очевидными способами. Уже неплохо для первой версии, я б сказал :) > Ну поэтому флэшку тоже приходится бэкапить. А винт я ронял со стола > со всеми вытекающими. SSD технически - та же флэшка. Так что так вот и живем. Есть довольно большая разница уронить винч включеным и выключеным. А так я аккуратно обращаюсь с бэкапным драйвом, подцепил, сбэкапал, убрал в надежное место. > Поэтому верификация и делается. Это фактически возможность распаковки проверяется. У меня > - раз в неделю. Еще бывает так что данные ну вот засрались. А сразу это не очевидно могло быть. И даже если оно распакуется - некие шансы налететь все же есть. В случае чексум шанс на такую хрень нарваться заметно понижается. > А если "ФС быканет"? Не вернетесь. Снепшот -не бэкап, У CoW дизайна не так уж много точек где он реально быкануть может. Если б это "накопитель быканет" я б еще поверил. А сам по себе btrfs если не делать дурацких вещей и железо откровенного левака не делает - вроде вполне стабильный, никаких сюрпризов у меня за эн лет не было при том что у меня его есть. Но я чекаю коректность работы железа а не пытаюсь конопатить глюкастики использованием пофигистичной ФС. > bcachefs тоже снепшоты умеет. Но, я боюсь, например, при порче суперблоков - снепшоты > не жильцы. У btrfs'а - суперблоков как правило аж 3 штуки, в довольно разных "known" локациях. Вот умеет ли Grub альтернативные читать - это вопрос, конечно. Однако возможность отыграть все вплоть до сноса кернела пакетником - прикольно :) > Одного поля ягоды. Просто bcachefs сможет очень таки не хило использоваться в > файлопомойках, NAS, да и просто на десктопах, Ну, вот когда сможет, тогда и :). Пока же в нем довольно приличный поток багов. И некоторые аспекты недопилены. > Ну будет btrfs развиваться параллельно, никто его не выкинет просто так, > а надобность в ZFS она отпадёт. Лично я о ZFS скучать не буду, мне out of tree выкидыши не интересны. > BTRFS просто менее надежен By Design чем тот же ZFS. Хотелось бы инженерное обоснование этого храброго заявления. Особенно учитывая недавние новости где господа кораптили файло :) > Если Bcachefs получит возможности btrfs и надежность zfs - Ненене, не надо нам такую надежность, в недавних новостях они уже показали что там НА САМОМ ДЕЛЕ. > он сожрет их обе когда-нибудь, вместе с ext4, lvm, luks, mdadm. Я как-то не уверен что one size fits all. Но про ^^^^^^ я предпочту забыть всем скопом. > Но вряд ли это случится в ближайшие 20 лет. За 20 лет могут еще дизайнов настрогать. Или даже иных типов памяти. И там окажется что под их требования и тут что-то не так, и кто-то пойдет делать v4 идеи... кмк новые дизайны будут следовать лекалам проложеным btrfs и потом bcachefs а не вон теми дино :)
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Shevchuk (ok), 09-Янв-24, 07:14
	> Всё остальное - хуже, инфа сотка. Разверните плз — интересно. Я конечно скоро и сам погоняю тесты, но чужой опыт тоже полезен.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	483. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (483), 22-Янв-24, 07:07
	Да нечего разворачивать. По скорости и удобству - проигрывает, половина из заявленного не реализована, еще половина из реализованного - experimental. Так что аккуратно тут... Ну и в экзотических случаях не протестировано.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 08-Янв-24, 14:39
	А причинами поинтересоваться? Btrfs поддерживает несколько режимов хранения в пределах одного волюма, т.е часть файлов может лежать в raid0, а часть в raid1 Сколько места осталось зависит от того, как ты файлы будешь записывать
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	68. "Релиз ядра Linux 6.7"	+/–
	Сообщение от t (??), 08-Янв-24, 15:16
	а как такое реализовать? это вот то что мне надо, но как сделать такое физически я не нашел.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 15:28
	Никак. Потому, что RAID в бэтре - это почти фикция.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 16:41
	> Никак. Потому, что RAID в бэтре - это почти фикция. Вот неправда ваша - RAID1 и DUP в btrfs совершенно точно работает. Вполне нормально. И весьма недурно парирует отклонения от идеала, даже довольно дурацкие, типа накопителя выдающего левак или бэдсектор.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 17:16
	Я не говорил, что он не работает. Я говорил, что он не спасет от проблем ФС, а проблемы у этой ФС при сетапе RAID0/RAID1 на одной файловой системе будут.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 18:07
	> Я не говорил, что он не работает. Я говорил, что он не > спасет от проблем ФС, а проблемы у этой ФС при сетапе > RAID0/RAID1 на одной файловой системе будут. Странно - как же я тогда RAID1 пользуюсь? Нельзя ли поподробнее о том какие именно у меня должны быть проблемы с RAID1?
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 18:58
	>> Я не говорил, что он не работает. Я говорил, что он не >> спасет от проблем ФС, а проблемы у этой ФС при сетапе >> RAID0/RAID1 на одной файловой системе будут. > Странно - как же я тогда RAID1 пользуюсь? Нельзя ли поподробнее о > том какие именно у меня должны быть проблемы с RAID1? Чукча не читатель? Часть ФС в RAID1, часть в RAID0. ВОт про это разговор.
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 09-Янв-24, 18:14
	>> Странно - как же я тогда RAID1 пользуюсь? Нельзя ли поподробнее о >> том какие именно у меня должны быть проблемы с RAID1? > Чукча не читатель? Часть ФС в RAID1, часть в RAID0. ВОт про это разговор. Это несколько отличается от "RAID в бэтре - это почти фикция" я б сказал. RAID1 в нем совершенно точно работает и никаких особых косяков с этим нет. Прекрасно достает копию взамен профакапленой и чинит в фоне например.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 08-Янв-24, 16:11
	А вот с этим есть ньюанс, пока это не настраивается) Можно получить смешанную фс если начать ребаланс с -dconvert, и не закончить его. Старые файлы останутся со старым raid, новые будут с новым. В будущем когда-то профиль будет настраиваем per-file/per-subvelume. Однако корень этого функционала уже реализован, и в mixed режиме ФС работает, ну и соответственно реализации df это мешает
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	110. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 16:44
	> Можно получить смешанную фс если начать ребаланс с -dconvert, и не закончить > его. Старые файлы останутся со старым raid, новые будут с новым. Можно также просто выставить новые дефолты - и вообще ничего не конвертить. Новые записи будут в новом формате, старые - в прошлом. Самому по себе дизайну этой штуки - оно нормуль. Он для порядка скажет в dmesg что видит такое, но ни к каким проблемам это не ведет. > соответственно реализации df это мешает Если кто не в курсе, Кент уже и 8% расхотел резервить, и ENOSPC vs GC познал, и некие фиксы отображения свободного места - таки ну вот concern в продвинутом дизайне, у которого возможно не тупое как дрова поведение а некая палитра действий.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 17:10
	> Если кто не в курсе И баги эти уже исправил. >некие фиксы отображения свободного места Собственно, это фиксы не того случая, когда свободного места нет, а оно показывается. В bcachefs это by design не может быть.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 18:11
	>> Если кто не в курсе > И баги эти уже исправил. Да он там хорошо разогнался, раза три фиксил. Попользовавшись -rc по полной. >>некие фиксы отображения свободного места > Собственно, это фиксы не того случая, когда свободного места нет, а оно > показывается. В bcachefs это by design не может быть. Мне кажется что вы несколько идеализируете design и что в таких штуках (не)может быть. Даже для классики можно - вот - аллицировать хоть все место под метаданные, не записав в регион данных ни байта. При этом формально мы ни 1 байта на полезное содержимое не тратили - а места нет. На этом эффекте какой-то юморист даже архивер писал, он все данные распихивал в ИМЕНА файлов, это была попытка выиграть контест сжатия. Он спросил можно ли несколько файлов. Можно! Ну он и! Формально суммарный вес данных файлов - ноль :). А то что все ушло в метаданные... не, приз ему вроде таки не дали - это читерство. Де факто вся просто аллокация ушла в метаданные. И вот это есть даже в совсем классических ФС.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 19:03
	>ллицировать хоть все место под метаданные, не записав в регион данных ни байта. Проблема в том, что в bcachefs место, аллоцированное под метаданные считается занятым. Т.е. аллокация этого пространства -> 0 свободного места в df. В btrfs (устал уже повторяться) - свободно 50 гигабайт, а записать в нее ничего не можем. Ребаланснуть не можем, удалить ничего не можем, потому что места мало. В btrfs все пространство поделено на так называемые buckets.И если все buckets аллоцированы - оно не покажет свободного места.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 09-Янв-24, 02:23
	> Проблема в том, что в bcachefs место, аллоцированное под метаданные считается занятым. Оно у всех будет откусывать от свободного места. Просто потому что описание создаваемых файлов надо где-то хранить. Так что то что df кажет и то что будет на самом деле - совпадать не обязано. А файлы 0 размера - это дурной утрированый пример, когда ФС целиком из метаданных состоит. Данных и нет. И вот все место спущено - при том что суммарный вес файлов 0 байтов. В менее дурных случаях - data to metadata ratio не есть мировая константа и варьируется в зависимости от того что записываем. > нее ничего не можем. Ребаланснуть не можем, удалить ничего не можем, > потому что места мало. На данный момент такое поведение не является типичным. > В btrfs все пространство поделено на так называемые buckets.И если все buckets > аллоцированы - оно не покажет свободного места. Не, не так. В btrfs оно аллоцируется в chunks. И если все аллоцировано, есть некоторые проблемы с data to metadata ratio если вдруг оно круто изменится. Но вообще с неких пор оно умеет подгребать малоиспользуемые chunks и как я уже сказал - по общей идее действа оба дизайна как бы конвергируют к чему-то похожему, с разных сторон (у bcachefs аллокация buckets, по иным правилам, и они довольно мелкие, а chunk btrfs - типично гиг, но можно и изменить вроде, одно время по 5 делали по дефолту но это оказалось плохой идеей и вернули как было).
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (239), 08-Янв-24, 23:42
	Там ещё нюанс, само упоминание будущих планов по реализации такого замечательного режима хранения данных найти можно только в кеше гугла со старого их сайта. А если не копаться в старых, сто лет назад удаленных, планах то окажется, что нет и никогда не будет никаких per-file и per-sub. Было бы хорошо, но нет.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	263. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 09-Янв-24, 02:12
	> окажется, что нет и никогда не будет никаких per-file > и per-sub. Было бы хорошо, но нет. В мейлинг листах это несколько раз обсуждалось, и даже предлагалось как это можно реализовать В планах это также есть, mixed режим не забрасывают, баги с ним фиксят, не оставляют исключительное как промежуточное состояние. Но да, пока не реализовано.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 15:24
	И на кой это ей, если она сама рассыплется так, что костей не соберешь при исправных накопителях? Имею опыт рассыпания этой ФС без всяких рейдов, данные спасти не удалось от слова совсем, потому что похерилось b-дерево полностью каким-то образом. Собсна, все эти рейды в btrfs, насколько я понимаю - та еще лотерея, т.к. метаданные если криво запишет - они не спасут. А у бэтра это самая частая проблема, если железки будут консьюмерские и не особо дорогие. Так как другие ФС так не дохнут - то, собсна, ой. А ещё этот бэтр при scrub у меня находил коррапченные файлы... Переусложненная и с хреновым дизайном она.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	79. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (-), 08-Янв-24, 15:30
	> И на кой это ей, если она сама рассыплется так, что костей не соберешь > при исправных накопителях? Имею опыт рассыпания этой ФС без всяких рейдов, > данные спасти не удалось от слова совсем, > потому что похерилось b-дерево полностью каким-то образом. Вообще-то на нормальных накопителях и исправном железе b-деревья не улетают вникуда. У вас никаких чудес типа дров от нвидии не было случайно? Они не так давно чудно выносили ядерную память через DMA и по этой линии я видел трупы как минимум XFS, EXT4 и btrfs. > Переусложненная и с хреновым дизайном она. Обычно вон то случается у владельцев глюкавого хардвара где ext4 как-то коптил но работал, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы. Или у счастливых обладателей глючных конфиг рушаших память так или иначе.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 15:46
	>Вообще-то на нормальных накопителях и исправном железе b-деревья не улетают вникуда. На нормальных ФС они вникуда не улетают. После гибернации ноутбук не проснулся. Скорее всего, оно по какой-то причине его полностью решило пересобрать или не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает. >У вас никаких чудес типа дров от нвидии Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС. Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на другой системе), но перезагрузка штатная и fsck решала. Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если бы это был btrfs - с данными я бы попрощался. >, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы. Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем на том же сетапе. Вот в чем бяда. И если ext4/xfs в общем-то попроще значительно, то ZFS - мультикомбайн шиздец какой и тоже переусложнён на мой взгляд местами (имею опыт восстановления с него данных - разобраться во всех его кишках было очень проблематично). Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так - то RAID становится бесполезен. И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу? В случае с RAID0 они размазываются на два диска как RAID0? =). Да и с raid1 замена диска - печаль: Device removal must satisfy the profile constraints, otherwise the command fails. Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате в тот же RAID0 можно здорово обгадиться при конверте в RAID10. Собсна, потому и говорю, что переусложнена - действия, которые должны быть простыми для пользователя, зачастую, оказываются весьма не тривиальными.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (120), 08-Янв-24, 17:14
	> На нормальных ФС они вникуда не улетают. После гибернации ноутбук не проснулся. Вообще-то при этом буфера сбрасываются и проч. Возможно в этот момент пошло что-то очень сильно не так - и память вынесло настолько что аж "ноутбук не проснулся". В нормальном железе с безглючным low level софтом - вон того не бывает. > Скорее всего, оно по какой-то причине его полностью решило пересобрать или > не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает. Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился, и что там в ФС записалось, возможно при сбросе буферов - ктулху б его знает. > Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС. Это очень храброе утверждение для ситуации "ноут не проснулся", намекающей что что-то довольно конкретно обломалось где-то на системном уровне. > Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на > другой системе), но перезагрузка штатная и fsck решала. Это видите ли когда как. Везение имеет свойство заканчиваться. > Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если > бы это был btrfs - с данными я бы попрощался. На btrfs в случае чего как-то больше опций потрепыхаться - запись изначально недеструктивная, это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. А в EXT4 если что-то не то запислось - упс, никаких старых версий и альтернатив, картина репина приплыли. И если fsck не выдюжил или полегло много... >>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы. > Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем Если хардавар не выходит из хибернации - он не в порядке. Если рушится EXT4 - тоже что-то идет не так. > - разобраться во всех его кишках было очень проблематично). Я в анатомию ZFS не очень сильно лазил - мне его дизайн не нравится, он не только переусложненный. но и - это еще и бессмысленно. Я не понимаю почему это недоразумение - замечательно. С другой стороны дизайн btrfs я более-менее раскурил. Bcachefs субъективно более хаотичный и там меньше архитектуры. Но общие core идей слизаны с btrfs. Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... реалии, конечно, оказались чуть прозаичнее. Перфоманс у bcachefs пока не чемпионский, фороникс даже уже померял чутка. А без backrefs операции связанные с троганием данных из логического смещения (ремув девайса, ряд сервисных операций и проч) - таки тупят и вон там Кент уже задумался что какой-то индекс нехило бы. Если его в рантайм строить это ессно просадит перфоманс. А если "когда потребовался" - это роняет перфоманс операций менеджмента. Такой вот tradeoff. > Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так > - то RAID становится бесполезен. На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. Если конечно данные факапнулись в памяти еще до того как в RAID отреплицировано - против такого лома приема конечно нет. Но с "ram corruption" что угодно дохнет, и я не только видел прецеденты но и данные с такого рекаверил, довольно неудобно ибо там обычно живого места нет. > И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу? По какому настроите! Хоть RAID1C4 (4 копии) - если девайсов на это есть и увеличение вчетверо не парит. Но такой хардкор имеет смысл имхо на конфиге с ECC, и заведомо стабильной системе. У btrfs могут быть разная схемы для данных и метаданных, более того - можно на ходу рестрайпнуть, это даже относительно безопасно благодаря логике CoW (у меня как-то powerloss был на компе где я конвертил схему). У bcachefs примерно та же идея. Кент передрал эту клевую идею. Воон там выбирается число копий и данных, и метаданных. В mkfs - точно. В рантайм, как в btrfs, переигровку реплик - пока не пробовал с ним, но вроде тоже можно. > Да и с raid1 замена диска - печаль: > Device removal must satisfy the profile constraints, otherwise the command fails. Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, если девайс живой, но его хочется вынуть, лучше btrfs device add нового, и потом remove старого. С него будут удвинуты данные - в том числе и на новый. Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой. Тоже обыгрывается как add нового -> remove старого, и там подшаманить профайл метаданных как раз придется - оно заметив второй диск радостно RAID1 для метаданных начинает юзать. Это немного клещится с планом вон тот девайс отобрать. Но решаемо конверсией профайла метаданных. Если кто захочет это повторить - не забудьте бутлоадер и загрузочные флаги на новом накопителе, иначе можно будет немного обломаться. FS UUID при этом фокусе не меняется, так что менять монтирование рутфс и проч не надо. > Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате > в тот же RAID0 можно здорово обгадиться при конверте в RAID10. В btrfs мало чего прибито на гвозди. Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу. И это безопаснее чем в других штуках. Оно аллоцирует данные в чанках, у чанка есть "схема хранения". И конверсия профайла это так: берется файл и его данные, из чанков старого типа. Пишется в новые, с новой схемой. Если прокатило - "указатели" в метаданных начинают показывать на новый вариант, и процесс продолжается. А при крахе - старое состояние никуда не делалось, новая недописаная версия - игнорится, ее еще не успели пометить как аллокацию. > Собсна, потому и говорю, что переусложнена - действия, которые должны быть > простыми для пользователя, зачастую, оказываются весьма не тривиальными. Звездо> На нормальных ФС они вникуда не улетают. После гибернации ноутбук не проснулся. Вообще-то при этом буфера сбрасываются и проч. Возможно в этот момент пошло что-то очень сильно не так - и память вынесло настолько что аж "ноутбук не проснулся". В нормальном железе с безглючным low level софтом - вон того не бывает. > Скорее всего, оно по какой-то причине его полностью решило пересобрать или > не знаю, как так вышло, а на барьеры дешевым девайсам плевать бывает. Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился, и что там в ФС записалось, возможно при сбросе буферов - ктулху б его знает. > Нет, у меня была система AMD+AMD. Тут косяк был именно в самой ФС. Это очень храброе утверждение для ситуации "ноут не проснулся", намекающей что что-то довольно конкретно обломалось где-то на системном уровне. > Вот в ядре 6.7-rc* корраптилась ext4 после гибернации (уже на > другой системе), но перезагрузка штатная и fsck решала. Это видите ли когда как. Везение имеет свойство заканчиваться. > Счас вроде как все работает по уму, но я продолжаю наблюдать. Подозреваю, что если > бы это был btrfs - с данными я бы попрощался. На btrfs в случае чего как-то больше опций потрепыхаться - запись изначально недеструктивная, это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. А в EXT4 если что-то не то запислось - упс, никаких старых версий и альтернатив, картина репина приплыли. И если fsck не выдюжил или полегло много... >>, т.к. ему все пофиг а рассыпавшиеся файлы - ваши проблемы. > Ну вот хардвар в порядке был и на xfs/ext4/zfs небыло проблем Если хардавар не выходит из хибернации - он не в порядке. Если рушится EXT4 - тоже что-то идет не так. > - разобраться во всех его кишках было очень проблематично). Я в анатомию ZFS не очень сильно лазил - мне его дизайн не нравится, он не только переусложненный. но и - это еще и бессмысленно. Я не понимаю почему это недоразумение - замечательно. С другой стороны дизайн btrfs я более-менее раскурил. Bcachefs субъективно более хаотичный и там меньше архитектуры. Но общие core идей слизаны с btrfs. Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... реалии, конечно, оказались чуть прозаичнее. Перфоманс у bcachefs пока не чемпионский, фороникс даже уже померял чутка. А без backrefs операции связанные с троганием данных из логического смещения (ремув девайса, ряд сервисных операций и проч) - таки тупят и вон там Кент уже задумался что какой-то индекс нехило бы. Если его в рантайм строить это ессно просадит перфоманс. А если "когда потребовался" - это роняет перфоманс операций менеджмента. Такой вот tradeoff. > Я к чему. BTRFS хорош, но если мы потеряем b-деревья вот так > - то RAID становится бесполезен. На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. Если конечно данные факапнулись в памяти еще до того как в RAID отреплицировано - против такого лома приема конечно нет. Но с "ram corruption" что угодно дохнет, и я не только видел прецеденты но и данные с такого рекаверил, довольно неудобно ибо там обычно живого места нет. > И, собственно, вопрос: а метаданные там зеркалятся? По какому принципу? По какому настроите! Хоть RAID1C4 (4 копии) - если девайсов на это есть и увеличение вчетверо не парит. Но такой хардкор имеет смысл имхо на конфиге с ECC, и заведомо стабильной системе. У btrfs могут быть разная схемы для данных и метаданных, более того - можно на ходу рестрайпнуть, это даже относительно безопасно благодаря логике CoW (у меня как-то powerloss был на компе где я конвертил схему). У bcachefs примерно та же идея. Кент передрал эту клевую идею. Воон там выбирается число копий и данных, и метаданных. В mkfs - точно. В рантайм, как в btrfs, переигровку реплик - пока не пробовал с ним, но вроде тоже можно. > Да и с raid1 замена диска - печаль: > Device removal must satisfy the profile constraints, otherwise the command fails. Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, если девайс живой, но его хочется вынуть, лучше btrfs device add нового, и потом remove старого. С него будут удвинуты данные - в том числе и на новый. Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой. Тоже обыгрывается как add нового -> remove старого, и там подшаманить профайл метаданных как раз придется - оно заметив второй диск радостно RAID1 для метаданных начинает юзать. Это немного клещится с планом вон тот девайс отобрать. Но решаемо конверсией профайла метаданных. Если кто захочет это повторить - не забудьте бутлоадер и загрузочные флаги на новом накопителе, иначе можно будет немного обломаться. FS UUID при этом фокусе не меняется, так что менять монтирование рутфс и проч не надо. > Ну и вообще вот с профилями и, соответственно, странными дефолтами при формате > в тот же RAID0 можно здорово обгадиться при конверте в RAID10. В btrfs мало чего прибито на гвозди. Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу. И это безопаснее чем в других штуках. Оно аллоцирует данные в чанках, у чанка есть "схема хранения". И конверсия профайла это так: берется файл и его данные, из чанков старого типа. Пишется в новые, с новой схемой. Если прокатило - "указатели" в метаданных начинают показывать на новый вариант, и процесс продолжается. А при крахе - старое состояние никуда не делалось, новая недописаная версия - игнорится, ее еще не успели пометить как аллокацию. > Собсна, потому и говорю, что переусложнена - действия, которые должны быть > простыми для пользователя, зачастую, оказываются весьма не тривиальными. На самом деле эти звездолеты с машиной времени довольно просты в пилотировании - после того как основные принципы поймешь. Да, это отличается от классики. И только. У Кента на мой вкус управление пока немного хаотичнее но в целом по образу и подобию, ибо общие идеи такие же. С прикручиванием к bcachefs-like идее, что так то добавляет аспектов в управлении. У кента можно нарулить иерархическую хранилку - с записью на быстрый буфер и медленным реплицированием с него вооон туда, и кешированием "горячего" на быстрый носитель. Но при этом в отличие от bcachefs оно явно в курсе реплик и их состояния. Так что вероятно будет несколько лучше bcache - который легко убивает файлухи наповал как только быстрый накопитель затерся.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (45), 08-Янв-24, 13:51
	>ZFS. Продавшиеся же давно
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	134. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 18:01
	>В нормальном железе с безглючным low level софтом - вон того не бывает. Бывает всякое. Да, накрути ECC-память, диски с суперконденсаторами, да строго соответствующие спецификации и т.п. А надо, чтобы работало на обычном консьюмерском железе, которое исправное, но вот может не успеть, например, сбросить кэш при выключении при некотрых специфических условиях. И то, что ФС потеряла b-дерево и не смогла обратитсья к предыдущей его копии - это, таки, настораживает, бо в суперблоке должна быть ссылка и на старые и на новые данные. >Судя по тому что ноут вообще не проснулся - я бы скорее поставил на то что у вас RAM крепко порушился "не проснулся" в данном случае означает, что он тупо завис после выхода из гибернации на картинке логина. И это не говорит о том, что RAM порушилась, т.к. после реинсталла ОС и на другой ФС этот же ноут отработал ещё 5 лет без единого сбоя, пока я его кофе не напоил. Были какие-то специфичные условия, которых btrfs не пережила. Я же не зря выше оговорился, что проблемы у нее будут на "не дорогом консьюмерском" оборудовании. >Это очень храброе утверждение Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных, записанную ранее и не может отреплеить журнал. Т.е. у нас фактически запись не прошла и мы не можем смонтироваться - так надо реплеить журнал, которого не оказалось, вместе с b-деревом. Точнее, оно там было и я уверен, что восстанови я структуру вручную или обратись к тем, кто понимает структуру этой ФС на уровне разработчиков - все бы оттуда вытащилось. Оборудование, кстати, больше не сбоило. >Это видите ли когда как. Везение имеет свойство заканчиваться. Это разница в подходе. Когда ext4 обнаруживает, что crc в метаданных не совпадает - оно начинает ругаться и прекращает всческую запись, уходя в RO. BTRFS в аналогичной ситуации проблем не заметит, т.к. она их замечает только при очередном scrub. >больше опций потрепыхаться Больше секса без видимого результата. Могу и по пунктам, но ext4 _значительно_ проще в силу того, что btrfs всё же CoW. И сырые данные с BTRFS восстановить почти не возможно, если будет утеряна структура ФС в силу CoW (упс). >это давет возможности опробовать разные варианты с использованием чуть более старых версий деревьев и проч. Чето в моем случае этих старых версий деревьев чего-то как-то не оказалось, а вручную дигать по диску в поисках копии данных я как бы это... Данные столько не стоили. Правда теперь у меня появился не только бэкап, но и проверка его содержимого, ага. >Если хардавар не выходит из хибернации - он не в порядке Софт безгрешен? >Если рушится EXT4 - тоже что-то идет не так. Да. В ядре 6.7 менялись некоторые механизмы, ога. Отсюда и проблема была, хи хи. И хардварь конкретно в данном баге ну вот вообще не при делах. При том, что из гибернации выходит и работает и даже может _штатно_ перезагрузиться. >но и - это еще и бессмысленно. Я не понимаю почему это недоразумение - замечательно. В сравнении с btrfs у него хотя бы аналог RAID5 работает и необходимости ребаланс (resilver) на каждый чих делать нет. А еще оно умеет в slog и L2ARC, оно ЗНАЧИТЕЛЬНО надежнее btrfs by design. Но формат там весьма сложен, да. >Хитрец Кент думал что ща он отломает backrefs, снизит оверхед, перфоманс и втопит... Не думаю, что он вот именно так рассуждал, но в отличие от btrfs он тянет лямку в одно хлебало. Тесты похороникса вообще с реальностью ничего общего зачастую не имеют. >На RAID так то обычно и деревья (и вообще метаданные) в минимум 2 копиях. >Но с "ram corruption" что угодно дохнет, Записываю: btrfs безгрешен и ошибок в алгоритмах иметь не может. Ещё раз: даже если это был @ram corruption@ - данные должны быть восстановимы. Всё. >, довольно неудобно ибо там обычно живого места нет. Да, если файловая система не имеет средств контроля. Именно поэтому та же ext4 имеет чексуммы метаданных, что почти сразу скажет о проблемах. При чем в рантайме. А вот btrfs не проверяла на момент моего крэша такое. Кент вон на это посмотрел и в планах коды рида-соломона прикрутить. >По какому настроите! Ага. Т.е. если изначально это был RAID0, то при превращении в RAID10 метаданные останутся в RAID0, ибо в документации это написано, но недостаточно очевидно. Хе-хе. >Кент передрал эту клевую идею. Тваю за ногу... bcachefs родилась из bcache, а не btrfs. И да, число копий метаданных настраивается, но не так, как в btrfs. И число данных тоже. Там каждый девайс имеет параметр durability. Т.е. при создании ФС указываешь число реплик для данных и метаданных и дальше при добавлении девайсов просто указываешь ему durability. Ты даже можешь raid аппаратный подсунуть и указать durability ему выше единицы, тогда данные, записанные на такой девайс могут и не реплицироваться, например. И т.д. и т.п. У btrfs же какаой-то секс с профилями и прочим При том - не всегда очевидный. Не надо говорить, что кто-то у кого-то передрал. Смиритесь, что некоторые вещи где-то могут быть реализованы лучше, а где-то хуже. >Можно грубо отключить и перестроить из degraded - но "плавный" вариант намного лучше, Бла-бла-бла. Посыл был не об этом. Если я хочу вынуть девайс из рейда - должно быть максимум две команды (отправить его в статус fail, а после вынуть). Но там предлагается несколько больше... >Де факто оно позволяет даже очень странные вещи, типа замены диска под работающей системой Охренеть странные вещи. Любой raid-контроллер, mdadm, LVM, ZFS это позволяют. И даже bcachefs. Дальше все что описано - ну ... Дичь же. Не надо ничего нигде шаманить - помечаем устройство сбойным и ынимаем, либо сразу вынимаем... Без шаманств с профайлами метаданных. Почему в btrfs это сложнее? >Схему хранения для данных и метаданных можно переиграть по желанию, прям на ходу Вообще-то я про неочевидность говорю. То, что это можно - это несомненный плюс. >На самом деле эти звездолеты с машиной времени довольно просты в пилотировании - после того как основные принципы поймешь. Да да да. Всё просто, когда знаешь. Мне вот ZFS сейчас проще кажется ;). >ибо общие идеи такие же Общие идеи - они впринципе проистекают как раз от ZFS, если уж так судить, да и до нее промелькивали. А про хаотичность... Ну не знаю, не знаю. Будем посмотреть, btrfs все же корпорации делать пытались, а не какой-то перец в одно хлебало. >будет несколько лучше bcache - который легко убивает файлухи наповал как только быстрый накопитель затерся. Эээ... Оно их убьет наповал, если там writeback. В остальном - ничего он не сломает. А у случае с writeback - ну... таки здесь как раз тот случай, когда сам по себе тип кэша именно смерть ФС при повреждении и подразумевает.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 08-Янв-24, 18:16
	> Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных, записанную ранее и не может отреплеить журнал. Т.е. у нас фактически запись не прошла и мы не можем смонтироваться - так надо реплеить журнал, которого не оказалось, вместе с b-деревом. О каком журнале вообще речь? В btrfs CoW, не журналирование
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 18:20
	CoW и журналирование это вообще разные вещи. Вон в bcachefs есть и журналирование и CoW. А в BTRFS накосячили By Design. Поэтому она такая ненадежная, ну. Нормальная ФС _знает_, что запись не прошла после резкого отключения питания. А BTRFS - _не знает_.
	Ответить | Правка | Наверх | Cообщить модератору

	350. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 23:03
	> CoW и журналирование это вообще разные вещи. Вон в bcachefs есть и > журналирование и CoW. А в BTRFS накосячили By Design. Поэтому она > такая ненадежная, ну. Поразвелось экспертов млин. Там ващет есть некий минимальный журнал под внутренние нужды, просто он далеко не главный элемент пейзажа в случае CoW, которые эквивалент полного журналирования достигают несколько иначе - сделав "журналом" всю площадь ФС. Откуда и нужда в GC, дабы неактуальное подчищать. Иначе из-за недеструктивной записи в сторону место постепенно кончится. Сложный GC и отложенная по времени деаллокация - это обратная сторона таких паттернов дизайна. В большинстве случаев это не проблема, но на интенсивно нагруженной ФС, забитой под завязку это следует учитывать по линии рисков ENOSPC (если забыть про фрагментацию и проч). > Нормальная ФС _знает_, что запись не прошла после > резкого отключения питания. А BTRFS - _не знает_. А ему оно на самом деле и не надо. В CoW запись недеструктивная. И это как-то так: пишется новое, если прокатило - на это перевешивается "указатель" (апдейтятся метаданные). Если не прокатило (крах), то что получается - аналог 100% rollback зафейленых потуг. Ибо той записи никогда не существовало, это неаллоцированое место а вид ФС "немного более старый". А старое состояние никто и не уничтожал. Когда-то потом, если вон там все прокатило, за ним может и пришел бы GC, если больше никому эти блоки не нужны были. Btrfs забавен тем что делает "рекурсивный" вариант трюка - к метаданным это все тоже применяется, по своему красивый фокус, изначально разработка кого-то из IBM чтоли. Технически это эквивалент полного журналирования. Только без тормозов от двукратной записи. И таки слеты питания оно вполне себе переживает в общем случае. В частных - выключение SSD, и вообще флешатины, без команды шатдауна ДО снятия питания является технически-некорректным деянием (FYI - логится в смарте) и там уже никто ничего не гарантирует, начиная с производителя накопителя. Так что если что - а вот там в смарте все ходы записаны!
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 08-Янв-24, 18:19
	И вообще судя по другим веткам... Ты случаем не использовал writeback кеш с btrfs? Потому что он с btrfs не работает, writeback кеш ломает CoW by-design
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	152. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 18:23
	writeback кэш ничего не ломает. Writeback ломает только в том случае, если его что-то скорраптит. Но в случае с btrfs кэширование было writethrough, потому что я боялся, что SSD сдохнет из-за износа в силу непонимания реального ресурса NAND.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 08-Янв-24, 18:27
	> writeback кэш ничего не ломает. Btrfs написан так, что ожидает что записи на диск пройдут в определённом порядке Сначала дерево обновили, затем записали указатель В случае с writeback, реальные записи на диск могут пройти в произвольном порядке, и вот тогда уже всё может сломаться, поскольку может возникнуть например ситуация что был записан указатель на ещё не существующую ветвь дерева. Существует не так много способов получить catastrophic failure на btrfs, и это один из них.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 19:08
	>Btrfs написан так, что ожидает что записи на диск пройдут в определённом порядке Ну. А если у диска отработал NCQ и пропало питание (часть данных не записалась) - то данные запишутся уже не в том порядке. Поэтому btrfs может сдохнуть просто на носителе с большим буфером, который не успеет сбросить все на блины, и на твердотельнике с большим DRAM при активной записи и удраконенном флэше без всяких кэшей. >В случае с writeback, реальные записи на диск могут пройти в произвольном порядке, и вот тогда уже всё может сломаться, поскольку может возникнуть например ситуация что был записан указатель на ещё не существующую ветвь дерева. Как это повлияет на ФС, если не записанные данные читаются из кэша, а не с бэкграунда? Никак. А вот если часть кэша пропадет внезапно - хана файлухе. До меня дошло. Ты, наверное, про writeback в RAM? Неа. Writeback на SSD я счас использую. Т.е. SSD у меня Writeback-кэш, а не оперативка, которая будет потеряна при сбое питания. Тогда это был bcache с writethrough.
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Релиз ядра Linux 6.7"	+/–
	Сообщение от morphe (?), 09-Янв-24, 02:24
	> А если у диска отработал NCQ Btrfs следит за тем в каком порядке данные доходят до диска, однако в случае с bcache "диск" ответит об успешности записи моментально, и btrfs будет считать что запись действительно прошла. И до реального диска они дойдут в произвольном порядке уже, т.к тут btrfs уже не знает что происходит. > Ты, наверное, про writeback в RAM? Нет, про любое writeback кеширование в bcache для btrfs. Это где-то в lkml обсуждалось, но лень искать, а в arch wiki есть такой вот блок текста Bcache write caching can cause a catastrophic failure of a btrfs filesystem. Btrfs assumes the underlying device executes writes in order, but bcache writeback may violate that assumption, causing the btrfs filesystem using it to collapse. Use bcache in writeback mode with btrfs at your own risk.
	Ответить | Правка | Наверх | Cообщить модератору

	359. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 01:30
	> Ну. А если у диска отработал NCQ и пропало питание (часть данных > не записалась) - то данные запишутся уже не в том порядке. Для начала - вы ОБЯЗАНЫ подавать команду шатдауна до снятия питания с SSD, если кто вдруг не в курсе. По спекам. Нарушение этого условия зачастую логгится и накручивает соотв счетчик, так что если что, гарантия там и проч, вам видимо этот счетчик и предъявят. "Нарушение условий эксплуатации". При снятии питания без предупреждения с флешовыми девайсами может быть что угодно, в зависимости от дури фирмвари, интенсивности записи и вашего (не)везения. Вплоть до слета трансляции или продолба здоровенных ERASE BLOCK'ов которые оно там в фоне ворочало во имя GC на уровне своего FTL и проч. И нет, никакая фс не готова к тому что кус на ...цать мегов просто возьмет и продолбается. Ну, btrfs с избыточностью -  починит, конечно и это тоже, если было откуда. Собссно scrub имеет смысл пинать для обнаружения таких подарков. Потому что обнаружить что копия данных битая в момент когда она понадобилась - довольно хреново.
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	484. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (483), 22-Янв-24, 07:18
	Т.е. я при перезагрузке сервера по питанию должен как-то при его зависоне подать команду отключения во флэш? Вот насмешили. И продолб 20 метров - вот ваще не проблема для нормальной ФС. Ну, а на счет флэша с дерьмовымми прошивками... НУ да, могут сдохнуть. Но тут даже HDD могут сдохнуть во время внезапного пропадания питания (запил поверхности, отвал головок от удара об рампу, вынос медиакэша к чертям - так вообще продолб минимум 50G минфы (если очень повезет, а обычно - слет транслятора). Чего уж тут. Речь идет о том, что нормальная ФС маленько по иному барьеры расставляет и данные на диск раскладывает (если они важны) в несколько копий. А не так, что бэкап суперблока один на устройство.
	Ответить | Правка | Наверх | Cообщить модератору

	487. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 23-Янв-24, 07:24
	> Т.е. я при перезагрузке сервера по питанию должен как-то при его зависоне > подать команду отключения во флэш? Вот насмешили. И продолб 20 метров > - вот ваще не проблема для нормальной ФС. Учитывая что это RMW + GC, там в принципе бывает что угодно, смотря насколько дурная фирмварь и ее логика и что там случилось. Это - unspecified! Может слететь партишн. Особенно если вы не в курсе концепции Erase Block/Erase Group и не сделали выравнивание и "guard area". Может слететь суперблок. Или дохрена метаданных. Btrfs с его DUP и несколькими суперами даже сможет потрепыхаться. С RAID1 - вообще самопочинится влет, а если у вас будет более обычный RAID, он при налете на десинк девайсов будет в полном ауте. Может слететь транслятор. И тогда если вам данные нужны - вы пойдете в DR лабу. И отвалите кучу денеш. Потому что оно не то что совсем не читается, но выглядит интересно. И сами вы это не почините. > Ну, а на счет флэша с дерьмовымми прошивками... НУ да, могут сдохнуть. Покажите мне у кого прошивки без греха? Это стремные багованые глюкала. У всех. Ну вон самс, крупнейший (?) производитель флеша на планете. Жуткое глюкало в FW. Везде. > Но тут даже HDD могут сдохнуть во время внезапного пропадания питания (запил поверхности, Для современных HDD не характерно: при этом там просто автопаркова на рампу. > так вообще продолб минимум 50G минфы (если очень повезет, а обычно > - слет транслятора). Это SSDшный failure mode вообще, изначально (анти)фича флешатины. А если кто хотел влезть в оба мира он и оба набора проблем получил. > Чего уж тут. Речь идет о том, что нормальная ФС маленько по иному барьеры > расставляет и данные на диск раскладывает Вообще-то недеструктивность записей btrfs как раз обеспечивает выживаемость оных в случаях когда многие другие запиливаются насмерть и без плана Б. А хранение по дефолту 2 копий метаданных даже на 1 носителе (схема DUP) дает куда больше шансов при отклонениях от идеала. А есди у EXT4 ...цать мегов улетят нафиг - плана Б нет и если не понравилось то что вышло, что хотите то и делайте. > (если они важны) в несколько копий. А не так, что бэкап суперблока один на устройство. У btrfs 2 бэкапа супера на девайс + по дефолту DUP метаданных даже на 1 устройство или RAID1 на >1 устройства (схема данных и метаданных могут отличаться). Если девайсов много, можно для метаданных RAID1C3/C4 (3 или 4 копии) юзать вообще.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 08-Янв-24, 20:28
	> Бывает всякое. Да, накрути ECC-память, диски с суперконденсаторами, > да строго соответствующие спецификации и т.п. А надо, чтобы работало на обычном > консьюмерском железе, которое исправное, но вот может не успеть, например, > сбросить кэш при выключении при некотрых специфических условиях. Глядя на Unsafe shutdown count == 102... ну, вот, за 102 попытки на этом SSD не сдох вроде :). А должен? Тем не менее - если буфера не скинули, команду на шатдаун накопителю тоже поди не послали. А так и весь eraseblock/erase group можно профачить, а то и таблицы транслятора. И ни 1 ФС не готова к тому что слетит 64-128 мегов или сколько там erase group - который in flight когда вы там питание грохнули без подачи команды на шатдаун. Имеет право слететь без подачи такой команды - накопитель сам внутрях GC и проч тоже гонял. > И то, что ФС потеряла b-дерево > и не смогла обратитсья к предыдущей его копии - > это, таки, настораживает, бо в суперблоке должна быть ссылка и на старые > и на новые данные. А там что, RAID не было и даже DUP? Что за ошибка была? В суперах ссылка на последнее консистентное состояние. Но есть опции монтирования с попыткой заякориться за другие деревья на случай если хрень все же почему-то случилась. Это не есть нормальная ситуация, потому - мануально. > "не проснулся" в данном случае означает, что он тупо завис после выхода > из гибернации на картинке логина. Я бы дал 50/50 что в RAM какая-то труха образовалось. > И это не говорит о том, что RAM порушилась, т.к. после реинсталла > ОС и на другой ФС этот же ноут отработал ещё 5 лет без единого сбоя, > пока его кофе не напоил. А это все в каком году и с каким кернелом было? Я просто про более-менее современные версии, скажем, ядра 6.x - а что там в 2.6.32 было я и не знаю, ибо в курсе что бесплатный сыр достается второй мышке, надо просто подождать :) > Я же не зря выше оговорился, что проблемы у нее будут на > "не дорогом консьюмерском" оборудовании. Я ее гоняю на самом разном хардваре. Очень интересно, где обещанные проблемы? > Косяк ФС в том, что она при COW не сохраняет ссылку на копию метаданных, Есть опция монтирования usebackuproots, вообще-то. > записанную ранее и не может отреплеить журнал. У нее почти нет журнала в привычном понимании, так, зачатки минимальные. Но если с ними проблемы, опять же - опция монтирования есть чтобы забить на реплей. А в целом - cow никуда прошлые состояния не девает и при крахе по сути просто игнорит то что записано но - "указатели еще не перевешены" и этого как бы никогда не было. Неплохо работает вроде. > Т.е. у нас фактически запись не прошла и мы не можем смонтироваться - > так надо реплеить журнал, которого не оказалось, вместе с b-деревом. В btrfs записи недеструктивные, на минутку. Так что красивая теория но не про btrfs. > кто понимает структуру этой ФС на уровне разработчиков - все бы оттуда вытащилось. Да там небось как максимум надо было nologreplay и/или usebackuproots. Правда кто вас знает в каком это году... > Это разница в подходе. Когда ext4 обнаруживает, что crc в метаданных не > совпадает - оно начинает ругаться и прекращает всческую запись, А на данные - он класть вообще хотел. С прибором. Основной регион - это данные. Более того, если метаданные не прочлись, ну там бэд или труха с накопителя, EXT4 ловит нехилое фаталити. Плана на этот случай совсем нет. И никаких копий метаданных тоже. Так что урон очень даже. Btrfs даже с 1-девайсной конфигой хранит метаданные в схеме DUP, и чаще всего может вынуть их из второй копии. На этом фоне EXT4 - как бы это сказать? Они CRC там не от хорошей жизни сделали, но в случае RAID например они не смогут умно читануть вторую копию с исправной версией. Если райд diverged - что хотите то и делайте, во! Хитрый план! Но мне btrfs'ный план ака читануть вторую копию, починить из нее убитую - нравится больше. Кенту этот план тоже по вкусу. > BTRFS в аналогичной ситуации проблем не заметит, Да неужели? У него чексумы на вообще все, и на метаданные, и на данные. > т.к. она их замечает только при очередном scrub. Булшит, оно замечает (и даже чинит в фоне, если есть откуда) при любом чтении. > Больше секса без видимого результата. Могу и по пунктам, но ext4 _значительно_ > проще в силу того, что btrfs всё же CoW. Он не только проще - но и фатальнее при отклонениях от идеала. Избыточности нет, возможности умно ей пользоваться даже если RAID и был (прицельно перечитать блок метаданных с второй копии) - тоже нет. Это динозавр. Плевавший на данные пользователя - чексум данных нет, а полный журнал конечно есть но это для совсем мазохистов. Никто более не проектирует ФС по этому паттерну. Его время вышло. > И сырые данные с BTRFS восстановить почти не возможно, если будет утеряна > структура ФС в силу CoW (упс). Чтобы вообще совсем снести весь btrfs в ноль надо нехило потрудиться. У него три копии суперов по зело разным смещениям, возможны разные точки входа в деревья, офлайн-вычитывалка в комплекте которая умеет вот это вот. И если даже ЭТО не смогло ничего нащупать - так там наверное и от данных мало что уже есть. И мне даже неудобно говорить что вычитка путем полного скана поверхности требует дофейхоа времени, дает много битых файлов, ведет к потере имен, и эта операция уж точно не для казуалов. А датареки за это уже прилично обдерут, т.к. довольно неудобный случай. > Чето в моем случае этих старых версий деревьев чего-то как-то не оказалось, А вы usebackuproots пробовали? > а вручную дигать по диску в поисках копии данных я как бы это... В команду "btrfs" встроен кроме всего прочего офлайн парсер на совсем тухлый случай. Man btrfs-restore в общем. Не, на ext4 такого тула нет. Во всяком случае штатно и под линух. Под винду на нтфс сторонние утили с своим парсером - да, но это сторонние проприетарные коммерческие проги. А тут прям в родном тулките ФС. У кента кстати этого тоже нет вроде, как минимум пока. > Данные столько не стоили. Правда теперь у меня появился > не только бэкап, но и проверка его содержимого, ага. А бэкап так то не лишний в любом случае. Should never happen как бы да, а бэкапы как бы вот. Потому что случаи бывают разные. >> Если хардавар не выходит из хибернации - он не в порядке > Софт безгрешен? Иногда даже бывает сложно понять кто и что. Если скажем при программировании DMA автомата в адресах облажались и прострелили кернелу мозг - это софт или хард? Так можно было, проверено как минимум нвидией, и файлухи ЭТО выносит на ура :). Вон там нвидия поубиваля хомякам их EXT4 и XFSы какой-то относительно недавней версией драйвера. > Да. В ядре 6.7 менялись некоторые механизмы, ога. Отсюда и проблема была, > хи хи. И хардварь конкретно в данном баге ну вот вообще не при делах. Это тоже случается. Я в контексте btrfs такое же примерно выловил и помог замочить пару ядер назад - но btrfs вообще попался только потому что рефактор его зацеплял. Вероятно и других цепляло - просто у меня были конкретные тестовые конфиги под -rc ядра где это вылезло я и отпинал бтрфсников, они доперли что это к mm/ и попинали их. Так клевый датакарапшн не прилетел на ваши бошки в энных случаях. Хотите мне еще рассказать что бывает? :) >> Я не понимаю почему это недоразумение - замечательно. > В сравнении с btrfs у него хотя бы аналог RAID5 работает Ага, тут недавно была новость как там что на самом деле работает. Там где про разрушение данных если быстро делать копии копий. Заодно всплыло немало интересного как господа фичу рефлинков выкатили - включив по дефолту, для тестов на хомяках. Ну и тестанули. Test failed ахнул гентушник билдивший go. > умеет в slog и L2ARC, оно ЗНАЧИТЕЛЬНО надежнее btrfs by design. Нехило бы это громкое заявление технически обосновать. Особенно учитывая что недавно у господ вышел сочный факап по линии их чудных кешей. И можно я скажу что Кент кеширование на SSD намного вменяемее продумал чем ZFSный бред? > Но формат там весьма сложен, да. Он не просто сложен - я так понимаю что он супертормоз и это вытягивают заливанием гигазами оперативы. Не вижу с чего этим структурам быть быстрыми. Это не bcachefs. И даже не btrfs. Какая-то полублочная муть. На которую, вот, рефлинки цать лет пытались, а когда смогли, крякнул кеш. > Не думаю, что он вот именно так рассуждал, но в отличие от btrfs он тянет лямку > в одно хлебало. Тесты похороникса вообще с реальностью ничего общего зачастую не имеют. Я немного сравнил с btrfs - и каких-то радикальных улучшений так с наскока не увидел. В принципе понимаемо - кенту пришлось идти на компромиссы для майнлайнинга, потом отыграет часть. > Записываю: btrfs безгрешен и ошибок в алгоритмах иметь не может. Может ессно. Проверено ZFS'ом недавно :). Но даже после такого фееричного обтекания вашего фетиша сватать его вам стыд глаза не ест... > Ещё раз: даже если это был @ram corruption@ - данные должны быть восстановимы. Всё. Откуда бы это все следует? Ну и в btrfs возможностей с этим потрепыхаться и читануть таки либо маунтом либо офлайн парсером - сильно больше чем в среднем по больнице. А выгрызать их фотореками всякими - удовольствие сильно ниже среднего. Как практикующий этсамое грю. > ext4 имеет чексуммы метаданных, что почти сразу скажет о проблемах. Пардон, но 1) Он нихрена с этим не сделает уже. 2) Он не парится насчет данных. А метаданные мне нужны только для доступа к данным и самоценности не имеют. И я не ок с отсутствием чексум данных, как угодно. Примерно 99% проблем с integrity в случае btrfs - на регионе ДАННЫХ было отловлено. Так что мне трогательная забота данных - не приболела, извините. Как и весь динозаверский дизайн с фиксированой аллокацией инодов. > Кент вон на это посмотрел и в планах коды рида-соломона прикрутить. И оно как бы похвально, вопрос в том не познакомится ли он с комбинаторным взрывом... > метаданные останутся в RAID0, ибо в документации это написано, но недостаточно очевидно. Я только 1 случай знаю когда btrfs сам умничать может - если 1-девайс с DUP до 2 добавить, метаданные будут RAID1 тогда. Но это внезапно может проблемы создать, если план был второй девайс вынуть. Такая автоматика может сделать мозг. И таки совершенно валидно RAID0 для данных и RAID1 для метаданных, так метаданные будут выживать сильно лучше, а если у части данных избыточности не было - ну, досадно, но урон небольшой. > Тваю за ногу... bcachefs родилась из bcache, а не btrfs. Если описывать его в 2 словах это выглядит примерно как гибрид первого со вторым. Часть кода похоже вообще скопипастили 1 в 1 - обработчик "same extent" у обоих был подозрительно похожий. Дальше он конечно в свои кишки по другому уже. > И да, число копий метаданных настраивается, но не так, как в btrfs. Не так - но в целом идея довольно похожая. И опять же - вот - разное число копий вполне валидною. А аллокация в buckets имеет что-то общее с chunks, хотя и отличий - есть. Такое ощущение что они пытаются конвергировать к чему-то - заходя с разных сторон. > И число данных тоже. Там каждый девайс имеет параметр durability. > Т.е. при создании ФС указываешь число реплик для данных и метаданных и дальше > при добавлении девайсов просто указываешь ему durability. У btrfs унутрях в чем-то похожая идея. Для данных и метаданных есть дефолтовая схема хранения для их блоков. И в конечном итоге RAID1 это "2 копии". С3/С4 - 3 и 4 соответственно. И мое частное мнение - кент с Durability хлебнет горя, когда умные клавы доверятся черти каким райдам, и тут окажется что обе копии было там - и это не прозрачно для ФС - так что re-read копиии с целью фонового репайра - "агащас!" и вот на ка тебе заваленый пул, золотая рыбка, ибо нефиг такое делегироватоь всякой мутной ср@ни c уровня ФС. Правда этот прострел пяток на усмотрение стрелков, но кмк - прострелы будут. > Ты даже можешь raid аппаратный подсунуть и указать durability ему выше единицы, Ага. А потом попробуй оттуда re-read если что-то все же ну вот не прочлось... КМК кент таки познакомится с теми кто на "кульной фиче" налетит. > У btrfs же какаой-то секс с профилями и прочим При том - не всегда очевидный. На самом деле примерно то же самое по смыслу. И кент секса тоже добавит с RAID56 и прочими ридсоломонами постепенно. > Не надо говорить, что кто-то у кого-то передрал. Смиритесь, что некоторые вещи > где-то могут быть реализованы лучше, а где-то хуже. Кент мог смотреть на 2 дизайна - и ессно имел все шансы учесть их траблы. Но дело в том что он уже заметил что некоторые решения вон там были не просто так. Как с backrefs... :). И вот уже оказывается что Кенту и самому скорость операций менеджмента и GC - "не очень". Зато backrefs не передрал. Пока. Это разгоняет перфоманс - но при желании отменеджить эту экономию захочется проклянуть. Ибо теперь вынуть девайс - уже не так уж просто и быстро. > Если я хочу вынуть девайс из рейда - должно быть максимум две команды > (отправить его в статус fail, а после вынуть). Кому должно? С чего? RAID1 вообще не должен штатно работать с 1 девайсом. Только degraded. В таком виде можно его и совсем без команд получить, выдернув накопитель. > mdadm, LVM, ZFS это позволяют. И даже bcachefs. Btrfs тоже. Я даже именно этот сценарий пару раз делал. А ваша вкусовщина - это ваша вкусовщина. На мой вкус вы и возитесь с вашими LVM, mdadm и ZFS. Я же предпочту без этого секса. И да, кентовская штука управляет местом "примерно как btrfs". Т.е. для нее не проблема подоткнуть или вынуть девайс и получить +N места, из-за аллокации bucket'ами. По общей логике это именно btrfs косплеит. Да, есть отличия, и все же. Оно сможет в ту же прелесть ненапряжного расширения места и ремува девайсов. Без делания мозга выравниванием и размерами. В отличие от блочных уродцев. Это то что у него как в btrfs. > Без шаманств с профайлами метаданных. Почему в btrfs это сложнее? Да там горе от ума походу. Ну, бывает :). Мне похрен ибо столь странная операция была нужна пару раз в жизни. При том вообще в научных целях - посмотреть, смогу я под живой системой системный девайс сменить без отвалбашки на горячую?! Мне была интересна технологическая валидация такой возможности. Это на самом деле дает довольно интересные технологические возможности фикса системы в режиме нонстоп. Как в анекдоте где хирург оперирующий на сердце садится в авто, заводит, и говорит мужику в автосервисе - мол, хочешь получать как я? Тогда чини авто вот так, как я твое сердце. Мне было интеерсно прочекать технологическую возможность смены накопителя под ОС без ее стопора. С btrfs этот фокус прокатил. > Да да да. Всё просто, когда знаешь. Мне вот ZFS сейчас проще кажется ;) А мне он нафиг не упал с его внемайнлайн проблемами и античным дизайном. Штука кента - оно в майнлайне и "Gen3" идеи, совсем другой разговор. > Общие идеи - они впринципе проистекают как раз от ZFS, если уж так судить, Частично - да. Но у ZFS вроде как раз и нету такой "пофайловой" аллокации места на девайсах, когда можно абы какие девайсы абы как добавлять-вынимать и там аллокация места "as needed", с пофигом на выравнивания и размеры девайсов. Это довольно круто придумано и делает менеждмент простым и ненапряжным. И это уже не блочный райд, ближе к "файловому", грубо говоря, это -  решение уровня аллокатора ФС, как вон то раскладывать. Для меня это довольно четкая граница водораздела по технологиям. Либо тупой блочный RAID, либо такая вот динамическая аллокация без прогрева мозга. В ZFS разве это было? > btrfs все же корпорации делать пытались, а не какой-то перец в одно хлебало. Поэтому архитектуры там все же побольше. Зато у Кента задора и упорства на троих хватит. И он уже мог смотреть на чужие траблы. Это ценный козырь, так что ряд проблем btrfs он обошел. Но вероятно получит ряд других. > Эээ... Оно их убьет наповал, если там writeback. В остальном - ничего он не сломает. В случаше bcachefs - ему статус реплик по накопителям - и факапы их чтения - виднее будут. А на фс подпертым bcache - они феерично сыпятся когда bcachе выгружает им баааальшой блок трухи с кешового накопителя. От такой диверсии ФС могут развалиться вдрызг. И я видел эн таких случаев. Btrfs'ники обычно замечают подарки по ору в логах ДО того как все совсем уж профачится, а остальные - вот как повезет. > именно смерть ФС при повреждении и подразумевает. Кент крут тем что увязал реплики с кешом. Кеш стал частью логики реплик - и на него теперь распостраняются все гарантии схемы хранения. Даже если он сдохнет или вернет труху, это теперь может обработано как любой иной сбой чтения реплики. А если работать на блочном уровне как bcache - это знание урыто на стыке уровней, нельзя осмысленный re-read и self heal сделать с другой копии вот так по простому. ФС с полными чексумами типа btrfs могут еще попытаться что-то изобразить, но получится ли это - без гарантий ибо оно не контролирует IO с копиями и успех этого маневра ниоткуда не следует. А вот если оно явно рассматривает кеша как реплику, и запрошено более 1 реплики, окей, оно сможет вынуть другую реплику вместо осыпавшейся - и проблемы как бы и нет. Ибо оно уже таки как раз может контролировать процесс.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	159. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 08-Янв-24, 18:29
	В продакшене в основном применяют ext-ы и xfs. Навороченные ФС в первую очередь нужны для бедных.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	396. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 15:16
	> В продакшене в основном применяют ext-ы и xfs. Навороченные ФС в первую > очередь нужны для бедных. А когда фйэсбук обнищать успел, не подскажете? Цукерберг тоже вместе с ним?
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 15:23
	> Если там не раздутый бегемот как Btrfs и не окаменевшее ископаемое как > ZFS то можно даже попробовать на чем-то некритичном. Сделан "по мотивам" btrfs - но с прицелом на шустрые сторажи и потому минимальный оверхед, а еще там иерархиеческое кеширование на уровне выбора девайсов и куда записывать. Так то прикольно придумано. Но багов пока есть, для прода пожалуй рановато. За время -rc раза 3 фиксы были т.к. довольно заметные проблемы вылезли при тесте толпой на майнлайне.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	76. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 15:26
	Для энтерпрайзного прода - рановато, а вот накатить на десктоп (у вас же бэкапы есть?) - вполне можно.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 08-Янв-24, 15:36
	> Для энтерпрайзного прода - рановато, а вот накатить на десктоп > (у вас же бэкапы есть?) - вполне можно. Я на десктопе работы работаю. И если ФС взбрыкнет а мне проект надо было доделать - это не айс. Вы не боитесь, я это добро потестил на VM. И таки огреб эн багов, показал причастным - половины уже нет. В целом оно в принципе юзабельно. Но... 1) Разработчики btrfs времени зря не теряли и с всеми их оптимизациями - bcachefs никаких особых революций в перфомансе не показывает, по сравнению с ними. Как минимум - пока. Впрочем сейчас вопрос о том чтобы оно вообще работало без косяков - а оптимизациям свое время. И вот тогда поговорим об этом. 2) Некоторые фичи все же откровенно WIP. Или совсем не запилены. В частности parity/reedsolomon, и еще ряд. Но кенту всяческие респекты за упертость. Теперь в ядре две продвинутых CoW и это хорошо, некий выбор, небольшая конкуренция между тимами и проч совсе не вредно :)
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (34), 08-Янв-24, 15:54
	>Я на десктопе работы работаю. И если ФС взбрыкнет а мне проект надо было доделать - это не айс. Вы не боитесь, я это добро потестил на VM. И таки огреб эн багов, показал причастным - половины уже нет. Ну я тоже работы работаю, только у меня елси ФС взбрыкнет - я просто пересяду за другую машину... Так что мне как-то похрен. Работу работаю - это энтерпрайзный прод, всё же. Под десктопом я имею ввиду всё же не рабочую станцию, а приспособу для маловажных вещей для дома - кинчик посмотреть, в игрушку поиграть, в интернетиках посидеть. А про баги это правильно, я баги в amdgpu показывал, их вроде все успели вынести до релиза. >bcachefs никаких особых революций в перфомансе не показывает, Да и с чего бы их показывать, на самом деле? Киллерфича - это бутербродная компоновка девайсов - сиречь кэш. Вот, например, я захотел в танки поиграть на выходных - и первая загрузка с харда - мееедленная. Зато последующие - быстрые, пока мне танки не надоедят и я не переключусь на другую игрулю. writeback кэш - тоже ооочень приятно (у меня основным хранилищем тормозной SMR). >Некоторые фичи все же откровенно WIP. Или совсем не запилены. В частности parity/reedsolomon, и еще ряд Я там выше писал, в общем-то. Согласен полностью, тут дело даже не только в фичах, а есть мелкие огрехи в утилитах. Так что оно явно не заменяет собой ни btrfs ни zfs во всех юзкейсах. А вот кое-где оно уже всех уделало, теперь bcache не нужен (он имеет проблемы с саспендом/гибернацией). >Но кенту всяческие респекты за упертость. Это таки да. Если бы не гребаная политика - задонатил бы.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 17:35
	> Ну я тоже работы работаю, только у меня елси ФС взбрыкнет - > я просто пересяду за другую машину... Это как минимум перенос проекта и сетап рабочего окружения заново. Не то чтобы велкам. А затестить можно и на виртуалке, коих у меня есть. Они для этого удобны :) > Так что мне как-то похрен. Работу работаю - это энтерпрайзный прод, всё же. А у меня - режим сам себе режиссера. Впрочем у меня есть пара "запасных" компов и ноут, но вообще-то агрессивное маневрирование на "primary" воркстейшне не логично. Он как раз "продакшн", а воооон те компы как раз чтобы можно было системные эксперименты ставить даже если все развалится нахрен. Но виртуалки чинить и сетапить проще :) > вещей для дома - кинчик посмотреть, в игрушку поиграть, в интернетиках посидеть. У меня ситуация несколько иная. > А про баги это правильно, я баги в amdgpu показывал, их вроде > все успели вынести до релиза. Во! Это правильный подход к делу. Эй, ташкинов и прочие freehck, учитесь как надо было! > Да и с чего бы их показывать, на самом деле? Киллерфича - > это бутербродная компоновка девайсов - сиречь кэш. Вообще кентушка заморочился low overhead. Правда с тех пор и btrfs'ники - заморочились :) > и я не переключусь на другую игрулю. writeback кэш - тоже > ооочень приятно (у меня основным хранилищем тормозной SMR). Ну я как бы согласен что фича - весьма годная. Я до нее со временем доберусь имхо :) > только в фичах, а есть мелкие огрехи в утилитах. И не очень мелкие тоже. Скажем FUSE реализация - вообще труп по сути. Они конечно честно пишут что экспериментальная. Но это экспериментальное в экспериментальном. Впрочем без этого можно жить. > юзкейсах. А вот кое-где оно уже всех уделало, теперь bcache не > нужен (он имеет проблемы с саспендом/гибернацией). ИМХО главная его проблема - когда SSD на который оно кешило затирается, это имеет тенденцию гробить подкешированую ФС наповал. Блочный уровень слишком дубов и туп чтобы на это норм рагировать. ФС же будет видеть какие реплики нагнулись и если избыточность есть, сможет маневрировать куда разумнее. >>Но кенту всяческие респекты за упертость. > Это таки да. Если бы не гребаная политика - задонатил бы. Есть более 9000 способов помочь гражданину не деньгами так борзыми щенками. Даже вот отловить косяки - тоже способ сказать спасибо. Файлуха в целом улучшится, станет более привлекательной, на нее быстрее подсядет кто-то крупный, кто денег насыпет.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (34), 08-Янв-24, 18:16
	>Это как минимум перенос проекта и сетап рабочего окружения заново. Не то чтобы велкам. Я не знаю, с чем вы работаете и какие у вас сроки поднятия из бэкапа. Мне нужно убдет отойти на 10-15 минут и я потеряю максимум час работы. Не смертельно, но неприятно. Ну и я не пользуюсь всякими хитрыми фичами. Т.е. вероятность проблем - приемлемая для меня ). >Вообще кентушка заморочился low overhead. Правда с тех пор и btrfs'ники - заморочились :) Да все равно мы упираемся в сырую производительность носителей... Тут уже никуда не денешься, CoW - значит фрагментация, больше оверхеда и т.п. Понятное дело, что чем больше фич, тем медленнее - вон, fat12 так вообще шустрый был... Да, то, что он заморачивается - это хорошо, конечно. >Скажем FUSE реализация - вообще труп по сути. Не тыкал, не знаю, мне не нужно, я в этом конкретно вопросе не копенгаген, могу говорить только за то, что трогал :) >когда SSD на который оно кешило затирается, это имеет тенденцию гробить подкешированую ФС наповал. Падажжи. Если SSD затирается - он уходит в RO, либо отваливается совсем, либо не отдает прочитанные данные, так как чексуммы не совпадают и ECC не может уже их поднять у диска. А перед этим начинает сыпать в смарте проблемами... Т.е. в нормальном случае носитель должен быть заменен до того, как начнет отдавать мусор вместо данных. А вот если у нас writeback кэш и, как у меня, скажем, метаданные лежат ТОЛЬКО на SSD - то как он у меня умрет - умрут вместе с этим SSD и все данные, что лежат в background hdd. Тут все от сетапа зависит. Но если я увижу ошибки в smart (а я его контролирую) - возможно, я успею выставить durability=0 носителю и он превратится в writethrough и я спокойно смогу дожить до магазина ;). >Даже вот отловить косяки - тоже способ сказать спасибо. Чем и занимался, так-то. Просто при моем сетапе косяков не возникло а те, что есть - складируются и потом либо буду багрепортить, либо сам поправлю (хочу сам, например, баг со временем поправить).
	Ответить | Правка | Наверх | Cообщить модератору

	338. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 20:41
	> Я не знаю, с чем вы работаете и какие у вас сроки поднятия из бэкапа. Я тоже не знаю - ибо не требовалось, как максимум откат снапшота за пару минут. Странно взять звездолет с гипердрайвом и машиной времени и не попрыгать по мультивселенным с альтернативными реальностями. Да, это нелинейный менеджмент системы. Можно хоть эн параллельных веток эволюции отращивать. Или - send этого в VM -> receive -> о, мой десктоп теперь в VM где я и болтаю с вами. С снапшотами почти нет отличия между VM и bare metal... > Мне нужно убдет отойти на 10-15 минут и я потеряю максимум час работы. > Не смертельно, но неприятно. Ну и я не пользуюсь всякими хитрыми фичами. > Т.е. вероятность проблем - приемлемая для меня ). Я вот именно бэкапы делаю реже и на физически отключаемый винч, так что он переживет полный rm -rf, runaway dd в блочный девайс, или что там еще. А снапшот - скажем перед крупным апгрейдом системы и ключевого софта. Если не понравится, верну за 2 минуты как было "1 в 1". При том могу старый state оставить для изучения, в отличие от бэкапов. Мультивселенная! > Да все равно мы упираемся в сырую производительность носителей... В энтерпрайзных SSD - уже и в кишки ядра бывает. Потому и рефакторы типа folios, io_uring, вот это все. И для ФС рефакторы и редизайны тоже так то логичны. > Тут уже никуда не денешься, CoW - значит фрагментация, больше оверхеда и т.п. На самом деле вот именно оверхед имхо можно и поурезать, само по себе решение "куда писать выносок" и апдейт метаданных быть быстрыми не обязаны. Оверхед возможен на блоках с эн референсами, e.g. снапшотах, рефлинках, ... и у btrfs и bcachefs есть особенности, они несколько разные из за разного дизайна. Их актуально знать при активном использовании снапшотов. Это как с VM - там тоже ряд концепций в CoW дисках стоит понимать, не отращивая очень большие дельты или их разлапистые иерархии. > дело, что чем больше фич, тем медленнее - вон, fat12 так > вообще шустрый был... У него индексов нет, с большими иерархиями FAT тормоз! И алокация педальная, эктентов там IIRC нет. Так что современные ФС его могут легко сделать. Боолее того - билд кернела ворочает около 250К файлов. И это не напрягает. Даже на btrfs. На FAT - удачи! Вы и на NTFS то это взвоете, там в разы тормознее все. А при 100К файлов в 1 дире в ntfs наступает апокалиптец, чтения диры дождаться малореально вообще. > Да, то, что он заморачивается - это хорошо, конечно. У него неплохое мышление. Мне не нравится его хайп с растом, хотя-бы из соображений build deps, но оно в данный момент там опционально. >>Скажем FUSE реализация - вообще труп по сути. > Не тыкал, не знаю, мне не нужно, Убер-глючное на данный момент. Я бы мог найти пару сценариев где это имеет смысл, но для меня это low priority экспериментальная хрень, я сильно на вот это - не дергался. > Падажжи. Если SSD затирается - он уходит в RO, либо отваливается совсем, Щаззз! Есть еще минимум 1 режим отказов! Падлюка в меру дурости начинает выгружать порушеные данные, IO error не репортит - и нате вам шум океанов марса (видимо после неуспешного декодирования FEC). У меня даже такая флеха есть, но ЭТО замечено и для энтерпрайзных SSD под bcache, файлухи разумеется очень плохо на такие подарки реагируют и при игноре этого - осыпаются к хренам и зачастую наповал. Btrfs'ник с энтерпрайзным SSD попал под внимание потому что удивлялся: - А это не баг в ФС? Орет постоянно CSUM FAILED?! - А что за конфиг? - Блаблабла, энтерпрайзный SSD, bcache, ... - Не, чувак, это не баг в ФС! Срочно замени свой SSD под кешом! Иначе у тебя подохнет все и совсем. Я потом видел еще несколкько случаев ЭТОГО в более жесткой форме, юзеры ext4 и xfs такое обычно замечают слишком поздно, когда оно - уже совсем хренакс. Чексумы по всей площади способствуют отлову ЭТОГО до того как оно приобретет совсем злой масштаб. > либо не отдает прочитанные данные, так как чексуммы не совпадают и > ECC не может уже их поднять у диска. Или, как оказалось - отдает, левак какой-то. Btrfs в этом случае радостно орет на левые чексумы, чем хайлайтит полезность таковых лишний раз. У меня со временем даже такая флеха вот была отловлена и теперь у меня есть "reproducer", хоть и не энтерпрайзный, но поведение то же самое. > А перед этим начинает сыпать в смарте проблемами... Смарт рулится фирмварью и потому - его полезность и реалистичность весьма варьируется. > Т.е. в нормальном случае носитель должен > быть заменен до того, как начнет отдавать мусор вместо данных. Как показали господа "в интерьере" это обычно скорее так: - А чойта за баг в btrfs - csum failed?! - Упс, а чойта мой ext4 развалился и совсем не маунтится? Был на bcache... Несколько вот таких succes story навели тех кто интересовался вопросом на понимание определенного паттерна. > умрет - умрут вместе с этим SSD и все данные, что > лежат в background hdd. Ну вот когда ФС кешируется bcache и SSD делает вон то, разлет получается хорош. > я успею выставить durability=0 носителю и он превратится в writethrough и > я спокойно смогу дожить до магазина ;). КМК лучше хотеть durability == 2 (RAID1) для как минмум метаданных, а лучше и данных, если они ценные. И кстати EPIC WIN на эту тему что у кента что у btrfs мог бы быть если бы это можно было по файлам/дирам/subvol конфигурить, при том я готов поспорить что аллокатор сам по себе мог бы это обеспечить, просто конфигурационного интерфейса для такого нет. А желательно еще и устаканившегося и одинакового для ФС которые так умеют (с точки зрения настройки из юзермода). Next-gen дизайнам на самом деле душно с чистым POSIX. >>Даже вот отловить косяки - тоже способ сказать спасибо. > Чем и занимался, так-то. Просто при моем сетапе косяков не возникло а > те, что есть - складируются и потом либо буду багрепортить, либо > сам поправлю (хочу сам, например, баг со временем поправить). Весьма похвальный подход к делу :). Вот все бы так. Учитесь ташкиновы и freehck как на самом деле надо было :P.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Релиз ядра Linux 6.7"	+/–
	Сообщение от DEF (?), 08-Янв-24, 15:53
	К следующему LTS.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	384. "Релиз ядра Linux 6.7"	+/–
	Сообщение от fuggy (ok), 10-Янв-24, 12:46
	Что все так носятся с этой Bcachefs.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

6. "Релиз ядра Linux 6.7"	–2 +/–
Сообщение от Аноним (6), 08-Янв-24, 11:18
>> Прекращена поддержка архитектуры ia64 Быстро как-то. Интел совсем зажало бабло на свою "прорывную" архитектуру. Архитектуры 80 и 90стых столько лет тянулись, а тут хрясь и усё. Причём ia64 в продакшене ещё куча.
Ответить | Правка | Наверх | Cообщить модератору

	8. "Релиз ядра Linux 6.7"	+11 +/–
	Сообщение от Аноним (9), 08-Янв-24, 11:34
	Интел мягко намекает что этот цирк пора сворачивать.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Релиз ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (14), 08-Янв-24, 11:49
	И много новых итаников вышло за последние лет 10? Всё, корабль утонул, желающие плавать на обломках собрали свои костыли и новейшее ядро им нафиг не нужно
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	59. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (59), 08-Янв-24, 14:55
	Одно формально новое поколение таки вышло в 2017. Кто-нибудь, кстати, видел бенчмарки поздних итаников? Ни одного 9500-9700 найти не смог (9350 на spec.org есть).
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Релиз ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (20), 08-Янв-24, 12:08
	https://opennet.ru/59164-x86s
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	23. "Релиз ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (23), 08-Янв-24, 12:15
	23 года — это быстро? Нормально архитектура пожила. (Ну ладно, в Intel его похоронили несколько раньше.) А вообще если ретроспективно так: 1999 — Pentium III. 2000 — Pentium 4. 2001 — Itanium. 2003 — AMD64. Бодрое время было.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	70. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Олег (??), 08-Янв-24, 15:18
	Это общая тенденция всех производителей железяк Cisco вон вырезало кучу десятигиговых asr\nexus и т.д неговоря о гиговых Все что в продакшене активно вынуждено обновиться покупками, хотя не о каком упоре в скорости на том же 3064, asr1001 нет Просто больше прошивок не будет и делайте с железяками что хотите, а уязвимости так и прут...
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	95. "Релиз ядра Linux 6.7"	–3 +/–
	Сообщение от Аноним (95), 08-Янв-24, 16:03
	>а уязвимости так и прут... что значит прут? они ж там и были :-)
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от InuYasha (??), 09-Янв-24, 10:21
	Это значит - о них не знали. :)
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (301), 09-Янв-24, 08:06
	На эти ваши сиськи вообще никто не обязан обновления делать. Ставьте OpenWRT.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	94. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (95), 08-Янв-24, 16:01
	>ia64 в продакшене ещё куча. с линкусом вряд ли. вижу такое с чпуксом.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	141. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 08-Янв-24, 18:14
	> Быстро как-то. Интел совсем зажало бабло на свою "прорывную" архитектуру. Архитектуры 80 > и 90стых столько лет тянулись, а тут хрясь и усё. Причём > ia64 в продакшене ещё куча. Извини, но у актуального кернела и так вышел перекос по added VS removed очень сильно в пользу added. Это значит что проект стал больше. И с этим не поздравляют. Если активно изучать какого размера люди могут вообще воротить - можно однажды обнаружить что почему-то все же не бесконечного. Торвальдс не хочет быть тем кто узнает свои и чужие лимиты в этом деле.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	227. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от Олег (??), 08-Янв-24, 22:32
	Проблема ещё в том, что пилят все одно ядро по сути Нету иного подхода, т.е все идёт по одним рельсам, а ведь кроме рельс ещё летать можно, плавать, ходить...
	Ответить | Правка | Наверх | Cообщить модератору

	341. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 21:22
	> Проблема ещё в том, что пилят все одно ядро по сути > Нету иного подхода, > т.е все идёт по одним рельсам, а ведь кроме рельс ещё летать можно, плавать, ходить... Это не проблема - ибо "it works!". А раз так то не будем чинить то что не сломано. Да и юзермод - отдельно от ядра. А всякие out of tree драйверы? Не, спасибо, я этого уже в винде наелся, надоело проприетарное нефиксабельное глюкало от индусни, сорянчики!
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (193), 08-Янв-24, 19:25
	Itanium сдох. Да здравствует Эльбрус!
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	274. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (274), 09-Янв-24, 02:57
	Вначале был TeraScale, потом Itanium, а теперь наступает очередь Эльбрус.
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Релиз ядра Linux 6.7"	+/–
	Сообщение от voiceofreason (?), 10-Янв-24, 13:12
	Tilera в микротиках тоже vliw
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Релиз ядра Linux 6.7"	–3 +/–
	Сообщение от Аноним (301), 09-Янв-24, 07:46
	Линуксоид синоним халявщик. Так мало того что халвщик, так ещё и наглый. Всё лафа кончилась, нужна поддержка - пл0ти денги!
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	303. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (303), 09-Янв-24, 09:56
	А как выли про бесплатность,безопасность и прочее... В результате имеем шиш с маслом и красивые обои как в Венде.
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (312), 09-Янв-24, 12:00
	Хрена вам лысого, а не денег! Дешевле платформу сменить чем кормить алчных корпорастов.
	Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

	342. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 21:32
	> Линуксоид синоним халявщик. Так мало того что халвщик, так ещё и наглый. > Всё лафа кончилась, нужна поддержка - пл0ти денги! Прикольно тут у некоторых подгорает. А таки не помню чтобы с меня денег требовали за скачку сабжа. И поддержку мне "на халяву" майнлайншики обеспечили в лучшем виде. Правда, халява все же условная - ибо для этого надо уметь в самообслуживание и понимать их рабочие процессы. Но вообще-то я ничего зазорного в том чтбы тупицы и лузеры платили - не вижу. Не умеешь работать головой - работай руками!
	Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

	389. "Релиз ядра Linux 6.7"	+/–
	Сообщение от voiceofreason (?), 10-Янв-24, 13:11
	Архитектура оказалась неудачной для практических применений в компах и серверах, вот и всё. При более удачных обстоятельствах оно могло ещё как-то барахтаться вечно догоняя x86, но доктор сказал в морг - значит в морг
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

11. "Релиз ядра Linux 6.7"	–6 +/–
Сообщение от Аноним (11), 08-Янв-24, 11:45
> Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.7 - Linux-libre 6.7-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. Понятно, пол оборудования не заведется, зато "щвабодка".
Ответить | Правка | Наверх | Cообщить модератору

	19. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от YetAnotherOnanym (ok), 08-Янв-24, 11:59
	> Понятно, пол оборудования не заведется, зато "щвабодка". Зато заведутся возраст оборудования, дата выпуска, место регистрации и прочие анкетные данные.
	Ответить | Правка | Наверх | Cообщить модератору

	55. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 08-Янв-24, 14:43
	Т.е "пол" для тебя значения не имеет? Это... толерантненько, но не буду тебя осуждать))
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 21:44
	>> Понятно, пол оборудования не заведется, зато "щвабодка". > Зато заведутся возраст оборудования, дата выпуска, место регистрации > и прочие анкетные данные. Серийники, серийники не забудьте.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	386. "Релиз ядра Linux 6.7"	+/–
	Сообщение от YetAnotherOnanym (ok), 10-Янв-24, 12:48
	А, точно! Самое главное же!
	Ответить | Правка | Наверх | Cообщить модератору

	50. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 08-Янв-24, 14:26
	Наши революционные товарищи из Латинской Америки всё правильно делают. Никакой проприетарщины в ядре!
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Релиз ядра Linux 6.7"	–4 +/–
Сообщение от Аноним (14), 08-Янв-24, 11:46
>> Добавлена поддержка ARM SoC: Qualcomm Snapdragon 720G Интересно как мой редмик 9s работает на 4.14.190 где этой поддержки якобы не было до 6.7) Асло интересно бы посмотреть на мазохиста пытающегося впихнуть 6.7 на смарт|планшет. Даже гентушники таким не занимаются(но это неточно)
Ответить | Правка | Наверх | Cообщить модератору

	29. "Релиз ядра Linux 6.7"	+8 +/–
	Сообщение от commiethebeastie (ok), 08-Янв-24, 12:48
	На телефоне патченное ядро, ваш кэп.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (45), 08-Янв-24, 13:49
	ARM64 в Gentoo давно есть. Уже даже Loong появился.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	48. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Qq (?), 08-Янв-24, 14:14
	А что на них смотреть? Вон некий @nobodyAtall с XDA в своё время запихнул ядро 3.4х на устройство с 2.6х. Наверняка были еще, хотя я о них не знаю
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	52. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (52), 08-Янв-24, 14:31
	PostmarketOS часто ставит новые ядра в телефоны. Я вон недавно сидел на 6.5
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	119. "Релиз ядра Linux 6.7"	+/–
	Сообщение от soarin (ok), 08-Янв-24, 17:15
	> Асло интересно бы посмотреть на мазохиста пытающегося впихнуть 6.7 на смарт|планшет года через два увидишь повсеместно
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	221. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (14), 08-Янв-24, 22:01
	Разве что на 8 gen4, никогда не было чтобы ставили свежий кернел на не топы. Да и то по принципу "завелось и в продакшн", потому всякие agni ядра где мусор подчищен такие популярные.
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (285), 09-Янв-24, 03:32
	У меня 5.15 в смартфоне. Уверен уже есть смартфоны на 6.1 или скоро будут
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	288. "Релиз ядра Linux 6.7"	+/–
	Сообщение от aaa (??), 09-Янв-24, 05:59
	мазохисты вот здесь. И они пихают, иначе бы в ядро 6.7 поддержка не попала https://wiki.postmarketos.org/wiki/Xiaomi_POCO_M2_Pro_/_Redm...)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	323. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от пгуыыцрщ (?), 09-Янв-24, 14:24
	Гентушник не будет собирать ничего под сок в котором встроена официально подтвержденная спайвара, которую ты не выпилишь, даже собрав свою линейку: https://www.nitrokey.com/news/2023/smartphones-popular-qualc...     “Through these software applications, we may collect location data, unique identifiers (such as a chipset serial number or international subscriber ID), data about the applications installed and/or running on the device, configuration data such as the make, model, and wireless carrier, the operating system and version data, software build data, and data about the performance of the device such as performance of the chipset, battery use, and thermal data.     We may also obtain personal data from third party sources such as data brokers, social networks, other partners, or public sources.”
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

13. "Релиз ядра Linux 6.7"	–2 +/–
Сообщение от Аноним (13), 08-Янв-24, 11:47
>Добавлен параметр командой строки ядра "ia32_emulation", позволяющий на стадии загрузки включать и отключать поддержку эмуляции 32-разрядного режима в ядрах, собранных для архитектуры x86-64. Обязательно найдётся дистр с альтернативно-одарённым менеджментом, который будет собирать ядра с этой опцией. Я даже почти уверен, что это OpenSUSE, который по дропу платформ даже федору обогнал.
Ответить | Правка | Наверх | Cообщить модератору

	155. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от НяшМяш (ok), 08-Янв-24, 18:26
	Онанимы аргумент запуска ядра от флага компиляции отличить не могут. Ну будет сюся этот флаг по-умолчанию в граб пихать - пойдёшь и удалишь, в чём проблема-то.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 07:20
	А что у нас сейчас на 32 бита завязано? Навскидку разве что wine в голову приходит...
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

16. "Релиз ядра Linux 6.7"	–3 +/–
Сообщение от Аноним (16), 08-Янв-24, 11:52
>Добавлен вредоносный API для вредоносной аттестации виртуальных машин, предоставленных копирастами, для подтверждения целостности Digital Restrictions Management внутри них. Без аттестации в будущем не сможете делать ничего на "своём" компьютере. Ясно.
Ответить | Правка | Наверх | Cообщить модератору

	18. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 08-Янв-24, 11:59
	Для таких как ты есть Linux-libre, в нем нифга не работает, зато можно наслаждаться швободкой.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (208), 08-Янв-24, 20:36
	Ну кстати, это возможно полезная фича и для обратного - реверсинжененинга проприетарного софта.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	258. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (258), 09-Янв-24, 01:28
	Хрен ты его пореверсишь. Запускается образ ОС, он проходит удаленную аттестацию, после чего в него скачивается архив с программой. И сохраняется в зашифрованном виде. Память машины тоже зашифрована, ты её читать или менять не можешь. А ключ шифрования архива - в TPM 2.0, который прямо внутри процессора, передавать свои хэши как на TPM, который на отдельной гребёнке на матплате, ты на него тоже не можешь.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 21:38
	> Хрен ты его пореверсишь. Запускается образ ОС, он проходит удаленную аттестацию, > после чего в него скачивается архив с программой. И сохраняется в зашифрованном > виде. Память машины тоже зашифрована, ты её читать или менять не > можешь. А ключ > шифрования архива - в TPM 2.0, который прямо внутри процессора, ...или виртуального процессора, виртуальной машины, в qemu даже уже есть виртуальный TPM 2.0 кажется. Конечно кому очень уж принципиально сможет и понять что его наели, но сколько таких будет? А если qemu чуток подпатчить - они вообще не заметят что их наели. > передавать свои хэши как на TPM, который на отдельной гребёнке на матплате, > ты на него тоже не можешь. В случае виртуалазатора тот видите ли в принципе может показывать софту все что тот софт хочет видеть. TPM2.0 бывает и с открытой прошивкой, и вообще виртуальный. А если DRMщики запускают на вашем хосте свои VM без вашего на то согласия у вас так то всяко проблемы...
	Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз ядра Linux 6.7"	+1 +/–
Сообщение от YetAnotherOnanym (ok), 08-Янв-24, 11:57
> с часто используемыми данными на базе быстрых SSD Чтобы быстрее накрылись медным тазом > В exFAT добавлены ioctl-вызовы для чтения и изменения атрибутов ФС А раньше не было? Нормально. > В подсистему io_uring добавлена поддержка операций > в BPF-программах разрешено использования > логика передачи данных в которых задаётся при помощи BPF-программы Ждём новых открытий чудных.
Ответить | Правка | Наверх | Cообщить модератору

	21. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (23), 08-Янв-24, 12:09
	> Чтобы быстрее накрылись медным тазом Вы уже перенесли swap, /temp и /home на HDD?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 08-Янв-24, 15:22
	еле в продаже нашел, плюс завел аккаунт в OneDrive :)
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 08-Янв-24, 21:54
	Гоните. HDD без проблем продаются хоть на маркетплейсах, хоть в более-специализированных магазинах. Отзывы конечно забавляют, когда люди ноют что это не SSD, но в целом заявлять что рынок умер преждевременно.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 08-Янв-24, 23:39
	> без проблем продаются хоть на маркетплейсах купил как-то раз такой с болтами и песком в придачу :) - оказалась флешка на 2ТБ, именно на 2ТБ
	Ответить | Правка | Наверх | Cообщить модератору

22. "Релиз ядра Linux 6.7"	+/–
Сообщение от Аноним (22), 08-Янв-24, 12:09
>спин-блокировки Нехорошая калька. Либо "spin-lock" как в оригинале, либо идите выдумывайте, как благозвучнее слово spin перевести, особенно учитывая, что в оригинале оно ни к селу ни к городу употреблено, а лучше было бы loop-lock с полностью калькированным переводом как "цикл-блокировка", что также не благозвучно. А теперь вопрос опеннетчикам. Неужели вендоры процессоров не могли придумать инструкцию, которая заменяет активное ожидание в спинлоке путём исполнения команд проверки адреса в памяти на изменения на делегирование оного специальному модулю в процессоре, который будет делать то же самое, но не загружая конвейер и предсказатель ветвлений хламом? То есть спец. инструкция "остаёмся на той же инструкции, ждём нуля по такому-то адресу в памяти, когда дождались - переходим к следующей инструкции". При попадании на неё ядро включает блок спинлоков, занося в него адрес ячейки, которую надо наблюдать. При переключении контекста блок спинлоков сбрасывается. Блок спинлоков соответствено следит за кешем 1 и 3 уровня, и при записи / чтении в кэш по нужным адресам делает прьверки и будит ядро. Таким образом с одной стороны ядро не потребляет энергии во время спинлоков, а с другой это не прерывание, требующее переключерия контекста, поэтому так же быстро, как и спинлок. Даже быстрее - спинлок выполняет инструкции, то есть латентность будет по латентности инструкций в цикле, а такой механизм даст латентность по срабатыванию блока слежения за спинлоками.
Ответить | Правка | Наверх | Cообщить модератору

	33. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (33), 08-Янв-24, 13:15
	>Спин-блокировка или спинлок (англ. spinlock — циклическая блокировка) — низкоуровневый примитив синхронизации[1 циклическая блокировка
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Релиз ядра Linux 6.7"	+5 +/–
	Сообщение от YetAnotherOnanym (ok), 08-Янв-24, 21:09
	Крутильный запор.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (301), 08-Янв-24, 23:27
	Обратись к специалисту.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Zulu (?), 09-Янв-24, 02:03
	Поворотный затвор.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	320. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 09-Янв-24, 13:45
	Волчковая защёлка
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Релиз ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (151), 10-Янв-24, 00:02
	> Волчковая защёлка Щеколда, на калитке.
	Ответить | Правка | Наверх | Cообщить модератору

	424. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 10-Янв-24, 22:54
	Спасибо, так даже лучше: волчковая щеколдА это spinlock и защекОлда (за[порная] щеколда) - mutex. Положено начало отечественной науке о счётах, дело осталось за малым - придумать всё остальное
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Релиз ядра Linux 6.7"	+/–
	Сообщение от anonymmm (?), 08-Янв-24, 13:26
	есть mwait, но иногда спать нельзя фан факт: лок фри алгоритмы используют спин лок, кто активно крутится, тот не заблокируется))
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	113. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (113), 08-Янв-24, 16:59
	О, спасибо. Вот ещё что нагуглил: https://lwn.net/Articles/790920/ https://www.felixcloutier.com/x86/umwait и https://www.felixcloutier.com/x86/umonitor . Доступны для юзерспейсных процессов.  И https://www.usenix.org/system/files/usenixsecurity23-zhang-r... сразу же.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Релиз ядра Linux 6.7"	+/–
	Сообщение от fidoman (ok), 08-Янв-24, 13:54
	Возможно такой механизм есть, по сути аппаратный брейкпоинт на ячейку памяти, работают же как-то TSX/HLE.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	101. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (87), 08-Янв-24, 16:25
	> То есть спец. инструкция "остаёмся на той же инструкции, ждём нуля по такому-то адресу в памяти, когда дождались - переходим к следующей инструкции". непонятен смысл - если у вас система на спинлоках тормозит то что-то с вашим кодом не так. Аппаратные спинлоки делают для гетерогенных систем, он запросом на прерывание пинает ядра при изменении своего состояния и у него свой блок физических адресов для хранения состояния.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	109. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (113), 08-Янв-24, 16:44
	Речь не о том, что тормозит, а о том, что спинлоки электричество жрут, проц греют, кэш забивают, да пайплайн засоряют. Предложенное решение этой проблемы 1. электричество хоть всё же и жрёт, но меньше, так как работает асинхронно по записи к кэш/память, что долго и гораздо реже, чем дёргать кэш и память каждые несколько циклов. Но при этом жрёт чуточку больше постоянно, так как наличиствует несколько дополнительных транзисторов. Но они мосфеты, поэтому постоянно жрать будет только операция сравнения. Учитывая, что в каждом модуле ядра есть по нескольку спинлоков и они по многу раз в секунду активируются, то не удивлюсь, если от такого решения система станет намного энергоэффективнее. 2. не держит нужную линию в кэше, освобождая кэш 3 уровня для других потоков и кэш 1 уровня для других гиперпотоков. Исполнительные блоки ядра тоже освобождается для других потоков и гиперпотоков. 3. конвейер не засоряется спекулятивно исполненными инструкциями с неверными предсказаниями, а сразу останавливается
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (87), 08-Янв-24, 17:02
	> спинлоки электричество жрут, проц греют, кэш забивают, да пайплайн засоряют вы неправильно используете спинлоки или не понимаете что это и зачем, спинлоки ставят когда контекст не позоволяет переключение контекста - это оброботчики прерываний в первую очередь и на короткий код, да даже они давно все threaded irq используют.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (190), 08-Янв-24, 19:09
	Спинлоки - это активное ожидание. while(memory[x] != neededValue); То есть label: movq (%rcx), %rdx; cmp $0xneededValue, %rdx; jne label; То есть постоянно жрёт энергию, срёт в кэш и конвеер. Но оказывается что они давно уже не спинлоки. https://lwn.net/Articles/790920/ - с третьепня уже всё на на monitor/mwait. Одно не понятно: почему mwait так варварски был специфицирован (не как указанно в моём сообщении, а только для 0 кольца и с участием ОС), если очевидно, что на многоядерных процах это будет полезно и чисто для юзерспейса. Для IPC без участия ядра ОС через кэш на отмапленной в оба процесса странице памяти. И не понятно, зачем для юзерспейса делать отдельные инструкции umonitor/umwait, а не заюзать те же, просто не вызывая исключения, если заюзаны из юзерспейса.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 08-Янв-24, 19:42
	Спинлоки всё же не так топорно реализуются, см например https://stackoverflow.com/questions/6935442/x86-spinlock-usi...
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 08-Янв-24, 19:13
	Современный CPU не работает с памятью прямо, только через кеш. Для задач синхронизации и нельзя никак иначе потому что CPU должен поддерживать модель консистентности обращения к памяти чтобы блокировки через память вообще работали. Память сама по себе ничего не синхронизирует
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	186. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 08-Янв-24, 19:03
	Практически в любом механизме блокировок есть loop, это неспецифичное название. spin как раз по этимилогии жарящий CPU loop. Что у тебя такое блок спинлоков? Это, внезапно, и есть CPU, так что жарить оно будет ровно также. Собственно спинлоки используются в стиуациях с низким уровнем коллизий, т.е. когда ожидания случаются крайне редко и нужно тратить как можно меньше CPU на синхронизацию. Для частых ожиданий есть эффективные мьютексы/фьютексы.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

24. "Релиз ядра Linux 6.7"	+/–
Сообщение от Другой анон (?), 08-Янв-24, 12:18
"совестно используемые в нескольких подразделах." Подвезли файловую систему с совестью
Ответить | Правка | Наверх | Cообщить модератору

25. "Релиз ядра Linux 6.7"	–1 +/–
Сообщение от Аноним (25), 08-Янв-24, 12:27
> 6.7 Куда так гнать?
Ответить | Правка | Наверх | Cообщить модератору

	32. "Релиз ядра Linux 6.7"	+6 +/–
	Сообщение от Аноним (32), 08-Янв-24, 13:11
	Спроси у Линуса, но учти, что он хоть и прошёл курсы толерантности, но морона мороном назвать вполне способен, если тупизна оппонента его раздражает.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Релиз ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (124), 08-Янв-24, 17:31
	>Спроси у Линуса, но учти, что он хоть и прошёл курсы толерантности, но морона мороном назвать >вполне способен, если тупизна оппонента его раздражает. Вот по этому не следует его спрашивать будучи белым мужчиной. Попросите у него поинтересоваться какую ни будь афроамериканскую трансгендерную даму ;) Ответит как миленький!
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (215), 08-Янв-24, 21:29
	> Попросите у него поинтересоваться какую ни будь афроамериканскую трансгендерную даму. Ответит как миленький! То есть, чтобы лихо обвинить Линуса в трусости, придётся самому спрятаться за женской юбкой?..
	Ответить | Правка | Наверх | Cообщить модератору

27. "Релиз ядра Linux 6.7"	+1 +/–
Сообщение от Аноним (27), 08-Янв-24, 12:40
Loongson уже может KVM. Эльбрус - в пролете.
Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (45), 08-Янв-24, 13:25
	Какой ему KVM? Он ещё в vanilla не попал.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Релиз ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (312), 08-Янв-24, 13:35
	И не попадёт.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 08-Янв-24, 18:17
	> Loongson уже может KVM. Эльбрус - в пролете. Галантерейщик и кардинал :)
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	244. "Релиз ядра Linux 6.7"	+/–
	Сообщение от llolik (ok), 08-Янв-24, 23:58
	Эльбрус так-то тоже в KVM может. Loongson в апстрим своё протолкнули.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	399. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 18:37
	> Эльбрус так-то тоже в KVM может. Loongson в апстрим своё протолкнули. Примерно так же как Шишкин - в создание ФС. Где-то там, за морями, за холмами, есть гора, в той горе бункер, в бункере комната, в комнате компьютер, и вот там - смерть кащея^W^W крутейшие файловые системеы, KVM, инопланетные технологии, порталы в другие миры и что там еще...
	Ответить | Правка | Наверх | Cообщить модератору

	410. "Релиз ядра Linux 6.7"	+/–
	Сообщение от llolik (ok), 10-Янв-24, 19:48
	>> Эльбрус так-то тоже в KVM может. Loongson в апстрим своё протолкнули. > Примерно так же как Шишкин - в создание ФС. Искать по словам Эльбрус-16С аппаратная виртуализация KVM/QEMU. Они есть, даже в кремнии. Вопрос с дальнейшим серийным производством решается (по понятным причинам никто не скажет где как и сколько)
	Ответить | Правка | Наверх | Cообщить модератору

	411. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 20:09
	> Искать по словам Эльбрус-16С аппаратная виртуализация KVM/QEMU. Они есть, даже в кремнии. > Вопрос с дальнейшим серийным производством решается (по понятным причинам никто не > скажет где как и сколько) В таком виде я, имхо, даже тот же лунгсон какой-нибудь увижу раньше чем это нечто. С намного более адекватными соотношениями. Без гальванизаций трупаков любой ценой, проприетарными компилерами, внемайнлайновыми выкидышами и чем там еще. Но в целом мой путь в целом лежит в сторону RISCV, имхо. Там все это уже есть, в майнлайне, и компилеры нормальные. А вон там MilkV кажется таки выкатит весьма неплохие SoC, такими темпами идея собрать мой следующий воркстейшн на чем-то отличном от x86 станет реальной.
	Ответить | Правка | Наверх | Cообщить модератору

28. "Релиз ядра Linux 6.7"	–5 +/–
Сообщение от Аноньимъ (ok), 08-Янв-24, 12:45
> архитектура ia64 не выдержала конкуренции с AMD64, главным образом из-за более высокой производительности AMD64 Офигеть, и нтеловские сказки 30летней давности снова оживают.
Ответить | Правка | Наверх | Cообщить модератору

	60. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 14:56
	На сколько я знаю, Майкрсофт не захотел всю свою экосистему перекомпилировать под новый процессор. Так как надо было создавать для регистров Итаниума новый компилятор, также нужно было переписывать железозависымые компоненты операционки. Перекомпиляции под новый процессор подлежали и программы сторонних производителей, типа Adobe Photoshop. Дешевле и просто было перейти на x86_64.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 15:53
	> На сколько я знаю, Майкрсофт не захотел всю свою экосистему перекомпилировать под > новый процессор. Так как надо было создавать для регистров Итаниума новый > компилятор, также нужно было переписывать железозависымые компоненты операционки. Перекомпиляции > под новый процессор подлежали и программы сторонних производителей, типа Adobe Photoshop. > Дешевле и просто было перейти на x86_64. Ну да, в целом как-то так. Ну а ещё интел, не первый раз, демонстрирует отсутствие рвения в поддержке своих нескучных технологий. Вот есть корова которую мы доим - и ничего нам другого ненужно. То есть их RnD что-то такое прикольное делает, но денег на развитие не выделяют. Итаниум они допинали столько лет лишь благодаря заказам HP. Сами бы закопали ещё в 2003. Ну типа вот они выпустили новую не совместимую со старым архитектуру, и такие через пол года - что-то она не завоёвывает рынок, компиляторы не переписываются, виндовс не портируют клятые майкрософты, надо бы урезать финансирование чтобы значит не вложить ценные инвесторов деньги в провальное направление. И потом ещё через год - ой, что-то не покупают наш итаниум, а мы ведь его на лучшем техпроцессе на 2 поколения отстающем от х64 выпускаем, и компиляторы не хотят писать, и совсем плохо стало - урежем ка финансирование ещё в 2 раза. Ну а на второй год - всё, закрываем производство. Кстати, они так же убили Optan память.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (59), 08-Янв-24, 16:25
	> а мы ведь его на лучшем техпроцессе на 2 поколения отстающем от х64 выпускаем Вовремя признали ошибку, значит. Как Pentium 5, например, отменили, хотя ранее Гелсингер ездил на конференцию ISSCC и рассказывал о процессорах на 30 ГГц в ближайшем будущем. 3D XPoint, пишут, плохо масштабировался - 2 слоя сделали, потом 4 и всё. Про рынок они что-то наверняка знают, чего не знаем мы - Samsung так же свернул свою Z-NAND после двух поколений.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 17:43
	Хз. Даже с ценой в несколько раз выше нанд, оптан был очень привлекательным решением. Слои то вообще совсем не линейно стоимость уменьшают, от слова совсем. Да и стоимость это штука такая весьма относительная. А если влить несколько десятков миллиардов, так можно и придумать как там слои сделать. Я думаю там типичные инвестиционные вампиры, х86 рыночек даёт 200% отдачи на инвестицию, а оптан 20%, нужно сократить и оптимизировать111. Вот если бы 500% дал, а лучше 1000% - вот тогда да. Кстати знатно они со своими нанометрами опростоволосились. Походу тоже, пытались сократить расходы на внедрение технологий по минимуму, мол оптимизируем старое производство, и будем на старых заводах клепать вариации корыдуба до бесконечности. Это забавно на самом деле. Обороты огромные, чистого дохода - просто жесть как много, но экономят на спичках.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (59), 08-Янв-24, 18:31
	Если бы 3D Xpoint был так хорош, его бы Micron продолжил развивать. Micron QuantX.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Qq (?), 08-Янв-24, 21:55
	Черт его знает что у них пошло не так, но оптан даже не смотря на цену выглядел вкусно. 290 000 Тб  записи в качестве наработки на отказ для p5800x и скорость мелкоблочки 10х от ТЕКУЩЕГО поколения SSD (по линейному - топовые быстрее чем упомянутый p5800x). Плюс отличная скорость по всему объему накопителя без просадок, как например у nand-флеш ссд при выходе за пределы кэша. Для дома, конечно, только единицы стали бы покупать, для дома оно того не стоит
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (164), 08-Янв-24, 18:34
	> Я думаю там типичные инвестиционные вампиры, х86 рыночек даёт 200% отдачи на инвестицию, а оптан 20%, нужно сократить и оптимизировать111. > Вот если бы 500% дал, а лучше 1000% - вот тогда да. Эксперты опеннет на марше. Ты как-нибудь поинтересуйся размером маржи у высокотехнологичных производств, и почему она такая хреновая. 200% отдачи. Ага.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	471. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 15-Янв-24, 15:39
	Хочу у вас спросить. Сколько главные владельцы Интел вложили своих денег в 2023 2022 2021 годах в компанию?
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 17:47
	> Samsung так же свернул свою Z-NAND после двух поколений Дело в том, что нанд память изнашивается. И изнашивается очень хорошо и быстро. И это её выгодное коммерческое свойство. Ну это как можно сделать лампу накаливания не на 500-1000 часов а на 20000, но тебя уроют конкуренты за такое, если ты не гигант с поддержкой государства. А если гигант, то тебе не очень выгодно такое делать. Такая же забавная история с капроновыми чулками произошла. Пришлось разрабатывать специальную вариацию низкопрочного полимера.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	165. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (59), 08-Янв-24, 18:35
	> И изнашивается очень хорошо и быстро. И это её выгодное коммерческое свойство. Ну можно ж было прочитать, что Z-NAND - это SLC-память. SLC и сейчас при необходимости можно купить: Solidigm D7-P5810, например.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 08-Янв-24, 18:51
	>D7-P5810 там qlc память распаяна
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (59), 08-Янв-24, 19:06
	Это вокруг QLC. А D7-P5810 (всё-таки на SLC) просто рядом стоит: "to augment the QLC storage tier".
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 12:48
	> Это вокруг QLC. А D7-P5810 (всё-таки на SLC) просто рядом стоит: "to > augment the QLC storage tier". Пришел поручик Ржевский и беззазренно отлил в компот любителя теории заговора. Оказывается все можно - просто за все хорошее надо платить.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 19:05
	> Ну можно ж было прочитать, что Z-NAND - это SLC-память. SLC и > сейчас при необходимости можно купить: Solidigm D7-P5810, например. Ок, подумал они там что-то особенное изобретали... В любом случае, принцип тот-же. Как производители жестких дисков стали shited magnetic record продавать по цене нормальных дисков в тех же моделях без уведомления. Так и производители SSD с радостью лепят QLC и продают по цене TLC а иногда и MLC. Its evolving, just backwards.
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	495. "Релиз ядра Linux 6.7"	+/–
	Сообщение от edo (ok), 29-Янв-24, 04:14
	Там QLC-память в TLC или SLC режиме. Вам известны недостатки такого подхода в сравнении с «настоящей» SLC/TLC памятью? Мне — нет
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (164), 08-Янв-24, 18:40
	> Ну это как можно сделать лампу накаливания не на 500-1000 часов а на 20000, но тебя уроют конкуренты за такое, если ты не гигант с поддержкой государства. Это просто праздник какой-то. Зачем нужна лампа накаливания со сроком службы во всего лишь 20000 часов, если современные LED служат в пять раз больше, при меньших расходах энергии?
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	174. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 08-Янв-24, 18:46
	> всего лишь 20000 часов это где такие лампы? У нас либо 3-500 китай/беларусь либо 3000-5000 польша и лампы, служившие 10000 часов, остались в советском прошлом а что до "зачем", глазам лампа накаливания всё же приятнее, и я не уверен в твоих "в 5 раз больше", особенно, с таким количеством брака.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 18:59
	> это где такие лампы? В производство они не шли. Но нечто похожее можно было, или сейчас можно? Найти в лампах спец назначения (типо для светофоров и прочих пром применений). Устойчивых к вибрациям в первую чоередь. Были кстати совсем недавно исследования, суть нить накала закрывали между стёкол отражающих ИК излучение. Вроде очень хорошо и круто получалось, но дело видимо дальше прототипов не пошло.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Qq (?), 08-Янв-24, 22:04
	Такие лампы есть, не среди ширпотреба, как уже упомянули для светофоров, уличного освещения делают. А в целом - это не проблема, суть такая: 1) Берутся светодиоды от не совсем подвальной фирмы на 1А (цифры условны). Количество светодиодов берётся чтобы обеспечить необходимый световой поток на токе 0,5А (цифры все также условны) 2) Диод светит не от напряжения, а от протекающего ток, поэтому берётся импульсный светодиодный драйвер и разрабатывается плата для светодиода с достаточным отводом тепла, возможно с радиатором. 3) Диоды запускаются в таком, щадящем режиме, на 0,5 А Без перегрева деградация кристалла наступит очень не скоро, по сути диоды больше всего боятся перегрева, и таким образом - прослушат оооочень долго. Импульсный драйвер как раз и обеспечит очень точное задание тока и ровное свечение без пульсаций.
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 09-Янв-24, 13:40
	Я о ЛЕД источниках знаю больше чем они сами и их мама. Так уж вышло. Да, на них можно сделать очень долгоживущий источник, условно вечный. Только он будет довольно увесистым. Как и с лампы накаливания. О том как бы и речь, что не делают. Делают обратное. Ну и, в оправдание дьявола, вы попробуйте сделать лампочку в форме лампочка на 1000люмьен чтобы она не перегревалась. А есть ещё другое измерение. Качество света. У большинства ледов донная цветопередача и проблемы с мерцанием. Сейчас правда отдельные производители слегка цветопередачу подкрутили. Но если вы посмотрите какие светильники продают и ставят в Европе допустим - это жуть вообще. Свет с улицы светит лучше. Его включил, вроде оно светит, а ничерта невидно.
	Ответить | Правка | Наверх | Cообщить модератору

	357. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 00:35
	> Да, на них можно сделать очень долгоживущий источник, условно вечный. > Только он будет довольно увесистым. Чего такого увесистого в алюминиевой рейке для светодиодной ленты например? Условно вечный источник, при том с параметрами хорошо контролируемыми вот именно покупаном. И крутость "рейки" и моща ленты. Не, все равно заговоры везде? > вы попробуйте сделать лампочку в форме лампочка А вы тогда сделайте чтобы A380 можно было вожжами управлять, во. > У большинства ледов донная цветопередача и проблемы с мерцанием. У светодиодных лент например в БП как правило весьма почтенные кондеры - пару секунд плавно затухает после poweroff. > Сейчас правда отдельные производители слегка цветопередачу подкрутили. Сейчас? Кому было принципиально - Cree какой-нибудь нормальные светодиоды делал лет 10 назад уже. > Но если вы посмотрите какие светильники продают и ставят в Европе допустим > - это жуть вообще. Свет с улицы светит лучше. Его включил, вроде оно светит, > а ничерта невидно. Я посмотрел разок россиянам продают. Отбраковку от подвального китая. Европеец такое УГ вообще не купит.
	Ответить | Правка | Наверх | Cообщить модератору

	470. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 15-Янв-24, 15:26
	> Чего такого увесистого в алюминиевой рейке для светодиодной ленты например? Условно вечный источник, при том с параметрами хорошо контролируемыми вот именно покупаном. И крутость "рейки" и моща ленты. Не, все равно заговоры везде? Ну прикиньте каких размеров и прочих характеристик должна быть рейка чтобы выдать 4000+ люмен комфорта для небольшой комнаты, при условии что отдельные диоды не должны греться выше 80С.А лучше не выше 70. При том что у лент и так то не высокая энергоэффективность. И найдите ту ленту для начала, с CRI > 96 и диодами в нужном режиме. И не забывайте про сопротивление самой ленты... > У светодиодных лент например в БП как правило весьма почтенные кондеры - пару секунд плавно затухает после poweroff. Да, там не так всё плохо у низковольтных девайсов с этим. > Сейчас? Кому было принципиально - Cree какой-нибудь нормальные светодиоды делал лет 10 назад уже. Точно делал? Помню что кришка делала очень мощные источники на каких-то угольных суперподложках. А вот LG делало в начале, но потом резко забили на это дело... Филипс ещё в начале выпускала классные лампы, но тоже забила и свернула всю линейку.
	Ответить | Правка | Наверх | Cообщить модератору

	472. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (472), 17-Янв-24, 18:07
	> Ну прикиньте каких размеров и прочих характеристик должна быть рейка чтобы выдать > 4000+ люмен комфорта для небольшой комнаты, при условии что отдельные диоды > не должны греться выше 80С. Мало? Берем несколько реек, по периметру! Просто и неинтрузивно. Мало?! Можно по углам, как плинтуса, врезные - в плоские поверхности, на потолке или карнизе для штор, или куда там еще еще бонусов приделать, если совсем делать нефиг. Формфактор такой что легко пристраивается куда угодно, лишь бы симпатично и глазам комфортно. С точки зрения комфорта глаз распределенный источник света - лучше нескольких суперярких точек, btw. Можно хоть мухой в прожекторе жить - если зачем-то надо. На комнату среднего пошиба редко надо больше сотни ваттов, примерно как 450-500 ваттов ЛН будет. Совершенно не проблема спихнуть в несколько реек, они едва теплые и светики живут - дохрена. Там кроме конвекции еще теплоотвод в немеряную поверхность стены/потолка или чего там. В прыщ-лампе косплеящей ЛН это недоступно, термальный режим совсем иной на ее горе. > А лучше не выше 70. При том что у лент и так то не высокая энергоэффективность. У них физический размер и теплопередача на вон ту поверхность. Какие нахрен 70, я на этом руку держу спокойно (12 или 24V к тому же током не долбанет "если что") и оно - едва теплое. А можно еще вот контроллер прикрутить и плавно рулить яркостью. И света "сколько надо" и режим светиков еще лучше. > И найдите ту ленту для начала, с CRI 96 и диодами в нужном режиме. Я не фотостудия, мне CRI >= 80 вполне ок. Тем более что у накалок CRI вообще фикция. > И не забывайте про сопротивление самой ленты... Поэтому я придумал пару фокусов. Скажем жирные провода - подводят в ЦЕНТР рейки. Провод заныканый в рейку не видно от слова вообще. А вместо 1 убер-питальника - поставить более локальные около своей рейки. Заодно "если что" - в дауне окажется только часть конструкции, не фатально, чинить дешевле, и вообще. > Да, там не так всё плохо у низковольтных девайсов с этим. Там весьма прилично с этим. Как забавный бонус, 12V акумы (или их парочка для 24V), например от, упсы могут довольно долго держать почтенный кус такой конструкции с весьма приличным светом, небольшой "plan b" если mains в ауте еще никому не мешал вроде. И вот все как лохи в темноте - а тут ррраз, довольно приличный свет. > Точно делал? Помню что кришка делала очень мощные источники на каких-то угольных > суперподложках. Они конечно тогда предпочитали в основном мощные серии, для фонарей, как более маржинальные (почти все хорошие продвинутые фонарики класса "карманный бластер" - это cree). Но уже вроде начинали и осветительные серии. Впрочем и из серий "для фонарей" можно освещение набрать. Дороговато? Дешевле чем сортир мощеный пентиумами. > А вот LG делало в начале, но потом резко забили на это дело... Всегда отставали от Samsung. Который был, есть и будет есть - только подтянули параметры раза три-четыре в спеках уже. Да и лыжи я до сих пор в стоках вижу. Если уж они нужны. Их не оч активно берут как и старые бины самсов - потому что то же самое но новее обладает более годными параметрами, процесс оптимизнули и отладили. > Филипс ещё в начале выпускала классные лампы, но тоже забила и свернула всю линейку. Да и фиг с ними, они никогда ничего такого эдакого из себя не представляли чтобы о них сильно горевать. У них самих LED производство вообще было? Никак не припоминаю в стоках светиков этих господ.
	Ответить | Правка | Наверх | Cообщить модератору

	474. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 17-Янв-24, 19:01
	>Можно хоть мухой в прожекторе жить - если зачем-то надо. На комнату среднего пошиба редко надо больше сотни ваттов, примерно как 450-500 ваттов ЛН будет. 100 ватт ледов это 10000 люмьен плюс минус. Это больше чем 500Вт ЛН. Раза в два. >Совершенно не проблема спихнуть в несколько реек, они едва теплые и светики живут - дохрена. Там кроме конвекции еще теплоотвод в немеряную поверхность стены/потолка или чего там. Да всё что угодно можно. А я говорил что нельзя? Я говорил что рейки ваши длиннющие дуры. Так понятней? И вы вроде бы согласны? >У них физический размер и теплопередача на вон ту поверхность. Какие нахрен 70, я на этом руку держу спокойно (12 или 24V к тому же током не долбанет "если что") и оно - едва теплое. Температуру кристалла посмотрите тепловизором. А не рукой замеряйте. А эффективность у лент таки хреновая. Резистором ток контролировать то такое. Так что это ещё один недостаток. > А можно еще вот контроллер прикрутить и плавно рулить яркостью. И света "сколько надо" и режим светиков еще лучше. Который их в режиме погоды на марсе питает. > мне CRI >= 80 вполне ок. Не, но тут я ничем помочь не могу. У меня соседи были, они вообще ребёнку в комнату вкрутили лампу для уличного освещения, не жёлтую натриевую, а тип "белого света". Ух, я там через 5 минут плакал кровавыми слезами. > Там весьма прилично с этим. Как забавный бонус, 12V акумы (или их парочка для 24V), например от, упсы могут довольно долго держать почтенный кус такой конструкции с весьма приличным светом, небольшой "plan b" если mains в ауте еще никому не мешал вроде. И вот все как лохи в темноте - а тут ррраз, довольно приличный свет. На ваш свет ракета прилетит, или быстрее патруль приедет. > Всегда отставали от Samsung. Который был, есть и будет есть - только подтянули параметры раза три-четыре в спеках уже. Да и лыжи я до сих пор в стоках вижу. Если уж они нужны. Их не оч активно берут как и старые бины самсов - потому что то же самое но новее обладает более годными параметрами, процесс оптимизнули и отладили. Не в кристаллах дело, а в люминофоре. Короче. У лент недостатки - эффективность, габариты, монтаж. Это никак не идеальное абсолютно лучшее решение. Но да, если напряжение правильно выставить могут очень долго жить, почти вечно.
	Ответить | Правка | К родителю #472 | Наверх | Cообщить модератору

	476. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (476), 18-Янв-24, 18:10
	> 100 ватт ледов это 10000 люмьен плюс минус. Это больше чем 500Вт ЛН. Раза в два. Я консервативно взял, с потерями на провода, рассеиватели, неидеальное размещение, не лучшие светики, ... - лучше если сюрприз приятный. Если много вышло - придушить контроллером. LEDы выгодно derate'ить. На 50% мощи останется 60-70% света, а глаз еще и нелинейно воспринимает - почти незаметно. > Да всё что угодно можно. А я говорил что нельзя? Я говорил что рейки ваши длиннющие дуры. Типовой кусок - пару метров, сейчас и метр можно найти. Не понимаю проблемы - алюминий мягкий металл, ножовкой по металлу как нож в масло. > Так понятней? И вы вроде бы согласны? Ну да. Это место обычно все равно не используется. Заодно и плинтус может изобразить. Но я по приколу и мелкие кусочки 1-2 сегмента делал, где уместно - на правах подсветки скорее. Актуально eg ночью по делам сходить, не считая стен, и чтоб глаза не вытекли. > Температуру кристалла посмотрите тепловизором. А не рукой замеряйте. Я и так вижу margins ломовые, сравнив температуру выводов светика VS другие дизайны. За ~8 лет не мрет, ну и норм. На питальник жаться не надо - запас 2..3 раза по моще мастхэв чтобы он долго жил. Для сравнения на LED "лампочке" 10W руку фиг удержишь (==60+ градусов). Тепло со светиков спихивается норм, но куда его в тупом формафакторе дальше?! Оно и дохнет. > А эффективность у лент таки хреновая. Резистором ток контролировать то такое. Так > что это ещё один недостаток. Там падает мало: для 12V 3 диода последовательно (==размер мин сегмента), там 9-10V, резистору остается 2-3V, кпд портится не сильно. Заодно удобно фактический режим и неравномерность мерять. А если вольтаж урезать... запас по моще и пригодится, КПД улучшится ;) > Который их в режиме погоды на марсе питает. 1) Оно ж жило на максималках неограниченно. По простому контроллер может только УРЕЗАТЬ максимум (buck или pwm). 2) Если мне принципиально, или надо что-то этакое (e.g. интеграцию в свои системы), я уже могу и сам себе DCDC скрафтить, налутав за вечер-два парочку таких из "mcu core". PWM даже ардуинщик сможет (==дергать полевик лапкой с разным duty), для себя предпочитаю до buck доделывать (катуха и кондеры == фильтр). С управлением в фирмвари по вкусу. Сжечь ТАКОЙ объект управления малореально, 0 до 100% валидно - баги не фатальны, удобно экспериментировать. Если кому приспичит такое, хинт: buck удобно "перевернуть", стабилизируя/регулируя относительно + питания, чтобы рулить N-FET без трансляции уровней. FET можно с дохлой мамки нашару взять. > Ух, я там через 5 минут плакал кровавыми слезами. А до этого вы не жили с лампами накаливания, где температура 2600-3000 градусов? Без верхней части спектра? Хотя перебарщивать с этим не стоит, самый край 4000К имхо. Выше - синего слишком много, даже если кому синеватый цвет нравится, для освещения не стоит: есть теория что это небезопасно для глаз вдолгую из-за недооценки силы синего света глазом. > На ваш свет ракета прилетит, или быстрее патруль приедет. В меня ракетами никто не пуляет, тьфу-тьфу. Если дело встанет так, логичнее, наверное, другие вундевафли крафтить. И если патруль агрится на это - он точно дружественный? Если да - что он предъявит за акум и ленту? Может и powerbank отжимать будет? А если недружественный, может, его с другой исполниловкой ознакомить надо? Кстати, если это работает, акум + эн лент сииииииильно дешевле самой ссаной ракеты. > Не в кристаллах дело, а в люминофоре. Лыжи умели что-то особенное? > Короче. У лент недостатки - эффективность, габариты, монтаж. ИМХО половина и достоинства сразу: инсталится куда угодно, сколько нужно, с минимальным constraints, без дурных режимов, время жизни ограничено жабой да знаниями. > Это никак не идеальное абсолютно лучшее решение. Идеальных решений не бывает. Но бывает good enough. ИМХО это оно. > Но да, если напряжение правильно выставить могут очень долго жить, почти вечно. Я научился в DC-DC vs firmware слегка, так что для меня это вообше "at my fingertips" :)
	Ответить | Правка | К родителю #474 | Наверх | Cообщить модератору

	477. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 18-Янв-24, 18:47
	> А до этого вы не жили с лампами накаливания, где температура 2600-3000 градусов? У этой лампы температура не меньше 7800K. А лампа накаливания это норм в плане качества света. Галогенка - вообще идеал. > Если да - что он предъявит за акум и ленту? Это я просто шучу так, время такое... Но если серьёзно спрашиваете - нарушение режима световой маскировки. А если боевые действие уже рядом с вами идут, то могу из вредности и на всякий случай прострелить. А технически, да, ленты от аккумулятора просто и приятно питать. Особенно если вы где-то за городом в глуши и перебои со светом включаются часто. > Идеальных решений не бывает. Но бывает good enough. ИМХО это оно. Не. Потолочный центральный светильник на порядок проще в монтаже, ничего никуда пилить ненужно. Думать о том где спрятать питальники ненужно. В случае поломки заменяется с помощью отвёртки за 15 минут. Для вас - самоделкина, ленты это достаточно отлично. А найти специалиста который их установит внутрь ремонта, чтобы оно было красиво, ровно, и с правильным питанием, и без падения яркости, и прочее прочее, и сколько он будет стоить, если вы его найдёте - это совсем совсем другая история.
	Ответить | Правка | К родителю #476 | Наверх | Cообщить модератору

	478. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (476), 20-Янв-24, 04:08
	> У этой лампы температура не меньше 7800K. А там при этом нет той же проблемы что и с синюшными светодиодами, на тему избытка синей части спектра, недооцениваемой глазом? Распределение мощность-длина волны у этой штуки какое? График этого где-то есть? > А лампа накаливания это норм в плане качества света. Галогенка - вообще идеал. Нафиг такие "идеалы" - верхушки спектра нет и все рыжее. Да еще от напряжения зависит, а если вдруг колеблется это еще и видно. Даже если забыть о ломовом жоре. Но если я об этом, даже CCFL отбились за ~год. А прожили явно больше. Пара до сих пор вроде живые, а это 12 лет. > Это я просто шучу так, время такое... Но если серьёзно спрашиваете - нарушение > режима световой маскировки. Ну если такое требование есть - ему стоит соотвествовать, конечно. Но я не помню чтобы на вот именно ЭТО кто-то сильно настаивал последние пару лет. Сейчас наведение на вот именно свет вроде бы не в моде, а спутнику GPS или глонасс вещать не запретишь, разве что заглушить, но вот глушак, если сильно наглый - может и притянуть к себе ракету, пожалуй. Противорадиационную. > А если боевые действие уже рядом с вами идут, то могу из вредности и > на всякий случай прострелить. Если боевые действия поблизости - то к ним имхо или присоединяться, раз уж пришло в дом, или если обе стороны противны, у...ть оттуда, чем быстрее тем лучше. Мало ли кто и чем там сдуру куда #$%нет, после активной разборки в энной территории насколько я вижу - остается лунный пейзаж. И по моему первый приоритет - как не стать его частью, совершенно зафиг. > А технически, да, ленты от аккумулятора просто > и приятно питать. Особенно если вы где-то за городом в глуши и перебои > со светом включаются часто. Оно просто остается более-менее электрически валидным в том диапазоне, и ни в какие жирные проблемы не вылезает. И довольно долго пашет от упсового акума, а от авто - вообще немеряно. > Не. Потолочный центральный светильник на порядок проще в монтаже, ничего никуда пилить > ненужно. Думать о том где спрятать питальники ненужно. Только если крюк и проводка уже были. А если его самому организовывать, и проводку - да еще не на виду - нихрена это не проще, и вон то пожалуй прикольнее. В рейке то провод не видно. А к люстре в середине потолка... ага... либо много гимора с каким-то желобом под это, либо посреди потолка дурной аррефакт. > В случае поломки заменяется с помощью отвёртки за 15 минут. А вон то вообще не ломается особо. Технику используют не для того чтобы чинить. > Для вас - самоделкина, ленты это достаточно отлично. А найти специалиста который > их установит внутрь ремонта, чтобы оно было красиво, ровно, и с правильным питанием, > и без падения яркости, и прочее прочее, и сколько он будет стоить, если вы его > найдёте - это совсем совсем другая история. И все же я кажется не уникальный и ленты стали продаваться - по сути везде, как и рейки, и цены вниз упали в многие разы - "магия количеств" заработала. Значит это юзаю не только я.
	Ответить | Правка | К родителю #477 | Наверх | Cообщить модератору

	479. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 20-Янв-24, 13:54
	> А там при этом нет той же проблемы что и с синюшными светодиодами, на тему избытка синей части спектра, недооцениваемой глазом? Я же пишу - из глаз кровь течёт. > График этого где-то есть? Ну вот Осрамовская похожая лампа, вероятно ещё очень неплохая. https://www.osram.com/appsj/pdc/pdf.do?cid=GPS01_1028063&vid... > недооцениваемой глазом Синий свет хорошо подчёркивает контуры объектов, поэтому для уличного освещения, особенно проезжей части - оно норм. >Нафиг такие "идеалы" - верхушки спектра нет и все рыжее. Ты что-то напутал вообще. Смотреть картинку - https://www.researchgate.net/profile/Muhammad-Jahandar/publi... График - Halogen. > Значит это юзаю не только я. Большинство не использует их как источник основного света. В ремонте - это подсветка рабочих поверхностей, в первую очередь кухонных. Декоративная подсветка. Всякие дорогие джакузи и бани. > И все же я кажется не уникальный Да, не уникальный.
	Ответить | Правка | К родителю #478 | Наверх | Cообщить модератору

	480. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 21-Янв-24, 04:47
	> Я же пишу - из глаз кровь течёт. Ну дык, при такой то температуре. Светодиоды на такую температуру не сильно лучше будут, их только улицу освещать, или что-то эпизодически юзаемое. > Ну вот Осрамовская похожая лампа, вероятно ещё очень неплохая. Ммм.. явно для улицы штука по всем параметрам. Начиная от 150 ваттов газоразряда одним куском. Глаза вытекут нахрен если дома такое вкрутить, имхо. > Синий свет хорошо подчёркивает контуры объектов, поэтому для уличного освещения, особенно > проезжей части - оно норм. Я себе многорежимный фонарик ака LED бластер для походов синеватый взял, он заметно эффективнее и в мизерной байде дохрена света благодаря Cree. Но вот повседневное освещение в таком виде? Да ну наф, нейтральный белый 4000К по моему абсолютный максимум. Ну может 4500 для любителей странного. > Ты что-то напутал вообще. Чего я напутал? В накалках синего почти нет, в галогенках больше, но - меньше чем в дневном свете нормальном. Оттенок все равно желтый остается. > Большинство не использует их как источник основного света. Видимо просто слишком консервативны чтобы не сношаться с набалдашниками. Да и не отдирать же уже приделаные, право? Про них Форд сказал что если бы он спросил что они хотят, они сказали бы - более быстрых лошадей. > В ремонте - это подсветка рабочих поверхностей, в первую очередь кухонных. > Декоративная подсветка. > Всякие дорогие джакузи и бани. Да оно так то по периметру дает весьма нехило света - и неинтрузивное получается. Если потолок низкий (e.g. сельский/загородный дом и т.п.) - вообще EPIC WIN, там здоровый набалдашник совсем не в тему бывает. >> И все же я кажется не уникальный > Да, не уникальный. Ну дык. Мне совершенно пофиг к каким там более быстрым лошадям кто привык и какие у них стереотипы. Я могу и критически переосмыслить некоторые аспекты, задав себе вопросы "почему мы делаемы это?" и "почему вот так?".
	Ответить | Правка | К родителю #479 | Наверх | Cообщить модератору

	481. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 21-Янв-24, 21:25
	> Оттенок все равно желтый остается. Цветопередача зато соточка. И это прекрасно. Пульсаций тоже немного. Вы же не кричите всё время до 11:00 и после 14:00 - аааааа оттенок солнца жёлтый всё жёлтое какой кошмар срочно задернуть шторы и ледами где синего побольше осветить11111 > Да оно так то по периметру дает весьма нехило света - и неинтрузивное получается. Если потолок низкий (e.g. сельский/загородный дом и т.п.) - вообще EPIC WIN, там здоровый набалдашник совсем не в тему бывает. Не понимаю, почему в загородном доме потолок ниже квартиры по вашему. > но - меньше чем в дневном свете нормальном Вы ещё пожалуйтесь, что жёсткого ультрафиолета нету в спектре у лампы.
	Ответить | Правка | К родителю #480 | Наверх | Cообщить модератору

	482. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 22-Янв-24, 04:03
	>> Оттенок все равно желтый остается. > Цветопередача зато соточка. И это прекрасно. Пульсаций тоже немного. Что значит соточка, если все желтит? Я печатку с синей маской под галогенкой фоткал - это УГ! И чинить заманаешься. С солнцем днем гораздо лучше. И еще это очень жручая и горячая байда. Случайно это потрогать? Ух! > Вы же не кричите всё время до 11:00 и после 14:00 - аааааа оттенок солнца жёлтый Он и красный может быть на закате/рассвете. Я ж не кричу что там цветопередача соточка?! > всё жёлтое какой кошмар срочно задернуть шторы и ледами где синего побольше осветить11111 Однако констатирую изменение цвета. > Не понимаю, почему в загородном доме потолок ниже квартиры по вашему. Хз, почему-то довольно распостраненное явление. Бывают и с высокими, конечно. >> но - меньше чем в дневном свете нормальном > Вы ещё пожалуйтесь, что жёсткого ультрафиолета нету в спектре у лампы. Ну вообще его избыток как и недостаток не есть гуд. Человек так то довольно капризная субстанция.
	Ответить | Правка | К родителю #481 | Наверх | Cообщить модератору

	179. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 18:54
	До массового производства дешёвых белых светодиодных источников - очень даже нужна была. Лампы накаливания, внезапно, больше 100 лет находились в активной эксплуатации. А некоторые из ранних так и проработали 100 лет... И всё ещё находятся в отдельных отраслях, но для бытового освещения больше не применяются. > если современные LED служат в пять раз больше Ну фантазёр, ну затейник.
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

	223. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Qq (?), 08-Янв-24, 22:07
	> Ну фантазёр, ну затейник. LED-ы могут много, проблема в вендорах которые собирают хрень. Благо хоть с большего перестали собирать их на линейных стабилизаторах напряжения
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 09-Янв-24, 13:45
	>> Ну фантазёр, ну затейник. > LED-ы могут много, проблема в вендорах которые собирают хрень. Благо хоть с > большего перестали собирать их на линейных стабилизаторах напряжения Металлгалидные лампы высокого давления - параллельная ледам технология с похожими показателями. Долгий срок службы, высокая эффективность, высокий CRI. Но в отличии от ЛЕДов тепло не помеха, а желанная характеристика. Видимо не пошло в бытовое освещение, так как требует защищённого корпуса, и долго выходит на рабочий режим. Но я себе такое поставил на кухню - и это просто чудо какой отличный источник света,
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 23:55
	> Металлгалидные лампы высокого давления - параллельная ледам технология > с похожими показателями. Долгий срок службы, высокая эффективность, высокий CRI. Светодиоды при _правильной_ реализации имеют почти бесконечный срок жизни, со временем немного падает яркость, но если с токами и температурным режимом не борзеть - а чему там дохнуть? В зверских режимах в подвальном китае - мрет по перегреву, от ломовых механических напряжений при циклах on-off и общей деградации ибо куча мизерных кристаллов, в микроскопическом корпусе, с явно underrated теплоотводом - на явно избыточном токе. Китайцы любят преувеличивать свои возможности - оно и мрет за обозримое время. Более приличные производители живут многие годы. А, да, россиянам китайцы поставляютя по сути отбраковку. Самые паршивые светодиоды самых поганых бинов (сортировка), малоизвестных производителей, по которым мусорка плакала, сэкономив размер теплоотвода и проч. И кстати светодиоды можно применять в менее идиотских формфакторах чем косплей ламп. Скажем как ленты. В специализированном алюминиевом желобе для лент, если возможности теплоотвода сбалансированы VS мощность ленты на метр - оно по сути вечное. Вооон там уже 8-й год такая конструкция пашет. Хренли ей будет? А заодно... 1) Это низковольтная штука, ленты обычно 12 или 24 вольта. Можно в помещениях с влажностью юзать в менее стремном виде, гальванически изолированом от опасных 220 на корню. 2) Можно не обвешиваться здоровенными набалдашниками, это может быть плоским/мелким/угловым и вообще сильно менее интрузивным. 3) Это при желании можно рулить электронно, например, диммировать. В целом - низковольтная, еле теплая штука, эффективная по свету - ня. Ни обжечься, ни удар током, ни взрывов и чего там. Мы ж не для создания опасностей освещение делаем? :)
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (190), 08-Янв-24, 19:36
	>Ну это как можно сделать лампу накаливания не на 500-1000 часов а на 20000, но тебя уроют конкуренты за такое, если ты не гигант с поддержкой государства. И как же? Рынок отнимаешь у них - а выгоду получаешь ты. Это фирма, которая так сделает, конкурентов уроет - её доля начнёт увеличиваться в ущерб доле конкурентов. Что заставит конкурентов делать так же. А так можно согласованно сокращать, и доля выравняется, но получать вся олигополия станет меньше уже. Это не конкуренты тогда, а картельный сговор называется.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	217. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 21:48
	Конкуренция качеством товара может существовать при соблюдении минимум двух условий: 1. При условии свободного открытого для всех честного рынка. Чего в природе за всю историю наблюдений замечено не было. 2. При наличии у потребителя возможности и желания объективно оценить качество товара. Что в ограниченном виде встречается у отдельных особей, но как массовое явление не наблюдается. И чем товар сложнее, тем меньше степень объективности в оценках. А реальная конкуренция, ну, есть классика - "Крёстный Отец".
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 21:53
	> Ну это как можно сделать лампу накаливания не на 500-1000 часов а > на 20000, но тебя уроют конкуренты за такое, если ты не > гигант с поддержкой государства. FYI основная проблема с этим чисто технчиеская. Металл при тех температурах - испаряется. А когда это научились немного решать (галогенки) оно уже стало не очень то и надо т.к. к тому моменту КЛЛ и LED лампы уже вскоре появляться стали и срок службы в несколко раз больше при хреновой энергоэффективности - уже не то, да и пальму первенства перехватили производители электроники а потом и производители полупроводников с их LEDами. Но эксперту по всему и любителю теорий заговора конечно винднее.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	392. "Релиз ядра Linux 6.7"	+/–
	Сообщение от voiceofreason (?), 10-Янв-24, 13:19
	3dxpoint как таковой был ну очень хорош, просто он дико дорогой и дико сложный в производстве и требовал десятки видов уникальных расходников
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	198. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 08-Янв-24, 19:47
	Всё ещё хуже, для каждого нового VLIW CPU нужно делать отдельные сборки всего ПО
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	218. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноньимъ (ok), 08-Янв-24, 21:51
	> Всё ещё хуже, для каждого нового VLIW CPU нужно делать отдельные сборки > всего ПО Это на самом деле мелочи. Тысячи дистрибутивов линукса только перекомпиляцией и занимаются. И успешно, и это они чужое ПО компиляют. Разработчику это сделать гораздо проще. Ну и не говоря уже о всяких джавах и дотнетах, у которых нет такой проблемы вообще.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 08-Янв-24, 22:45
	Делать 1 пакет вместо нескольких десятков под неизвестное тебе железо нифига не мелочь. Всякие твои джавы хорошо работают только на не VLIW архитектурах, т.е. где могут делать разумно несложную кодогенерацию.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 02:01
	> Это на самом деле мелочи. Тысячи дистрибутивов линукса только перекомпиляцией и занимаются. > И успешно, и это они чужое ПО компиляют. Разработчику это сделать гораздо проще. А таки ведет к нехилой нагрузке на ровном месте. Это как бы минус. > Ну и не говоря уже о всяких джавах и дотнетах, у которых > нет такой проблемы вообще. Зато есть другая - истошно тупят своим кодогенератором. Или если не тупят то код неоптимальный. Так что комп с дотнетом после апгрейда нета полдня вообще неюзабельный, он там активно косплеит билдферму. ...в этом месте всякие хрустики получают свой шанс пооткусывать у этих суперпро рынка.
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	436. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (436), 11-Янв-24, 12:17
	>для каждого нового VLIW CPU нужно делать отдельные сборки всего ПО Как бы, для мира СПО это не самое страшное.
	Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

	498. "Релиз ядра Linux 6.7"	+/–
	Сообщение от edo (ok), 30-Янв-24, 10:50
	> На сколько я знаю, Майкрсофт не захотел всю свою экосистему перекомпилировать под новый процессор. Так как надо было создавать для регистров Итаниума новый компилятор, также нужно было переписывать железозависымые компоненты операционки. Вы ерунду написали. В 2001 году вышел сам itanium, в 2001 же xp для него, в 2003 — windows server
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

31. "Релиз ядра Linux 6.7"	–7 +/–
Сообщение от Аноним (32), 08-Янв-24, 13:09
> громкоговорителей В русском языке мы уже давненько их называем "динамиками". "Громкоговоритель" теперь несёт в себе оттенок старины.
Ответить | Правка | Наверх | Cообщить модератору

	35. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (33), 08-Янв-24, 13:17
	>уже давненько их называем "динамиками" Называем кто? Учащиеся 7б?
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Релиз ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (45), 08-Янв-24, 13:27
	Может, ещё в новостях об электроэнергетике турбогенераторы динамками называть?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	40. "Релиз ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (40), 08-Янв-24, 13:40
	Видимо, ты громкоговоритель ни разу не видел, раз говоришь за весь русский язык.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	41. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (312), 08-Янв-24, 13:40
	Что ты имеешь против старины? Как на каких-нибудь "викингов" наяривать, так старина вам не мешает, а как только речь заходит о русских, то старина вам сразу поперёк горла становится.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	44. Скрыто модератором	–2 +/–
	Сообщение от Аноним (-), 08-Янв-24, 13:49
	Что? Нет конечно! Вы сударь просто умом скуден, но на юродивых не обижаются.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Релиз ядра Linux 6.7"	–2 +/–
	Сообщение от penetrator (?), 08-Янв-24, 20:58
	потом там только лапти и азиопы
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	49. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (96), 08-Янв-24, 14:24
	Можно еще головные телефоны подключить для комплекта)
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	56. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 14:47
	В моём новеньком телевизоре вместо слов "Volume" присутствует слово "Громкоговоритель". Ну, телевизор был так локализован. Парень мне кажется ты пытаешься выдать желаемое за действительное. Что касается слова "динамик", то да, это слово в операционной системе Windows XP обозначало звуковые колонки. Я с Windows XP перешёл на Линукс, и с тех пор, что сейчас творится на Виндовсе ничего не знаю.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	203. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 08-Янв-24, 20:14
	Переводы делают для овощей, нормальные люди пользуются международным языком в технике. И в особенности это касается пользователей линуксов и СПО, где переводы делает сообщество неравнодушных. Т.е. переводят в основном как раз маргиналы для себя лично, чтобы показать какие они все ценители скреп.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (215), 08-Янв-24, 21:36
	Вопрос, кто ещё маргинал. У тебя, видать, ни родителей, ни друзей, ни знакомых. Ну, или они все в Лондоне проживают и говорят по-английски. Или в пещере, и бытовой техникой совсем не пользуются. Сидите на холодном каменном полу и целыми днями всех ненавидите. Как ни крути, а на нормальных представителей русскоговорящей части человечества вы не тянете.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 08-Янв-24, 22:56
	Дедушки-бабушки прекрасно справлялись с EN вариантами техники из, например, Японии ещё в конце 80-х. А на некоторых экземплярах не было даже EN перевода. Хотя сами учили только немецкий. Сверстники прекрасно знают EN язык хотя бы на уровне понимания типичных слов, и это минимум. Вы же, например, попёрлись на opennet, а это, внезапно, не на русском. Если вы весь из себя русскоговорящий, то отстаньте просто от техники, это нерусское изобретение в принципе и не РФ технику развивают. Также можете перестать пользоваться гражданской авиацей, там, внезапно, все пилоты говорят на работе на английском даже на внутренних рейсах.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (274), 09-Янв-24, 19:33
	"я считаю, его уже и иностранным считать [нельзя], потому что английский везде. Это язык технологий, экономического развития, мировой коммуникации, поэтому английский знать нужно просто в обязательном порядке"   Дмитрий Песков //   Заместитель руководителя Администрации президента Российской Федерации.  Действительный государственный советник Российской Федерации 1 класса.
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	289. "Релиз ядра Linux 6.7"	+/–
	Сообщение от aaa (??), 09-Янв-24, 06:13
	А у меня у друга на стекле микроволновки (LG или Samsung) было наклеена инструкция со словами: "Чmо mакое" (должно было быть "Что такое"). Мы часто, когда на кухне с ним выпивали, по этому поводу шутили. В печатном варианте "чмо" тоже присутствовало. Так что инструкция, тем более, неправильно переведенная, еще не руководство к действию. Должно присутствовать критическое мышление.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	355. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 00:00
	> "Чmо mакое" (должно было быть "Что такое"). > Мы часто, когда на кухне с ним выпивали Ну, вот видите, переводчик не облажался... :)
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Релиз ядра Linux 6.7"	+/–
	Сообщение от DEF (?), 09-Янв-24, 07:21
	Как дела, старина? Что нового?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	307. "Релиз ядра Linux 6.7"	+/–
	Сообщение от InuYasha (??), 09-Янв-24, 10:37
	а ничего что бывают не только электродинамические громкоговорители?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	322. "Релиз ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (154), 09-Янв-24, 13:53
	А ничего, что громкоговоритель это примерно мегафон, а не просто говоритель или тихоговоритель? И что делать, если хочу послушать музыку, а не говорильню?
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Релиз ядра Linux 6.7"	+/–
	Сообщение от InuYasha (??), 09-Янв-24, 22:15
	Ничего. Направь ещё свою борьбу на QWERTY-клавиатуры. Переучи планету, принеси пользу. )
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Релиз ядра Linux 6.7"	+/–
	Сообщение от _kp (ok), 09-Янв-24, 11:25
	>>мы уже давненько их называем "динамиками". "Громкоговоритель" теперь несёт в себе оттенок старины. Да Сами Вы старина. Спикерами их называют. Если толстый, то колонка. Шутка. :)
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

47. "Релиз ядра Linux 6.7"	+4 +/–
Сообщение от Аноним (47), 08-Янв-24, 14:13
> По производительности Bcachefs опережает Btrfs и другие ФС на базе механизма Copy-on-Write, и демонстрирует скорость работы, близкую к Ext4 и XFS. Почему хотелки, до которых ещё очень далеко, подаются как свершившийся факт?
Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз ядра Linux 6.7"	+/–
Сообщение от Аноним (83), 08-Янв-24, 15:33
потому, что хоелок много
Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз ядра Linux 6.7"	+/–
Сообщение от Beta Version (ok), 08-Янв-24, 16:48
Вроде в 6.7 должны были вернуть доступ к разгону/андервольту 7000 радеонов.
Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз ядра Linux 6.7"	+/–
Сообщение от d_kazbek (?), 08-Янв-24, 17:25
"...архитектура ia64 не выдержала конкуренции с AMD64, главным образом из-за более высокой производительности AMD64...". Интел сам был в испуге от своей разработки и душка не хватило довести экосистему IA64 до основных рыночных сегментов (Как признался в интервью один из разрабов IA64). При прочих равных IA64 производительнее и перспективнее...
Ответить | Правка | Наверх | Cообщить модератору

	147. Скрыто модератором	+/–
	Сообщение от Аноним (-), 08-Янв-24, 18:19
	Да, но сабботаж архитектуры Итаниум со стороны Майкрософта тоже был.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (166), 08-Янв-24, 18:38
	AMD64 когда закопают? Тут ARM пиарился сильно одно время.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	192. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от d_kazbek (?), 08-Янв-24, 19:22
	"With over 230 billion ARM chips produced, as of 2022, ARM is the most widely used family of instruction set architectures." - данные Wiki
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Qq (?), 08-Янв-24, 22:13
	Не в ближайшее десятилетие, из десктопов по факту только apple, QC со своими чипами все никак не влезет. Сервера - 3,5 вендора, да, решения выглядят «вкусно», но массового исхода - не наблюдать. Одноплатники? Ну… в целом, да, но в зависимости от цели, имхо, иногда есть смысл смотреть в сторону мини-пк х86-64. Да и с UEFI и описанием железа через ACPI - по идее все хорошо только на серверах, а u-boot хоть и оптимистично развивается - не дает такой гибкости, описание железа через dtb вместо acpi меня немного вгоняет в грусть P.S. А вот рынок мобильных устройств они захватили наглухо
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	361. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 01:49
	> Не в ближайшее десятилетие, из десктопов по факту только apple, QC со > своими чипами все никак не влезет. Воооон там уже Milk-V с довольно нехилыми спеками на подходе... и вот как раз замайнлайнили. У эпла нет монополии на прогресс :)
	Ответить | Правка | Наверх | Cообщить модератору

	441. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (436), 11-Янв-24, 13:50
	Milk-V уже продаётся.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (47), 10-Янв-24, 01:09
	> главным образом из-за более высокой производительности AMD64 Скорее из-за обратной совместимости, которой у IA64 не было
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	362. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 01:52
	>> главным образом из-за более высокой производительности AMD64 > Скорее из-за обратной совместимости, которой у IA64 не было Скорее из-за... 1) Конских цен. 2) Програмеров покрутивших палцем у виска и не ставшими это покупать. 3) Кастомеров заметивших что за дохрена денег считает оно "не очень". Ибо програмеры из 2) не оптимизировали код под это от слова вообще. 4) А поскольку это VLIW-like нечто, родовое проклятье в виде компилеров все дополнительно усугубило. Получилось дорого и хреново. Сделать lite версию платформы для програмеров, дома - интел покусаный гигантоманией не допер. А потом пришел AMD с атлонами и дал мастеркласс как надо было, стало не до концепций и попыток навара на девах... :)
	Ответить | Правка | Наверх | Cообщить модератору

158. "Релиз ядра Linux 6.7"	+/–
Сообщение от dannyD (?), 08-Янв-24, 18:27
ладно, кто нить уже накатил, или как все только бла-бла-бла???
Ответить | Правка | Наверх | Cообщить модератору

	169. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (166), 08-Янв-24, 18:42
	Смысла в этом нет. Разве что ценителям новомодных ФС. Выше отписались они уже.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Релиз ядра Linux 6.7"	+/–
	Сообщение от dannyD (?), 08-Янв-24, 23:41
	у мну AMDGPU, и вроде ему стало лучше )))
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Релиз ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (170), 08-Янв-24, 18:42
	Последние человеки, которые сами компилировали ядра остались в нулевых. Сейчас жрут что дают дистростроители. Дебианщики получат это ядро через 5 лет, а вот арчешкольники думаю уже накатили новое ядро, у них и спроси.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	176. "Релиз ядра Linux 6.7"	+/–
	Сообщение от dannyD (?), 08-Янв-24, 18:49
	>>арчешкольники думаю уже накатили новое ядро, так я у них и спросил, а не вас которые с нулевых только бла-бла-бла.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (235), 08-Янв-24, 23:32
	дебианщики скачают 6.7 и запустят сборку деб пакета make -j`nproc` bindeb-pkg
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	363. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 01:55
	> Последние человеки, которые сами компилировали ядра остались в нулевых. Вот те раз?! Кажется моя машинв времени работает эффективнее чем ожидалось, меня на 20 лет пробросило а я даже не заметил.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	206. "Релиз ядра Linux 6.7"	+/–
	Сообщение от dannyD (?), 08-Янв-24, 20:27
	ну всё, 6.7.0 походу нормально, еще надо ритуал бокс проверить.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	364. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 01:57
	> ладно, кто нить уже накатил, или как все только бла-бла-бла??? Я еще -rc гонял, в основном из-за Кента. Интересно было посмотреть на его творение. А что, опеннетчики уже настолько слились что только потребительствовать умеют и гордиться объемом захаваного? Плюсы опенсорса имеют пойнт только если ими еще и пользоватсья.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

168. "Релиз ядра Linux 6.7"	+/–
Сообщение от Аноним (-), 08-Янв-24, 18:41
> прекращение поддержки архитектуры Itanium кому мешало? и вот рассказывайте теперь что линпус годится для старого и экзотического железа. с такими темпами и х86 выпрут, народ день повозмущается и молчаливо пойдет обновляться.
Ответить | Правка | Наверх | Cообщить модератору

	171. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (166), 08-Янв-24, 18:44
	Старые ядра всё так же рабочие. Поддерживать ещё долго будут.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (228), 08-Янв-24, 22:42
	Мешает тем, чье время на поддержку оно тратит Зачем поддерживать никому не нужный код для никому не нужной архитектуры?
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	233. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (301), 08-Янв-24, 23:24
	Intel x86 устаревшая архитектура. Linux разрабатывают корпорации. Корпорации не обязаны поддразнивать старое железо анонимов. Актуальные архитектуры AMD64, ARM64.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	245. "Релиз ядра Linux 6.7"	+3 +/–
	Сообщение от llolik (ok), 09-Янв-24, 00:03
	В новости же написано > при этом Линус Торвальдс выразил готовность вернуть поддержку ia64 в ядро, но только если найдётся сопровождающий, который продемонстрирует качественное сопровождение данной платформы вне основного ядра как минимум в течение года. Идешь в рассылку и пишешь "я готов быть тем, кто продемонстрирует качественное сопровождение данной платформы вне основного ядра как минимум в течение года". Ну, чувак, извини, что других за несколько лет так и не нашлось. Придётся тебе, раз ты хочешь.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	368. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 07:39
	Как будто в этом есть что-то плохое? Предполагаю - и возмущаться не будут - когда оно до mainstream-LTS дистрибутивов доползет в том x86 совсем уж никакого смысла не останется.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

202. "Релиз ядра Linux 6.7"	+1 +/–
Сообщение от Анонус (?), 08-Янв-24, 20:13
> GC 11.5, NBIO 7.11, SMU 14, SMU 13.0 OD, DCN 3.5, VPE 6.1 и DML2 Кто все эти люди?
Ответить | Правка | Наверх | Cообщить модератору

	366. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 02:28
	>> GC 11.5, NBIO 7.11, SMU 14, SMU 13.0 OD, DCN 3.5, VPE 6.1 и DML2 > Кто все эти люди? Это IP-блоки GPU-чипов от AMD. Например: SMU == System Management Unit. DCN == Display Core Next.
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (383), 10-Янв-24, 12:36
	Добавили поддержку обновленных IP-блоков GPU, которые появяться в анонсированных гибридных процессорах Ryzen 8000G
	Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

213. "Релиз ядра Linux 6.7"	–1 +/–
Сообщение от cheburnator9000 (ok), 08-Янв-24, 21:17
Столько изменений. Но извините меня, улучшения для Линукс как "декстоп системы" когда-нибудь планируются? Или там культ онанистов на файловые системы?
Ответить | Правка | Наверх | Cообщить модератору

	225. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Янв-24, 22:17
	Линпус никогда не будет пригоден для десктопа. Никогда, потому что нет централизованной модели разработки, нет единого GUI интерфейса, нет единых стандартов, нет нормальных дизайнеров, которые за бесплатно будут готовы состряпать что-то пригодное в плане UI/UX.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от DEF (?), 09-Янв-24, 07:16
	Все есть. GNOME, systemd, Wayland, Kernel, DNF, RPM.
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (312), 09-Янв-24, 12:04
	В гибкости сила линукса, а не слабость. Если бы всем нужен был готовый блоб от корпораста, то все пользовались бы виндой.
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

	360. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 01:47
	> В гибкости сила линукса, а не слабость. Если бы всем нужен был > готовый блоб от корпораста, то все пользовались бы виндой. Ибо сказано - "зачем стадам дары свободы?" :). Вон тот гражданин решил проиллюстрировать что именно имеется в виду.
	Ответить | Правка | Наверх | Cообщить модератору

	369. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 07:41
	... сказал Аноним и пошел конпелять генту на телефон... Или нет?
	Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

	231. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Beta Version (ok), 08-Янв-24, 22:48
	Чем вам сейчас Линукс плох для десктопа?
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	241. "Релиз ядра Linux 6.7"	+/–
	Сообщение от cheburnator9000 (ok), 08-Янв-24, 23:46
	Уу, много чем, все даже и не перечислить, например количеством so.libs которые засирают систему начиная от пакетных менеджеров, заканчивая snap/flatpak. Да вы сейчас начнете заявлять что это не проблема Линукса, но под эту гребенку можно подмести абсолютно все, у линукса все шикарно (там в терминале с консольным busybox) это дистростроители упороты. Вот вариант за который отвечает линукс - то как система ведет себя в ситуации сильной нагрузки на CPU (не I/O), если компуктер нагрузить множеством приложений часть которых жрет 90% cpu и во всю AVX инструкции ведь в такой ситуации (по крайней мере на моем опыте) не редко что все нахрен зависнет. Тогда даже firefox запустить долго. Например, на венде все закешированное в озу в этот момент работает ок, под линуксом же ощущение что он вычещает кеш озу или вообще активно начинает его сбрасывать на диск, но так как у нас сейчас везде (кхе кхе) zswap/zram которые lz4/zstd (алгоритмы активно утилизирующие много потоков) это сделать системе сложнее. Да блин и опять же можно заявить что проблемы пользователей решаются 16 ядерными 5ггц Интелами! Иными словами я могу компилировать, запустить тяжелую игру и смотреть ютуб в браузере одновременно под Windows, я не могу этого сделать под линуксом, ибо видео в браузере просто будет зависать. Про I/O на системах с проблемными накопителями я вообще молчу тут можно только сопереживать. Был один веник подозреваю что с размагничиванием ибо лежал он 10 лет и пользовались им для футбола, с которого нужно было хоть что-то спасти, так вот вендовый "проводник" фоточки скопировал, линукс не смог смонтировать ntfs с первого раза, ls/cd работали с пингом до марса, а копировалось все на bytes per second скорости. Наверное это тоже не проблема линукса ведь пользователь сам криворук не имеет бекапов и не приобрел такой новомодный и современный NVME.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Релиз ядра Linux 6.7"	+/–
	Сообщение от cheburnator9000 (ok), 08-Янв-24, 23:53
	Иными словами ведь это вообще не проблемы линукса как ядра такового, вон они файловые системы ковыряют уже 33 года, до стабильности и качества вендового NTFS из состава Windows 10 как до луны на велосипеде. Пользователю не нужны quotas/layers/bcache. Линус обслуживает хотелки корпорацией и ничего более, которым в свою очередь нужно хранить ваши персональные данные и как то доставлять их через интернет с минимальными затратами.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (129), 09-Янв-24, 00:32
	>стабильности и качества вендового NTFS из состава Windows 10 В ней регулярно (минимум каждые 2 года из того что я знаю) чинят рассыпающиеся метаданные, о чём ты? При относительно нормальном использовании. Ну, исчерпание места это нормальное использование. Это полный разнос, с ext4 ничего даже близко похожего не случалось на моей памяти. Сама ntfs днище абсолютное, хоть как-то она работает сегодня только благодаря ssd.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от cheburnator9000 (ok), 09-Янв-24, 00:34
	>>стабильности и качества вендового NTFS из состава Windows 10 > В ней регулярно (минимум каждые 2 года из того что я знаю) > чинят рассыпающиеся метаданные, о чём ты? При относительно нормальном использовании. Ну, > исчерпание места это нормальное использование. Это полный разнос, с ext4 ничего > даже близко похожего не случалось на моей памяти. Сама ntfs днище > абсолютное, хоть как-то она работает сегодня только благодаря ssd. Как перешел на SSD ничего нигде ни разу не "рассыпалось" за 10 лет. В ntfs растет MFT ровно потому что очень мелкие файлы хранятся прямо в записи MFT, точно также как половина линуксовых ФС делает. О как "исчирпании" места идет речь? Или вы при 100% заполности файлов пытаетесь туда еще записать пару гигабайт? А под линуксом что свободное место само появится силой мощи ФС? Под линуксом любая ФС работает благодаря SSD, иначе привет lost+found коим я являюсь свидетелем видеть два раза за пользование ноутбуком в 2010-15 годах.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (129), 09-Янв-24, 00:47
	> О как "исчирпании" места идет речь? Или вы при 100% заполности файлов > пытаетесь туда еще записать пару гигабайт? А под линуксом что свободное > место само появится силой мощи ФС? помимо эээ проблем с кончившимся местом при обновлении (насколько я знаю это кое-как научились решать в итоге), файловая система может рассыпаться из-за багов и дальше только форматирование и переустановка, в случае с ntfs. > Под линуксом любая ФС работает благодаря SSD, иначе привет lost+found коим я > являюсь свидетелем видеть два раза за пользование ноутбуком в 2010-15 годах. Какие-то фантазии, я использую ext4 в writeback режиме на hdd, что является опасной практикой. С большой вероятностью повреждаются файлы, открытые на запись. И lost+found пополнялась только 1 раз из-за бага с fast_commit, при перезагрузке повреждался журнал и были различные проблемы с суперблоком, было около 30 таких деструктивных повреждений в сумме. Файлы пишутся постоянно. При чём тут ssd вообще непонятно, на ssd повреждений при обесточивании куда больше. Для ntfs твердотельный накопитель критично из-за низкой производительности при работе с файлами и необходимости постоянно сканировать данные.
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 07:52
	>файловая система может рассыпаться из-за багов и дальше только форматирование и переустановка, в случае с ntfs. Ухтыж, новости. А в linux волшебным образом не может? И лечится это "более другими" способами - ну там, подцепить к компу с виндой и запустить что-нибудь пипиритарное для извлечения рассыпухи, да? IRL - "проблемы с ntfs" эффект большой базы, и то предполагаю, что если посчитать проблемы с фс "в штуках" на lin\win - выйдет примерно одинаково при нормальной вменяемой эксплуатации и там, и там "около нуля". А то, что некоторые... свободолюбители на UPS раскошелиться пожадничали, свободное место на мониторинг не поставили, кетай-кетай-подешевше с помойки без рейда воткнули и с двух рук на "чексуммы" наяривают - нууээээ... порадуемся за них!
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 10-Янв-24, 08:56
	Покажи мне хоть 1 баг в ext4, где суперблок разлетался из-за кончившегося места. Выживаемость под бсодами тоже имеет значение конечно, от них тебе не поможет никакой бесперебойник. Кроме того, ntfs куда чаще теряет файлы и венда отправляет повреждённые файлы в кучу и без имени.
	Ответить | Правка | Наверх | Cообщить модератору

	393. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 13:25
	> Покажи мне хоть 1 баг в ext4, где суперблок разлетался из-за кончившегося > места. Выживаемость под бсодами тоже имеет значение конечно, от них тебе > не поможет никакой бесперебойник. Кроме того, ntfs куда чаще теряет файлы > и венда отправляет повреждённые файлы в кучу и без имени. Вот не поверишь - у меня нет зубов в труднодоступных местах. У меня за 20 лет ни на ext, ни на ntfs рассыпухи по исчерпанию места - не было. И случаев "внезапно кончилось место" за последние десять лет было - по пальцам одной руки и то, сюрприииз! не на винде раздел логами засирало. И после bsod\kernel panic фатального разлета ФС - не было. По десктопам статистики не имею - но "на слух" тоже не помню. Потерянные файлы - да, было - и там, и там. При этом шансы восстановить данные с ntfs по ощущениям - больше тупо по тому, что средств восстановления - кратно больше. Не то, чтобы статистика абсолютно релевантная - но громкость стонов анонимов в интернетах параметр тоже... сомнительный.
	Ответить | Правка | Наверх | Cообщить модератору

	400. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 18:44
	> 20 лет ни на ext, ни на ntfs рассыпухи по исчерпанию места - не было. А у майкрософта был фееричный баг, когда на винче более 2 терабайт доступ врапался - MBR а заодно и MFT за ним - выпилен к хренам. После энного числа прецедентов даже MS KB запилили и апдейт выкатили. Но сначала разумеется у эн юзерей файлухи полетели. А починили лишь когда >= 2TiB массовыми стали и поток неудачников подозрително прибавился. Или вон там прикольная шутка юмора, если кто что-то делает с файлом с именем типа $I30 чтоли - нтфсу наступает жесткий и бескомпромиссный кабздец. Прикольный баг так то. Присылаешь нелоху архив - а у него файлуха ХРЯСЬ!
	Ответить | Правка | Наверх | Cообщить модератору

	409. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 19:13
	>[оверквотинг удален] > А у майкрософта был фееричный баг, когда на винче более 2 терабайт > доступ врапался - MBR а заодно и MFT за ним - > выпилен к хренам. > После энного числа прецедентов даже MS KB запилили и апдейт выкатили. Но > сначала разумеется у эн юзерей файлухи полетели. А починили лишь когда > >= 2TiB массовыми стали и поток неудачников подозрително прибавился. > Или вон там прикольная шутка юмора, если кто что-то делает с файлом > с именем типа $I30 чтоли - нтфсу наступает жесткий и бескомпромиссный > кабздец. Прикольный баг так то. Присылаешь нелоху архив - а у > него файлуха ХРЯСЬ! "ext3\ext4 data loss" сами нагуглите или помощь нужна?
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 20:18
	> "ext3\ext4 data loss" сами нагуглите или помощь нужна? Настолько брутальных багов в релизной версии кода, чтобы файлуху совсем наповал уделывало - я все же не припоминаю. Так что майкрософт с их качеством кода за пальму первенства в шитпараде явно может порубиться. Про их BSOD в ntfs.sys даже упоминать неудобно, индусское качество кода настолько классика жанра, что сисинтерналс, кажется, в FAQ аж это записали - мол, если бсод в ntfs.sys это у вас файлуха побилась. Кстати морды у юзерей при этом очень интересные, ибо попытка зацепить винч в другой комп немедленно приводит к тому же результату - бсод на попытке его монтирования. Это вызывает у хомяков довольно прикольную панику. И не, в лине такого треша в ядерном коде десятилетиями я не припоминаю. Для меня господа btrfs за полдня починили вообще (я баги в -rc несколько раз ловил до релиза и рубал "на подлете"). Мне так больше нравится.
	Ответить | Правка | Наверх | Cообщить модератору

	423. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 22:33
	>> "ext3\ext4 data loss" сами нагуглите или помощь нужна? > Настолько брутальных багов в релизной версии кода, чтобы файлуху совсем наповал уделывало > - я все же не припоминаю. Так что майкрософт с их > качеством кода за пальму первенства в шитпараде явно может порубиться. Да-да. Вы там главное два раза подряд на LTS-ядре не перезагружайтесь - и всё ок будет. Ой, этадругое! Остальное, звиняюсь, поскипал - что негров в америке вешают, я уже понял.
	Ответить | Правка | К родителю #412 | Наверх | Cообщить модератору

	452. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 13-Янв-24, 00:12
	> Да-да. Вы там главное два раза подряд на LTS-ядре не перезагружайтесь - > и всё ок будет. Ой, этадругое! Линуксоиды свои баги чинят. А ntfs.sys летал в бсод от порушеных ФС на моей памяти ... от NT4 до десятки точно. А может и сейчас летает. В линухе такое считается за баг, если не вулн, и чинится при обнаружении в темпе вальса. Мне такое отношение к софту больше нравится. И да, стандартный маневр в таком кейсе - читануть нтфсину линем. Гребаный стыд, дорогой майкрософт. Впрочем, теперь то мне похрен - это счастье уже не у меня :) > Остальное, звиняюсь, поскипал - что негров в америке вешают, я уже понял. Не, вы не поняли. Мне отношение винды к качеству дров и системного софта вообще совсем не нравится. И мой опыт в починке багов с линухом намного лучше - в винде если что-то не работает или глючит, это все, кабздец, не доорешься в принципе. Интересно, а пропадающий хзкуда индикатор раскладки так и донимает юзерей по сей день? Понятно что проблемы господ с >1 локали манагеров из редмонда не волнуют, но все же очень прикольный баг. По интенсивности матюков юзерей.
	Ответить | Правка | К родителю #423 | Наверх | Cообщить модератору

	458. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 13-Янв-24, 11:13
	> Линуксоиды свои баги чинят. А ntfs.sys летал в бсод от порушеных ФС > на моей памяти ... от NT4 до десятки точно. А может > и сейчас летает. В линухе такое считается за баг, если не > вулн, и чинится при обнаружении в темпе вальса. Мне такое отношение > к софту больше нравится. За-ме-ча-тель-ный пример "переобувания в прыжке". Засчитано. > Не, вы не поняли. Мне отношение винды к качеству дров и системного > софта вообще совсем не нравится. И мой опыт в починке багов > с линухом намного лучше - в винде если что-то не работает > или глючит, это все, кабздец, не доорешься в принципе. То ли дело вот в линуксах - нувошный драйвер файлухи портил, то понятно, другое - "К" - "качество!" > Интересно, а пропадающий хзкуда индикатор раскладки так и донимает юзерей по сей > день? Понятно что проблемы господ с >1 локали манагеров из редмонда > не волнуют, но все же очень прикольный баг. По интенсивности матюков > юзерей. Уй. Вот это ржака, да. Учитывая объем плясок-с-бубном вокруг этого индикатора в различных DE - я-б про это ей-ей, молчал. Да и само переключение... иксы, вейланд - нестандартные раскладки (Переключите eng на us dvorak и посмотрите что с хоткеями будет при переключении языков) - в винде, что характерно, just works.
	Ответить | Правка | К родителю #452 | Наверх | Cообщить модератору

	453. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 13-Янв-24, 00:24
	> Ну, баги везде бывают. Да. Только в линухе я с вон теми господами за полдня их зашибаю - и порядочек. А в винде дораться вообще - удачи. И самому пофиксить тоже не судьба - сорцов же нет. Так и живут некоторые баги десятилетиями. Нафига б мне такой хоккей - я не придумал, потому и не юзаю винду. > Зато по фичам Линукс отстаёт вроде. В NTFS > можно создать файл с '\0' в середине имени, а в Linux как? Там так нельзя, это 1 из немногих ограничений POSIX. А фича то в чем? Позволяет заглючить чуть менее чем весь софт в системе? Я без этого наверное переживу, какие у этого легитимные применения? :). Впрочем в линухе "C:\con\con" - валидное имя файла (нет, не путь, именно имя). Удачи создать ЭТО вообще в винде. А если стало скучно можно загнать в файло 0x0d и 0x0a, так и половина линуксоидов откушает лулзов при процессинге этого. > Или вот ':' в имени - зачётная фича, называется Alternative Data Stream. Ога. Вирье одобряет. Еще 1 суперфича - которой я ни разу не пользовался. Да... это вам не рефлинки и даже не перфоманс ФС чтобы 250К файлов за присест. Но мне вот эти фичи как-то немного актуальней, печалька :) > Документирована в MSDN. А все про неё узнали, когда вдруг обнаружились миллионы > невидимых драйверов, рассылающих спамы и куки. Ну дык! Вирмейкер тоже человек, тоже клевых фич хочет. Их клиент! Майкрософтовский, в смысле :))
	Ответить | Правка | Наверх | Cообщить модератору

	463. "Релиз ядра Linux 6.7"	+/–
	Сообщение от maximnik0 (?), 14-Янв-24, 08:12
	>2 терабайт доступ врапался - MBR а заодно и MFT Хм, > 2 Тб  и МБР .....Кто то что слегка привирает.Нет ,есть утилиты для работы и загрузки ,но это из разряда гланды через задний проход.Не удевлчюсь что оно сыпались.Тогда уж надёжней было вообще без разметки работать,подключать диск через монтирование.Да да,в винде можно монтировать диски в папку.
	Ответить | Правка | К родителю #400 | Наверх | Cообщить модератору

	473. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (472), 17-Янв-24, 18:20
	> 2 Тб и МБР .....Кто то что слегка привирает. Может оно и GPT было. Или несколько разделов. Факт в том что доступы врапались - и то что должно было в хвост диска отправиться - выносило начало файлухи, в том числе - MFT, после чего все было достаточно печально. > Нет,есть утилиты для работы и загрузки ,но это из разряда гланды через задний проход. > Не удевлчюсь что оно сыпались.Тогда уж надёжней было вообще без разметки работать, > подключать диск через монтирование.Да да,в винде можно монтировать диски в папку. А таки коронный номер с убиением файлух врапом - подогнал сам майкрософт. Даже MS KB какой-то писал - мол если у вас диск более 2 тер, вайвай, срочно накатите - а то все может помереть по мере заполнения диска.
	Ответить | Правка | Наверх | Cообщить модератору

	488. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 23-Янв-24, 07:39
	> Хм, > 2 Тб  и МБР .....Кто то что слегка привирает.Нет > ,есть утилиты для работы и загрузки ,но это из разряда гланды > через задний проход. Если что я вспомнил что мне даже кажись ЭТО лично попадалось, я походу рекаварил именно ТАКОЕ разок кому-то. Представляешь, начало винча. Партишн, MFT, вот это все. Опппппа? При взгляде хексэдитором... а там вместо всего этого ... кусок PE EXE файла какой-то записан! Вау! И нормальные такие ошметки PE EXE там где должны быть партиции, MFT и проч. Видимо тот неудачник что-то сетапил - ну оно и отврапилось воооон туда! А круто получить виндовые бинарники какой-то проги вместо партишна и прочих MFT так то? :) Ессно оно после этого - в хлам и не маунтится стандартным методом от слова вообще. Чинится это ессно неудобно, альтернативным парсером выцепить самое нужное - может прокатить, но flawless не получится и возни - хватает. В этом слуае скажите спасибо за то что есть, ибо там самых критичных частей фс с нами уже как раз и нет.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Beta Version (ok), 09-Янв-24, 00:21
	Можно подробнее, что за засирание системы so.libs и как это мешает десктому и конкретно обычному пользователю? И что там со snap/flatpak? >Иными словами я могу компилировать, запустить тяжелую игру и смотреть ютуб в браузере одновременно под Windows, я не могу этого сделать под линуксом, ибо видео в браузере просто будет зависать. А можно что-то, что мешает десктопу и обычному пользователю, а не вот это вот натягивание совы на глобус? 10 лет пользуюсь Линуксом и до сих пор не знал, что я на нём страдаю от невозможности запустить одновременно компилятор, тяжёлую игру и ещё в фоне смотреть видео в браузере. Хотя я не проверял. Может, мой 5600X без проблем справится. Тем более я компилирую на 6 потоках. Все же десктопники что нибудь дома компилируют каждый вечер. >Был один веник подозреваю что с размагничиванием ибо лежал он 10 лет и пользовались им для футбола, с которого нужно было хоть что-то спасти, так вот вендовый "проводник" фоточки скопировал, линукс не смог смонтировать ntfs с первого раза Насколько я знаю, MS никогда и не портировала официально свою ntfs под Линукс. Как там работают костыли со сторонней проприетарной фс на древнем убитом hdd - проблема этой фс и владельца убитого hdd. Давай сойдёмся на том, что Виндовс не подходит для десктопа, т.к. не поддерживает ext4. И я читал, что Венда до сих пор не умеет устанавливаться на ПК с двумя подключёнными SSD (ток не уточнял, nvme или даже с sata). Приходится лезть отключать один. В общем, пока как-то неубедительно.
	Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

	255. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (154), 09-Янв-24, 00:49
	>  запустить одновременно компилятор, тяжёлую игру и ещё в фоне смотреть видео в браузере. Хотя я не проверял. Может, мой 5600X без проблем справится Я проверял, всё ок
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Релиз ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (324), 09-Янв-24, 14:35
	> Можно подробнее, что за засирание системы so.libs и как это мешает десктому и конкретно обычному пользователю? Да он просто с праздников не протрезвел еще и перепутал "so.libs"  с "dll hell", бывает
	Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

	253. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (154), 09-Янв-24, 00:46
	Если у тебя столько важных проблем, то можешь не пользоваться. Видишь же, не для тебя сделали > так вот вендовый "проводник" фоточки скопировал, линукс не смог смонтировать ntfs с первого раза NTFS чья ФС? Ну, давай до свидания
	Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

	372. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 07:56
	Ээээ... а с XFS предлагаете в SGI идти? :)
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 15:22
	> Ээээ... а с XFS предлагаете в SGI идти? :) Хороший совет между прочим. Некромансеру кладбище - дом родной!
	Ответить | Правка | Наверх | Cообщить модератору

	398. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 15:37
	>> Ээээ... а с XFS предлагаете в SGI идти? :) > Хороший совет между прочим. Некромансеру кладбище - дом родной! Ну, только окажется, что "своих" ФС у linux'а не то, чтобы разбежаться останется. Вот ext(2|3|4) - выбирай, что нравится!
	Ответить | Правка | Наверх | Cообщить модератору

	402. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 18:48
	> останется. Вот ext(2|3|4) - выбирай, что нравится! А btrfs и bcachefs - чьи тогда файлухи? Они обе сразу под линух эксклюзивно деланы. Первого правда под винду кой-как откосплеили, криво и косо, видимо инновационный треш из 90 от майкрософт корп имени фат и нтфс кого-то возбуждал еще меньше чем вон то.
	Ответить | Правка | Наверх | Cообщить модератору

	406. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 19:05
	>> останется. Вот ext(2|3|4) - выбирай, что нравится! > А btrfs и bcachefs - чьи тогда файлухи? Они обе сразу под > линух эксклюзивно деланы. Первого правда под винду кой-как откосплеили, криво и > косо, видимо инновационный треш из 90 от майкрософт корп имени фат > и нтфс кого-то возбуждал еще меньше чем вон то. Первый - оракловый, если не путаю. Второй... Не, ну удачи его использовать в проде )
	Ответить | Правка | Наверх | Cообщить модератору

	413. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 20:27
	> Первый - оракловый, если не путаю. Это по какому бы критерию? И сам оракл про это в курсе? Сейчас основная разработка делается вон теми, из FB/SuSE/WD/... У оракла вообще линуксные девы разбежались что-то. Иногда букмарки нехило апдейтить. На момент дизайна - были еще заклятые друзья оракла из IBM - cow деревья их перец кажется придумал. Это нещитово? А Мэйсон дизайнивший это - в FB перешел. И он что так core arcnitect был что сяк, человек то один и тот же. > Второй... Не, ну удачи его использовать в проде ) Насчет прода хз, а эн виртуалок уже - in flight. Даже попинал их там немного по части нескольких косяков, часть даже починили. Вы не боитесь, мы себе системы нарулим. А всякие потребуны с маздайным настроям имхо пусть лучше делают мозги саппортам майкрософт корп. Который несомненно обеспечит господам светлое будущее. То которое вон те заслуживают. Мне же такое будущее чем-то не нравится и я для себя буду стараться получить иную версию оного.
	Ответить | Правка | Наверх | Cообщить модератору

	422. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 22:09
	> Это по какому бы критерию? И сам оракл про это в курсе? > Сейчас основная разработка делается вон теми, из FB/SuSE/WD/... У оракла вообще > линуксные девы разбежались что-то. Иногда букмарки нехило апдейтить. Юзе вики, Люк! И читай, на что именно отвечаешь - помогает. БэТэЭр "оракловый" примерно в той же степени, как XFS - SGI'шный а линуксьячий NTFS - "майкрософтовский". А "не-корповского" в линуксах - полтора "ничего" из работоспособного. Так ферштейн, или кроме разжевывания еще и переварить надо? > Насчет прода хз, а эн виртуалок уже - in flight. Даже попинал > их там немного по части нескольких косяков, часть даже починили. Вы > не боитесь, мы себе системы нарулим. А всякие потребуны с маздайным > настроям имхо пусть лучше делают мозги саппортам майкрософт корп. Который несомненно > обеспечит господам светлое будущее. То которое вон те заслуживают. Мне же > такое будущее чем-то не нравится и я для себя буду стараться > получить иную версию оного. Ну я ж говорю - удачи там на локалхосте, а ко мне - в дефолте какой-нибудь прости осспыдя, Astra Linux по текущим раскладам, пожалуйста. Можно в унутре какого "наш-ответ-нетаппу" - тоже норм. А так - пионЭры, идите в ..., пжалста.
	Ответить | Правка | Наверх | Cообщить модератору

	454. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 13-Янв-24, 00:35
	> Юзе вики, Люк! И читай, на что именно отвечаешь - помогает. Нафиг мне ваша вика, если у меня вон там - код, вон там - разработчики. А вику мало того что хз какой блохастик писал, так еще вопрос когда он букмарки апдейтил. По состоянию на сейчас оракл в btrfs - далеко не первая скрипка. > БэТэЭр "оракловый" примерно в той же степени, как XFS - SGI'шный а > линуксьячий NTFS - "майкрософтовский". Если с XFS еще можно на этот счет подискутировать, ибо ща пилится в основном редхатом и новые фичи вносят они - то NTFS вот именно майкрософтовский от и до. Никто кроме них это не разрабатывает, в том смысле что новые фичи и проч - только они привносят. И вот тут без вариантов. > Так ферштейн, или кроме разжевывания еще и переварить надо? Да тут все понятно, холуй корпо-противный, 1 штука. Я таких считаю за слизняков. > Ну я ж говорю - удачи там на локалхосте, а ко мне > - в дефолте какой-нибудь прости осспыдя, Astra Linux по текущим раскладам, Лияно мне совершенно не интересно что там у вас в вашем австралинухе, это не мои проблемы. > пожалуйста. Можно в унутре какого "наш-ответ-нетаппу" - тоже норм. А так > - пионЭры, идите в ..., пжалста. На мой вкус это вы с вашими астрами и прочей растительностью идите куда-нибудь где вам самое место, бишь, задворки цивилизации. Кто еще этим кроме всяких чукч пользуется?
	Ответить | Правка | Наверх | Cообщить модератору

	457. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 13-Янв-24, 11:05
	Эммм... а вы точно не чатжэпэтэ и не аквариумная рыбка? Ответ "на последний коммент" с полным игнорированием логики ветки дискуссии кагбэ намекает :) Опять же, обилие ритуальных инвектив в сторону "корпов" - по-доз-ри-тель-но
	Ответить | Правка | Наверх | Cообщить модератору

	489. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 23-Янв-24, 07:43
	> Эммм... а вы точно не чатжэпэтэ и не аквариумная рыбка? Ответ "на > последний коммент" с полным игнорированием логики ветки дискуссии кагбэ намекает :) > Опять же, обилие ритуальных инвектив в сторону "корпов" - по-доз-ри-тель-но Для аквариумных рыбок сообщаю: почитайте новость про Ханса Рейзера. Там почему-то будет упоминание Криса Мэйсона. Оказывается он не собственность энной корпы и так то может сменить место. И так то на его счету журналинг Reiser3 еще. Который вон тот гражданин кстати хвалил. Ну а что, вот конкретно эта часть рейзер3 никаких проблем ни у кого не вызвыала. Там у них совсем в другом факап.
	Ответить | Правка | К родителю #457 | Наверх | Cообщить модератору

	490. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 23-Янв-24, 08:51
	>> Эммм... а вы точно не чатжэпэтэ и не аквариумная рыбка? Ответ "на >> последний коммент" с полным игнорированием логики ветки дискуссии кагбэ намекает :) >> Опять же, обилие ритуальных инвектив в сторону "корпов" - по-доз-ри-тель-но > Для аквариумных рыбок сообщаю: почитайте новость про Ханса Рейзера. Там почему-то будет > упоминание Криса Мэйсона. Оказывается он не собственность энной корпы и так > то может сменить место. И так то на его счету журналинг > Reiser3 еще. Который вон тот гражданин кстати хвалил. Ну а что, > вот конкретно эта часть рейзер3 никаких проблем ни у кого не > вызвыала. Там у них совсем в другом факап. Ну, т.е. конь-текст дискуссии вы так и ниасилили, поздравляю.
	Ответить | Правка | К родителю #489 | Наверх | Cообщить модератору

	491. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 23-Янв-24, 16:47
	>> вот конкретно эта часть рейзер3 никаких проблем ни у кого не >> вызвыала. Там у них совсем в другом факап. > Ну, т.е. конь-текст дискуссии вы так и ниасилили, поздравляю. Ваш конь прост как рыбка гупи - вы холуй (в данном случае корпоративный) до мозга костей. Ну что, золотая рыбка, довольна честной демаркацией терминов и контекстом? Для меня вы соответственно что-то типа слизня прилипшего на ботинок.
	Ответить | Правка | К родителю #490 | Наверх | Cообщить модератору

	493. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 23-Янв-24, 20:49
	>>> вот конкретно эта часть рейзер3 никаких проблем ни у кого не >>> вызвыала. Там у них совсем в другом факап. >> Ну, т.е. конь-текст дискуссии вы так и ниасилили, поздравляю. > Ваш конь прост как рыбка гупи - вы холуй (в данном случае > корпоративный) до мозга костей. Ну что, золотая рыбка, довольна честной демаркацией > терминов и контекстом? Для меня вы соответственно что-то типа слизня прилипшего > на ботинок. Не сумев удержать в голове не то, что "разжеванное", а "перевареное" даже содержимое диалога колхозный сайберпунк перешел на обсуждение личности оппонента. Не удивительно. Абизяны вот во все непонятное фекалиями кидаются - ну и колхозные сайберпунки от них не то, чтобы далеко ушли. Ч.и т.д.
	Ответить | Правка | К родителю #491 | Наверх | Cообщить модератору

	417. "Релиз ядра Linux 6.7"	+/–
	Сообщение от namenotfound (?), 10-Янв-24, 21:28
	> например количеством so.libs которые засирают систему начиная от пакетных менеджеров, заканчивая snap/flatpak ну, то есть, тебе не нравится подходы "давайте все в одну свалку скинем и заставим пакетный менеджер разбираться как это все совместить и не дать системе попердолиться" и "давайте разделим кому что нужно, а пакетный менеджер будет только предоставлять доступ и дедуплицировать файлы для сохранения пространства на диске". адепт статической линковки что-ли? > под линуксом же ощущение что он вычещает кеш озу или вообще активно начинает его сбрасывать на диск пиши в спортлото^W^W дистростроителям или настраивай ядро сам > сейчас везде (кхе кхе) zswap/zram которые lz4/zstd (алгоритмы активно утилизирующие много потоков) это сделать системе сложнее так и винда жмет место в оперативке и в свопе > линукс не смог смонтировать ntfs с первого раза а винда не сможет смонтировать ext4 с первого раза, и что?
	Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

	419. "Релиз ядра Linux 6.7"	+/–
	Сообщение от cheburnator9000 (ok), 10-Янв-24, 21:49
	Установи ubuntu последнюю где firefox идет в виде snap, и firefox из бинарного архива с оффсайта, наблюдай за оперативкой. Snap версия кушает ровно в 2 раза больше ОЗУ для своего запуска. Потому что Cannonical навешала всем лапшу на уши "как они там оптимизировали все", firefox snap грузит дофига solibs для своей работы, все эти solibs могут совпадать с системными версиями, но они по хеш сумме разные, ибо другая база сборки/компилятор/флаги/патчи, и по этому у тебя в системе уже мусорка by design. Можешь еще установить flatpak и его 20 рантаймов и наблюдать как в пустую уходит пространство на диске. Когда ядро вычистит файловый кеш кода библиотек от firefox snap тот в свою очередь пойдет перечитывать их с диска иными словами распаковывать и тратить ресурсы cpu впустую, так как они все сжатые. Со flatpak то же самое только они там не сжатые, но для десятка flatpak программ у тебя будет 5 рантаймов минимум в половине из которых будут библиотеки с уязвимостями. Есть огромная разница когда в кеше озу лежит одна копия libsmb2 и шарит свой код со всеми, совершенно другая когда их там штук 5 и пара с уязвимостями. В венде 8.1+ работает memory compression и swap, причем первое можно выключить, как и второе и по отдельности. Вендовое сжатие слабое и фоновое, иными словами не агрессивное. Сравни работу Unity игры где погромисты загрузили 12 гб ассетов на 16 гб ПК, венде все будет прилично, в какой-нибудь Fedora из коробки будут минимум лаги работы всей системы, максимум она нафиг тупо зависнет. Более того самая позорная реализация сжатия памяти это в MacOS. Когда система by design течет сотнями МБ сжатие не поможет. Привет WindowServer и ладно он у них еще до 3 гб утечет, так ведь люди работуют что и 20+, 30+ ГБ вполне реально получить.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (129), 08-Янв-24, 23:32
	Изменения в основном в интересах корпораций и "грязных" спецслужб. Линукс идеальная система для десктопа. Особенно, если ты отлично знаешь баш, питон, си, и не боишься использовать собственный софт и допиливать чужой под свои задачи. Ядро, в общем-то, пофиг, но в нём есть весьма удобная и полезная функциональность, которой в альтернативных системах не завезли. Если ты знаешь только дотнет/жс, лучше валить на венду, там и вскод протрояненый тебе и всё остальное.
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	240. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (235), 08-Янв-24, 23:46
	скажите честно, ваш опыт с Линукс ограничился запуском инсталлятора RedHat в 90х?
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 09-Янв-24, 00:17
	Нет, мой опыт с системами на базе линукса 20 лет применения на десктопе. Венда начиная с 10 стала немного пригодна, но слишком дорого и сложно по сравнению с линуксом, многие проблемы не решаемы в принципе. Движение в правильном направлении в целом, но отсутствие контроля над системой и различные регулярные ошибки системы (в частности, деструктивные обновления) не позволяют использовать такую систему эффективно.
	Ответить | Правка | Наверх | Cообщить модератору

	351. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 23:04
	> Изменения в основном в интересах корпораций и "грязных" спецслужб. Я затруднился определить - Кент с его дохреналионом строк кода относится таки к первым или все же ко вторым? :)
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	373. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 07:59
	И что из описанного относится именно к desktop-usage для усредненного _пользователя_?
	Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

	376. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 10-Янв-24, 08:58
	> И что из описанного относится именно к desktop-usage для усредненного _пользователя_? какой-нибудь criu относится именно к desktop-usage
	Ответить | Правка | Наверх | Cообщить модератору

	377. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 09:21
	>> И что из описанного относится именно к desktop-usage для усредненного _пользователя_? > какой-нибудь criu относится именно к desktop-usage Ну, т.е. из перечисленного "баш, питон, си, и не боишься использовать собственный софт и допиливать чужой под свои задачи. Ядро, в общем-то, пофиг, но в нём есть весьма удобная и полезная функциональность, которой в альтернативных системах не завезли." к "условно-десктопу" относится "удобная и полезная функциональность, которой в альтернативных системах не завезли", а именно criu? Нуууу... ооооууук. А как вы её используете на десктопе и как её должен использовать "обычный пользователь"?
	Ответить | Правка | Наверх | Cообщить модератору

	378. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 10-Янв-24, 09:31
	Обычный пользователь напишет однострочник, который остановит ему программу и потом продолжит. "Обычный" не значит "глупый и ленивый".
	Ответить | Правка | Наверх | Cообщить модератору

	380. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (59), 10-Янв-24, 10:46
	Как говорится, Linux не должен опускаться до уровня домохозяйки. Это домохозяйки должны возвыситься до уровня Linux. Если обычный пользователь увидит, что CRIU не работает с его гуёвой программой, он пойдёт и доделает CRIU?
	Ответить | Правка | Наверх | Cообщить модератору

	388. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 12:54
	> Как говорится, Linux не должен опускаться до уровня домохозяйки. Это домохозяйки должны > возвыситься до уровня Linux. Если обычный пользователь увидит, что CRIU не > работает с его гуёвой программой, он пойдёт и доделает CRIU? Мне все же не понятно, НАХРЕНА пользователю фризить его гуёвую программу? Не важно - работает\не работает, на-хре-на?
	Ответить | Правка | Наверх | Cообщить модератору

	403. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 18:54
	> фризить его гуёвую программу? Не важно - работает\не работает, на-хре-на? Вообще, процесс-странник это очень старая концепция. А эти, вот, заимплементили. Без всяких кульных plan9 в обязаловку и прочего высококонцептуального ненужно. При том вон те это сделали по довольно прагматичным целям даже.
	Ответить | Правка | Наверх | Cообщить модератору

	407. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 19:08
	>> фризить его гуёвую программу? Не важно - работает\не работает, на-хре-на? > Вообще, процесс-странник это очень старая концепция. А эти, вот, заимплементили. Без всяких > кульных plan9 в обязаловку и прочего высококонцептуального ненужно. При том вон > те это сделали по довольно прагматичным целям даже. На-хре-на?
	Ответить | Правка | Наверх | Cообщить модератору

	414. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 20:33
	>>> фризить его гуёвую программу? Не важно - работает\не работает, на-хре-на? >> Вообще, процесс-странник это очень старая концепция. А эти, вот, заимплементили. Без всяких >> кульных plan9 в обязаловку и прочего высококонцептуального ненужно. При том вон >> те это сделали по довольно прагматичным целям даже. > На-хре-на? Я думаю что если захотеть - можно найти довольно прагматичные и продвинутые применения такой технологии. У унылых потребунов, конечно, фантазии не хватит. Правда вон там они в основном не столько GUI сколько "счет на GPU" трансферить на другую систему без потери state хотят, но т.к. это довольно близкая хотелка...
	Ответить | Правка | Наверх | Cообщить модератору

	420. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 21:59
	>>>> фризить его гуёвую программу? Не важно - работает\не работает, на-хре-на? >>> Вообще, процесс-странник это очень старая концепция. А эти, вот, заимплементили. Без всяких >>> кульных plan9 в обязаловку и прочего высококонцептуального ненужно. При том вон >>> те это сделали по довольно прагматичным целям даже. >> На-хре-на? > Я думаю что если захотеть - можно найти довольно прагматичные и продвинутые > применения такой технологии. У унылых потребунов, конечно, фантазии не хватит. > Правда вон там они в основном не столько GUI сколько "счет на > GPU" трансферить на другую систему без потери state хотят, но т.к. > это довольно близкая хотелка... Мы напишем N-комментариев но на вопрос "НАХРЕНА?!!!111" - не ответим. Засчитано.
	Ответить | Правка | Наверх | Cообщить модератору

	455. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 13-Янв-24, 00:38
	> Мы напишем N-комментариев но на вопрос "НАХРЕНА?!!!111" - не ответим. Засчитано. Ну как бы мне эта фича жить не мешает, а коли так можно - я могу и придумать со временем какие-то применения. А юзеры виндов - унылые овощи. Примитивные и неэффективные. Им нихрена не нужно, кроме как хомячить. За что я и отношусь к этой мерзости как к слизню налипшему на ботинок.
	Ответить | Правка | Наверх | Cообщить модератору

	456. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 13-Янв-24, 11:00
	>> Мы напишем N-комментариев но на вопрос "НАХРЕНА?!!!111" - не ответим. Засчитано. > Ну как бы мне эта фича жить не мешает, а коли так > можно - я могу и придумать со временем какие-то применения. А > юзеры виндов - унылые овощи. Примитивные и неэффективные. Им нихрена не > нужно, кроме как хомячить. За что я и отношусь к этой > мерзости как к слизню налипшему на ботинок. Ну, т.е. читать, прежде чем отвечать и понимать логику дискуссии больше, чем на один коммент вверх - "не овощи" так и не научились.
	Ответить | Правка | К родителю #455 | Наверх | Cообщить модератору

	387. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 12:51
	> Обычный пользователь напишет однострочник, который остановит ему программу и потом продолжит. > "Обычный" не значит "глупый и ленивый". Нуууу... удачи продать эту корову за пределами 2% рынка. И тем - разве что "забисплатна".
	Ответить | Правка | К родителю #378 | Наверх | Cообщить модератору

	391. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (129), 10-Янв-24, 13:12
	На самом деле, клинических идиотов среди обычных пользователей не так уж и много, несмотря на то, что пытаются утверждать некоторые олухи в интернете. Ленивых много, это правда, но выдавать психические отклонения за норму не надо. Заскриптовать необходимое поведение готовых инструментов способна даже типичная домохозяйка, это факт. И если необходимость самостоятельно решать определённые задачи возникает регулярно, тут уже есть повод задуматься о выборе более подходящего инструмента (ну или мириться с неэффективностью существующих костылей).
	Ответить | Правка | Наверх | Cообщить модератору

	395. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 14:30
	> На самом деле, клинических идиотов среди обычных пользователей не так уж и > много, несмотря на то, что пытаются утверждать некоторые олухи в интернете. > Ленивых много, это правда, но выдавать психические отклонения за норму не > надо. Заскриптовать необходимое поведение готовых инструментов способна даже типичная > домохозяйка, это факт. И если необходимость самостоятельно решать определённые задачи > возникает регулярно, тут уже есть повод задуматься о выборе более подходящего > инструмента (ну или мириться с неэффективностью существующих костылей). Клинических идиотов не так уж много - примерно как и упоротых фриков, ага. Сильно меньше 2%, думаю :). Реально домохозяйка готова настроить автоплатеж в сбербанк-онлайн ну и примерно все. В энтерпрайзе где тиражных задач овердофига с автоматизацией не то, чтобы "хорошо" - но делается она, поверьте, нифига не башпортянкингом или сильнощелингом - BPMN, RPA вот это всё - platform agnostic обычно.
	Ответить | Правка | Наверх | Cообщить модератору

	404. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 10-Янв-24, 18:57
	Домохозяйка и плату в CAD не нарисует. Отсюда, видимо, вывод что CAD не нужны, а производства - закрыть надо, и CNC - забыть. Правда, всяким, типа вас и прочим домохозяйкам врядли понравится такой откат прогресса.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 19:09
	> Домохозяйка и плату в CAD не нарисует. Отсюда, видимо, вывод что CAD > не нужны, а производства - закрыть надо, и CNC - забыть. > Правда, всяким, типа вас и прочим домохозяйкам врядли понравится такой откат > прогресса. Ну, "домохозяйку" в тред не я притащил - здесь родос, здесь и прыгай. Ну или задавай вопрос автору идеи "каждая домохозяка МОЖЕТ!"
	Ответить | Правка | Наверх | Cообщить модератору

	415. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Янв-24, 20:34
	> Ну, "домохозяйку" в тред не я притащил - здесь родос, здесь и > прыгай. Ну или задавай вопрос автору идеи "каждая домохозяка МОЖЕТ!" Дофига домохозяек пользуется фэйсбуком - и btrfs стало быть.
	Ответить | Правка | Наверх | Cообщить модератору

	421. "Релиз ядра Linux 6.7"	+/–
	Сообщение от User (??), 10-Янв-24, 21:59
	>> Ну, "домохозяйку" в тред не я притащил - здесь родос, здесь и >> прыгай. Ну или задавай вопрос автору идеи "каждая домохозяка МОЖЕТ!" > Дофига домохозяек пользуется фэйсбуком - и btrfs стало быть. А в Киеве - батька! Засчитано-2.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Релиз ядра Linux 6.7"	+/–
	Сообщение от DEF (?), 09-Янв-24, 07:19
	Файловые системы - наше все. А Линукс стал готов для десктопа еще 15 лет назад.
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	304. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (303), 09-Янв-24, 10:02
	Странный у вас десктоп. Вообще Вино 3 вышло к 18 году только.
	Ответить | Правка | Наверх | Cообщить модератору

284. "Релиз ядра Linux 6.7"	+/–
Сообщение от I 1008465039 Shishkin (?), 09-Янв-24, 03:29
Когда reiser5 ждать в ядре?
Ответить | Правка | Наверх | Cообщить модератору

	296. "Релиз ядра Linux 6.7"	–1 +/–
	Сообщение от DEF (?), 09-Янв-24, 07:18
	Никогда. Шишкин не осилил разработку Reiser5 и забросил ее в 2020 году. Шишкин оказался теоретиком-балаболом.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (312), 09-Янв-24, 12:20
	Ты не сравнивай сложность разработки нормальной файловой системы и наколенной студенческой поделки, разваливающейся от каждого чиха. Что btrfs, что bcachefs -- нежизнеспособные монстры, не снискавшие популярности несмотря на все пропагандистские уловки и созданные людьми, не ведающими слова "ответственность". Даже ZFS несмотря на свой неофициальный статус -- и та оказалась популярней.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Релиз ядра Linux 6.7"	+/–
	Сообщение от DEF (?), 09-Янв-24, 15:00
	Btrfs уже более 10 лет в продакшене. Свое глючное дырявое железо замени на нормальное и ничего разваливаться не будет. А что такое нормальная ФС? Та, которая не работает и валяется недопиленная, как Reiser5? Бгг.
	Ответить | Правка | Наверх | Cообщить модератору

	435. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (436), 11-Янв-24, 12:11
	Сервисные утилиты BTRFS ни о чём (не справляются).
	Ответить | Правка | Наверх | Cообщить модератору

	492. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 23-Янв-24, 17:29
	> Сервисные утилиты BTRFS ни о чём (не справляются). Вообще, файлухами пользуются не для того чтобы сервисными утилитыми там ковыряться.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (151), 09-Янв-24, 22:27
	> Ты не сравнивай сложность разработки нормальной файловой системы и > наколенной студенческой поделки, разваливающейся от каждого чиха. Понятно, Шишкин умрет от старости не релизнув нихрена. Академику видимо никто не сказал - но люди не живут вечно... К тому же это moving target. Пока мистер академик будет городить крутой концепт, реалии изменятся. And we're back to square one. > Что btrfs, что bcachefs -- нежизнеспособные монстры, > не снискавшие популярности несмотря на все пропагандистские уловки Если обслуживание миллиарда хомяков мордокниги это не популярность - тогда вы наверное покажете нам более масштабное внедрение более правильных технологий, для сравнения?! > и созданные людьми, не ведающими слова "ответственность". Давно известно что не ошибается тот кто ничего не делает... > Даже ZFS несмотря на свой неофициальный статус -- и та оказалась популярней. C ответственностью там совершенно точно не задалось. Достаточно почитать недавние новости с разрушением данных - и какие факты про ее широко распиареных девов всплыли, на предмет их отношения к релизам. У них там на гитхабе - фейспалм полнейший.
	Ответить | Правка | К родителю #315 | Наверх | Cообщить модератору

287. "Релиз ядра Linux 6.7"	+1 +/–
Сообщение от Сергей (??), 09-Янв-24, 05:24
А кто-нибудь в курсе что там за специфический код для itanium? Я всегда думал, что оптимизацией под конкретную архитектуру используя все её фичи компилятор занимается.
Ответить | Правка | Наверх | Cообщить модератору

	306. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от yet another anonymous (?), 09-Янв-24, 10:24
	Это прерывания/исключения. Это модель памяти (вот вы лезете к аппаратуре по адресу 0xYYYYY; а что и когда увидит аппаратура? там кэши, ...).
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (151), 10-Янв-24, 18:59
	> А кто-нибудь в курсе что там за специфический код для itanium? Все что arch/* например в контексте сабжа. > Я всегда думал, что оптимизацией под конкретную архитектуру используя все её фичи > компилятор занимается. Кроме этого есть и код уникальный для каждой платформы. Вооон там.
	Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

309. "Релиз ядра Linux 6.7"	+/–
Сообщение от Аноним (309), 09-Янв-24, 11:51
Как отключить NVMe over TCP полностью?
Ответить | Правка | Наверх | Cообщить модератору

	329. "Релиз ядра Linux 6.7"	+1 +/–
	Сообщение от pavlinux (ok), 09-Янв-24, 15:58
	CONFIG_NVME_TCP=n CONFIG_NVME_TARGET_TCP=n
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (309), 09-Янв-24, 19:25
	А без пересборки ядра? install nvme_tcp /bin/false blacklist nvme_tcp install nvmet /bin/false blacklist nvmet install nvmet-tcp /bin/false blacklist nvmet-tcp [?]
	Ответить | Правка | Наверх | Cообщить модератору

	497. "Релиз ядра Linux 6.7"	+/–
	Сообщение от edo (ok), 30-Янв-24, 10:34
	А зачем? Без дополнительных движений со стороны userspace оно всё равно само не включится, и даже модуль ядра не загрузится.
	Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

317. "Релиз ядра Linux 6.7"	+/–
Сообщение от Васян Люмпенович (?), 09-Янв-24, 12:44
Поставил вчера на бомжару. Потребление ОЗУ стало 1 Гб, вернулся на 6.6 - там 570 МБ. Разницы в работе ядер не заметил.
Ответить | Правка | Наверх | Cообщить модератору

327. "Релиз ядра Linux 6.7"	+/–
Сообщение от Аноним (327), 09-Янв-24, 15:18
>Добавлена поддержка звуковых интерфейсов ноутбуков HUAWEI, поставляемых с CPU AMD Неужели наконец-то у меня на ноуте заработает звук ?!  Скорее бегу ставить новое ведро.
Ответить | Правка | Наверх | Cообщить модератору

394. "Релиз ядра Linux 6.7"	+/–
Сообщение от Аноним (394), 10-Янв-24, 14:22
Как там с обоями, нескучные завезли?
Ответить | Правка | Наверх | Cообщить модератору

	442. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Аноним (436), 11-Янв-24, 13:51
	Эта новость про ядро. Вам в новости про DE.
	Ответить | Правка | Наверх | Cообщить модератору

401. "Релиз ядра Linux 6.7"	+/–
Сообщение от zog (??), 10-Янв-24, 18:47
> После двух месяцев разработки Линус Торвальдс представил релиз... К чему такая скорострельность? Торвальдс перед смертью не нарелизится?
Ответить | Правка | Наверх | Cообщить модератору

451. Скрыто модератором	+1 +/–
Сообщение от Fullscreen video (?), 12-Янв-24, 10:42
>разрешено использование до 4096 виртуальных CPU. https://xkcd.com/619/
Ответить | Правка | Наверх | Cообщить модератору

467. "Релиз ядра Linux 6.7"	+/–
Сообщение от Ilya Indigo (ok), 14-Янв-24, 22:18
А разве драйвер NVK не должны были добавить?
Ответить | Правка | Наверх | Cообщить модератору

	468. "Релиз ядра Linux 6.7"	+/–
	Сообщение от Ilya Indigo (ok), 14-Янв-24, 22:21
	https://docs.mesa3d.org/drivers/nvk.html > NVK requires at least a Linux 6.6 kernel https://www.gamingonlinux.com/2023/12/check-out-this-great-o.../ > What's to come in 2024 for the NVK driver? Get it bumped up to Vulkan 1.3 support and eventually pass conformance which should happen in the first part of the year. This involves a rewrite of the pipeline code and implementing the VK_EXT_shader_object extension, which should bring the driver out of Beta so that distributions can ship NVK by default. Sounds like everything it needs will be ready in Linux kernel 6.7 and potentially in the Fedora 40 release. Понял, он пока работает через nouveau, и является аналогом RADV для amdgpu, и поддержка прошивок в nouveau ему было необходимо.
	Ответить | Правка | Наверх | Cообщить модератору

494. "Релиз ядра Linux 6.7"	+/–
Сообщение от rcl (ok), 28-Янв-24, 02:21
Orange Pi5 полной поддержки нет. HDMI не работает (https://gitlab.collabora.com/hardware-enablement/rockchip-35...)
Ответить | Правка | Наверх | Cообщить модератору

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

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