The OpenNET Project / Index page

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



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

Оглавление

Выпуск Debian 9.8, opennews (??), 16-Фев-19, (0) [смотреть все]

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


25. "Выпуск Debian 9.8"  –4 +/
Сообщение от Аноним (7), 16-Фев-19, 22:08 
Будущее Линукс за Arch
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

32. "Выпуск Debian 9.8"  –4 +/
Сообщение от Аноним (32), 16-Фев-19, 22:36 
Нет, за никсос
Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск Debian 9.8"  –2 +/
Сообщение от zzz (??), 16-Фев-19, 23:02 
Девочки, не спорьте. Все рано или поздно приходят к единственно нормальной ОСи - FreeBSD
Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск Debian 9.8"  +4 +/
Сообщение от Аноним (49), 17-Фев-19, 00:01 
Это типа в могилу?
Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск Debian 9.8"  –3 +/
Сообщение от zzz (??), 17-Фев-19, 00:55 
Это типа к нормальной ОС, в которой всё просто работает. Когда подрастешь - поймешь, что вся эта возня с цифрой после второй точки в номере версии гнома не имеют никакого значения. Главное - как стабильно работает ОС. И тут FreeBSD даст десятки очков форы любой лапчатой раскривушке, при этом совмещая в себе все плюсы как Debian, как стабильной ОС, так и свежесть пакетов арча без арчевских неожиданностей.
Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск Debian 9.8"  –1 +/
Сообщение от IRASoldier (?), 17-Фев-19, 01:54 
>возня с цифрой после второй точки в номере версии гнома не имеют никакого значения

Имеют, если речь идёт об одном из вариантов десктопного использования ОСи. FreeBSD, несомненно, велика и прекрасна, но сколько сапиенсов на планете выходят за рамки сугубо серверного юзания оной?

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

73. "Выпуск Debian 9.8"  +/
Сообщение от Аноним (73), 17-Фев-19, 07:28 
Если в твоем трепе заменить FreeBSD на что угодно прочее ничего не изменится. Хорош уже мантрами жырнить.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

86. "Выпуск Debian 9.8"  –1 +/
Сообщение от пох (?), 17-Фев-19, 09:31 
> Если в твоем трепе заменить FreeBSD на что угодно прочее ничего не изменится.

к сожалению, да.
Нормальных свободных систем не осталось.

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

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

84. "Выпуск Debian 9.8"  +/
Сообщение от пох (?), 17-Фев-19, 09:26 
это у которой одна fs "works as intended", а у второй, как давеча выяснили "нет средств проверки консистентности в принципе"? Красиво жить не запретишь.

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

118. "Выпуск Debian 9.8"  +/
Сообщение от анонн (?), 17-Фев-19, 21:43 
> это у которой одна fs "works as intended",

"Works as intended" вполне документирована - делай бэкапы, отключай "оптимизацию" записи данных на диск (или не бери диски, которые в ответ на sync "врут", что они все записали, хотя на самом деле ... а ведь просто нужно было вовремя и дружно бить маркетологов арматуриной, когда они проталкивали эту пакость, вместо покорного подстраивания и вкорячивания квирксов) или отключай журнал или заимей УПС и будет тебе щастье.
Опять же, dump+restore прекрасно работает, в отличие от.

К тому, есть некоторые сомнения что чексуммы метаданных в журнале решают эту проблему сильно лучше, т.к. по умолчанию запись и в пингвине вроде как "ordered" (и зависит от этого) плюс журналируются только метаданные. Но целостность метаданных совсем не означает целостность самих данных.


Или вы хотели сказать, что лучше (потому что меньше знаешь -- крепче спишь) просто тихо портить данные (типа blq-mq) в любой FS, заодно превращая бэкапы в тыкву?

https://www.opennet.ru/keywords/ext4.html


[05.12.2018] Выпущен патч, решающий проблему с blq-mq в ядре Linux 4.19, которая приводит к потере данных    
[23.05.2015] Проблема с повреждением разделов Ext4 оказалась в md-raid0    
[20.05.2015] В ядре Linux выявлены ошибки, приводящие к зависанию процессов и повреждению разделов EXT4    
[05.04.2013] В Ext4 исправлена ошибка, которая потенциально могла привести к разрушению данных    
[06.11.2012] Обновление ядра Linux 3.0.51, 3.4.18 и 3.6.6 с устранением нашумевшей проблемы в ext4    
[02.11.2012] Выпущен патч для исправления ошибки в ext4, которая могла привести к повреждению ФС    
[25.10.2012] Появившаяся в ядре Linux 3.6.2 ошибка способна привести к повреждению данных в ФС Ext4    

