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

"Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
Сообщение от opennews (ok), 05-Дек-18, 09:53
Дженс Эксбо (Jens Axboe), мэйнтейнер подсистемы блочных устройств,  подготовил (https://bugzilla.kernel.org/show_bug.cgi?id=201685#c255) патч, решающий проблему с файловой системой ext4 в ядре Linux 4.19, которая может привести (https://www.phoronix.com/scan.php?page=news_item&px=Linux-4....) к повреждению данных. Проблема (https://bugzilla.kernel.org/show_bug.cgi?id=201685) проявляется при сборке ядра с опцией "CONFIG_SCSI_MQ_DEFAULT=y", которая выставляется по умолчанию начиная с версии 4.19. Необходимым условием также является работа без планировщика ввода-вывода (/sys/devices/virtual/block/*/queue/scheduler  содержит значение "none"). Так как источник проблемы не специфичен для ext4 и присутствует в слое разделения очередей для блочных устройств ("blk-mq"), то теоретически проблема могла затрагивать и другие файловые системы, но в силу популярности проявление проблемы пока зафиксировано только для Ext4. URL: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c255 Новость: https://www.opennet.dev/opennews/art.shtml?num=49720
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
Сообщение от Fracta1L (ok), 05-Дек-18, 09:53
Хорошо, что у меня везде mq-deadline выставлен)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–4 +/–
Сообщение от Аноним (2), 05-Дек-18, 09:54
Слава богу мне его Debian testing не прислал и я сижу на 4.18.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от anonymous (??), 05-Дек-18, 10:30
	Что хорошего в использовании ядра с истекшим сроком жизни? Либо 4.19, либо 4.14.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	24. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+13 +/–
	Сообщение от А (??), 05-Дек-18, 11:40
	Действительно, срок годности превышен, надо утилизировать, что бы не отравиться. Потреблять все свежее, что бы здоровье было крепче.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	28. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Анимус (?), 05-Дек-18, 11:45
	На твоём локалхосте всем плевать, что ты там употребляешь. А обновления безпасности для ветки 4.18 больше не поставляются, или 4.14, или 4.19.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (2), 05-Дек-18, 11:54
	Доо, а в бубунту 4.15. А мужики-то не знали, что у них там обновлений безопасности нету))
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	38. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
	Сообщение от Аноним (38), 05-Дек-18, 12:40
	В в бубунту бекпортируют патчи безопасности и как качественно они это делают на их совести ибо тестят это только на бубунту.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	108. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (108), 06-Дек-18, 00:48
	Что ты этим хотел сказать? Что в ядре убунту ошибки? Доказательства есть? А то вон в "свежем" 4.19 у официальных мейнтейнеров ошибка на ошибке.А про убунту только голословности.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	117. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (-), 06-Дек-18, 05:43
	> Что ты этим хотел сказать? Что в ядре убунту ошибки? Доказательства есть? > А то вон в "свежем" 4.19 у официальных мейнтейнеров ошибка на > ошибке.А про убунту только голословности. Если git log почитать, так 4.19 ничем таким не особенный. В ядрах всегда есть баги, разной степени скверности. Если кто думал что можно накодить проект такого масштаба совсем без ошибок - пусть обломается, все это - совершенно точно не про написание кода людьми. Другое дело что в один из багов 4.19 оказался более неприятным чем типовые. Его пофиксили и очень рекомендовали обновиться, соответственно. Нормальный рабочий процесс. При том гарантий что таких же по смыслу, или совершенно других багов в 4.18 нет - никто разумеется не даст. А убунта как таковая делает довольно маргинальный объем работ по ядру. Самое критичное они, конечно, бэкпортнут. Но вообще им тоже надоело воевать с ветряными мельницами и они периодически просто выкатывают даже для древних LTS-ов HWE, или как они там это называют, с свежими ядрами. Там же рядом и свежая графика и проч. Общий софт не трогают чтобы конфиги не ломать - потому и LTS. Но вот именно разработки то там как раз и немного. Полисовка/майнтенанс под декларированные цели больше. Это тоже нужно и полезно - потому что если вы надеялись на работу вон той машины, а там все развалилось по причине обновления на новую несовместимую версию программ и библиотек, это как бы тоже не айс...
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	54. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от 4.4 (?), 05-Дек-18, 15:01
	Везде 4.4 ЧЯДНТ?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	59. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:08
	> Везде 4.4 ЧЯДНТ? Свежее железо не используешь, etc. А так вон там и 2.6.32 предлагают, еще и на ноут.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	98. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от 4.4 (?), 05-Дек-18, 19:09
	Вы в этом чатике всё врете 4.4 поддерживает до 2022 года. А 2.6.32 до 2023. Так что ваш 4.19 нафиг никому не сдался.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	118. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 05:46
	> Вы в этом чатике всё врете 4.4 поддерживает до 2022 года. Однако бэкпортить в него поддержку железа выпущенного новее никто и близко не удумает, только секурити фиксы и прочий маентенанс для УЖЕ РАБОТАЮЩИХ РАНЕЕ систем. Будешь как умная клава использовать только железки существовавшие на момент выхода 4.4 и поддерживаемые им. А если у тебя вон та юсбшная вафля не заведется например - так на момент выпуска 4.4 ее чипсета еще и не существовало, так что 4.4 про него ни ухом ни рылом, соответственно, и оно так BY DESIGN. Но на железе которое работало при выпуске 4.4, оно, конечно, продолжит работать. Даже в 2022 году :)
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	125. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 08:17
	А было бы это микроядро, то постоянно в него что-то бэкпортировать бы не приходилось. Только бы речь шла про файло конкретных дров и другой _отдельный_ от ядра код. Не волнуясь о том, что тебе прилетит подарочков. Прав был старик Таненбаум, однако.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	128. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (128), 06-Дек-18, 08:25
	> А было бы это микроядро, то постоянно в него что-то бэкпортировать бы > не приходилось. Только бы речь шла про файло конкретных дров и > другой _отдельный_ от ядра код. Не волнуясь о том, что тебе > прилетит подарочков. И вместо рака будет грыжа! В виде проприетарной хни вместо драйверов, потому что так можно было. Спасибо, но винды и того миндфака который там с дровами творится мне хватило. Именно поэтому я и пользуюсь Linux - чтобы использовать дрова от вменяемых кодеров, подогнанные под актуальное состояние ядра. При этом ядерщики могут эволюционировать структуру ядра. В отличие от той же винды, где на такое идут только когда совсем прижмет и в результате все-равно получается знатный тарарам, как с видеодровами в висте. А в линухе эти процессы нормальное явление, они случаются плавно и постепенно, при куда большем масштабе изменений. А потом мы вот так посмотрим на результаты бенчмарков - обана, прога в лине компилится втрое быстрее. Потому что в винде только тронь что-то - и все развалится. А убедить дровописак выкатить драйвер под затвиканый вариант той или иной подсистемы - да удачи. > Прав был старик Таненбаум, однако. Так и пользуйтесь его операционкой. Вон как раз в ME вам ее и напихали добровольно-принудительно. Радуйтесь полчаса.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	144. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 10:54
	Объясни, анон, какая связь твоей политически насыщенной речи с микроядром, про которое я писал?
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	157. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним (-), 06-Дек-18, 13:11
	> Объясни, анон, какая связь твоей политически насыщенной речи с микроядром, про которое я писал? Это оценка того во что оно превратится в результате, если ты не понял. Вон твой миникс, на management engine крутится. Забирай, пользуйся. Это оказался единственный вариант как его пользователям впарить.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	175. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 18:03
	Миникс отродясь никому не впаривали. Это свободно доступное дополнение к учебным книжкам Таненбаума. И если это дополнение оказалось столь хорошим, что пригодилось для ME, то мне это говорит за MINIX. И я так и не вижу, в чём связь микроядра и твоей пафосной речи с амвона. Извини, я не прихожанин вашей церкви, копеечку за громкие звуки не подам.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	197. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (197), 07-Дек-18, 18:53
	> Миникс отродясь никому не впаривали. Это свободно доступное дополнение к учебным книжкам Таненбаума. Только до третьей версии. > И если это дополнение оказалось столь хорошим, что пригодилось для > ME, то мне это говорит за MINIX. Уж, спасибо профессору, осчастливил так осчастливил - снаряды поднес тем кто их в мою сторону запускает. Я очень рад. > И я так и не вижу, в чём связь микроядра и твоей пафосной речи с амвона. Это всего лишь дамп результата небольшой симуляции вероятного направления развития процесса. Не вижу как и почему этот процесс случился бы по другому. > Извини, я не прихожанин вашей церкви, копеечку за громкие звуки не подам. Ты можешь меня порадовать и совершенно бесплатно. Жаль что тебе не понравятся варианты.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	199. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 07-Дек-18, 19:44
	>> Миникс отродясь никому не впаривали. Это свободно доступное дополнение к учебным книжкам Таненбаума. > Только до третьей версии. wiki.minix3.org/doku.php?id=www:download:start А это — что? >> И если это дополнение оказалось столь хорошим, что пригодилось для >> ME, то мне это говорит за MINIX. > Уж, спасибо профессору, осчастливил так осчастливил - снаряды поднес тем кто их > в мою сторону запускает. Я очень рад. Такие средства удаленного мониторинга и управления есть у всех производителей энтерпрайзного железа. Это как бы для владельцев серверов предназначено. А проблемой оно становится, главным образом, в случаях взлома или при наличие бекдора и злых умыслов поставщика оборудования. Тебе-то, понятно, с твоей эмбедовкой ничего такого не светит, экономия каждого цента на пересылку с Али. :-)
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	207. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 09-Дек-18, 13:26
	> wiki.minix3.org/doku.php?id=www:download:start Круто, я тоже это нашел. > Такие средства удаленного мониторинга и управления есть у всех производителей энтерпрайзного железа. Нет, такие средства удаленного управления и мониторинга теперь есть в каждом интеловском писюке новее 2010 года. Потому что удаленно управлять и мониторить всю планету - очень уж соблазнительно. И кстати даже в этом вашем миниксе CVE таки нашелся. А круто когда атакующий может вгрузить на сервисный проц, который может dma к системной памяти делать и который изолирован от x86, да? Поэтому код на этой гадости тебя - видит, а ты его на своем x86 - вообще совсем нет. Как бы намекает на фактический уровень привилегий. И как обычно - ключи от двери почему-то не у пользователя а у интеля. Здорово придумано. АМДшникам идея тоже понравилась - и теперь вот вам EPIC в EPYC - такого же толка процессорное ядро, "secure" процессор. Он тоже таки завязан на инициализацию системы, и таки если ты его реально изгальнешься отключить СОВСЕМ - у тебя железо не взлетит толком. Офигенно, чо. > Это как бы для владельцев серверов предназначено. А проблемой оно становится, > главным образом, в случаях взлома или при наличие бекдора и злых > умыслов поставщика оборудования. Нет, проблемой оно стало в 2010, когда это встроили вообще всем и кадому в чипсет. А потом дошло до того что если ты эту фичу выключишь, через 30 минут у тебя вырубится компьютер. Это то что ты получаешь если ME не выполняет код. > Тебе-то, понятно, с твоей эмбедовкой ничего такого не светит, экономия каждого цента > на пересылку с Али. :-) Если мне такое станет надо - я сам сравнимое и заимплеменчу. Забыв предоставить хрен знает кому черный ход. Не так уж и сложно сделать на ARM-ах, кстати. Знаешь чем мы отличаемся? Ты п@нторез а я технологист. Ты растопыриваешь пальцы чужими заслугами. Покуда тобой нагло пользуются. А я смеюсь над этим. Потому что папуса с бусами - это забавно. Забавно вдвойне когда папуас мнит себя системщиком, понятия не имея что ему реально туда напихали.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	209. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 09-Дек-18, 13:51
	>> wiki.minix3.org/doku.php?id=www:download:start > Круто, я тоже это нашел. Нашёл, но всё равно соврал? Молодец, чо. >> Такие средства удаленного мониторинга и управления есть у всех производителей энтерпрайзного железа. > Нет, такие средства удаленного управления и мониторинга теперь есть в каждом интеловском > писюке новее 2010 года. Потому что удаленно управлять и мониторить всю > планету - очень уж соблазнительно. Похоже, ты глуповат даже не слегка. Ты вот даже не понимаешь, _что_ это и _зачем_ — но апломбу на весь опеннет… Просвещайся: en.wikipedia.org/wiki/Out-of-band_management >[оверквотинг удален] > когда атакующий может вгрузить на сервисный проц, который может dma к > системной памяти делать и который изолирован от x86, да? Поэтому код > на этой гадости тебя - видит, а ты его на своем > x86 - вообще совсем нет. Как бы намекает на фактический уровень > привилегий. И как обычно - ключи от двери почему-то не у > пользователя а у интеля. Здорово придумано. > АМДшникам идея тоже понравилась - и теперь вот вам EPIC в EPYC > - такого же толка процессорное ядро, "secure" процессор. Он тоже таки > завязан на инициализацию системы, и таки если ты его реально изгальнешься > отключить СОВСЕМ - у тебя железо не взлетит толком. Офигенно, чо. Ну так ты же и тебе подобные были недовольны отсутствием прогресса — вот вам Интел и сделал прогресс. Тебе вообще приходит в голову, что такие вещи возможны лишь с молчаливого согласия невежественных терпил? И что раньше такого почему-то не было. Ни телеметрии в Windows, ни бэкдоров в инфраструктуре удалённого управления компьютерами, ни «прогрессивных веб-приложений». А нынче каждая сопливая макака мнение имеет визжать про то, что надо срочно отменить Фортран, Кобол и Аду, потому что они-де устарели и умерли. Приложения для бизнеса и космоса макака хочет писать на пихтоне и запускать сиситемдой. >> Это как бы для владельцев серверов предназначено. А проблемой оно становится, >> главным образом, в случаях взлома или при наличие бекдора и злых >> умыслов поставщика оборудования. > Нет, проблемой оно стало в 2010, когда это встроили вообще всем и > кадому в чипсет. А потом дошло до того что если ты > эту фичу выключишь, через 30 минут у тебя вырубится компьютер. Это > то что ты получаешь если ME не выполняет код. Иди почитай Википедию про «возраст согласия». Может какие-то проблески мыслей в твоей голове заискрятся. >> Тебе-то, понятно, с твоей эмбедовкой ничего такого не светит, экономия каждого цента >> на пересылку с Али. :-) > Если мне такое станет надо - я сам сравнимое и заимплеменчу. Забыв > предоставить хрен знает кому черный ход. Не так уж и сложно > сделать на ARM-ах, кстати. > Знаешь чем мы отличаемся? Ты п@нторез а я технологист. Ты растопыриваешь пальцы > чужими заслугами. Покуда тобой нагло пользуются. А я смеюсь над этим. > Потому что папуса с бусами - это забавно. Забавно вдвойне когда > папуас мнит себя системщиком, понятия не имея что ему реально туда > напихали. Хорошо, технологист, хорошо. Верь. Это самое главное.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	217. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 11-Дек-18, 19:46
	> Нашёл, но всё равно соврал? Молодец, чо. Это уже интересно. Меня даже в чем-то обвиняют. Нельзя ли пруфца, вот прям 1 к 1, написано то-то, а этот кондом сказал то-то - врет и не краснеет, дескать? > Похоже, ты глуповат даже не слегка. Ты вот даже не понимаешь, _что_ это > и _зачем_ — но апломбу на весь опеннет… Просвещайся: en.wikipedia.org/wiki/Out-of-band_management Да нет, мистер, это ты глуповат и не понимаешь кой-чего. Даже не в технике а в людских взаимодействиях. Так что под удобным предлогом всякие шустрые веники на раз выносят "три кинокамеры отечественные". У Supermicro всплывает "забытый" инженерный логин, интель всего лишь торгует бизнесу фичу, коли уж она есть. Все эти vPro/AMT и ко - всего то расширенный набор модулей на все тот же Management Engine. Однако сам проц, система и куча кода - есть в вообще каждом первом компе на интеле. Сорцов этого нет, стартует оно вообще независимо от x86 и достаточно маложручее для того чтобы питаться от дежурки. Что и позволяет ему включать комп и проч. Заодно оно же на некоторых мамках вентилятором рулит и проч (PWM донавесить процику как периферия - дело не хитрое). Так что даже у древних компов при потугах деактивации ME отпадает как минимум управление вентилем проца. А у более новых - они вообще выключаются, если система за 30 минут не взлетит. > Ну так ты же и тебе подобные были недовольны отсутствием прогресса — вот вам > Интел и сделал прогресс. Что-то я не понял в чем это прогресс. В троянизации, бэкдорах и шпионаже? Не помню чтобы я сильно фанател по этим направлениям. Хотя жизнь заставила изучить основы. Чтобы эффективно защищаться, надо мыслить как атакующий. Иначе толку от защит будет фиг. > Тебе вообще приходит в голову, что такие вещи возможны лишь с молчаливого > согласия невежественных тepпил? А я - не они :). И соответственно если кто думал что сможет меня нахлобучивать и я буду это глотать - ща. ARM-ы я могу не хуже x86 использовать уже. И таки на ряде камней у меня может быть убер-доступ. С _моим_ кодом в trust zone, _моим_ загрузчиком. И _я_ его даже могу локнуть ридонли или подписать ключом. Моим. И вот тогда его станет сложно снести хакерам уже. И ключи я забуду дать. Проблема не в двери - а в том у кого ключи. Поэтому я учусь делать так, чтобы ключи были у меня. И дверь защищала меня от редисок, а не охрану от меня. > И что раньше такого почему-то не было. Ни телеметрии в Windows, Гнилая дорожка началась с икспы еще аж. А так то да, когда '95 только делали и прочие НТ - там операционку б допинать, на кейлогера ресурсов уже не хватает. А потом MS цать лет к ряду барыжил одним и тем же, меняя обоину. Вот при этом ресурсы на кодинг кейлогера появляются. И чего я сделаю по этому поводу? Я и сделал что придумал - проголосовал ногами свинтив на Linux. И стараюсь развивать семейства технологий где MS-а нет. Ну коли уж скурвилась компания, так скурвилась. Мне это слабо отменить, но я могу обойтись без них и их продукции - так что меня они натягивать не смогут. > визжать про то, что надо срочно отменить Фортран, Кобол и Аду, > потому что они-де устарели и умерли. Визжать можно. А отменить не получится. И с чего ада устарела то? Вроде ж до сих пор в ракетах применяют. > Приложения для бизнеса и космоса макака хочет писать на пихтоне и запускать сиситемдой. Как по мне - может писать на чем угодно. С одним условием. Первым живым тестировщиком станет автор. Говоря за себя - я всегда делаю мое добро, как будто оно будет моим автопилотом. Это честно по отношению к клиентам. И таки системд по сравнению с sysv init позволяет делать надежнее. Он по крайней мере на таймауты и коды возврата не кладет, в отличие от sysv скриптов. Которые если виснут - то на веки вечные. Таймауты в sysv скриптах - невероятная экзотика. Пожелаю любителям sysv бортовой компьютер себе так накодить. И потом наверное болтаться на высокой орбите следующие несколько миллионов лет - в назидание остальным. > в твоей голове заискрятся. Это ты так намекаешь что можно раздвинуть булки и получить удовольствие? Фигвам, с точки зрения дел системных я соглашусь на такое не раньше чем меня положат в гроб. Хотя, у некоторых мозг наполовину умирает и до биологической смерти остального. В тяжелых случаях даже приходится в специальные учреждения помещать - в хучшем случае человек может недееспособен. > Хорошо, технологист, хорошо. Верь. Это самое главное. Я не верю на честное слово. Я в отличие от папусаов стараюсь разобраться что и как работает, за кого меня держат, и сделать так чтобы вся схема работала на меня, а не против меня. В принципе я могу неплохо нейтрализовать даже ME. На самом деле я думаю что я сделал очень забавную инфраструктурку, на которой факапнутся и запалятся очень многие попытки делать что-то подобное. А я к тому же окажусь парой уровней выше и смогу потыкаться монитором. И со своей стороны я буду считать системщиком тех кто может как-то так же, а не тех кто загибает пальцы с п-нтом под з-нтом, раздвигая булки под management engine и чего там еще.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	218. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 11-Дек-18, 19:56
	Да иди ты на линукс, 294-й (или какой у тебя там номер). Я не читаю твои бессмысленные простыни, поскольку ты пустобрёх.
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	200. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (-), 07-Дек-18, 20:45
	> Уж, спасибо профессору, осчастливил так осчастливил - снаряды поднес тем кто их в мою сторону запускает. Я очень рад. Он - груз целлюлозы и азотной кислоты, из которых вместо бумаги и удобрений сделали начинку для снарядов, ты лично - деньги пушку и весь техпроцесс производства снарядов, запускаемых не только в тебя. Но виноват конечно профессор.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	208. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (-), 09-Дек-18, 13:28
	> Но виноват конечно профессор. Профессор создал для этого условия. Сделав так что из его фиговины ничего кроме снарядов для пушки толком не получается. Minix как операционка общего назначения даром никому не вперся, а вот для мутных проприетарных делишек в стиле management engine - ничего так, вариант. Там не надо сотни дров и проч. Достаточно чтобы полторы железки в ME окучивало, сам с собой интель о наборе периферии как-нибудь договорится.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	138. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от пох (?), 06-Дек-18, 10:35
	> А было бы это микроядро stable api is nonsense прекрасно достижимо и с микроядром. > Только бы речь шла про файло конкретных дров тоже совместимых с конкретным микро-ведром и его api. К тому же я вообще не вижу разницы, что именно мне патчить - модуль обычного ядра или чудо-userspace-модуль ядра-микро, пока патч локален, как в данном случае (впрочем, в данном случае правильнее выключить недотестированный функционал ведра вообще, там еще будут race conditions, судя по коду из костылей и подпорок).
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	143. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 10:52
	> stable api is nonsense прекрасно достижимо и с микроядром. Эти-то могут. >> Только бы речь шла про файло конкретных дров > тоже совместимых с конкретным микро-ведром и его api. Да какое там API… Пинать по таймеру, не сдохло ли ещё там снаружи, где драйвер должен жить, да принудительно оживлять через сервер перезапуска, например. И посылать админу алярмы на почту и мобилу, чтобы принял меры. Одарённые, кстати, что-то похожее пытаются сделать системдой. Вот ведь извращение уже запредельное… > К тому же я вообще не вижу разницы, что именно мне патчить > - модуль обычного ядра или чудо-userspace-модуль ядра-микро, пока патч локален, как > в данном случае (впрочем, в данном случае правильнее выключить недотестированный функционал > ведра вообще, там еще будут race conditions, судя по коду из > костылей и подпорок). Разница в том, что поломка в монолитном большом ведре заканчивается кернелпаником, а в системе на микроядре, если та правильно спроектирована, это заканчивается только локальной поломкой, не обрушивающей всю систему. В теории, во всяком случае.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	146. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 11:02
	> В теории, во всяком случае. в очень теоретической теории, и на теоретической аппаратуре. А на практике у тебя "поломка" в драйвере блочных очередей, и хотя драйвер сетевухи еще прекрасно работает, но серверу от этого ни разу не легче, он ни записать, ни прочитать с диска ничего не может. А если в драйвере физического устройства - то еще и устройство стоит рачком-с, и не факт что выводимо из этого состояния штатным способом, кроме сигнала reset по шине.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	161. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 13:21
	> кроме сигнала reset по шине. Осталось найти сигнал reset в современных скоростных сериальных шинах. Хотя некий аналог конечно бывает, но этот аналог - именно некий. И весьма приблизительный. Пример: если мой МК питается от батарейки или внешнего питания, и коммуницирует по usb - хост ему именно reset уровня чипа, реально ребутающий именно фирмвару - ну вообще совсем никак не вкатит. При всем желании. Если от хоста питается - можно попробовать радикально питание снять (линух умеет как last resort, если хост/хаб это позволяет). А ресет usb софтварная штука. Ну то-есть фимрварь его заметит конечно. Но только если живая. А если фирварь не живая или решит проигнорировать это - да фиг оспоришь. С pci-e и прочими sata это тоже до некоторой степени аналогично.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	164. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 14:46
	все так и есть - по сути имеем подвисший ящик, который даже hw reset не может иногда оживить, только перезагрузка отключением питания. поэтому польза от микроядер в писюковой архитектуре сильно-сильно преувеличена. собственно, если посмотреть на работающие реализации, а не на мертворожденные проекты, то везде и всюду увидишь что микроядро может и есть, но параллельно ему работает полноценное ядро какой-нибудь bsd или линукса, естественно, с прямым доступом и к железу, и к памяти всего хоста, ограниченным только от честных людей.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	169. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от 4.4 (?), 06-Дек-18, 15:23
	Так и пиши что гибридный подход самый правильный.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	189. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (-), 07-Дек-18, 09:38
	> hw reset не может иногда оживить, только перезагрузка отключением питания. Понятие HW reset в многопроцессорной системе без сигнала reset заведенного на ВСЕ процессоры штука весьма номинальная. Хотя обычно reset все же срабатывает, более или менее. Тем не менее, если например у SATA винча вклинит фирмварь, жать ресет конечно можно но вот реагировать на это винч не очень то и обязан, потому что интерфейс из фирмвари рюхается. Да и с IDE большой вопрос куда там что заведено и что по факту вызывает. Кэп намекает что приехавший в произвольный момент RESET в адрес винча и тем более SSD может наделать дел, вплоть до убиения девайса наповал. Мало ли что там фирмвара делала, а тут ее, значит, неконтролируемо вышибать? Может оно служебные структуры апдейтило, а тут ресет. > поэтому польза от микроядер в писюковой архитектуре сильно-сильно преувеличена. Именно. Кроме всего прочего - чтобы линевое ядро жестко встряло именно в самом себе... ну не знаю, это какая-то дикая экзотика. Я такого вообще не припоминаю. Вот отвесить call в недра биосо-уефанского добра и там повиснуть - это пожалста. Биосоуефанство и само прекрасно виснет, на половине компов вообще достаточно клаву невовремя потелепать после заставки bios/uefi до бутлоадера - и оно встает колом. А поскольку такой же код там везде, потуги юзать сервисы фирмвары - весьма чреваты. > параллельно ему работает полноценное ядро какой-нибудь bsd или линукса, естественно, с > прямым доступом и к железу, и к памяти всего хоста, ограниченным > только от честных людей. Реально взлетели как максимум гибриды, где адресное пространство дров один фиг на всю толпу общее. Пролезать через уровни изоляции все же довольно тормозно и никому не надо графику с в разы более низким FPSом при маргинальном выигрыше в стабильности. От GPU lockup например никакое микроядро не спасет. И если тот после "ресета" вдруг не удумает выйти на режим - что микроядро что монолит останутся без графики на экране совершенно одинаково.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	168. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от 4.4 (?), 06-Дек-18, 15:20
	Просвятите откуда вы берете столько нового железа что оно не работает на 4.4?
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	176. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 18:08
	> Просвятите откуда вы берете столько нового железа что оно не работает на > 4.4? В магазине «Всё для игромана» в отделе новинок. ;-)
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	190. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 07-Дек-18, 09:40
	> В магазине «Всё для игромана» в отделе новинок. ;-) Да можно и просто какой-нибудь вайфай свисток купить, или там что еще. Выпустят новый чипсет - о опачки. Производитель его впаяет без спроса и предупреждения. Половина даже название не сменят, только напишут мелко v7, наверное чтобы сертификацию заново не проходить. А реально в корпусе совсем другая железка уже.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	191. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 07-Дек-18, 09:57
	Если вы железо выбираете для себя и под какое-то ответственное применение, то всё равно же читаете надписи мелкими буквами про v7. И ставите на него, полагаю, не самый свежий прогрессивный ролинг-релиз Арчбунты, а что-нибудь более LTS-ное.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	198. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (197), 07-Дек-18, 18:58
	> него, полагаю, не самый свежий прогрессивный ролинг-релиз Арчбунты, а что-нибудь более > LTS-ное. Если LTSное - то или убунта LTS или дебиан stable. ЧСХ в обоих можно свежее ядро вкатить, наверное вот поэтому. Потому что мелкие буковки читать задалбывает. И в магазин менять свисток идти всем не охота. Что делают всякие юзеры древних рхелов я не в курсе, по моему мнению это вообще как десктоп не котируется.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

3. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
Сообщение от plan8 (?), 05-Дек-18, 09:54
При более внимательном взгляду на обсуждения бага 201685 видно, что эта проблема проявилась и у пользователей ZFS.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:01
	ZFS не часть ядра - поэтому врядли линуксных ядерщиков колышет что в нем. А вот ext4...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	61. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от plan8 (?), 05-Дек-18, 15:12
	С btrfs аналогично: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c211
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	82. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от OldFart (?), 05-Дек-18, 16:45
	После того как красная шапка отказалась продолжать супортить БТРФС, у кого то еще есть надежда что взлетит ?
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	90. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+2 +/–
	Сообщение от Аноним (90), 05-Дек-18, 18:13
	> еще есть надежда что взлетит ? У шапки вообще дельных спецов по файлухам толком не осталось. Так что их благосклонность к той или иной ФС просто похрен. И их потуги сделать что-то в духе btrfs/zfs путем написания обвязки на пихтонрасте к xfs+lvm  - да это прикола кусок. А btrfs ща обслуживает миллиарды хомяков у фэйсбука. Так что он взлетел, протестирован довольно злобно, отловили даже весьма довольно странные случаи когда на 20-м терабайте файла что-то может пойти не так. У большинства людей таких файлов то нет, но у фэйсбука много разной странной фигни и достаточно ресурсов чтобы тестировать самые странные вещи.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	99. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (99), 05-Дек-18, 19:41
	> У большинства людей таких файлов то нет, но у фэйсбука много разной странной фигни Именно. Фейсбук тестирует то, что нужно ему, а не большинству людей. Для большинства людей потеря домашнего пор^Wфотоархива является проблемой, а у фейсбука все задублировано настолько, что падения файловой системы отдельной машины никто особо и не заметит. Просто возьмут новый диск из очередной поставки и заменят им старый.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	119. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 05:54
	> Именно. Фейсбук тестирует то, что нужно ему, а не большинству людей. И гугл. И редхат. И все остальные, в общем то. Откуда мораль: чем больше народа наваливается на то или иное - тем лучше по багам. А точнее их отсутствию. > Для большинства людей потеря домашнего пор^Wфотоархива является проблемой, а у фейсбука > все задублировано настолько, что падения файловой системы отдельной машины никто особо и не заметит. Однако даунтаймы и переходные процессы - нежелательны и для фэйсбука... > Просто возьмут новый диск из очередной поставки и > заменят им старый. С другой стороны, обычная файлуха при например осыпающемся винче выдающем на гора труху - может довольно долго вообще не издавать ни звука. А когда дестрой наконец доберется и до метаданных, в объеме когда ФС это замечает - одному Ктулху известно что там с данными уже в этот момент. Ну и так простой пример: btrfs налетев на BAD в метаданных на ноутбучном диске отругался на чексум еррор и просто достал метаданные с второй копии. Потому что по умолчанию он кладет на однодисковых конфигах метаданные дважды. А будь там ext4 какой - во там дестроища то было бы, когда блок метаданных вообще совсем не прочелся, недоступен, консистетность потеряна, и за дальнейшее никто вообще совсем не отвечает... а RAID это прекрасно, но куда ж его в ноуте упаковать? Вот btrfs с своей гибкостью аллокации для метаданных эрзац-RAID1 из 1 диска делает. А обычные ФС так конечно же не умеют. Особенно чтоб только для метаданных. Потому что зеркалить винч целиком сам на себя все же не очень полезно - он может и целиком загнуться и тогда с зеркала толку мало. Зеркало только метаданных - это такой очень разумный баланс, минимизирующий тормоза и повышающий надежность самых критичных областей файлухи, сбой в которых чреват очень большими разрушениями. Как бы бэд под файлом - портит только файл. Бэд под метаданными - может половину ФС развалить.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	136. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 10:09
	>> все задублировано настолько, что падения файловой системы отдельной машины никто особо и не >> заметит. > Однако даунтаймы и переходные процессы - нежелательны и для фэйсбука... если они окажутся трейдоффом с производительностью - пейсбук просто померяет, сколько нод ему потребуется добавить для относительно незаметной пользователю потери, а сколько - ради работы с менее эффективной fs, а если с ценой обслуживания грамотными специалистами - то сколько можно заменить макаками и сколько на сэкономленные зарплаты можно установить картонных серверов (или из чего они там у пейсбука, картонные были у гугля) А вот редгада не поймут-с, если он данные клиентов превратит в тыкву, им индуса стимулировать придется. > С другой стороны, обычная файлуха при например осыпающемся винче выдающем на гора труху это можно долго не замечать только в сервере в шкафу со швабрами, все равно не нужен - на своей любимой домашней машине с котиками ты заметишь раньше, чем сработает оповещалка smart. Правда, со времен "щелкающих" дятлов я подобных дисков не видал - сейчас, обычно, чпок - и все твои данные превращаются в тыкву без объявления войны и долгих предисловий, а признаком беды является медленная запись или чтение, когда рано или поздно прочитывается. > Бэд под метаданными - может половину ФС развалить. да нет, с чего это. Ключевые метаданные так или иначе дублируются в любой fs, начиная с ms fat (как, по-твоему, вообще работает fsck на тех fs где ее осилили написать?). Либо файл испортит, либо каталог, а файлы найдешь потом в lost+found. Правда, современные (в смысле, после ext2) fs и дисковые драйверы еще и очень неадекватно работают (совсем я бы сказал не работают) с нечитаемыми секторами, который на современном винте получить - достаточно выключить питание в момент записи.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	150. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 12:00
	> сэкономленные зарплаты можно установить картонных серверов (или из чего они там > у пейсбука, картонные были у гугля) Для них зарплата нескольких файлушников - сущая фигня на фоне толпы админов, скриптомакак и прочего сброда. И если скриптомакак можно в случае чего новых нанять из очереди за забором, то вот с парнями занимающимися ФС и блочным уровнем это не работает. Достаточно посмотреть на пируэты RH с XFS-ом. Видимо там очереди за забором не нашлось и редхат выкручивается как умеет, пытаясь сделать какое-то подобие прямо из скриптомакак. Идея прикольная, конечно, но, ух, некоторым менеджерам видимо не сказали что идеальная взаимозаменимость сотрудников - это все же немного миф и желаемое состояние дел, а не действительное. > А вот редгада не поймут-с, если он данные клиентов превратит в тыкву, > им индуса стимулировать придется. Ну так к особо крупным клиентам - может и первым самолетом кто-нибудь относительно вменяемый прилететь. Он таки сможет и в хексэдиторе посмотреть, по месту, и худо-бедно допинает до кондиции. Но на всех такого сервиса явно не хватит. Поэтому им будут наслаждаться только те в состоянии отвалить чемодан баксов. Остальные отфильтруются и пойдут в пень. А нагрузка на саппорт придет в норму как раз. Заодно и совсем отказаться от шляпного саппорта будет чревато. Для крупняка. А мелочь и их проблемы редхат мало интересуют, если кто не заметил. Это еще старина Ульрих прямым текстом глаголил :) > все равно не нужен - на своей любимой домашней машине с > котиками ты заметишь раньше, чем сработает оповещалка smart. Да щас. Вон там юзери с глючным железом заметили что с нтфс что-то не то. К моменту когда они это заметили - половина файлов уже в состоянии трухи. Битые блоки в середине картинок, так что вот вам фото до пояса - а дальше decode error, сбойный блок. И кучка зипушников с CRC error. И сетапы которые не запускаются, падают или вопят про corrupt installer. Ну вот заметили. И обтекли. Потому что бывает поздняк метаться. При таком уровне дестроя пролюблено довольно много данных. С чексумами они бы это заметили гораааааздо раньше. Соьссно было бы достаточно запустить изредка тест на зипарях - он все скажет. Но это ж надо явно заморочиться. А тут и матюки в логах сами, про scrub слышали все кто минимально интересовался темой, и это все ж стандартная процедура, а не ее эрзац из самоличного теста зипов по всему диску. > Правда, со времен "щелкающих" дятлов я подобных дисков не видал - сейчас, > обычно, чпок - и все твои данные превращаются в тыкву без > объявления войны и долгих предисловий, Зато я видел предостаточно такого. В многих случаях винч начинает плавно осыпаться. А бывают глюки железа, ну там SATA кабель поганый например. Да что там, даже если по винчу #$%нули или уронили, он чаще всего скопытится не сразу. Пыль от head slap по гермозоне разлетаться, конечно, начнет, данные будут рушиться, если долетит до служебки и накроет все копии - "ойпи...ц". Потому что после этого винч даже стартануть не сможет, с точки зрения юзеря будет полным трупиком. Но ДО этого момента можно успеть вынуть многое, если руки и голова на правильных местах. Профи могут потрепыхаться и опосля, забутявив хард с внешнего интерфейса, если тот не может модули с блинов читануть. > а признаком беды является медленная запись или чтение, когда рано или поздно прочитывается. Smart к этому моменту скорее всего будет содержать уже полдюжины индикаторов проблем. Даже у дубовых и глючных фирмварин. И если уж кого признаки интересовали - в smart они обычно виднее. Хотя замер времени чтения вполне себе известный метод оценки общего состояния пациента. Есть специализированные проги которые это делают более-менее правильно. > да нет, с чего это. А с того что очень зависит что именно там грохнется и как на это среагирует код ФС. Это нестандартная ситуация и в целом там может быть все что угодно. Кормить софт нестандартными ситуациями - на редкость дерьмовая идея, если интересовал результат. Кроме случая когда ты тестированием занят и запустил AFL и прочие Syzkaller'ы конечно, так что тебе за дестрой еще и зарплату платят. А вот на своих данных что-то такое сделать - офигенный способ их резко и больно пролюбить, в случае если упомянутые именно вот так почему-то еще не попробовали. > Ключевые метаданные так или иначе дублируются в любой fs, начиная с ms fat (как, > по-твоему, вообще работает fsck на тех fs где ее осилили написать?). Угу. И работает это зачастую так: вот тебе 75% от второй таблицы FAT, и более - нифига, даже партишна нетути. Потому что FAT по eraseblock-ам неудачно попал. По законам мерфи, потерли eraseblock, а записать взад не успели, питание чих-пых как раз. И отлетел весь первый FAT с партишном, и кус второго. На фабричной ФС такого пытались избежать, но умная клава отформатила флеху. И теперь неаккуратное выдергивание без размонтирования - это вот так. Спасибо если так. Потому что может и транслятор у контроллера развалиться - и тогда ты получишь своих котяток причудливо нарезанной зеброй. И хрен сам что сделаешь. Да и про могут многое но - не волшебники, и если транслятор совсем уж пролюбился - собрать из котлеты корову можно лишь какой-нибудь угадайкой, для пары самых нужных файлов. > Либо файл испортит, либо каталог, а файлы найдешь потом в lost+found. Угу, при том если порушится какое-нибудь описание размещения файла, по законам мерфи, самого ценного и нужного, конечно же (его поди часто телепают, если это БД какая, так что там много метаданных, их часто трогают, так что отклонения от идеала как раз где-то там и случатся) - искать его придется по всей площади диска. Без полноценной инфо о размещении файла. Очень увлекательно. И хранить вообще всего по, допустим, два - ну как бы можно но усложняет и замедляет ФС и так делают не все, не всегда и не везде. И как там Мерфи сложится в вот конкретно этом бэде вот конкретно здесь - проверять на своих данных не рекомендуется, если они нужны. Ну да, может быть дестрой будет и небольшой. А может и большой. Это будет очень экспериментальный запрыг на грабли с крайне негарантированным результатом. А если там реально всего по два так что ФС тупо вынула копию блока из другой локации - вот тут метаданные не пострадали, как там будет крючиться в глюках парсер - мы таки к счастью не узнаем. И это таки очень полезно для сохранности данных. > Правда, современные (в смысле, после ext2) fs и дисковые драйверы еще и > очень неадекватно работают (совсем я бы сказал не работают) с нечитаемыми секторами, Да как сказать? Если например инфо о размещении файла утрачено - как адекватная работа с файлом вообще может выглядеть, интересно? Ну если метаданные дублированы - логично попытаться починить проблемную копию из второй. Винч при записи ремапнет проблемный сектор (или не ремапнет, если тот запишется и прочтется) и дело с концом. Самое умное - выпасть в ридонли да констатировать факап, чтобы сильнее все не испортить. Собственно большинство ФС что-то такое и предпочитают - и это очень хорошая и умная реакция на проблему. Ну и ядро обычно делает несколько попыток читануть сектор. Если тот за несколько попыток не того - вот честно, лучше оставить его в покое. Потому что если долбить проблемную область попытками чтения - есть шансы что механика или кто там сбоил - окончательно склеит ласты и тогда данные вынуть напрягутся даже эксперты по восстановлению. Поэтому если за несколько попыток не проканало - это лучше вытаскивать уже вообще совсем другим софтом. Специализированным. Реализующим весьма специфичные паттерны доступа, нацеленные на постепенную реконструкцию образа. Пхать ЭТО в логику обычного ФС-а ни к чему - это для махровых датареков, когда все уже плохо, рядовой юзерь с этим уже не справится и даже не оценит проблему адекватно. А потом пролюбит вообще все, резко и больно, и вот тогда это даже про уже не вынут. > который на современном винте получить - достаточно выключить питание в момент записи. Ну да, странная хня иногда случается. Многие типа-сбойные (UNC) сектора после перезаписи - вполне исправные оказываются. Особенно актуально для глючных питальников. Но вообще это чревато именно резкой кончиной девайса. Там еще и сервометки, видите ли, и если при глюках винч их вынесет - он потом вообще не будет знать где у него что. И вот просишь ты сектор - а тебе в ответ бабах - IDNF. Нет такой буквы в этом слове. Хотя запрошенное и было в верном диапазоне. А случае с флешовыми штуками все хуже - они крупноблочные и апдейт любых структур, что ФС, что внутренней трансляции подразумевает RMW больших блоков. При этом они неизбежно висят в RAM накопителя на момент патчинга и если питание пролюбится... в лучшем случе механика сделает cow-like фокус и откатится на вариант до начала этого маневра. А в хучшем будет очень чудесатый трупик, отдающий очень чудесатые данные. Или ничего не отдающий - фирмварь может и не взлететь без критичных таблиц.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	165. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 15:01
	> то вот с парнями занимающимися ФС и блочным уровнем это не работает. именно по этой причине их лишней работой и не перегружают - для мордокниги нужна производительность, ее и пилите. А надежность - вон, у оракла много лишних денег, правда, он их никому не дает, потому и много... > Ну так к особо крупным клиентам - может и первым самолетом кто-нибудь относительно вменяемый > прилететь. ну прилетит, а дальше-то что? Если разведет руками и скажет "ой, оно тут уже не чинится" - так я тоже умею. > Smart к этому моменту скорее всего будет содержать уже полдюжины индикаторов проблем. читайте гуглодоки, они рулез. Вообще не нашлось корреляции между состоянием смартовых индикаторов и вероятностью внезапного отказа на большой выборке, увы. Может с тех пор смарт и стал получше, но вряд ли что глобально изменилось. > Если тот за несколько попыток не того - вот честно, лучше оставить его в покое. а вот этого они как раз и не умеют. Поэтому вместо одного ненужного файла в tmp - получаем убитый диск. А бегать при любом мелком сбое за специализированным софтом и хардом мало кто может себе позволить. (да и толку, если это экзотическая система, а не fat) В каком-нибудь 2004м в подобных случаях я переключал диск в pio (чтобы нормально работали таймауты, а не dma reset по всей роже), искал в логе сбойный блок, оно там обычно было, и добавлял его в badlist - те fs так умели. Хрен с ним, с тем файлом, он уже мертвенький - зато остальной сервер я не буду переустанавливать, а просто склонирую. Попробуйте повторить этот фокус с lvm, xfs или чем там модно? Даже если в файл попало, а не в чортов журнал. > Ну да, странная хня иногда случается. ничего странного - ibm запатентовала sector marks, [пере]записываемые вместе с данными, еще в 97м году. Нет метки - нет сектора, вообще нет его такого.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	193. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (193), 07-Дек-18, 15:29
	> именно по этой причине их лишней работой и не перегружают - для > мордокниги нужна производительность, ее и пилите. Для мордокниги надо все и сразу. Надежность снижает затраты на обслуживание. А производительность еще никому не мешала. > А надежность - вон, у оракла много лишних денег, правда, он их никому не дает, потому и много... Оракл не есть активные разработчики линукса. Судя по всему для линуксных разработчиков это за проклятое место считается. Репутация у фирмы в опенсорсной среде - не ахти. > ну прилетит, а дальше-то что? Если разведет руками и скажет "ой, оно > тут уже не чинится" - так я тоже умею. Ну может он и соберет что-то и закатит солнце вручную. А может и не соберет. Откуда я знаю что редхат планирует делать? Это их бредовые идеи, кто на них купится тот и будет в саппорте редхата узнавать как они себе это представляют. > и вероятностью внезапного отказа на большой выборке, увы. На самом деле некая корреляция все же есть. Но специфичная по семействам винчей, фирмвари глючны в этом аспекте, поэтому в "формальных" попугаях зачастую как-то так: все збс, почти збс, ой, я "неожиданно" убился об стену! Ну вот как-то очень нелинейно smart обваливается, не знаю зачем так сделано. Однако если смотреть RAW значения, зная повадки семейства можно прикинуть более реальное состояние дел. Но вот в автоматический мониторинг такое знание - сложно, да. И статстику набрать сложно. Там что-то типа AI надо, знающего заскоки семейств технологий. Кроме того чтобы объективно узреть состояние поверхности, надо тест гонять. Это производительность просадит. Поэтому так делают не все и не всегда. А фирмвара соответственно сама по себе статистику может и не набрать адекватно. Потом при чтении со всей поверхности опа - а там ошибок оказывается уже. И тут read error rate фигась резко вверх! Особенно если повторять попытки чтения сбойных секторов. > Может с тех пор смарт и стал получше, но вряд ли что глобально изменилось. Он всегда вел себя очень специфично - и это не изменилось. И все же зная на то смотреть, можно не так уж плохо прикинуть чего от пациента ждать. Если он намерен скончаться на операционном столе, это к счастью зачастую заметно. >> Если тот за несколько попыток не того - вот честно, лучше оставить его в покое. > а вот этого они как раз и не умеют. Неправда ваша, кернель как раз таки сделает 2-3 попытки прочесть, не прокатило - оставляет в покое, возвращает наверх read error и даже кеширует походу, так что повторные попытки мигом вызывают отлуп с read error совсем без насилия над девайсом вроде. И тут тоже обоюдоострая штука. С 10-й попытки сектор мог бы и прочитаться. На этом эффекте читалки строящие образа правильно и работают. Сперва грубо вычитывают без залаза в сбойные области, а потом все и более настырно читают. В идеале могут вынуть вообще все - и тогда потерь данных нет. Хотя будучи диском компа где это просто смонтировано - выглядело ужасно. > Поэтому вместо одного ненужного файла в tmp - получаем убитый диск. Если диск собирался скопытиться - то уж собирался. Ну подложил бы он тебе свинью чуть позже, тебе сильно полегчало бы? Ты бы ошибочно думал еще пару месяцев что все ок. Сомнительная радость. > А бегать при любом мелком сбое за специализированным софтом и хардом мало кто может > себе позволить. Если винч совсем сдох от хоть какой активности софта снаружи в пределах спеков ATA - мяч на стороне винча, как ни крути. Ему можно помочь сдохнуть немного раньше, но с точки зрения использования это ничего особо не даст, кроме некоторого времени пребывания в ложной уверенности что все ок. Это важно в основном при восстановлении данных - чтобы пациент если и скопытился, то после того как бэкапный образ хотя-бы приблизительно построен. Иначе датарек получит фигу вместо денег, просадив кучу времени, плюс недовольный клиент. И таки при проблемах чтения стандартная логика ФС и кернела не расчитана на продвинутый рекавери с полудохлого носителя с минимизацией урона. Это специальная отдельная область, под это специально пишут программы для DR-ов. А в обычной логике ОС это явный перебор. > (да и толку, если это экзотическая система, а не fat) Ну я народу чаще всего EXTы выколупывал... хотя немного и FAT, конечно. И даже слегка нтфс-ы. > В каком-нибудь 2004м в подобных случаях я переключал диск в pio (чтобы > нормально работали таймауты, а не dma reset по всей роже), Read dma multiple - хуже чем чтение единичных секторов. Но не сильно роялит. С правильным софтом один черт при начальном чтении скипается большой кус после налета на проблему, чтобы быстро выйти из порушеной области. А в следующих заходах можно и более активно долбить проблемные области, чем позднее итерация, тем агрессивнее. В удачном случае так даже может получиться lossless. Потому что с цатой попытки нестабильный сектор может взять и прочитаться. А может и винч вместо этого скопытиться. Фирвари нервно относятся к RAW ERROR RATE. Если все время просить проблемные сектора, можно случайно устроить накрутку, в какой-то момент фирмварь решит что устройство запредельно поломано. Уйдет в safe mode - и тогда ты точно пойдешь к профессионалам, если данные нужны. Потому что сектора то оно отдает, но даже на identify может не отвечать. И вот это для хомячка уже обломно - оно ни биосом, ни осью не детектится, а если и детектится то не подцепляется. Те как-то не готовы что 90% команд будет отлуплено/проигнорено, только read sector. Не multiple. > искал в логе сбойный блок, оно там обычно было, и добавлял его в badlist - те fs так умели. Современные винчи, да и SSD умеют remap. Фимрварь сама проблемные сектора переназначит, большинство фирмварей это даже достаточно сносно умеют. Если есть куда. А если уже некуда - прекратите насиловать труп. Или вы ждете пока служебка перестанет читаться? Вот тогда и останетесь без данных, резко и внезапно. Не выйдет на режим после очередного включения - и вы пролетаете. > Хрен с ним, с тем файлом, он уже мертвенький - зато остальной сервер я не > буду переустанавливать, а просто склонирую. При попытке это сделать обычным софтом в обычном виде есть шанс что пациент в этом процессе откинет ласты окончательно. Иногда конечно может прокатить. Но вот это уже поиск проблем на свой окорок. Если оно реально надо - образ лучше софтом типа ddrescue/myrescue/whdd/... снимать за несколько итераций. И даже так - что он прочтется lossless не факт, поэтому безбашенно его влупить как есть куда-то еще чревато глюками или ВНЕЗАПНЫМ отвалом файлухи. Оно надо? Сэр очень талантлив в раскладывании грабель, теперь я понимаю почему у него линуксы так глючат. > Попробуйте повторить этот фокус с lvm, xfs или чем там модно? Даже если в файл попало, а > не в чортов журнал. Журнал иной раз можно и аннигилировать к чертям, если проблема в нем, зачастую с маргинальными потерями. Но в этом случае речь не идет о flawless восстановлении и 100% сохранности данных. Это ок для аварийного восстановления, когда выбор нифига совсем, или хотя-бы это, вот так. А если ФС так будет в крейсерском режиме - юзер будет постепенно пролюбливать данные. Чем неполный журналинг и плох. > ничего странного - ibm запатентовала sector marks, [пере]записываемые вместе с данными, > еще в 97м году. Нет метки - нет сектора, вообще нет его такого. Там все хитрее. У голосовой катушки нет треков. Она аналоговая, линейная, ей все-равно куда. Сервопривод по сервометкам понимает в какую сторону напряжение крутить, чтобы нужный трек найти. И даже вроде держит головы на дорожке, даже если та не идеально расположена, активно трекая размещение. И начала секторов помечены. Если это все слетит, запросто и целой группы секторов не будет. Вот вам IDNF - и гудбай. Нет такого сектора на этом накопителе. При том возможности фирмвари по ремапу таких областей весьма лимитированы и когда они закончатся, фирмварь сдастся. Обычно это никто не перезаписывает, потому что себе дороже. Более того - наносят это на фабрике, прецизионным серворайтером, который таки может отмерять мелкие дорожки и нанести разметку, в отличие от винча. Сам винч это не может, поэтому фирмвара боится перспективы снести это как огня. По этой причине настоящий low level format технически невозможен без, хы-хы, серворайтера. А вот глючное питание например может на раз помочь перезаписать сервометки. Фирварь прикладывает серьезные усилия чтобы это "should never happen", там много фокусов на тему. Вплоть до того что оставлен отступ от области данных, хоть это и пролюбливает место. Но если помочь - глючащая механика и электроника таки может сделать что-то не то.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	213. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от пох (?), 10-Дек-18, 10:36
	>> Правда, со времен "щелкающих" дятлов я подобных дисков не видал - сейчас, >> обычно, чпок - и все твои данные превращаются в тыкву без >> объявления войны и долгих предисловий, ну вот, кстати, верующим в смарт - добрался я таки до диска в своей безвременно сдохшей домашней помойке - он, к моему великому счастью, в принципе живой, детектится по минуте и с пары ресетов, но читается. смарт _идеальнейший_, хоть сейчас на авито такой выставляй - ни ремапов, ни prefail состояний, даже ошибок мизер. И только лог с записью о failed sector выдает советского разведчика ;-)
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	215. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от OldFart (?), 10-Дек-18, 17:07
	> смарт _идеальнейший_, хоть сейчас на авито такой выставляй - ни ремапов, ни > prefail состояний, даже ошибок мизер. > И только лог с записью о failed sector выдает советского разведчика ;-) Чтобы СМАРТ обновлялся, надо переодически делать long test (делаю раз в неделю на всех серваках), а так, да, иногда диск явно сбоит, а смарт чистенький, но после лонг теста все встает на свои места
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	219. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 11-Дек-18, 19:59
	> смарт _идеальнейший_, хоть сейчас на авито такой выставляй - ни ремапов, ни > prefail состояний, даже ошибок мизер. А ты запость выхлоп smartctl -a сюда, как есть... глядишь, несколько хинтов и найдется. > И только лог с записью о failed sector выдает советского разведчика ;-) КМК ты не понимаешь что такое идеальный смарт. Да, если ты будешь ждать пока проги начнут явно вопить - в половине случаев попль может быть за 5 минут до кончины, а еще в половине - воплей не будет потому что из винча не удалось прочитать SMART. Но если немного более проактивно смотреть на изменения параметров... ...возможно это дает идею почему smamontools'овский демон умеет мониторить изменения параметров и ругаться в лог по этому поводу.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

4. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–16 +/–
Сообщение от Аноним (4), 05-Дек-18, 10:00
3.10.0-957.1.3.el7 смотрит на всё это как на школьников
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+7 +/–
	Сообщение от Аноним (5), 05-Дек-18, 10:11
	Ты бы ещё на 2.6.32 сидел и хвастался этим.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	11. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Q (??), 05-Дек-18, 10:37
	дык 2.6.32 до сих пор поддерживается в RHEL/Centos 6.10 и будет поддерживаться еще пару лет... На нетбуке с древним атомом - самое то :) 2.6.32 и второгном
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	32. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноим (?), 05-Дек-18, 11:52
	RHEL на нетбуке?.. 10 минут работы от батареи вас устраивают?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	45. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Q (??), 05-Дек-18, 13:06
	Ну хоть не тормозит особо. После старта жрет 300- метров озу. Новые дистры там печальнее смотрятся. А батарея... за 8 лет от нее мало что осталось. На проводе висит. Вилка от бп маленькая, а не блямба, как у ноутов побольше.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	60. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:10
	> Ну хоть не тормозит особо. После старта жрет 300- метров озу. > Новые дистры там печальнее смотрятся. А дебиан с XFCE 250 жрет. Это как 64-битная инсталляция. А для совсем тощих можно и 32 бита пока еще. > А батарея... за 8 лет от нее мало что осталось. На проводе висит. Так бы сразу и сказали что у вас убогая пародия на десктоп. Ни портабельности, ни свежей графики, ни управления питанием, ни поддержки сколь-нибудь свежих железок - ни-че-го.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	46. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Q (??), 05-Дек-18, 13:10
	До 15 года была минт-9, коя на 10.04 сделана. Потом вот - центось.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	58. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:06
	> На нетбуке с древним атомом - самое то :) А он там хотя-бы GPU цепляет вообще, такой красивый? И софт вокруг не напрягает своей архаичностью? Или это рецепт для тех кому VGA-адаптера хватает и консольки 80x25, а ноут не вынимать из розетки?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	105. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от КГБ СССР (?), 05-Дек-18, 22:36
	Да, анон. Вот, например, у меня так. Devuan: i2.imageban.ru/out/2018/11/06/789af20d62e8693f6903e1fc4b70f0dc.png Slackware: i2.imageban.ru/out/2018/11/16/316ac015031f62d6f8a542f83b4f5548.png
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	111. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от анонзыы (?), 06-Дек-18, 01:55
	ну тот анон походу не понимает еще всего смысла дзен существования ))))) и все эти gpu с амд и прочими кажутся весьма важными. эх куда делся blakbox. вот это был стиль))) юным хакверям бы понравился. прям истинный дзен бунтарства. амитабха)) ахахах
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	112. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 02:05
	Да, самые красоты и самое графическое богатство в юниксах — оконные менеджеры. На любой вкус и любую эстетику. :) Люди, которые выбирают третьегном, даже не догадываются, чего себя лишают.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	114. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от анонзыы (?), 06-Дек-18, 02:48
	и правда в свое время начинал эксперименты с иксами именно с 3 кедами и 2 гномом. причем все это богатство шло на livecd , а теперь минималистичный дистр уже стал 11 гигов(эт я о недавней новости). раньше помнится совсем минималистичный умещался в 43 мб. да и иксовые DE разъелись жадно. хотя еще есть дистры готовящие неплохо. но все как то в сторону потребительства идем))
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	122. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним (-), 06-Дек-18, 06:14
	> любой вкус и любую эстетику. :) Люди, которые выбирают третьегном, даже Я таки выбираю XFCE. С общей парадигмой на манер '95 и достаточно специфичной графической темой. Половину из которой пришлось отрихтовать самому. > не догадываются, чего себя лишают. Именно третий гном со всеми своими автоиндексаторами и проч - явно ориентируется на склеротиков-имбецилов, гадящих прямо под себя, так что за ними убирать видите ли надо. Ну типа как клетку за хомяком.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	127. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 08:22
	> Именно третий гном со всеми своими автоиндексаторами и проч - явно ориентируется > на склеротиков-имбецилов, гадящих прямо под себя, так что за ними убирать > видите ли надо. Ну типа как клетку за хомяком. Я вообще не могу себе в пределах рациональной логики объяснить, как, находясь в здравом уме, можно напроектировать что-то наподобие третьегнома. Это точно какое-то «калекам от калек с любовью».
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	130. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (130), 06-Дек-18, 08:38
	Да это что-то типа попытки закосить под планшеточный интерфейс, чтоли, было. Фэйл в том что планшеток с этим так и не появилось толком - поэтому десктоп зачем-то запохабили, а что приобрели в результате - не понятно. В поздних версиях вроде более-менее схватились за голову и немного переиграли... для того чтобы гнум4 начать пилить, чо.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	139. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 10:39
	под винду8. потому что ничего, кроме копипасты с проклятой, увы, в головах нет. Причем даже не с настоящей винды, а с представлений о ней хейтеров, толком никогда и не пользовавшихся. Поэтому и получается такое вот, клон пародии. > для того чтобы гнум4 начать пилить, чо. все правильно - ms так сделала с десяточкой, значит и им надо.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	152. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (152), 06-Дек-18, 12:48
	> под винду8. Да какую винду 8? У той кнопки уродские и меню на весь экран. И два набора настроек, лол. Гномеры не настолько долбанулись. Как угодно но восьмеру замесили с гуано все хомяки которых я знаю. Да и с десятки они не в восторге, некоторым удружили блин обновлением, так что они аж ОС переставляли или откатывали с рекавери раздела. > толком никогда и не пользовавшихся. Поэтому и получается такое вот, клон пародии. Да не похож гнум на восьмерку, имхо. Из той планшетный интерфейс вообще ни о чем. > все правильно - ms так сделала с десяточкой, значит и им надо. MS с десяточкой похоже был больше занят наворачиванием кейлогеров и всучиванием виндосторов. Операционка там так, до кучи вообще, как повод.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	121. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 06:11
	> и все эти gpu с амд и прочими кажутся весьма важными. Они по своему важны. Ну вот например - с ними KiCAD здорово резвее работает. И не только он. Но это если дорожки по плате тягать а не в консольку пыриться на свои "достижения" в засирании системы, конечно. > эх куда делся blakbox. вот это был стиль))) юным хакверям бы > понравился. прям истинный дзен бунтарства. амитабха)) ахахах Мое бунтарство просто немного не там. Оно уже сочетается с некоторым опытом и прагматизмом - так что системная магия происходит не ради спецэффектов, а ради убедительного результата, который имеет какой-то более прагматичный смысл чем школьный п@нт... :). Я просто научился им немного управлять. Это делает меня мощнее.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	120. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 06:01
	> Да, анон. Вот, например, у меня так. Олдскульненько. Хотя дебиан даже по своему стильный. Однако список процессов таки не влезает на экран. Special fuckoff за виртулабоксы и кучу левых сервисов а также белый, белый цук терминал! Нельзя же настолько виндогипертерминалмакакой то быть, особенно олдскульщику, чогт.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	129. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 08:32
	> Олдскульненько. Хотя дебиан даже по своему стильный. Однако список процессов таки не > влезает на экран. Ну так там же 800х600. Таких экранов нынче уже и мало где встретишь. >  Special fuckoff за виртулабоксы и кучу левых сервисов > а также белый, белый цук терминал! Нельзя же настолько виндогипертерминалмакакой то > быть, особенно олдскульщику, чогт. Поставь себе жолтый, как в Сюзи. Да хоть зелёный с малиновыми буквами или ещё какой — всё ж настраивается. ;-) А чем плох виртуалбокс? Я специально для иллюстрации сделал таких скриншотов на виртуалке. Приятно слушать далёкое потрескивание чьих-то разрывающихся <CENSORED> из интернетов, когда аноны видят полностью графическую среду на 40 МБ памяти (а в Дебиане 3.1 было вообще 25 МБ). :)
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	131. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (130), 06-Дек-18, 08:43
	> Ну так там же 800х600. Таких экранов нынче уже и мало где встретишь. Ну так правильно, у меня даже у виртуалок экраны больше. У меня у смартфона разрешение около такого, поэтому десктоп такого размера мне все-таки немного западло. У меня такое разрешение было где-то в совсем уж начале 90-х, на моем самом первом пузатом CRT. > Поставь себе жолтый, как в Сюзи. Да хоть зелёный с малиновыми буквами > или ещё какой — всё ж настраивается. ;-) Дык я и настроил себе терминалку как мне там надо было. > А чем плох виртуалбокс? Тем что при наличии KVM-а на...й не упал, да еще внебрачный выперыш в линуксе. Разрабатывается хрен знает кем, хрен знает как, поэтому если чей-то левый модуль дестабилизирует ядро, жаловаться с этим только в спортлото разве что можно. > интернетов, когда аноны видят полностью графическую среду на 40 МБ памяти Если уж на то пошло, '95 и на 4 мегах всползал. Но желающих им сейчас пользоваться как мне кажется будет немного. Хоть так и можно, по крайней мере, теоретически. Особенно на древнем железе.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	134. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 09:01
	>> А чем плох виртуалбокс? > Тем что при наличии KVM-а на...й не упал, да еще внебрачный выперыш > в линуксе. Разрабатывается хрен знает кем, хрен знает как, поэтому если > чей-то левый модуль дестабилизирует ядро, жаловаться с этим только в спортлото > разве что можно. KVM только в линуксах. Мне надо больше. >> интернетов, когда аноны видят полностью графическую среду на 40 МБ памяти > Если уж на то пошло, '95 и на 4 мегах всползал. Но > желающих им сейчас пользоваться как мне кажется будет немного. Хоть так > и можно, по крайней мере, теоретически. Особенно на древнем железе. На 4 метрах он тяжело ползал. На 32 начиналась взрослая половая жизнь. А вот NT у меня тяжеловато ворочался на такой машине. Где теперь та кнопочка Turbo, эх…
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	153. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (152), 06-Дек-18, 12:55
	> KVM только в линуксах. Мне надо больше. Ну так вон у меня в KVMине и висит какая-то qnx-ина устройства которое я воссоздам на ARM и линухе, без всей этой коммерческой реалтайм-порнографии. > На 4 метрах он тяжело ползал. Ога. На 8 уже нормально, если офис не надо. > На 32 начиналась взрослая половая жизнь. На 32 можно было нормальный NT4 запустить и почувствовать себя человеком. С нормальной изоляцией процессов и правами, так что оно не виснет в миг от заскоков 1 кривой задачи. Ну вот правда плагнплея не было и дрова ставились очень уж досяво, разве что setup.exe заменили на setup.inf. > А вот NT у меня тяжеловато ворочался на такой машине. Где Да нормально NT на 32 мегах ворочался, вы там зажрались. > теперь та кнопочка Turbo, эх… Она теперь быстрая и электронная, еще и вольтажи менять умеет. А если жарко - то может и отжаться на время.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	133. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от КГБ СССР (?), 06-Дек-18, 08:52
	Debian GNU/Linux 3.1 r8 “Sarge”: 1) в консоли: i6.imageban.ru/out/2018/12/06/af167da6d95bf1087c5c3fee43ec7c36.png 2) в Иксах: i5.imageban.ru/out/2018/12/06/9be4ce1430f61e455dfc3b633b385327.png Кто меньше? ;-)
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	154. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (152), 06-Дек-18, 12:57
	> Кто меньше? ;-) У меня дебиан мегов 20 бинарей. Правда на ARM и 9-й. Иксов там правда в страшном сне не предвидится, графика если там и понадобится то скорее всего KMSный фреймбуфер какой. Хоть при желании можно конечно иксы вкатить и все такое. Только зачем оно мне там такое...
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	155. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (152), 06-Дек-18, 12:58
	p.s. самое жирное что там есть - список пакетов на почти 100 метров... софта все-же понакатали много. Это если его скачать, конечно.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	184. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Q (??), 06-Дек-18, 19:28
	Цепляет. Проблемы с интегрированным видео на древних атомах (у меня n450) начались позже, с 11 года, на ядрах старшн 2.6.32. убунты 10.04 и 10.10 хорошо шли, а вот с 11.04 или 11.10, не помню уже, жопа началась
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	7. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+3 +/–
	Сообщение от Аноним (7), 05-Дек-18, 10:16
	> 3.10.0-957.1.3.el7 > 957 Блажен кто верует.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	23. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от пох (?), 05-Дек-18, 11:38
	собственно, да - кто сказал что баг не бэкпортирован? А вот теперь иди и трахайся, это проверяя - в отличие от пользователей vanilla, которым достаточно uname -r чтобы либо спать спокойно, либо бегом обновляться.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

6. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
Сообщение от Аноним (6), 05-Дек-18, 10:14
у меня вообще вот такая портянка в /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet rd.udev.log-priority=3" GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/ acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1 hpet=force clocksource=hpet pti=off l1tf=off spectre_v2=off spec_store_bypass_disable=on nospectre_v1 nospec_store_bypass_disable intel_pstate=disable intel_idle.max_cstate=0 processor.max_cstate=0 nospectre_v2 nopti spectre_v2_user=off irqpoll pci=ioapicreroute,use_crs,routeirq,pcie_bus_peer2peer,realloc" там много чего лишнего, но вот без этого, Е4500 интеловский да и не только он просто фризит намертво и виснет иногда: pti=off l1tf=off spectre_v2=off spec_store_bypass_disable=on nospectre_v1 nospec_store_bypass_disable intel_pstate=disable intel_idle.max_cstate=0 processor.max_cstate=0 а это так дополнением на случай если другие опции вырежут nospectre_v2 nopti spectre_v2_user=off причем если чисто pstate/cstate вырубать отдельно или mitigations противодействия последним уязвимостям все равно виснет, не зависает тока когда все вкупе юзаешь вместе. x3 почему...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от dimez (?), 05-Дек-18, 11:10
	> pti=off l1tf=off spectre_v2=off spec_store_bypass_disable=on nospectre_v1 nospec_store_bypass_disable nospectre_v2 nopti spectre_v2_user=off У тебя ОКР что ли? 2 опции распихал в 9.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	101. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от anonymous (??), 05-Дек-18, 21:28
	>spec_store_bypass_disable=on Судя по остальным параметрам намерение выключить избегания этих уязвимостей, чтобы включить spec store bypass нужно указать параметр spec_store_bypass_disable=off т.к. выключение spec store bypass - это избегание этой уязвимости. Иными словами надо поменять на spec_store_bypass_disable=off
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	21. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от ryoken (ok), 05-Дек-18, 11:34
	А где net.ifnames=0 и intel_iommu=on ?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	25. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–3 +/–
	Сообщение от пох (?), 05-Дек-18, 11:42
	ну так может потому оно у тебя и виснет, что ты понапихал неведомых заклинаний, а если ВСЕ это выкинуть - то и pti/spectre не будут тебе так сильно мешать. Но чур - именно все. Я вот понятия не имею, кому сегодня нужно acpi=force, да и весь остальной треш.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	40. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Crazy Alex (ok), 05-Дек-18, 12:44
	тому, у кому fancontrol  нужен, вестимо
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	65. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:26
	> тому, у кому fancontrol  нужен, вестимо А что, ядро без этого acpi не пользуется? Оно вроде по дефолту acpi, кроме случаев когда тот поломан в терминальной стадии. Так то он поломан почти всегда и везде, жестоко глюча на всем что не винда, но обычно кое-как работает и в линухе глюки заворкэраундили более-менее, по крайней мере на популярных железках.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	73. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–3 +/–
	Сообщение от пох (?), 05-Дек-18, 16:19
	> А что, ядро без этого acpi не пользуется? Оно вроде по дефолту > acpi, кроме случаев когда тот поломан в терминальной стадии. Так то именно так - и если тебе повезло с именно такой конфигурацией - а ты еще и прооверрайдил ее "я лучше знаю", то потом странно удивляться, что что-то виснет. > он поломан почти всегда и везде, жестоко глюча на всем что > не винда ну конечно, во всем виноваты жы...ой, простите, винда проклятая.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	84. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+2 +/–
	Сообщение от Аноним (84), 05-Дек-18, 17:23
	Не винда, а acpi, написали ж. Просто если посмотреть, как решаются проблемы с ним и количество подпорок.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	86. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (86), 05-Дек-18, 17:46
	> ну конечно, во всем виноваты жы...ой, простите, винда проклятая. монополия microsoft в том числе виновата
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	91. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (90), 05-Дек-18, 18:16
	> ну конечно, во всем виноваты жы...ой, простите, винда проклятая. В этом случае скорее вендоры проприетарной клоаки (BIOS, UEFI и ACPI, вся троица). Которые не тестили свой кусок гуано ни на чем кроме винды, написав его как курица лапой - мол, винда как-то загружается - идем продавать. Ну а на всякие глупости типа стандартов оно кладет с прибором, соответственно. Можно посмотреть какой список firmware bug'ов по этому поводу линь выдает при загрузке. Их походу заманало такое и они теперь бракоделов палят от души. Выдавая баги прям по списку.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	141. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 10:45
	ты-то веб-страницы под браузер с 3% аудитории - каждый раз тестишь? > Их походу заманало такое они похоже решили что 3% десктопов это много, надо 1. Ну заодно и серверов тоже, а чо, выбирай правильные (хз только какие - эппл вроде давно уже серверов не выпускала, чтоб "как у Линуса на ноуте"), ибо нефиг. Что значит "винда и вмварь работают"? Здесь вам не тут, опенсорсие во все дыры.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	156. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 13:08
	> ты-то веб-страницы под браузер с 3% аудитории - каждый раз тестишь? Если каждый 30-й будет грызть мозг - это довольно паршиво. А так - либо уж трусы, либо уж крестик. Если виндоблобы - так и скажите. Нефуя тогда "стандартами" размахивать, чтоли. А то получается что скроить таблицы левой пяткой - можно, а виноват в этом почему-то линукс. Нравится мне такая логика у мс и их шестерок - всегда спихивают с больной головы на здоровую. Я понимаю что проприетарщики баги чинить не лю. Ну и они пусть поймут за что их не лю. И таки я в состоянии разобраться кто в этой схеме накосячил и без ваших сопель. И таки я привык называть бркоделов бракоделами и желать им соответствующей репутации. > они похоже решили что 3% десктопов это много, надо 1. А я решил что бракоделов надо называть бракоделами. > Ну заодно и серверов тоже, а чо, выбирай правильные Ну так довыпендриваются - там вон с ARMовскими серверами только ленивый не отметился, а тут еще RISC-V 64-битные наворачивать начинают. Kто SoC а кто и чипы пожирнее и пошустрее. Это конечно не xeon еще, но как бы навернуть побольше ядер, кэша и частоты задрать дело не хитрое.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	160. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Michael Shigorin (ok), 06-Дек-18, 13:15
	>> они похоже решили что 3% десктопов это много, надо 1. > А я решил что бракоделов надо называть бракоделами. Ой, а по их методичке уже целых три процента, я всё пропустил? :D >> Ну заодно и серверов тоже, а чо, выбирай правильные > Ну так довыпендриваются - там вон с ARMовскими серверами только ленивый не > отметился, а тут еще RISC-V 64-битные наворачивать начинают. Kто SoC а > кто и чипы пожирнее и пошустрее. Это конечно не xeon еще, > но как бы навернуть побольше ядер, кэша и частоты задрать дело > не хитрое. Заметьте одинарные стандарты человека, который крошил батон на эльбрусы, а riscv, поди, в руках не держал ;-) (там, мягко говоря, _далеко_ не xeon -- как и на нынешних aarch64)
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	171. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 16:14
	> Ой, а по их методичке уже целых три процента, я всё пропустил? :D Да вот тоже удивляюсь, заапдейтили что-то. Наверное после десятки. > Заметьте одинарные стандарты человека, который крошил батон на эльбрусы, а riscv, поди, > в руках не держал ;-) В руках не держал, НО... - Уже поставил тулчейн. Разумеется, GCC. - И виртуалки наготове. Qemu с поддержкой этого у меня уже есть. - Я по немногу изучаю как и что с билдовкой кернеля на это. Just because I can. - Думаю что скоро наступит момент когда я попробую дебутстрапнуться, используя гибридную технологию, допускающую что настоящей железки может и не быть. С армами этот трюк прокатил, следующим видимо станет как раз RISC-V. И таки при появлении железки мне останется заинтегрить бутлоадер в образ да может еще какую специфику обыграть. И система примерно того вида от которого я танцую в (около)эмбеде пойдет на взлет. После чего я попаду в привычный мне дебиан. Без NDA, приватных репов, с открытым тулчейном. Я считаю что опенсорц должен быть как-то так. > (там, мягко говоря, _далеко_ не xeon -- как и на нынешних aarch64) Aarch64 - весьма растяжимое понятие. И может включать в себя как одноплатник с TDP 5 ваттов на все, так и довольно могучий агрегат с старшими ядрами на приличных частотах, с жирными кешами, кучей pci-e и все такое. Который может и не ксеон, но большинство серверных задач потянет без особых проблем. При том как угодно но на армы есть нормальная открытая экосистема, а младший ARM, чтобы вообще технологию ощутить, можно купить баксов за 20. В отличие от. Без всяких NDA, приватных репов и прочего миндфака.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	166. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 15:07
	> Если каждый 30-й будет грызть мозг - это довольно паршиво. closed, notabug, следующий! > Если виндоблобы - так и скажите. а часовню вам тоже блин гейтс развалил? Отлаживали - да, на том что и будут ставить большинство юзверей. Тестировать не тестировали, китайцам некогда. (да и не видел я тестов именно acpi или uefi. Вот windows compliance тесты - да, видел. У вас, кстати, есть такие?) > А я решил что бракоделов надо называть бракоделами. да пожалуйста, им от ваших 2% не холодно и не жарко. ищите сферические серверы в вакууме, работающие с вашим линуксом. > Ну так довыпендриваются - там вон с ARMовскими серверами только ленивый не отметился вы скоро и проблемы devicetree будете на "проклятую ms" валить?
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	172. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 16:54
	> closed, notabug, следующий! Ну вот на опеннете например 10 000 посетителей в день. А 300 раз это повторить за день не заканает? А то с браузерами оно как-то так, некоторые эстеты страдают даже поддержками немолодых ишаков через костыли добавляющие им поддержку как-бы-html5 :). Хоть это и гораздо болезненнее и ресурсозатратнее чем поддержка линуха - там, блин, просто по стандарту писать не катит. Надо именно хренову кучу кастомного кода под отклонения от стандартов и неполные реализации. > а часовню вам тоже блин гейтс развалил? Отлаживали - да, на том > что и будут ставить большинство юзверей. Тестировать не тестировали, китайцам некогда. Ну тогда не обижайтесь если линуксоиды в результате наделают своих стандартов. Они могут. Вон например лаптопчики на ARM64, даже открытые есть. Линухи, андроид - пожалста. А винду там вообще фиг бутанешь. Такой гибрид планшета с ноутом, чтоли. С управлением питанием планшета и возможноятсми ближе к ноуту, если нечто типа дебиана вкатить. > (да и не видел я тестов именно acpi или uefi. У стандартов где не джамшутили - есть conformance test suite. > Вот windows compliance тесты - да, видел. У вас, кстати, есть такие?) Нет. А нафуя они мне? У меня и виндоуса нет. Я не девелопаю под виндоус. В гробу я такое удовольствие видал. Как максимум там где взаимодействие с виндой будет - чекается in situ, но это минимальные проверки. > да пожалуйста, им от ваших 2% не холодно и не жарко. Да собственно глядя на то какой крындец творится с PSP, ME и проч - мне так грешным делом кажется что новых x86 лаптопов у меня возможно больше и не будет, например. Для моих задач я могу лаптоп на любой архитектуре использовать. Меня на x86 ничего не держит, мои workflow все перенесены на кроссплатформенный софт давно. Пацан захотел, пацан сделал. И теперь фиг меня кто посмеет строить, навязывая мне какие либо условия. > ищите сферические серверы в вакууме, работающие с вашим линуксом. Ггг вот чего-чего а железок работающих с линуксом у меня почти 2 десятка вокруг. На большинстве из них винда не заработает даже если захотеть. Так что я имею наглость полагать что на мой век железяк хватит, с большим запасом. Так что напугать меня немного не получится. >> Ну так довыпендриваются - там вон с ARMовскими серверами только ленивый не отметился > вы скоро и проблемы devicetree будете на "проклятую ms" валить? Нет, с проблемами devicetree мы таки сами разберемся :). В отличие от - там видите ли апстриму патчи можно слать, и вообще.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	177. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 18:09
	> Ну вот на опеннете например 10 000 посетителей в день. их винде ничего не угрожает, там acpi работает. > Ну тогда не обижайтесь если линуксоиды в результате наделают своих стандартов. Они могут. они могут только испортить списанный ноут от ibm, стереть следы кофе с клавиатуры и пытаться продать его за $3000 с неработающим энергосбережением. > Линухи, андроид - пожалста. да, я как такое вижу - закрываю страничку. Мне, пожалуйста, без анального зонда, вшитого в неперезаписываемую часть флэша. А винда у меня уже есть. > У стандартов где не джамшутили - есть conformance test suite. жаль что компьютеров нет. > Нет. А нафуя они мне? я имел в виду - аналогичные тесты для линукса. Вы же не джамшутили, у вас есть? Как то есть нет? > Для моих задач я могу лаптоп на любой архитектуре использовать. жаль что их нет, да? Есть лишь планшеты-переростки с неизвлекаемым ведроидом в флэшке. > Ггг вот чего-чего а железок работающих с линуксом у меня почти 2 десятка вокруг. На > большинстве из них винда не заработает даже если захотеть. да, на rpi она не очень. жаль что сервер из нее тоже не очень, да и ноутбук так себе выйдет. > Нет, с проблемами devicetree мы таки сами разберемся :). В отличие от - там видите ли апстриму > патчи можно слать, и вообще. какому еще апстриму? Китайцу Ляо, что конкретно эту плату наляпал, ничего не пришлешь. У него, наоборот, спереть надо, потому что реверс-инжинирить немного затруднительно. Это тебе не acpi.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	194. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (194), 07-Дек-18, 17:14
	> их винде ничего не угрожает, там acpi работает. А ты попробуй для 3% из них сайт криво зарендерить - узнаешь как это выглядит. А в случае линя это таки компетентные технари зачастую. И таки в результате у вендырей портится репутация, порой на довольно видных местах. Ну как, если тебя фороникс и прочие слэшдоты и реддиты замесят с грязюкой - довольно ощутимо уже. > они могут только испортить списанный ноут от ibm, стереть следы кофе с > клавиатуры и пытаться продать его за $3000 с неработающим энергосбережением. Перец из Olimex отрисовал в KiCad'е платку под 64-битный китайский ARM. И вопрос с корпусом решил. Взяв да и спроектировав лаптоп сам. В свободном софте, чтобы совсем эпично. Можно долго кудахтать о том как и что, но маленькая веха пройдена: теперь можно даже и лаптоп себе сделать. Под линуксом. Открытым софтом. И таки это довольно высокий уровень. Разводка платы с DDR3... это внушает уважение любому про, понимающему какие там требования к этому самому. Да и плотный BGA одним открытым софтом и по сути в 1 физиономию раскидать - неплохо так, по любым стандартам. А когда это еще и открытым софтом - на улице опенсорсников и вообще DIY-энтузиастов маленький но прикольный праздник. > зонда, вшитого в неперезаписываемую часть флэша. И такое тоже есть. Вон в olimex - нет никаких неперезаписываемых флешек, и вообще, процесс старта проца достаточно документирован. Ну и вообще, уж не обладателям x86 с глючными биосами и бэкдорами в ME про это пиндеть :). Allwinner'а то без блобов, целиком в сорцах - я забутявлю. А вот с x86 у меня на это кишка тонка, скажем прямо. И таки если я бутлоадер и линя которого он пинает собрал из сорцов, они, наверное, на меня будут работать все-таки. С довольно раннего power-up'а и до конца :) > жаль что компьютеров нет. Как бы это сказать? Ситуация пока далека от идеала, но если принципиально, это уже сейчас стало вполне решаемым вопросом. И дальше ситуация будет только улучшаться. Рубикон пройден, open hardware быть. Этот процесс уже не остановится. > я имел в виду - аналогичные тесты для линукса. Вы же не > джамшутили, у вас есть? Как то есть нет? Я почему-то думал что conformance test suite должен быть у тех кто стандарт делает, а не "линуксоидов" каких-то. Линуксоиды совершенно не обязаны как таковые это писать, покуда не называются стандартом. Ну и какой-нибудь u-boot например как бы не является формальным стандартом. Но это не мешает орде народа им пользоваться. И с точки зрения дел системных проблем с ним гораздо меньше чем с UEFI, да и перепахать под себя можно. В том числе и в случаях когда как раз надо что-то нестандартное. > жаль что их нет, да? Есть лишь планшеты-переростки с неизвлекаемым ведроидом в флэшке. Уже таки есть несколько. Забег начат Olimex. И таки вот на такой штуке у меня совершенно точно никакого андроида не будет вообще совсем. I'm not easily cornered. Если ты думаешь что сможешь загнать системщика в угол, я отвечаю: "попробуй". > да, на rpi она не очень. Да мне пофиг на rpi, я в основном allwinner предпочитаю и немного рокчипа. У китайцев цена-качество в целом прикольнее чем у броадкома. > жаль что сервер из нее тоже не очень, да и ноутбук так себе выйдет. Поэтому olimex сделал на allwinner A64. А постепенно и на других процах платки подгонят. Да, там можно поспорить на очень-не очень, но вот моему ноуту и не надо быть "очень". Ему надо быть таскаемым и батарею не жрать как x86. А вот это может любой чип с околомобилочным DVFSом и нормальным менеджером питания. Большинство этого добра даже цепляется майнлайном уже. И таки в idle практически холодное, x86 до этого как раком до пекина. У таких штук вентилятора то зачастую совсем нет - пассивное охлаждение. А x86 с полностью пассивным охлаждением - весьма экзотичный зверь. И я как-то видел за сколько планшет на атоме расправляется с батарейкой, хватило. Она там заряжается дольше чем разряжается, лол. > какому еще апстриму? Китайцу Ляо, что конкретно эту плату наляпал, ничего не > пришлешь. Ну так не захочу китайца - будет олимекс. А вот это уже нормальный апстрим. У них и CAD файлы выложены под открытой лицензией. Можешь хоть сам платы на ближайшей фабе сделать. Это правда для платы такого уровня правда будет достаточно хлопотно и затратно, но тут уж сорь, уровень технологий уж такой какой есть. Это тебе не проводульки в ардуину тыкать. > У него, наоборот, спереть надо, потому что реверс-инжинирить немного затруднительно. > Это тебе не acpi. Выбирая между ляо и acpi я буду за ляо. Ляо простой как тапка, ему главное чтобы как-то заработало и у него нет ресурсов на пхание ME, DRM, secureboot и прочего крапа. В отличие от интелского дачья.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	57. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от 4.4 (?), 05-Дек-18, 15:05
	Шапочку из фольги на сервер не забыл надеть?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