А вот в простой, как валенок, UFS только "works as intended".

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

119. "Выпуск Debian 9.8"  +/
Сообщение от анонн (?), 17-Фев-19, 21:45 
> по умолчанию запись и в пингвине вроде как "ordered" (и зависит от этого) плюс журналируются только метаданные.

Уточнение: речь в основном идет о ext4.

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

120. "Выпуск Debian 9.8"  +/
Сообщение от пох (?), 17-Фев-19, 22:13 
> "Works as intended" вполне документирована

вы, похоже, не в курсе, что именно там "intended".

ups, внезапно, раз в десять лет тоже может сделать "oops". И ядро может само по себе.

Так вот, если вы не разобрались в проблеме - суть не в том что в fs побьются данные, которые только что писались - они не могут не побиться, и это совершенно нормально, а нормально спроектированная программа должна это пережить. Суть не в том что побьются метаданные, хотя journaled, cow, log-store fs изобретены сто лет назад и при правильной реализации ведут только к потере последнего изменения и то если звезды не сошлись.
Суть в том, что в системе произойдет _silent_ corruption, который будет расти, пока не приведет к полному развалу fs.

Разница что в случае ufs можно просто подождать часок после перезагрузки, пока штатный fsck тупит и тормозит, потому что гранты уже попилены, наверх доложили что fsck при загрузке ненужно, и оптимизировать его под современные диски и память никто не собирается, а в случае zfs лучше самовыпилиться побыстрее, там вообще нет fsck, а scrub "works as intended", то бишь циклично ребутится, и так называемый "разработчик" не видит в этом _своей_ проблемы.

> https://www.opennet.ru/keywords/ext4.html

видите ли, там ни одна проблема не закрыта с ресолвом "as intended" и "notabug". Разработчиков пока еще немного беспокоит работоспособность их детища. В этом и заключается существенная разница с freebsd, где работоспособность системы беспокоит почему-то совсем других людей, а разработчики годами игнорируют даже работающие и отлаженные в HL проектах патчи, вместо этого таща в систему всякий мусор, отсыпанный на лопате линуксным апстримом.

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

125. "Выпуск Debian 9.8"  +/
Сообщение от анонн (?), 17-Фев-19, 22:50 
> Так вот, если вы не разобрались в проблеме - суть не в
> том что в fs побьются данные, которые только что писались -
> они не могут не побиться, и это совершенно нормально, а нормально
> спроектированная программа должна это пережить. Суть не в том что побьются
> метаданные, хотя journaled, cow, log-store fs изобретены сто лет назад и

Я-то может не разобрался, но вот проблема была как раз в системах с gmirror+журнал+unexpected poweroff.
Что и упоминалось в ответе:
> This is a problem that is endemic to all overwriting  filesystems that use journalling. Specifically, the journal only checks and corrects things that it knows need to be fixed.

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

> при правильной реализации ведут только к потере последнего изменения и то  если звезды не сошлись.

Ну да, ну да.
https://lwn.ext4 experience
> Posted Nov 30, 2011 4:52 UTC (Wed) by ringerc (subscriber, #3071)
> In reply to: ext4 experience by dskoll
> The usual culprit in those sorts of severe corruption or loss cases is aggressive write-back caching without battery backup. Some cheap RAID

https://opensource.com/article/18/4/ext4-filesystem


Journal checksumming

Ext3 did not checksum its journals, which presented problems for disk or controller devices with caches of their own, outside the kernel's direct control. If a controller or a disk with its own cache did writes out of order, it could break ext3's journaling transaction order, potentially corrupting files being written to during (or for some time preceding) a crash.

In theory, this problem is resolved by the use of write barriers—when
(...)
In practice, it's been discovered that storage devices and controllers frequently do not honor write barriers—improving performance (and benchmarks, where they're compared to their competitors) but opening up the possibility of data corruption that should have been prevented.

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

> Суть в том, что в системе произойдет _silent_ corruption, который будет расти, пока не приведет к полному развалу fs.

Суть в том, что без чексум всех _данных_ - silent corruption может быть в любом случае.

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

150. "Выпуск Debian 9.8"  +/
Сообщение от Алкогол (?), 18-Фев-19, 14:48 
> (...)
> In practice, it's been discovered that storage devices and controllers frequently do
> not honor write barriers-improving performance (and benchmarks, where they're compared
> to their competitors) but opening up the possibility of data corruption
> that should have been prevented.

Это всё совсем не так. Там вообще путаница. Барьеры, о которых в цитате речь, вообще относятся к ОС, не к самому диску, и ОС должна их как-то реализовывать. И как выянилось где-то не совсем реализует :-) Где-то да, из-за прогресса в устройстве дисков. Прогресс этот однако -- инженерный процесс, отнюдь не от маркетологов...

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

151. "Выпуск Debian 9.8"  +/
Сообщение от Алкогол (?), 18-Фев-19, 15:33 
> Суть в том, что без чексум всех _данных_ - silent corruption может быть в любом случае.

Не в любом :-) В ошибочном только. Вот для лучшего выявления этих случаев и сделали. В норме ошибок быть не должно.

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

152. "Выпуск Debian 9.8"  +/
Сообщение от анонн (?), 18-Фев-19, 15:53 
>> Суть в том, что без чексум всех _данных_ - silent corruption может быть в любом случае.
> Не в любом :-) В ошибочном только.

Угу, угу.
https://queue.acm.org/detail.cfm?id=1866298
> The NetApp study looked at the incidence of silent storage corruption in individual disks in RAID arrays. The data was collected over 41 months from NetApp's filers in the field, covering more than 1.5×106 drives. The study found more than 4×105 silent corruption incidents.
> их как-то реализовывать. И как выянилось где-то не совсем реализует :-)

Вот именно что при отсутсвии надежного способа делать sync -- "как-то".

> Где-то да, из-за прогресса в устройстве дисков. Прогресс этот однако -- инженерный процесс, отнюдь не от маркетологов...

Читсо технически то да. Но вот есть у меня большие сомнения, что инициатива "а давай сделаем так, что write cache будет игнорить все попытки синхронизации, сразу возвращая "ок"? Пусть оно будет ломать данные, зато в бенчах все будет ого-го как!" исходила от иженеров.
Да и в чем тут "прогресс", кроме как для синтетических бенчей и дополнительного (в идеальном случае, если не забьют) геморроя разрабам ФС?

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

126. "Выпуск Debian 9.8"  +/
Сообщение от Анонн (?), 17-Фев-19, 23:26 
>видите ли, там ни одна проблема не закрыта с ресолвом "as intended" и "notabug". Разработчиков пока еще немного беспокоит работоспособность их детища.

dump/restore в качестве примера был не зря. Багрепорт "не работает для онлай фс"для ext закрыли как раз с "нотабаг/нинужно".

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

88. "Выпуск Debian 9.8"  +/
Сообщение от Аноним (88), 17-Фев-19, 09:48 
>Все рано или поздно приходят к единственно нормальной ОСи - FreeBSD

Не позорьтесь, они сотрудничают с Google Analytics.

Давно пора, делать свою ОС...

Как пример:
>KolibriOS — операционная система для PC, полностью написанная на ассемблере fasm и распространяемая на условиях лицензии GPL.
>Основной дистрибутив имеет размер 1,44 Мб (помещается на одной 3,5″ дискете).

1,44 Мб!!!!!!!!

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

108. "Выпуск Debian 9.8"  +/
Сообщение от Аноним (108), 17-Фев-19, 15:10 
fasm, безусловно, интересная штука. Правда, в тексте масса восклицательных знаков, вместо "я написал на нём то-то для Колибри". Странно.
Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск Debian 9.8"  +/
Сообщение от тов. майор (?), 17-Фев-19, 22:15 
>>Все рано или поздно приходят к единственно нормальной ОСи - FreeBSD
> Не позорьтесь, они сотрудничают с Google Analytics.

все , рано или поздно, соглашаются на сотрудничество.

У меня есть очень эффективные средства убеждения.

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

155. "Выпуск Debian 9.8"  +/
Сообщение от Аноним (155), 18-Фев-19, 20:16 
OpenIndiana же!
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

153. "Выпуск Debian 9.8"  +/
Сообщение от Аноним (155), 18-Фев-19, 20:11 
FreeBSD замечательная ОС, но я сейчас смотрю в сторону OpenIndiana. Не зря над ней работал автор Дебиан перед смертью
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

46. "Выпуск Debian 9.8"  +/
Сообщение от axredneck (?), 16-Фев-19, 23:30 
Сам пользуюсь Арчем, но при этом понимаю, что существует куча юзкейсов, для которых Арч не подойдет. Например, своей маме я не Арч поставил.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

51. "Выпуск Debian 9.8"  +4 +/
Сообщение от А (??), 17-Фев-19, 00:03 
о, тяжелый продакшн подтянулся.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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