Сообщение от Аноним (8), 05-Дек-18, 10:26
В целом что с ZFS, он сам разруливает в случае проблем в избыточных RAID, правильно понял?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от ddd788 (?), 05-Дек-18, 11:26
	Да, ZFS определяет расхождение между контрольными суммами, полученными с разных носителей, и корректирует ошибку. Ext4 этого не делает, точнее делает только для метадат (опция появилась пару лет назад). Как видим, аргумент который они приводили против сплошного чексуммирования, оказался неверен.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	41. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Crazy Alex (ok), 05-Дек-18, 12:47
	Бороться с багом в ядре надо фиксом, а до того - откатывая версию до предыдущей рабочей, а не пытаться на лету править.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	64. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+4 +/–
	Сообщение от nonimus (?), 05-Дек-18, 15:25
	zfs борется не с багами ядра, а с bit rotting / silent data corruption. То, что кто-то умудрился это сделать на уровне ядра - заслуга разработчиков ядра. Примерно тех же самых, что и чексуммы в ext4 не хотели, потому что это дело накопителя. Думаю, теперь у них точка зрения немного изменилась.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	74. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 05-Дек-18, 16:21
	> zfs борется не с багами ядра, а с bit rotting / silent > data corruption. > То, что кто-то умудрился это сделать на уровне ядра - заслуга разработчиков > ядра. > Примерно тех же самых, что и чексуммы в ext4 не хотели, потому > что это дело накопителя. > Думаю, теперь у них точка зрения немного изменилась. да не, зря ты думаешь. Они не думают - систему переустановят, git clone с кернелорг, и дальше кодошлепствовать, все равно у них на той fs ничего кроме порно с пингвинами ценного не было, а там выпавшие сотни пикселей никто не заметил. системы используемые исключительно для пересборки нового ведра к этому багу устойчивы ;-)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	88. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (86), 05-Дек-18, 17:54
	> Думаю, теперь у них точка зрения немного изменилась. А чем чексуммы здесь бы помогли?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	94. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от nonimus (?), 05-Дек-18, 18:25
	Помогло бы тем, что повреждение данных выявилось сразу же. Хотя накопитель и отрапортовал что все Ок. Если уж нельзя исправить ошибку, то хотя бы напечатать в кернел лог, где и что произошло. Возможно, перемонтировать фс в режим для чтения, чтобы избежать дальнейших проблем. Не говоря уж о том, что баг этот было бы гораздо проще найти.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	87. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (86), 05-Дек-18, 17:51
	> Ext4 этого не делает, точнее делает только для метадат а можете рассказать подробней, как ext4 «определяет расхождение между контрольными суммами, полученными с разных носителей» для метадат?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	92. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от nonimus (?), 05-Дек-18, 18:17
	А где я такое писал? это касатся зфс, потому что он включает в себя и блочный уровень. ехт4 оставляет это на откуп блочному уровню и проверяет только метадату, которая может оказаться испорченной, несмотря на то что на блочном уровне все выглядит Ок. Как видим, это может выйти сильно боком, в худшем случае (например, в этом) это полная фикция. С ФС все в порядке, с данными - нет.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

10. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+3 +/–
Сообщение от Аноним 80_уровня (ok), 05-Дек-18, 10:37
Отличный заголовок. Подумал, что статья про окончательное решение вопроса ext4.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от blackst0ne (ok), 05-Дек-18, 10:45
	Чем заменять-то? И зачем?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–16 +/–
	Сообщение от Аноним (13), 05-Дек-18, 11:04
	BTRFS. Ибо эта ваша ext4 - устаревший шлак, без каких-либо современных плюшек и преимуществ.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	15. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (15), 05-Дек-18, 11:13
	Плюшки BTRFS нужны всем?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	17. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+19 +/–
	Сообщение от Michael Shigorin (ok), 05-Дек-18, 11:17
	Ему данные надоели.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	66. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+2 +/–
	Сообщение от Аноним (-), 05-Дек-18, 15:28
	> Ему данные надоели. Фейсбуку не надоели, а шигорину надоели. Впрочем, чего от эксперта по NDA ожидать. Наверное не объективного взглядя на Linux.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	75. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от пох (?), 05-Дек-18, 16:24
	>> Ему данные надоели. > Фейсбуку не надоели, а шигорину надоели. Впрочем, чего от эксперта по NDA пейсбуку твоих данных не жалко вот совсем. Кстати, народ недавно жаловался на пустые ленты (потом потихоньку снова начавшие заполняться) - так что похоже я был неправ, предполагая что relation graphs они хранят как-то отдельно от котиков, как ценный товар. Чо там ценного - за неделю ты заново всю картотеку на себя заполнишь...
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	107. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от псевдонимус (?), 05-Дек-18, 23:25
	ФСБуку твои котики постольку поскольку. Есть хорошо,потеряется несколько тоже не проблема.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	116. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 05:21
	> ФСБуку твои котики постольку поскольку. Есть хорошо,потеряется несколько тоже не проблема. Я как-то пользую для себя btrfs в хвост и в гриву. И ничего не потярелось. А если он развалится - там rescue встроенные есть. Который пытается вынуть данные вообще без монтирования и ничего не записывая в источник, чтобы не порушить его дополнительно. Да еще с возможностью потыкаться в разные по времени состояния (выбор generation от которого плясать) в надежде что какое-то из них окажется более-менее валидным и нужные файлы вытащить удастся. А вот сказать то же самое про допустим гражданина Шишкина и его ФС - я решительно не готов. И поэтому с точки зрения пессимистичного расклада, пусть Шишкин внятно расскажет как с его штуки вообще данные доставать. А то когда в 3-м рейзере fsck том может целиком разнести и это "known issue" - это как-то очень неубедительно, как по мне. В случае xfs - у них так вообще полного журнала нет. Это как бы очень намекает о заботе ФС о целостности данных и всем таком. У ext4 он есть, но скорость работы классики с полным журналом понятно какая, да и без чексум данных это как-то совсем уж полумеры и в целом конструкция не сказать что сильно логично выглядит и работает.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	137. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 10:30
	> Я как-то пользую для себя btrfs в хвост и в гриву. держи нас в курсе, админ локалхоста > А то когда в 3-м рейзере fsck том может целиком разнести и это "known issue" - это как-то очень > неубедительно, как по мне. оно происходит только в случае, когда там уже все плохо и том и так разнесен в хлам. Причем его для этого надо запускать специальным образом, о чем оно раньше (я лет пятнадцать уже не пользуюсь) даже внятно и не говорило, а высовывало вместо этого табличку "заплати $25 правильным пацанам - они тебе починят". То есть довести до этого надо постараться. Но правильные пацаны одно, а Шишкин - совсем-совсем другое, и issues там пока совершенно unknown. Нехай другие по ним потопчутся, я, пожалуй, пешком постою. > Это как бы очень намекает о заботе ФС о целостности данных и всем таком. это как бы намекает, что авторы понимали, что для целостности данных он вообще бесполезен, а проблему производительности собирались решать другим способом. > У ext4 он есть, но скорость работы классики с полным журналом понятно какая нормальная скорость - если ты знаешь, для чего на самом деле этот журнал и правильно все соберешь. Правда, опять же лет десять уже не видел таких конструкций, у всех, кому оно на самом деле надо -  ZIL под понятно какой fs и тоже понятно что он собой представляет и какие есть особенности (а они есть) > и в целом конструкция не сказать что сильно логично выглядит и работает. в целом - в 2005м работала, дальше не тестировали. Вполне логично, но опеннет, трудами неадекватов у руля, не место для лекций.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	174. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (174), 06-Дек-18, 17:59
	> держи нас в курсе, админ локалхоста Локалхосты локалхостами, а у меня довольно много всякой странной фигни, подвергающейся странным приключениям и экспериментам. Если оно не сдохло - это хороший признак. Ну и в конечном итоге мне мои данные нужны на моих локалхостах, внезапно. А остальное меня колышет или из научного интереса или для понимания возможностей имплементации той или иной штуки и не замесят ли меня потом с гуано. > оно происходит только в случае, когда там уже все плохо и том > и так разнесен в хлам. Оно происходит если эта штука нарвалась в процессе лопатинга тома на образ диска с другим рейзером. После чего оно вкатит чужие структуры оттуда прям в "починяемый" том. С понятным результатом. > Причем его для этого надо запускать специальным образом, о чем оно раньше > (я лет пятнадцать уже не пользуюсь) даже внятно и не говорило, > а высовывало вместо этого табличку "заплати $25 правильным пацанам - они > тебе починят". То есть довести до этого надо постараться. У авторов амула оно вообще ничего не спрашивало - том перестал монтироваться требуя fsck. При попытке fsck он был доломан окончательно и сервак вынужденно ушел в даун на переустановку оси. Ну и вот лично мне системные тулсы которые работают как-то так - скажем прямо, "не очень". Я как бы допускаю мысль что Рейзер сумасшедший гений, и что у него и его команды есть крутые решения. Но, честно, для решения годного для продакшна роялит общий букет свойств. В том числе и какой-то план на случай если все обломалось. Идея недеструктивно вычитать нужные файлы из подубитой ФС мне как-то более симпатична - если не получится, можно попробовать снова. Ничего не испортив. А вот когда fsck рейзера разгромит том - undo самого по себе нет. Кста, когда я чиню fsck'ом файлухи (это чаще всего небольшое data recovery в частном порядке), это таки reflink-копия образа обычно. Таки на этом самом btrfs'е. Хотя-бы потому что из него хранилку  на потребный размер ненапряжно делать, есть сжатие, умеет reflinks, так что можно работать как бы с "копией" образа но весить будет только отличия от бэкапного образа. Хотя формально как бы две чушки на эн терабайт. При этом я конечно закладываюсь что btrfs меня не подведет в этой механике, но по другому undo на терабайтных файликах вообще сложновато. > Но правильные пацаны одно, а Шишкин - совсем-совсем другое, и issues там > пока совершенно unknown. Нехай другие по ним потопчутся, я, пожалуй, пешком постою. Ну вот я о чем. Может у этих сумасшедших гениев и есть интересные технологии, но от ФС важен набор свойств в целом. И некая вытоптанность поляны все-таки. > это как бы намекает, что авторы понимали, что для целостности данных он > вообще бесполезен, а проблему производительности собирались решать другим способом. Как-то так он и сделан. Быстрый в некоторых специфичных допущениях, если файлы огромные и разложить на несколько устройств правильно. Файлуха для редактирования нежатого видео в общем, чего еще от SGI ожидалось? :). А разлапистые иерархии с кучей мелочи например там не рулят. И фрагментированый торент может удаляться добрых 5 минут. Ну в общем работа с метаданными у них - довольно специфичная. И даже потуги редхата это подразогнать - подразогнали, но все-равно, довольно специфичненько. > нормальная скорость - если ты знаешь, для чего на самом деле этот > журнал и правильно все соберешь. "А если вот так посмотреть - вовсе даже и не кривой". Проблема в том что это такое красивое требует отдельного внимания и неприменимо ко многим конфигурациям. Ну вот например на моем лаптопе - 1 винч. Это данность. И соответственно я или кукую без нормального журнала, или получаю скорость записи грохнутую в 2 раза. А еще там бывают некие рабочие материалы и проч - сохранность данных там меня таки может колыхать и повыше среднего. Но с ext4 там нечего ловить. > надо -  ZIL под понятно какой fs и тоже понятно > что он собой представляет и какие есть особенности (а они есть) Ну а меня вот вполне устраивает что btrfs'ина сделает мне CoW и в общем случае запись будет однократной. А то что за это иногда где-то в фоне GC будет подгребать мусор - на удивление он тихий, мирный, проблем не создает. В каких-то специфичных ворклоадах наверное можно на проблемы нарваться, но для дба сделали nodatacow, а остальным вроде и так ок. В том числе мне и моей сра... кошке, простите, лаптопу, например. > в целом - в 2005м работала, дальше не тестировали. Вполне логично, но > опеннет, трудами неадекватов у руля, не место для лекций. Да я и без лекций переживу - я в состоянии принять для себя решения сам. И отдуться за них потом. Даже если ситуация окажется отличной от идеала.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	181. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от пох (?), 06-Дек-18, 18:26
	> Локалхосты локалхостами, а у меня довольно много всякой странной фигни, подвергающейся > странным приключениям и экспериментам. Если оно не сдохло - это хороший проблема в том, что твоих данных тоже никому не жалко, экспериментатор ты наш. А вот мне моих жалко, и я с ними не экспериментирую по этой самой причине. А на экспериментальных системах, увы, нельзя оценить надежность. > Оно происходит если эта штука нарвалась в процессе лопатинга тома на образ > диска с другим рейзером. После чего оно вкатит чужие структуры оттуда ну, не только. Впрочем, там тоже была похожая идея - найти на диске похожие  структуры и решить их употребить. Потому что от данных отличать не умели ;-) > У авторов амула оно вообще ничего не спрашивало - том перестал монтироваться > требуя fsck. При попытке fsck он был доломан окончательно и сервак говорят тебе - reiserfsck такого не делал. Его надо было специльно попросить, причем до этого где-то где работает прочитать документацию - на --help он предлагал быстро и качественно помочь всего лишь за $25 ;-) > При этом я конечно закладываюсь что btrfs меня не подведет в > этой механике, но по другому undo на терабайтных файликах вообще сложновато. ну она либо вся сдохнет, либо нечему подводить - данные -то не перезаписываются. > Ну вот я о чем. Может у этих сумасшедших гениев и есть > интересные технологии, но от ФС важен набор свойств в целом. И там разные гении. Ганс был гений как денег с бесплатного софта поиметь - по чуть-чуть, но на всех и без обид. А этот гений только в области код наплюхать, возможно интересный, но для внедрения нужно уметь с людьми, а вот этого-то без Ганса и нет. >> нормальная скорость - если ты знаешь, для чего на самом деле этот >> журнал и правильно все соберешь. > "А если вот так посмотреть - вовсе даже и не кривой". Проблема да нет, оно изначально для этой цели задумано. Журнал с данными, а не метаданными, изначально предполагалось класть на отдельный быстрый диск. По сей день рудименты сохранились (то есть создать такую ext4 можно, а насколько оно работает - не ведаю) >> надо -  ZIL под понятно какой fs и тоже понятно >> что он собой представляет и какие есть особенности (а они есть) > Ну а меня вот вполне устраивает что btrfs'ина сделает мне CoW и смысл zil (и data journaling) он немного в другом - быстро и с гарантией сообщить процессу об окончании записи, а на медленный основной стор перенести потом, когда будет время тихое. cow - он и в zfs такой же > Да я и без лекций переживу - я в состоянии принять для > себя решения сам. И отдуться за них потом. Даже если ситуация для этого надо хотя бы знать, для чего оно задумано и как должно использоваться. вот для btrfs понятно что задумали фигню, а сейчас пытаются приспособить к докерам и прочей иерархической муре - поэтому рефлинки как раз будут работать, а все остальное - может быть. А вот что думает redhat - я лично не понимаю.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	195. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 07-Дек-18, 18:02
	> проблема в том, что твоих данных тоже никому не жалко, экспериментатор ты наш. Насчет никому ты таки загнул. Вот конкретно мне их очень даже жалко. FAIL. > А вот мне моих жалко, и я с ними не экспериментирую по > этой самой причине. А на экспериментальных системах, увы, нельзя оценить надежность. Btrfs по состоянию на сейчас ровно настолько же экспериментальный как любая другая ФС в Linux. Как я это оценил? По характеру багов и фиксов, конечно же. Единственное исключение на этот счет разве что RAID56. > Впрочем, там тоже была похожая идея - найти на диске похожие   > структуры и решить их употребить. Потому что от данных отличать не умели ;-) Тоже здорово придумано. В любом случае, при отклонениях от идеала если я захочу увидеть мои данные с немонтируемого стоража (а судя по воплям народа оно так умеет) я пойду юзать их fsck, и когда толпа народа вопит что это не прокатило, том урыт, а другого plan B нет, мне это не нравится. В btrfs я таки выну rescue'ом данные в таком случае, и черт с ним с fsck. В конечном итоге меня больше интересует доступность моих данных, даже если ситуация по законам Мерфи вышла отличной от идеала. > говорят тебе - reiserfsck такого не делал. Его надо было специльно попросить, > причем до этого где-то где работает прочитать документацию - на --help > он предлагал быстро и качественно помочь всего лишь за $25 ;-) Ну как бы если у тебя том не монтируется - вариантов вынуть данные мало. Ты же не предлагаешь хексэдитором с немонтируемого тома самому вытаскивать? Это канительно и долго, вообще совсем-совсем last resort. Когда подвело все что может подвести, вплоть до сломавшегося под задницей кресла. > ну она либо вся сдохнет, либо нечему подводить - данные -то не > перезаписываются. И метаданные в случае btrfs'а. Собственно, это и позволяет попробовать в случае полного абзаца попытаться репарсинг с разных точек, пытаясь подцепить деревья с разных generation'ов. В каком-нибудь из них может оказаться относительно исправное - и вот вам ваши данные. Может и без изменений за последние полчаса. Но это лучше чем хэксэдитором с немонтируемого стоража вынимать. А поскольку оно при этом ничего не пишет в том - то если не прокатило, можно попробовать другие варианты, не запарывая при этом оригинал. > там разные гении. Ганс был гений как денег с бесплатного софта поиметь > - по чуть-чуть, но на всех и без обид. Да у него и по части ФС здравые идеи были, как впрочем и у разработчиков Reiser4. Но идеи идеями, а продукт продуктом. И таки концептуальной но хреново управляемой как продукт/фича ФС стремно и чревато свои данные отдавать. Интересно почему бы. > нужно уметь с людьми, а вот этого-то без Ганса и нет. Нужно вообще некое сбалансированное видение проекта. Это называется Project Management. Каждый солдат мечтает стать генералом. А каждый разработчик PM'ом. Но не любой солдат хороший стратег. И не любой разработчик хороший PM. И если Мэйсон как PM своей фичи для меня ОК, то вот про Шишкина я это сказать не готов. > да нет, оно изначально для этой цели задумано. Журнал с данными, а > не метаданными, изначально предполагалось класть на отдельный быстрый диск. И это как бы круто. Кроме того что на допустим ноуте (и типовом хомячьем десктопе) это работать не будет - за отсутствием отдельного устройства. И вот это вот - ФС совсем не украшает. Это ок для энтерпрайзников, но остальные пролетают. И наверное когда вот это принципиально у меня на лаптопе нормально не будет работать, я тебя не пойму в эстетстве про то что там для кого фэйсбук пиляет. Потому что вот это по отношению ко мне и моему лаптопу например еще хреновее. А игнорить этот юзкейс полагая что есть только энтерпрайзные хранилки - я таки не собираюсь. Потому что я этим пользуюсь и как я уже сказал, не собираюсь быть сапожником без сапог. > По сей день рудименты сохранились (то есть создать такую ext4 можно, а насколько > оно работает - не ведаю) Да и я тоже не ведаю - потому что специфичная конфига. Не под мои юзкейсы. И вообще, не скажу что я фанат подобной концепции. В CoW такие вещи как-то поизящнее обыграли, не грохая данные к тому же и без таких требований. По поводу чего я склонен считать CoW достатчно удачной идеей в целом. Хоть и с своими закидонами. > смысл zil (и data journaling) он немного в другом - быстро и > с гарантией сообщить процессу об окончании записи, а на медленный основной > стор перенести потом, когда будет время тихое.cow - он и в zfs такой же Тихое время - понятие абстрактное. Может быть а может и нет. Сан вообще свою штуку как-то специфично делал, по сути под файлохранилки под солярой на энтерпрайзном железе. А если у меня не это - опачки. И таки например мой ноут как-то совсем на это не похож. Вот вам 1 винч и извольте уж с ним как-нибудь вертеться. Когда создатели ФС подумали и о таких кейсах, мне это нравится. > для этого надо хотя бы знать, для чего оно задумано и как > должно использоваться. Несомненно. Однако это должно покрывать мои юзкейсы. Которые как-то совершенно не переклинены на энтерпрайзных хранилках. Иначе нафига оно мне такое? Я вообще не особый фанат огромных централизованных хранилок как парадигмы, это стремная и неудобная парадигма, как по мне. > вот для btrfs понятно что задумали фигню, а сейчас пытаются приспособить к > докерам и прочей иерархической муре - поэтому рефлинки как раз будут > работать, а все остальное - может быть. В случае btrfs - задумали более-менее универсальную файлуху, которая неплохо уместится от мелких устройств до умеренных энтерпрайзных хранилок. Неплохо работая в довольно разных конфигурациях. Это ясен хрен сложно. И довольны окажутся не все и не всегда. А рефлинки - там же рядом и снапшоты, например. И вообще cow. Рефлинки как таковые - частная манифестация возможностей cow и гибкой аллокации места. Так что можно несколько файлов сослать на одни блоки. А zfs вроде так и не умеет до сих пор, они там рассказывали что чего-то в их механике для этого не хватило и файлуху очень здорово переделывать надо. При том что дедуп оно как бы вроде даже делает - чисто по человечески очень странно что нельзя сделать такой вот захинтованый крупнооптовый дедуп сразу по факту нужды в нем :) > А вот что думает redhat - я лично не понимаю. "У нас разбежались спецы по файлухам и мы не смогли нанять новых, давайте заткнем амбразуру индусами - их у нас много". Обычная логика эффективного манагера вроде.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	206. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от пох (?), 08-Дек-18, 18:47
	> Btrfs по состоянию на сейчас ровно настолько же экспериментальный как любая другая я имел в виду - на своих экспериментальных. А то что жалко - лежит на ext4 hw raid1, да. (на не-экспериментальную zfs хранилку с нормальным быстрым подключением к потребителям, увы, не хватило денег и времени) > Тоже здорово придумано. В любом случае, при отклонениях от идеала если я > захочу увидеть мои данные с немонтируемого стоража (а судя по воплям > народа оно так умеет) я пойду юзать их fsck, и когда там, говорю же, были ньюансы. при мелких повреждениях все само восстанавливалось. При серьезных, и это обычно проблемы с hardware, а не просто неудачно выключили питание, иногда fsck помогал. Если он не помогал - то надо было набрать --help и следовать инструкциям, куда заслать $25. Потому что дальше уже нужно было понимание, как что работает, и какие последствия может иметь. (эх, sgreen, где ты? Крымнаш(или нам крыш),sun банкрот, а двадцатку я тебе все еще торчу) > plan B нет, мне это не нравится. В btrfs я таки > выну rescue'ом данные в таком случае, и черт с ним с если смонтируется и найдет там нужный срез ;-) > Ну как бы если у тебя том не монтируется - вариантов вынуть говорят же - дэнгы давай, ага. Они реально могли за эти деньги помочь - причем ты тоже понимал, что не ремонт провалов оплачиваешь, а продолжение разработки. >> там разные гении. Ганс был гений как денег с бесплатного софта поиметь >> - по чуть-чуть, но на всех и без обид. > Да у него и по части ФС здравые идеи были, как впрочем ну, в общем, вспоминая _тогдашнюю_ ext3 - очень даже здравые ;-) >> нужно уметь с людьми, а вот этого-то без Ганса и нет. кстати, я не прав, там не только в одном Гансе было дело. Тот же sgreen буквально заставил меня найти баг в net3 - который у разработчиков не воспроизводился. Хрен теперь таких разработчиков найдешь, даже за большие деньги :-( notabug, следующий. > И это как бы круто. Кроме того что на допустим ноуте (и > типовом хомячьем десктопе) это работать не будет - за отсутствием отдельного ну так в ноуте давно ssd, и в типовом десктопе гибридный диск (который ровно то же самое делает прозрачно для юзера) правда, когда накроется - опять таки никого не жалко. > Тихое время - понятие абстрактное. Может быть а может и нет. Сан > вообще свою штуку как-то специфично делал, по сути под файлохранилки под нет, он ее тоже вполне универсальную делал, файлохранилок как класса в те годы вообще еще не придумали. (то есть надо понимать, что у тех enterprize машинок только вес и занимаемые в стойке размеры выглядели круто, а производительности было примерно с мой атом, да и те scsi диски тоже были не лучше моих) > опачки. И таки например мой ноут как-то совсем на это не > похож. Вот вам 1 винч и извольте уж с ним как-нибудь > вертеться. Когда создатели ФС подумали и о таких кейсах, мне это все норм: last pid: 57245;  load averages:  0.37,  0.42,  0.41   up 194+17:43:19 18:24:39 23 processes:  1 running, 22 sleeping CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle Mem: 3888K Active, 19M Inact, 812M Wired, 144M Free ARC: 284M Total, 10M MFU, 161M MRU, 2080K Anon, 1340K Header, 110M Other Swap: 1024M Total, 40M Used, 984M Free, 3% Inuse, 4K In (нет, это я не меряюсь аптаймом, это я ядро там сломал и перезагрузить боюсь, а времени чинить нет и не предвидится) swap, понятно, не в zvol. одно ядро, один гиг оперативы, один мелко-сайтик - который, тем не менее, не дохнет, если гугл вдруг заглядывает на огонек. это не из-за острой любви к zfs, если что, а из-за works as intended в ufs. То есть там выбирать не из чего. Но, как видим, в целом - работает. > особый фанат огромных централизованных хранилок как парадигмы, это стремная и неудобная > парадигма, как по мне. это пока не приходится в этом ентер-прайсе работать. Тогда ты полюбишь хранилку, и будешь кирзовым сапогом хреначить любого, кто вздумает развести локальненькую помоечку (потом хомячок отрастает до размера носорога, становится бизнес-критикал, а потом наворачивается блок питания) > В случае btrfs - задумали более-менее универсальную файлуху, которая неплохо уместится ты историю-то хорошо знаешь? Задумали ее как "мы тоже могем zfs, только гепеле-гепеле". Вышел пшик. Потом, внезапно, подключился сам-хозяин-zfs (новый, понятно). Потом (поскольку ext4 уже было мучительно больно пользоваться) взялась suse (еще та, настоящая). Ну и энтузиастов нашлось, внезапно. Оно даже стало работать. Потом случился доцкер. Долго бредил трупом aufs, специально откопанным уже в совершенно гнилом гробу, написал две несовместимых версии оверлея, а как был kernel panic на kernel panic'е, так и остался. И тут опачки - btrfs умеет рефлинки, то шта нада! > А рефлинки - там же рядом и снапшоты, например. И вообще cow. ну вот у zfs оказались не рядом. > zfs вроде так и не умеет до сих пор, они там они типа их даже вроде бы соорудили в самой fs, но до юзерлевел дотянуть не хватило - причем что у орасана, что у zol. Ну а потом прибежал ошпаренный менеджер дельфикса с большой палкой - "что вы тут хренью маетесь, у меня тормозит!" и тему что-то забросили совсем. >> А вот что думает redhat - я лично не понимаю. > "У нас разбежались спецы по файлухам и мы не смогли нанять новых, они для этого купили цельный большой бизнес, что странно. Купить пару индусов из проекта zol было бы куда дешевле - но, похоже, боятся.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	216. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (216), 11-Дек-18, 18:53
	> я имел в виду - на своих экспериментальных. Вот уж нет. На компах с btrfs работается работа и лежат ценные данные, потери которых могут поставить меня на деньги или сделать жизнь сложнее. Самое ценное бэкапается, но отказ может вызвать срыв обязательств. Не в моих интересах. > А то что жалко - лежит на ext4 hw raid1, да. А смысл? Вернет один из сторажей мусор, а его примут за чистую монету, потому что чексум данных нет. Технически фирмварь может что угодно вернуть. В проводе данные могут побиться. При тестировании мусором crc и fec - лажа может и пролезть, когда объемы терабайтами а ошибки частые. Ext4 с raid от этого не поможет. И не факт что разрушения сразу заметно будет. А потом постепенно окажется что бэкапы битые. А вечное хранение всех бэкапов - не для всех. > (на не-экспериментальную zfs хранилку с нормальным быстрым подключением к потребителям, > увы, не хватило денег и времени) Оно сделано под узкие допущения. И поэтому принести счастье на, допустим, моем лаптопе - не способно. А энтерпрайзные железки - большие, тяжелые и прожорливые. Лаптоп из них фиговый. Тем кто хранит дофига - логично использовать что-нибудь распределенное, разнесенное в множество локаций. Так даже метеорит в датацентр ок: сервис не завалится, бизнес не встрянет. Наверное, по мере понимания этого и наработки алгоритмов сани и оказались понятно где. Оно как бы круто, но как бы золотой унитаз по сути. Дорого и бестолково. > При серьезных, и это обычно проблемы с hardware, а не просто неудачно > выключили питание, иногда fsck помогал. Когда разработчики ФС говорят что это чуть ли не by design - меня это несколько нервирует, чтоли. > Если он не помогал - то надо было набрать --help и следовать > инструкциям, куда заслать $25. Дарю идею: монтировать ФС первых полгода, а потом резко требовать $25. Шароварщики так и делают по жизни, кстати. > Потому что дальше уже нужно было понимание, как что работает, и какие > последствия может иметь. ИМХО, удачность tradeoff'а спорная. То что я себе с btrfs при нужде выну данные не сильно хуже разработчиков, кроме совсем странных случаев - пожалуй. А когда разработчику выгодно по деньгам чтобы ФС дохла... это стремно, на уровне причинно-следственных связей. Этак они еще специально баги лепить начнут, выгода же. > (эх, sgreen, где ты? Крымнаш(или нам крыш),sun банкрот, а двадцатку я тебе > все еще торчу) Ну вот сан и показал насколько всем надо суперхранилки по суперцене. Оракл даже за ценный актив это не посчитал. Ни соляру, ни zfs. Просто слили обоих. >> выну rescue'ом данные в таком случае, и черт с ним с > если смонтируется и найдет там нужный срез ;-) ФС не монтируется при этом, чудак. Сама утилса парсинг делает, как тирамисы и акронисы для фата и нтфс. Только платить не надо: штатная фича утилсов ФС. И вот это уже с прицелом на вытаскивание данных, может себе позволить странные вещи типа сканирования тома, и совсем иных приоритетов чем у драйвера ФС, который не может позволить себе 5 минут шариться в всех мыслимых generation'ах. > Они реально могли за эти деньги помочь - причем ты тоже понимал, > что не ремонт провалов оплачиваешь, а продолжение разработки. Получается что выгодно баги лепить, чтобы ФС рассыпалась. Стремная бизнес-модель. > Хрен теперь таких разработчиков найдешь, даже за большие деньги :-( notabug, следующий. Да ну фигня, я для амдшников git bisect делал несколько раз. А Ульрих из Редхата - явно не вчерашний персона. Так что как повезет, люди разные бывают. По эпохам это медленно меняется. > ну так в ноуте давно ssd, и в типовом десктопе гибридный диск У лично меня SSD в десктопе - потому что это задумано как высокопроизводительная конфигурация. А в лаптопе винч, потому что SSD маловато. Приемлимой емкости или TLC сыпучий, или стоит как самолет, на выбор. А второй девайс в ноуте некуда. Ну и SSD надежности явно не прибавит. Особенно дешевый TLC, достаточно на досуге почитать MTDшные рассылки линуксоидов, на предмет того что это из себя представляет. Ну и между нами, как там 9 женщин будут за месяц ребенка и что там в мифическом типовом лаптопе - в общем то не мои проблемы. Меня интересуют мои юзкейсы и чтобы с ними было оки-доки. > правда, когда накроется - опять таки никого не жалко. При том накроется менее предсказуемо, паттерны протирания не контролируемы, фирмварь и хардвар сложнее чем у SSD и HDD по отдельности, так что восстанавливать данные с гибрида - удачи, но это экзотика и лучше сразу искать хороших про. И готовить чемодан денег. Как-то так. > нет, он ее тоже вполне универсальную делал, файлохранилок как класса в те > годы вообще еще не придумали. Я не знаю что там "делали" но получилось не особо, с своеобразными требованиями и допущениями, за пределами которых резко terra incognita и хексэдиторы, как на лисяре. С отмазками что и не обещали. В btrfs на это посмотрели и изначально постарались быть более удобными, унивресальными и гибкими. Так что ноутам DUP метаданных на 1 носитель. Можно и данных, но надежность вырастет не столь радикально, а половину места изволь отдать. Для БД и VM с cow дисками - nodatacow есть, если долговременный перфоманс важен. Так что оно не только COW, но и in-place overwrite, если надо. Сторажи можно как добавить, так и изъять. И уровни избыточности не высечены в камне, можно на ходу переиграть. Снапшоты, которые суть cow'нутая иерархия (subvolume). Оно удобное. Ну или по крайней мере пытается быть таковым. Для меня это работает. > круто, а производительности было примерно с мой атом, да и те > scsi диски тоже были не лучше моих) У них допущения по обвесу, его свойствам, надежности и проч - другие. При их размере и весе там можно и пачку дисков засунуть. А вот в ноуте соображения размера и веса это исключают, например. А весь лейтмотив ZFS - факапы на блочном уровне "should never happen". А если все же ой - тогда вообще совсем ой. Без запасного парашюта на этот случай толком. И это ОЙ. > (нет, это я не меряюсь аптаймом, это я ядро там сломал и > перезагрузить боюсь, а времени чинить нет и не предвидится) А вот кстати говоря, лично я к внебрачным модулям ядра отношусь крайне негативно - потому что вечный источник проблем. Для меня есть майнлайн. Их политики и разработчики мне нравятся. А вот на всякие виртуалбоксы, зфсы и прочих нвидий это не распостраняется. Хотя-бы потому что потом с таким кернелом даже баг нормально не зарепортишь. Как максимум мне может хотеться какие-то мелкие кастомные самописный модули, но там я буду сам себе саппорт и в случае факапов - понятно на кого пенять. > swap, понятно, не в zvol. одно ядро, один гиг оперативы, один мелко-сайтик > - который, тем не менее, не дохнет, если гугл вдруг заглядывает на огонек. Да я не спорю, бывает и круче, типа как с опеннетом, где МегаКастомнаяКонфига, которую потом при развале не могут неделями поднять. Но со своей стороны я предпочту забыть такое администрирование как страшный сон. Потому что машины должны работать, а человек - думать (c) IBM. > это не из-за острой любви к zfs, если что, а из-за works > as intended в ufs. То есть там выбирать не из чего. Наверное бсда, судя по описанию. Потому и загибаются на пару - бенефиты неубедительны. > Но, как видим, в целом - работает. Мне Linux и его разработчики нравятся за то что они делают меня мощнее. С ними я ощущаю себя как те парни на летучем крыле. Запустил турбины и усвистал вверх, себе по кайфу. А с всем этим ветеран-юникс-энтерпрайзом ощущаешь себя шаманом занимающимся камланием, при том уже никто и не помнит почему это хорошо, "просто тут так принято". Как в том эксперименте с обезьянами, водой и бананами. > это пока не приходится в этом ентер-прайсе работать. А что значит "приходится"? Я не раб, к стойке с хранилкой не прикован, так что если я не захочу этим заниматься - фиг заставишь. Мной это воспринимается как что-то типа попыток гонять на почтовом дилижансе, с аргументом что раньше работало и инфраструктура отлажена. А почтовые грузовики и тем более авиапочта - от лукавого. > Тогда ты полюбишь хранилку, и будешь кирзовым сапогом хреначить любого, > кто вздумает развести локальненькую помоечку (потом хомячок отрастает до размера носорога, > становится бизнес-критикал, а потом наворачивается блок питания) Сапоги надо направлять в правильном направлении - на источник гемора. Поэтому если кто несколько веков назад завязался на почтовые дилижансы и никак не может перейти на грузовик - вот ему и врезать, может встряска мозги вправит чутка. Ну а штуки типа гуглей, фэйсбуков и твиттеров с уберами и прочие коины с этим не так уж плохо справляются. Так что если кто хочет на своем дилижансе рассекать, постепенно заметит что клиенты и сотрудники ушли к другим. Поэтому даже просто нового конюха нанять - приключение. > ты историю-то хорошо знаешь? Задумали ее как "мы тоже могем zfs, только > гепеле-гепеле". Мэйсон анализировал что есть вокруг, какие с этим есть проблемы и как бы их поизящнее обыграть. Понятно что философский камень - штука сложная. Но лично мне то что вышло пришлось по вкусу. > Вышел пшик. Worksforme, так что... > Потом, внезапно, подключился сам-хозяин-zfs (новый, понятно). Вообще-то сам-хозяин-zfs подключился еще до, и Мэйсон там и работал сначала, насколько я помню. А потом до кучи саней прибрал к рукам, в основном из-за явы и клиентуры. ZFS и соляра вышли дублирующими технологиями, которые к тому же надо целиком самому, это вам не линукс где можно у редхата все стырить и только напилить по патчикам, сделав вид что крутой работник. > Потом (поскольку ext4 уже было мучительно больно пользоваться) взялась suse (еще > та, настоящая). Ну и энтузиастов нашлось, внезапно. Оно даже стало работать. Для начала основы накатал сам Мэйсон, архитект этой штуки. И оно худо-бедно работало. Но, конечно, без легиона народа все предусмотреть не удалось и оно конечно же брыкалось в разных странных юзкейсах, о которых Мэйсон даже и не задумывался. Однако в целом брыкалось оно поменее других, особенно при таком то наборе фич. Если кто думает что может сравнимый набор фич, с соотношением грабель лучше - пусть покажет мастеркласс. > btrfs умеет рефлинки, то шта нада! Да оно и для виртуалок неплохо. Без всяких докеров. И вообще, отлично придумали фичу. У меня нет никаких докеров, что не мешает мне рефлинки наворачивать на иерархии в контейнерах и VMные диски-в-файле. > ну вот у zfs оказались не рядом. Да у них вообще много чего странного и странные допущения. Реально проектировали под суровый энтерпрайз, не смея даже на секунду думать о чем-то ином. В btrfs'е вот подумали - так что DUP для метаданных на лаптопе выручил. А в ZFS так вроде нельзя, они не настолько смело мыслили на предмет гибкости аллокатора. > они типа их даже вроде бы соорудили в самой fs, но до > юзерлевел дотянуть не хватило - причем что у орасана, что у zol. И это как раз очень странно - потому что онлайн дедуп с диким жором ресурсов оно даже умеет же, а hinted дедуп, когда заранее явно задекларено что ВСЕ блоки - дупы, так что ресурсы на отлов дупов тратить и не надо - почему-то нельзя?! Чудеса да и только. > Ну а потом прибежал ошпаренный менеджер дельфикса с большой палкой > - "что вы тут хренью маетесь, у меня тормозит!" и тему что-то забросили совсем. Да с чего ему быть быстрым то? Как я понимаю оно даже на экстентный дизайн тянет весьма условно. Там блоки переменного размера есть, но пойнт экстентов - в том чтобы мелкий регион метаданных адресовал кучу данных. Это улучшает соотношения и разгоняет ФС. Но в ZFS видимо преследовали какие-то иные цели. Или черт их там разберет. "Я его слепила из того что было". Мэйсон лепил позже - и поэтому смог в нормальные экстенты. Не хуже чем у других вроде. >> "У нас разбежались спецы по файлухам и мы не смогли нанять новых, > они для этого купили цельный большой бизнес, что странно. Чего они купили по файлухам? Явно не опенсорсное и вообще, XFS и так был, нафиг чего-то покупать? Что это дает то и кому? Ну и лично я не доверяю всяким скупкам и вываливанию в опенсорц. Это на моей памяти сработало 1 раз - в случае Google и утиной компании. Но там извините вопрос на миллиард, всех приперло, гугл умел пиариться, услышал просьбу FSF и сотоварищей и таки сделал ровно то что опенсорсники просили. Но такое сочетание факторов бывает раз на миллион. А в случае редхата ситуация немного не та чтобы все безальтернативно цеплялись за почему-то XFS с менеджментом на пыхтонрасте поверх lvm и проч. > Купить пару индусов из проекта zol было бы куда дешевле - но, похоже, боятся. Скорее, имеючи легион нормальных ядерных разработчиков понимают бессмысленность этого процесса. Вне ядра оно как таковое не жилец. Шапке и так думаю хватает с бэкпортами на свое чудо-ядро. Врядли они добавки хотят. Это не изменится - оракл заклятый друг редхата, делать удобно редхату не будет. Да и за столько лет все-равно большинство спецов поразбежалось из оракла кто куда. И как с футболистами, чтобы всю команду скупить и клуб сменить не сработает, имхо. Даже если теоретически допустить что оракл и редхат забьют на разборки и смогут взаимовыгодно договориться.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	223. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 22:44
	>> я имел в виду - на своих экспериментальных. > Вот уж нет. На компах с btrfs работается работа и лежат ценные Всё, что вам надо знать о 294-ом >> А то что жалко - лежит на ext4 hw raid1, да. А потом постепенно окажется что бэкапы > битые. Третий тип сисадмина
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	224. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (224), 16-Дек-18, 02:53
	> Всё, что вам надо знать о 294-ом Как я уже сказал - я изволю использовать то что изволю упоминать, в отличие от титиретиков с NT6 и крутым юниксвеем и прочего сброда. Так что покупаясь на мои сообщения можно быть уверенным что я хотя-бы примерил шапку на себя, в отличие от расхваливающих юниксвеи из винды. > Третий тип сисадмина На самом деле я проверяю бэкапы ценных данных. И таки есть несколько версий. Корпоративщики меня таки подучили основам как это делать правильно. Так что для меня не характерно терять данные. Я наоборот иногда развлекаюсь тем что достаю некоторым линуксоидам их добрецо с полудохлых винчей.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	27. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
	Сообщение от пох (?), 05-Дек-18, 11:45
	не, ну на атоме с двумя запаянными гигами и 80G ssd прошлого века - я уверен, не нужны. ext2 will be enough
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	39. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним (38), 05-Дек-18, 12:42
	Как минимум чексуммы сильно помогают.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	76. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от ааа (??), 05-Дек-18, 16:25
	Они есть и в XFS, так-то.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	77. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним84701 (ok), 05-Дек-18, 16:27
	> Как минимум чексуммы сильно помогают. Авторитеты > 17.02.2015 17:48  Выпуск systemd 219 с поддержкой расширенных возможностей Btrfs утверждают, что там даже error correction есть ;) https://lists.freedesktop.org/archives/systemd-devel/2015-Fe... > Lennart Poettering lennart at poettering.net > Wed Feb 18 02:07:38 PST 2015 [...] > But btrfs checksumming cannot fix things for you either if you lose non-trivial amounts of data. It might be able to fix a few bits of errors, but not non-trivial amounts. I mean, that's a simple property of error correction codes: the more you want to be able to correct the longer must your checksum be >
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	126. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 08:19
	Ух, да, если метеорит попадет в твой сервак - RAID тебе от этого никак не поможет. Потому что масштаб проблемы превышает корректирующие способности схемы.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	163. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним84701 (ok), 06-Дек-18, 14:17
	> Ух, да, если метеорит попадет в твой сервак - RAID тебе от  этого никак не поможет. Потому что масштаб проблемы превышает корректирующие способности  схемы. А если сервак поставить в бузину на огороде? Там контекст -- Лео Великолепный сделал очередную оптимизацию (выпуск "systemd 219 с поддержкой расширенных возможностей Btrfs") : > > > On 2015-02-16 23:59, Lennart Poettering wrote: > > > >         * journald now sets the special FS_NOCOW file flag for its > > > >          [...] It degrades btrfs' data integrity guarantees for the files to the same levels as for > > > >           ext3/ext4 however. This should be OK though as journald does its own data integrity checks and all its objects are Его спрашивают: >> Zbigniew Jędrzejewski-Szmek: >> btrfs checksumming theoretically allows you to transparently recover after media corruption if filesystem has redundancy (more than one copy of data). Journald checksum will probably detect corruption, but can it repair it? Т.е. "btfs проверки целостности позовляют прозрачно восстановить данные, если есть копия, позволяет ли journald провернуть такое же" На что следует ответ: > [Lennart] No it cannot. > But btrfs checksumming cannot fix things for you either if you lose non-trivial amounts of data. It might be able to fix a few bits of  errors, but not non-trivial amounts. I mean, that's a simple property of error correction codes: the more you want to be able to correct the longer must your checksum be. Neither btrfs' nor journald's are substantial enough to correct even a sector... И тут номерному анониму становится резко непонятно: https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_fu... > Currently Btrfs uses crc32c for data and metadata. то ли вика БТРФа не отображает реальность, то ли номерной аноним что-то фатально не понимает, то ли Лео Великолепный поступил в лучших традициях опеннета -- с умным видом <эт самое>. Что в исполнении главного/ системного разработчика повсюду встраиваемой компоненты, как минимум стремновато.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	18. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним (18), 05-Дек-18, 11:17
	Ну или на Шишкина обратить внимание.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	67. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
	Сообщение от Аноним (-), 05-Дек-18, 15:32
	> Ну или на Шишкина обратить внимание. Лучше не обращать, потому что его "недостатки" высосаны из пальца, типа забития файлами ФС размером с сидюк. И что хуже - ничего взамен благородный дон не предлагает. Нет, теоретически у него конечно reiserfs4 есть, но вот он протестирован вообще никем и никак, лагает в портировании на актуальные ядра, в третьем рейзере вообще фича вида "fsck может убить ФС". Портировали ли это в 4-й - проверять на своих данных почему-то совсем не хочется. А при такой протестированности ФС как у Шишкина - чего доброго придется.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	33. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от псевдонимус (?), 05-Дек-18, 11:53
	Избавление от головной боли методом отрубания головы?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	71. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от SysA (?), 05-Дек-18, 15:55
	Пока в БТРе не будет нормального multipath'а делать ему в производстве нечего!
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	78. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от пох (?), 05-Дек-18, 16:29
	> Пока в БТРе не будет нормального multipath'а делать ему в производстве нечего! md0 : active multipath sdb[0] sdc[1] sdd[2]       83824870 blocks super 1.2 [2/2] [UU] /dev/md0 /srv btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 не вижу проблемы. У воспетого xfs точно такой же "multipath".
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	95. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 18:31
	По линии btrfs'а тут фокус в том что админить его в результате не проще XFS'а с md. А по задумке должно бы быть поприятнее. Собссно пойнт btrfs всегда был в том что в нем даже продвинутые конфигурации рулить достаточно просто и логично. Ну вон там сейчас например даже снапшоты можно стирать как диры стало. Собственно subvolume всегда были этакими дирами на стероидах, в свежих ядрах их стало можно стирать вообще совсем как диры. Что логично.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	103. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 05-Дек-18, 22:09
	> По линии btrfs'а тут фокус в том что админить его в результате > не проще XFS'а с md. с чего вдруг? md этот создается один раз и работает вечно, его трогать вообще больше не надо. > А по задумке должно бы быть поприятнее. ну если тебе в принципе нравится синтаксис btrfs - то поприятнее, поскольку все в одном месте, а не отдельно fs, отдельно lvm, в двух разных ипостасях, снапшоты там, свободное место сям, кто на ком стоял поди разбери, и кого чинить если отвалится, тоже. в общем, не вижу особых проблем у такой конфигурации, кроме сомнений в надежности обоих ее компонент. Но в случае xfs + lvm сомнений не меньше.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	115. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 05:16
	> с чего вдруг? md этот создается один раз и работает вечно, его > трогать вообще больше не надо. Половина пойнта btrfs - в том что нет этой фиксации навечно как в более обычных RAID. И можно переиграть все под текущие нужды, на лету. Если они изменились - то и ФС можно подрихтовать. Плавно и без ухода в аут. А рулить им как XFS'ом/EXT4/... - работает, конечно, но... > ну если тебе в принципе нравится синтаксис btrfs - то поприятнее, поскольку > все в одном месте, а не отдельно fs, отдельно lvm, в > двух разных ипостасях, снапшоты там, свободное место сям, кто на ком > стоял поди разбери, и кого чинить если отвалится, тоже. А еще фичи логично интегрированы. Снапшоты неплохо ложатся на механику ФС. А файлуха нормально относится даже к тому что половина стоража в одном формате райда, а половина в другом. И все это можно гибко переигрывать по ходу дела. Допустим решил некто RAID5 вместо зеркала сделать. Доткнул третий диск. Запустил конверсию. Файлуха продолжит работать пока рестрайпер жует блоки. И даже в случае облома - оно просто продолжит конверсию дальше. Механика нормально относится к тому что здесь и сейчас часть блоков в RAID1, а часть в RAID5. На самом деле оно нормально отнесется даже к тому что разные файлы или subvolume - с разными уровнями RAID. Когда заходит вопрос о метаданных оно может к ним ДРУГУЮ схему избыточности применить, опять же. И, ясен фиг, это требует именно плотного взаимодействия на стыке файловых операций и блочного уровня. У btrfs'а файлуха на самом деле принимает решение какие chunk-и выбрать под схему хранения нужную для вот этой вот записи вот этого вот добра - и пытается это изыскать на девайсах с свободным местом. Это позволяет расширить стораж просто подоткнув еще 1 девайс, совершенно не парясь. С точки зрения балансировки нагрузки - ребаланс потом может и иметь смысл сделать, но это наглухо опционально. Файлуха просто возьмет в оборот свободное место на девайсе(ах) и покуда на других девайсах было свободное место, оно без проблем скроит запрошенную схему хранения. А вот как например расширить классический RAID, допустим, 5 после дотыкания в него 1 диска, без полного рестрайпа всей штуки, как абсолютно MANDATORY операции, к тому же исключающую нормальное использование пула на момент рестрайпа... мне почему-то кажется что индусня из редхата с их пихтонрастом вот эту вот часть системной магии ну вообще совсем никак не осилит. Потому что это уже не про маркетинговый булшит, а про awareness ФС и ее работы с низким уровнем относительно желаний более высокого уровня. Этот awareness в обычном RAID как раз аккуратно грохается уровнями абстракций и нагоном дешевой индусни с пихтонрастом и громким маркетингом все это НЕ ЛЕЧИТСЯ. > в общем, не вижу особых проблем у такой конфигурации, кроме сомнений в > надежности обоих ее компонент. Но в случае xfs + lvm сомнений не меньше. Я бы очень не хотел пытаться отколупать XFS с какого-нибудь RAID56, под LVM, да еще с снапшотом и менеджментом на пихтонрасте делающем со всем этим фиг знает что. Хотя-бы потому что индусня с пихтонрастом потом даже сказать не сможет - что мне с этим пулом вообще делать...
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	142. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 10:52
	> Хотя-бы потому что индусня с пихтонрастом потом даже сказать не сможет - что мне с этим пулом > вообще делать.. выкрасить и выбросить, чего еще - ровно как и с грохнувшимся за пределы штатных возможностей автовосстановления btrfs. Который вот грохнется первым - надо в каждом случае уточнять, потому что это не к качеству проекта, а к качеству кода в конкретных местах. Который писали может и хорошие, но немного затраханные программисты, причем пяти разных команд каждый.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	173. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 17:46
	> выкрасить и выбросить, чего еще - ровно как и с грохнувшимся за > пределы штатных возможностей автовосстановления btrfs. Ну дык в случае btrfs я из него выну данные rescue'ом, если вдруг с бэкапами вышла лажа. А вот то что я смогу этот фокус-покус с кучей пихтонрасии поверх xfs + lvm, и что меня не подведут тулсы, особенно в нестандартной ситуации, я мягко говоря не уверен. Пусть это как-нибудь клиентура редхата проверяет, имхо. > Который вот грохнется первым - надо в каждом случае уточнять, потому что это не к качеству > проекта, а к качеству кода в конкретных местах. Который писали может > и хорошие, но немного затраханные программисты, причем пяти разных команд каждый. Качество кода не есть константа по времени. Поляна вытаптывается. А кроме этого есть еще взаимодействия между компонентами. И вот с этой точки зрения мне пихтонрасия и не нравится. Мой опыт подсказывает мне что вот там у пихтонрасии полный швах. А когда какой-нибудь индус в своем питоне как обычно забьет на статус операции - рапидно все же разрабатывают не для того чтобы глупые статусы операций на ощибки проверять, это потом довольно дорого обойтись может в вот конкретно таком применении. Чтобы было совсем ЗБС, компоненты как таковые довольно независимые, слабо интегрированы, друг о друге ничего не знают и наверняка будет много технически возможных но логически некорректных комбинаций, которые можно отпедалить, а потом здорово об этом пожалеть. Если к вам вылетает мужик с хексэдитором первым самолетом - это в принципе переживаемо. А если рисуется перспектива самому этим мужиком быть - тогда я отгибаю средний палец в адрес редхата и пихтонрасов.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	170. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от SysA (?), 06-Дек-18, 16:07
	XFS - это просто FS, но БТР претендует еще и на функции и LVMa, и RAIDa, декларируя оптимизацию и повышения работы с дисками напрямую, но при этом не поддерживая multipath, т.е. надежный доступ к данным! Нонсенс! А приведенный тобой костыль как раз-таки и кастрирует БТР, превращая его также просто в FS. Где тут профит?! При этом он все равно очень плохо работает с операциями типа rsync, git и svn при больших объемах данных и при большом числе файлов. Поэтому мы его выпилили на серверах разработчиков. При относительно небольших объемах (несколько терабайт) Ехт4 вполне себе справляется. XFS ставил там, где от нескольких десятков тер до петабайт и множестве больших (сотни гиг) файлов...
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	183. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 18:39
	> А приведенный тобой костыль как раз-таки и кастрирует БТР, превращая его также > просто в FS. Где тут профит?! При этом он все равно профит что очередь можно раскидывать по разным каналам, а если обезьяна наступит на опту - все еще останется вторая. Какого еще профита тебе нужно? Кусок md отвечающий за это - банальный перебрасыватель указателей на блоки в очереди, он не вносит ни лишних проблем, ни лишних накладных расходов. > Ехт4 вполне себе справляется ext4 плохо справляется с докером, заменяя рефлинки и сабвольюмы кривым overlayfs, да и просто неэффективна при больших объемах записи.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	16. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+2 +/–
	Сообщение от Аноним 80_уровня (ok), 05-Дек-18, 11:15
	Для себя считаю, что xfs — FS выбора в течение последних почти пятнадцати лет.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	20. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от вейланд (?), 05-Дек-18, 11:30
	Xfs не умеет уменьшаться. Вот так разбил жестак, через годик решил поменять разбивку - а хрен тебе. Так что только jfs, только хардкор.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	22. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от ryoken (ok), 05-Дек-18, 11:36
	Напарывался на сие ровно 1 раз, решил пертаскиванием системы на более объёмистый винт+ допразделы, для которых хотел уменьшать XFS. Мораль сей басни такова: ещё более тщательно планируйте разбивку\FS с заделом на не очень далёкое будущее :D.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	31. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним 80_уровня (ok), 05-Дек-18, 11:52
	Для меня неактуально, поэтому и написал "считаю для себя". На край для переразбивки всегда есть бэкап на ленту или ещё куда.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	149. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от вейланд (?), 06-Дек-18, 11:57
	> Для меня неактуально, поэтому и написал "считаю для себя". > На край для переразбивки всегда есть бэкап на ленту или ещё куда. Одобряю ваш выбор.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Stax (ok), 05-Дек-18, 12:47
	jfs прикольная, но незаслуженно забытая. Но проблема у нее все-таки была: фрагментация со временем копилось что-то сильно. Вроде и экстенты есть, но почему-то через годик-другой эксплуатации реально тормозить начинало. Возможно даже не сами данные, а метаданные по большим файлам фрагментировались, либо может кэширование метаданных и записей каталогов хуже работало, чем в ext2/3/4. В общем, не очень приятный эффект, особенно на многодисковых рейдах.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	70. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:42
	> jfs прикольная, но незаслуженно забытая. В ней просто нет ничего интересного. Обычная файлушка. Довольно слоупочная. Продвинутости по целостности данных не умеет, дефрага нет, reflinks нет, ну и в целом - оно как бы работает. Но как бы единственный реальный плюс - мизерная нагрузка на проц. Аргумент только для винча в usb роутера с хилым процом, разве что - качать на него торенты какие. Для всего остального можно ФС получше подобрать. > со временем копилось что-то сильно. Вроде и экстенты есть, но почему-то > через годик-другой эксплуатации реально тормозить начинало. Да он и изначально по скорости звезд с неба не хватает. > Возможно даже не сами данные, а метаданные по большим файлам фрагментировались, Он вообще с метаданными работает не сказать что сильно быстро. > приятный эффект, особенно на многодисковых рейдах. Да он и на однодисковых конфигах далеко не чемпион по скорости. Вообще ни в какой из номинаций. При том если какому-нибудь btrfs это можно простить за фичи то тут это нечто типа ext4 тормознутого. Даже хуже, если по фичам.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	162. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Stax (ok), 06-Дек-18, 13:49
	>> Возможно даже не сами данные, а метаданные по большим файлам фрагментировались, > Он вообще с метаданными работает не сказать что сильно быстро. Это не так, изначально он по любым таким операциям обгонял ext3, и был сравним с xfs при большей надежности в условиях риска отключения питания. Я вообще никогда не видел никаких глюков и проблем с jfs, он железно стабильный. >> приятный эффект, особенно на многодисковых рейдах. > Да он и на однодисковых конфигах далеко не чемпион по скорости. Вообще > ни в какой из номинаций. При том если какому-нибудь btrfs это > можно простить за фичи то тут это нечто типа ext4 тормознутого. > Даже хуже, если по фичам. jfs был актуален во времена ext3. Тк reiserfs была та еще какаха, которую везде стали выкидывать после появления ext3 (ну, кроме суси :P), а xfs в то время мог устроить очень сильные глюки при некорректном отключении - обнуления файлов, неудаляемые записи в каталогах, рандомные имена и прочее. jfs был надежнее и лучше, чем ext3 на больших разделах (на малых, понятно, хватало ext3). Изначально на таких я заводил xfs, но увидев несколько очень неприятных проблем перевел все на jfs. И везде, где использовался jfs, не было ни одной проблемы, кроме фрагментации метаданных (или чего там) по истечении приличного времени. А когда ext4 стал полностью оттестирован и пригоден для использования и на системных разделах, появился смысл и большие с jfs на него перевозить. Т.к. преимуществ у jfs перед ext4 особых то и нет, в том числе по скорости ext4 подтянулся (https://www.opennet.dev/opennews/art.shtml?num=29877)
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	178. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 18:20
	> Это не так, изначально он по любым таким операциям обгонял ext3, Ну так правильно, у jfs какие-никакие экстенты есть. А ты с ext4 сравни, чтоли, чтобы уж набор технологий более-менее одинаковый. > и был сравним с xfs при большей надежности в условиях риска отключения питания. Я бы назвал эту ситуацию так: и та и другая штуки умеют тупить в работе с метаданными, просто они это делают по разному. У jfs производительность по метаданным заурядненькая всегда и везде. У XFS сильное место работа с большими файлами, если правильно разложить. А если туда вместо этого какой-нибудь линуксный кернель распаковать, сорцом, файлуха для работы с нежатым видео от SGI не очень хорошо ворочает то что на это не похоже. > Я вообще никогда не видел никаких глюков и проблем с jfs, он железно стабильный. Кроме того что опять же это классика. С in-place переписыванием файлов и - отсутствием полного журнала в этом процессе. И если вдруг питалово слетит когда файл наполовину старый и наполовину новый - ХАХА! На этот случай нет вообще совсем никакого плана. Есть файл из старой и новой половинок, что хотите с ним то и делайте. Такая забота о сохранности данных, когда журнал только для метаданных. > jfs был актуален во времена ext3. В этом собственно его проблема. EXT4 сделал его малоинтересным. > заводил xfs, но увидев несколько очень неприятных проблем перевел все на > jfs. И везде, где использовался jfs, не было ни одной проблемы, > кроме фрагментации метаданных (или чего там) по истечении приличного времени. У меня как бы были и xfs и jfs. Немного xfs даже осталось, но в целом я большинство добра на btrfs перетащил. За удобство в управлении, расширяемость, и полезные мне фичи. > А когда ext4 стал полностью оттестирован и пригоден для использования и на > системных разделах, появился смысл и большие с jfs на него перевозить. Ну так и я о чем. EXT4 на мой вкус пошустрее на обычном компе в типовых сценариях. И опять же умеет побольше фич на разные случаи.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	148. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от вейланд (?), 06-Дек-18, 11:56
	Jfs так устроена, да. Я вот ей пользовался на ssd, там этр незаметно.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	179. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 18:21
	> Jfs так устроена, да. Я вот ей пользовался на ssd, там этр незаметно. Btrfs прикольнее. Можно снапшотами баловаться. Так что если система дохнет - откатил на исправный, да поехал дальше. А рояль с 20 этажа как бы и не падал на нас в этой версии вселенной.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	29. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 05-Дек-18, 11:46
	вы просто не видели ее крэшей. Я вот для себя не могу решить, можно ли ей + lvm хотя бы сейчас-то пользоваться, или проблема в любой момент проявится снова.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	30. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним 80_уровня (ok), 05-Дек-18, 11:49
	Не видел, именно поэтому так и считаю. А ext (включая и ext4) за это же время валились не раз и даже не два.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	36. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним 80_уровня (ok), 05-Дек-18, 12:03
	Насчёт LVM хорошей статвыборки у меня нет — единственная машина с xfs на LVM поверх софтового RAID5, года четыре без проблем, тьфу-тьфу.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	43. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Crazy Alex (ok), 05-Дек-18, 12:53
	Да это у человека травма какая-то lvm + xfs - это давний рекомендованный сетап редхата, соответственно пашет оно прекрасно.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	52. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+2 +/–
	Сообщение от Минона (ok), 05-Дек-18, 14:35
	давний?! емнип, в дефолте она с 7-й сентоси идет, в 6-й её (xfs) даже в исталляторе нету.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	196. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Crazy Alex (ok), 07-Дек-18, 18:21
	с 14го года. Более чем достаточно, я бы сказал.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	220. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 11-Дек-18, 20:08
	> Да это у человека травма какая-то lvm + xfs Учитывая сколько данных протер народу нулями XFS - его так себе репутация по этому поводу не то чтобы на ровном месте.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	80. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 05-Дек-18, 16:36
	> Не видел, именно поэтому так и считаю. > А ext (включая и ext4) за это же время валились не раз > и даже не два. у меня xfs (без lvm под ней, что, в общем, проблема отдельная - снапов нет, управления стором нет, чего ни хватишься, из положенного современным fs, ничего нет) валилась сотни. Просто вот в рутинном режиме - упало, не поднимается, reinstall. А ext4 - ну да, не раз, и не два, а может даже целых пять, и то каждый раз восстанавливалась. про ext3 не надо, это был полный беспросветный п-ц, до появления barriers и log integrity checks. Гугль ПЯТЬ лет самостоятельно поддерживал полумертвую ext2, чтобы не переходить на это убожище (обычной 2 пользоваться обычному смертному тоже было нельзя, как из-за вшитых ограничений так и из-за "мы тут опять massive filesystem corruption поправили, но только в 3, до 2 как-то руки не дошли пока", несколько раз).
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	89. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (86), 05-Дек-18, 17:59
	> у меня xfs валилась сотни. Это скорее говорит об использованном вами плохом оборудовании, нежели об xfs. Если диск говорит SYNC OK, а там не ОК то ФС вам тут не поможет.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	96. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (-), 05-Дек-18, 18:38
	Ну а вот btrfs фиговое оборудование по крайней мере делает заметным, воплями про сбой чексум. И это лучше чем если заметить сие по порушеным файлам.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	214. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от пох (?), 10-Дек-18, 11:09
	не, ну kernel panic-то ты точно заметишь, в отличие от воплей где-то там в логах, но что-то мне подсказывает, что супермикровские железки с hotplug backplane и ecc памятью не настолько фиговое оборудование, и тем более вряд ли эта фича works as intended.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	221. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 11-Дек-18, 20:11
	> не, ну kernel panic-то ты точно заметишь, в отличие от воплей где-то там в логах, Да ну его в пень, предпочитаю менее бурную реакцию. > hotplug backplane и ecc памятью не настолько фиговое оборудование, и тем > более вряд ли эта фича works as intended. А смысл передо мной пальцы растопыривать? SATA, особонно eSATA хотплаг уж сто лет, ECC у меня в десктопе есть. Так что п0нт фичами получился какой-то на редкость не энтерпрайзный в этот раз. Это все можно и на ширпотребе уже.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	102. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 05-Дек-18, 21:58
	> Если диск говорит SYNC OK диск ничего не говорит - xfs говорит kernel panic, приехали. Заметьте, не "диск подсунули хреновый, remount ro", а просто "шито-то хреново мне, давайте на всякий случай panic!". Или молча висла (реже). После ребута требуется ручное восстановление, поэтому систему просто переустанавливали.  Причем ничего, кроме записи логов, эти диски особо и не нагружало, не сказать чтоб особо тяжело она пахала. а "плохое оборудование", конечно же, само собой чудесным образом стало хорошим, как только эту странность заменили на ext4.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	63. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
	Сообщение от Адекват (ok), 05-Дек-18, 15:20
	да-да, там все хорошо, пока не начнет магическим образом исчезать свободное пространство, помогает только утилита ***xfs*** вместо звездочек что-то там. Реально разница между df -h и du -sh / показывала 10Gb
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	72. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 05-Дек-18, 16:16
	> да-да, там все хорошо, пока не начнет магическим образом исчезать свободное пространство, > помогает только утилита ***xfs*** вместо звездочек что-то там. Реально разница между > df -h и du -sh / показывала 10Gb имя сестра, имя - в смысле, на какой версии чего у тебя такое происходит? И насколько часто - один раз - не п-с?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	83. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Andrey Mitrofanov (?), 05-Дек-18, 17:00
	>> да-да, там все хорошо, пока не начнет магическим образом исчезать свободное пространство, >> помогает только утилита ***xfs*** вместо звездочек что-то там. Реально разница между >> df -h и du -sh / показывала 10Gb #>> du -sh / > имя сестра, имя - в смысле, на какой версии чего у тебя Да,  /var/log он почислил, а апач, сислог и проч.шатию-братию, держащую удалённый лог на добавление, -- не-по-пере-запускал. Вангую: версия -- любая! > такое происходит? > И насколько часто - один раз - не п-с?
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	123. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Адекват (ok), 06-Дек-18, 06:46
	Арч линукс... было это 8 января 2018 последний раз, после этого я съехал на минт и ни разу не пожалел (думаю, чтобы съехать на семерку, но комп мне дома нужен крайне редко и только для браузеров и музычки - вот сижу и думаю...). Проявлялось это в том, что при выключении из системы исчезало от 30 до 60 Мегабайт свободного места, раздел был 250Гб, рано или поздно место заканчивалось, df -h говорил, что осталось скажем 500Мб свободного места, du -sh / говорил, что свободного места 13Гб (примерно). xfs_repair решало проблему. Если систему загасить кнопкой ресета - проблема не проявлялась, возможно, что проблема как-то связана с журналом от системД (но не факт). Всех подробностей не помню.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	68. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним (-), 05-Дек-18, 15:32
	> Для себя считаю, что xfs — FS выбора в течение последних почти > пятнадцати лет. Ужасно слоупочный по метаданным. Все 15 лет к ряду.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	106. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от Аноним (106), 05-Дек-18, 23:09
	Всем хороша xfs, если бы не приколы с внезапно пустеющими файлами при включении питания. Я этот баг помню ещё со времён первых патчей в ядро для поддержки xfs. Баг упорно жил и портил людям жизнь почти 13 лет.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	132. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 08:49
	> Всем хороша xfs, если бы не приколы с внезапно пустеющими файлами при > включении питания. Я этот баг помню ещё со времён первых патчей > в ядро для поддержки xfs. Баг упорно жил и портил людям > жизнь почти 13 лет. А вы злопамятный. Баг починен аж в 2.6.28 :). Хотя о приоритетах разработчиках в вопросах сохранности данных, он, конечно, намекает.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	167. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 15:11
	в ext3-4 до появления barriers (через пять, что-ли, лет?) был точно такой же.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	180. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 06-Дек-18, 18:24
	> в ext3-4 до появления barriers (через пять, что-ли, лет?) был точно такой же. Нет, ну нули в файлы "по соображениям безопасности" он все-же специально не записывал. А XFS специально протирал спорные области нулями. Чтобы после краха левый юзерь чужие данные не уволок бы. Это, конечно, по своему оригинальное мышление авторов файлухи, но на практике в результате у народа после крахов и слетов питания файлы содержали подозрительно много нулей и это им почему-то не нравилось. Наверное потому что файлики работать от этого очень уж переставали.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	186. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от пох (?), 06-Дек-18, 22:31
	> Нет, ну нули в файлы "по соображениям безопасности" он все-же специально не записывал. он вообще ничего не записывал - просто truncate им делал. "мы же вам сохранили консистентность метаданных, как вы просили" ;-) работали они от этого как-то тоже не очень хорошо.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	222. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 11-Дек-18, 20:18
	> он вообще ничего не записывал - просто truncate им делал. "мы же > вам сохранили консистентность метаданных, как вы просили" ;-) Он таки вроде шел чуть дальше и еще и явно протирал нулями все спорные фрагменты. С аргументом "чтобы левый пользователь не спер ваши данные даже так". Поэтому он был даже несколько более деструктивен чем остальные. > работали они от этого как-то тоже не очень хорошо. Это касается любой "классической" ФС без полного журнала. Если запись в файл началась, но не заверщилась - то чего? Информации чтобы ее завершить или откатить нигде нет - журнал это только для метаданных делал. А данные в результате наполовину новые и наполовину старые. Без возможности откатить транзакцию или довести ее до финиша. Но в метаданных все ЗБС, как бы файл, как бы нормального размера. А содержимое никто и не обещал. CoW в этом несколько мухлюет, делая по сути всю площадь журналом и избегая второй записи. Вместо этого ему для отката достаточно по сути просто забить на то что новее энного момента - получается предыдущее состояние. Реально конечно чуть сложнее и еще GC надо, иначе, если хранить все изменения вечно - в множестве реальных сценариев место кончится за обозримое время и будет FAIL.
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	26. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от igroeb (?), 05-Дек-18, 11:42
	ZFS
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	56. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от 4.4 (?), 05-Дек-18, 15:04
	Ред хат сказал xfs значит будет xfs.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	69. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 15:34
	> Ред хат сказал xfs значит будет xfs. И менеджмент к нему на пихтонрасте, с lvm, пытающийся изобразить из этого эрзац-подобие btrfs/zfs. Кушайте не обляпайтесь. Правда что там сделают корпоративные индусы - вы наверное догадываетесь. И если не дай боже у вас нет упса и генераторов и длительная операция с ФС завалится - как вы будете эту пихтонрастию вышибать из нестандартной позы неплохо бы наверное подумать.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	81. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
	Сообщение от пох (?), 05-Дек-18, 16:41
	>> Ред хат сказал xfs значит будет xfs. > И менеджмент к нему на пихтонрасте, с lvm, пытающийся изобразить из этого там вроде nodejs с angular жеж ? > эрзац-подобие btrfs/zfs. Кушайте не обляпайтесь. Правда что там сделают корпоративные > индусы - вы наверное догадываетесь. это зависит от длины и весомости палки, которой их колотят. В смысле, не надо думать, что индусы из дельфикса сделают вам лучше, или ораклосузя расстарается. Палок редхату щас  новых завезут. > И если не дай боже у вас нет упса и генераторов и длительная операция с ФС завалится упсы и генераторы не панацея, к сожалению. И могут отдельно подгадить в самый неподходящий момент.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	97. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (-), 05-Дек-18, 18:49
	> там вроде nodejs с angular жеж ? Обещали уровень менеджмента на питоне и расте. Вот прям так, дословно. И оно соответственно из xfs и lvm сделает "типа, btrfs" :D. Как по мне так пусть фанаты пихтонрасии этим и пользуются, а мне что-то совсем не хочется чесать репу что делать когда индусская пихтонрасия завалится на продвинутой операции, когда дешевые индусики кодившие это и близко не помогут шалтая-болтая собрать. Просто потому что они умеют только на пихтонрасте погонщиками слонов работать. А ветеринария - это уже не к ним, дескать, это вы сами уже как-нибудь. > это зависит от длины и весомости палки, которой их колотят. Мозги палкой не вколачиваются. Поэтому когда что-нибудь сглючит - индусики будут фигурно уворачиваться от палки, переводя стрелки, а как и кто свои данные отколупает - вот это загадка. > В смысле, не надо думать, что индусы из дельфикса сделают вам лучше, или > ораклосузя расстарается. Палок редхату щас  новых завезут. У оракла полтора разработчика осталось. Ну вот враждебная опенсорсу компания, с гнилым климатом. Поэтому дельных линуксных разработчиков там как-то осталось мизер. Из видных рож там разве что Dan Carpenter вспоминается, но он такой себе универсал по всему, с уклоном вообще в секурити, чтоли. А вот именно те кто btrfs активно кодит - в основном фэйсбук, фуджики и зюзя, хотя и от других иногда прилетает. > упсы и генераторы не панацея, к сожалению. И могут отдельно подгадить в > самый неподходящий момент. Да я догадываюсь. И таки под btrfs'ом у меня пару раз факапы были даже при смене уровня избыточности. Ну оно после ребута и продолжает то что обломалось, доезжая до финиша. А что в такой ситуации делать в XFS с пихтонрасией я себе в самом диком комшмаре представить не возьмусь. Изначальный дизайн такого не предполагает, в отличие от, и как там индусики это законопатят - черт бы их там знает...
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

44. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
Сообщение от Аноним (44), 05-Дек-18, 12:59
Народ, noop deadline [cfq] (по умолчанию в Fedora) не подвержен?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+2 +/–
	Сообщение от plan8 (?), 05-Дек-18, 13:31
	Набор планировщиков говорит о том, что blk-mq не включен. Так что можно не беспокоиться.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	49. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (44), 05-Дек-18, 13:55
	Благодарю.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

48. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–2 +/–
Сообщение от Аноним (48), 05-Дек-18, 13:55
У меня в arch'е linux 4.19, я чувствую себя бесплатным бетатестером-ослом.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от A (?), 05-Дек-18, 14:15
	Использовать lts-ядро религия не позволяет?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	147. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
	Сообщение от Аноним (147), 06-Дек-18, 11:24
	Где-то на lkml Линус писал, что зря они заранее предупредили, что 4.14 будет LTS. Потому что все сразу ломанулись коммитить в него новый функционал, даже плохо протестированный, с аргументами (утрирую) "Ща закоммитим, а потом в течение времени жизни уже будем тестировать и исправлять. Пусть у пользователей будет этот новый, лучший функционал, даже если первые несколько десятков релизов он будет работать криво". В результате (читать в lkml сообщения Линуса о выходе первых rc) 4.14 по объёму изменений получился одним из самых больших за последний десяток релизов, и (по ощущениям) потом ещё два релиза (4.15, 4.16) они боролись с последствиями этого "Закоммитим, а там станет видно", исправляя вылезающие проблемы. Размер 4.9 тоже был одним из самых больших, что наталкивает на размышления по похожих проблемах. Так что, полагаю, использовать lts-ядро ему не позволяет здравый смысл. А религия - это удел тех, которые молятся на lts с аргументацией "Ну вот же уже под полторы сотни исправлений вышло, значит оно действительно стабильное".
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	51. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+4 +/–
	Сообщение от Mike Lee (?), 05-Дек-18, 14:21
	Разве не в этом фича арча?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	55. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–1 +/–
	Сообщение от 4.4 (?), 05-Дек-18, 15:02
	Зачем тебе тогда арч переходи на девиан стейбл вот там софт проверенный временем.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

62. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+/–
Сообщение от Адекват (ok), 05-Дек-18, 15:14
Арчеводы уже отхавали. Гармония проблем от новизны.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	79. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	–3 +/–
	Сообщение от helloworld (?), 05-Дек-18, 16:30
	В арче по-умолчанию mq-deadline. Тех, кто зачем-то сделал [none], не наблюдается.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	85. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"	+1 +/–
	Сообщение от Аноним (85), 05-Дек-18, 17:33
	При этом этот none по умолчанию выставлен в ядре для всех dm-устройств без возможности изменения. А dm используется в том числе и шифрованными LUKS-разделами.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

100. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–4 +/–
Сообщение от Аноним (100), 05-Дек-18, 19:49
Scsi еще поискать нужно, это вам не sas/nvme/sata...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	110. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	+1 +/–
	Сообщение от Аноним (106), 06-Дек-18, 01:50
	Сам-то понял чо сказал?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	185. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–1 +/–
	Сообщение от Аноним (106), 06-Дек-18, 20:49
	Чего минусите, балбесы? Или как и тот аноним, тоже не в курсе, что ide/sata/sas/nvme в ядре через scsi-layer работает?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

104. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–1 +/–
Сообщение от кузмич (?), 05-Дек-18, 22:18
Ребятки а я попал на эту хреновину думал ssd диск помер ан-нет сделал fsck.ext4 до загрузки системы с установочной флэшки.Система стала грузится а так аварийно останавливалась на середине загрузки.Система Gentoo вот ведь как и бэкап то не поможет если на битой системе делался уже.А я не мог понять что происходит все перелопатил а оно вон как.Разработчикам ядра большой Минус а ежели на сервере то зело на них я обиделся какой не хороший баг.И сколько попадет еще систем прям диверсия какая то.Вот теперь исходники качать заново и систему пере собирать.Сделал временно sheduller в Deadline.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	109. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–1 +/–
	Сообщение от axredneck (?), 06-Дек-18, 00:55
	> ... а ежели на сервере то зело на них я обиделся какой не хороший баг. На сервер такое новое ядро вряд ли кто-то станет ставить. Такие баги, как правило, отлавливаются до того, как они попадут в LTS-ядро.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	113. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	+/–
	Сообщение от M i M (?), 06-Дек-18, 02:18
	К счастью, при сборке ядра с использованием конфига от более старых версий оно само не включается. $ uname -sr Linux 4.19.6-gentoo $ zcat /proc/config.gz | grep CONFIG_SCSI_MQ_DEFAULT # CONFIG_SCSI_MQ_DEFAULT is not set
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	212. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	+/–
	Сообщение от пох (?), 10-Дек-18, 10:14
	> К счастью, при сборке ядра с использованием конфига от более старых версий оно само > не включается. мне кажется, тебя где-то кидают: In 4.19, cfq is not available due to commit d5038a13eca72 ("scsi: core: switch to scsi-mq by default"). https://bugzilla.kernel.org/show_bug.cgi?id=201685#c223 и io scheduler none, оказывается - _единственный_ в этом случае возможный вариант. А я -то удивлялся, откуда столько людей со странными настройками.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	203. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	+1 +/–
	Сообщение от Led (ok), 08-Дек-18, 04:31
	> Сделал временно sheduller Что-что сделал?
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

124. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–1 +/–
Сообщение от Аноним (124), 06-Дек-18, 07:38
Хм хм хм какое-то время пользовался именно в такой конфигурации без планировщика, пока не завезли. Сейчас вроде должен стоять. Пронесло? Ведро подревнее было правда, ещё 4.1 по-моему.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

135. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–1 +/–
Сообщение от Аноним (4), 06-Дек-18, 09:42
> + { "SAMSUNG*MZ7KM*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM, }, что за слово такое, 'horkage' ? > ata_device_blacklist а вообще, существуют SSD, которые не г-но по версии linux? Все мои два в том списке: самс и тошибка.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

151. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–2 +/–
Сообщение от кузмич (?), 06-Дек-18, 12:44
Диск у меня samsung-850pro 128гб проблем с ним никогда не было. Систему пересобрал sheduller в deadline и еще раз провел fsck.ext4 на всякий случай перед пересборкой все в порядке проблем ни каких.А было так работает firefox и тут бац! зависает с заморозкой всего xfce4 потом отпускает и вроде работает и так пару тройку раз с разными периодами.А после перезагрузки падает корень системы на стадии загрузки идет fsck но бестолку видимо на примонтированной системе не востанавливает.Затем система монтируется только для чтения.Но когда грузишся с флэшки и переходишь в chroot вся система полностью работоспособна.А про LTS на сервере категорически согласен но нужны последние наработки по amdgpu в ядре для видеокарты.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	187. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	+1 +/–
	Сообщение от Аноним (4), 07-Дек-18, 08:55
	для чего тебе видеокарта нужна на сервере? ну и поток сознания. 850pro разьве бывает 128гб ?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

192. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–1 +/–
Сообщение от кузмич (?), 07-Дек-18, 12:09
Сервер и по совместительству десктоп так как не могу заработать железо очень дорогое по нашим доходам как то так.А самсунг именно на 128Гб там же и на 256Гб для тестирования открытых драйверов amdgpu в играх.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

210. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	–2 +/–
Сообщение от кузмич (?), 09-Дек-18, 15:18
Проверил на gentoo-sources-4.19.8 вышел патч  на исправление blkMq в sheduler ядра как оказалось проблема была по версии разработчиков в формировании очередей запросов к файловой системе.В итоге откатил опять на dedline патч не помог что то не то они тестируют проблема где-то еще.Не ставьте noop в планировщике только deadline или sfq система виснет как убрал сразу все в порядке вот так то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	211. "Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, ..."	+1 +/–
	Сообщение от КГБ СССР (?), 09-Дек-18, 20:17
	Купи себе клавиатуру с запятой и научись ею пользоваться. Невозможно же читать этот поток букв.
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

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

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