http://rulinux.net/ http://rulinux.net/ http://rulinux.net/rss_icon.png https://rulinux.net/message.php?newsid=42720&page=1#218298 https://rulinux.net/message.php?newsid=42720&page=1#218298 Thu, 03 Nov 2016 07:51:31 +0300 Что-то мне кажется, хоть я и не эксперт, ни одна система не сможет гарантировать тебе 100% гарантии сохранности всех недописанных данных перед отключением питания. У тебя будет либо consistent state ФС за некоторое время до креша (хороший дизайн), либо мусор (плохой).

]]> https://rulinux.net/message.php?newsid=42720&page=1#218294 https://rulinux.net/message.php?newsid=42720&page=1#218294 Wed, 02 Nov 2016 17:32:06 +0300 > ZFS вон вообще меньше recordsize не читает/пишет. Это 128кб по дефолту

И как потом узнавать что пытался скинуть в логи сервер непосредственно перед крешем? Как уцелеет журнал транзакций БД?

]]> https://rulinux.net/message.php?newsid=42720&page=1#218292 https://rulinux.net/message.php?newsid=42720&page=1#218292 Wed, 02 Nov 2016 16:42:38 +0300 Мне кажется, таким ОС должна заниматься. ZFS вон вообще меньше recordsize не читает/пишет. Это 128кб по дефолту

]]> https://rulinux.net/message.php?newsid=42720&page=1#218285 https://rulinux.net/message.php?newsid=42720&page=1#218285 Wed, 02 Nov 2016 14:53:24 +0300 > А зачем там большой кеш, когда время доступа и так меньше, чем в HDD?

У SSD количество перезаписей ограниченное, а при последовательной записи велика вероятность что в один из недавно записанных блоков снова пойдёт запись (например логи или инсерты в таблицу). DDR дешёвая, было бы логично кешировать как можно больше. При условии сабжа, разумеется.

]]> https://rulinux.net/message.php?newsid=42720&page=1#218281 https://rulinux.net/message.php?newsid=42720&page=1#218281 Wed, 02 Nov 2016 14:18:52 +0300 А зачем там большой кеш, когда время доступа и так меньше, чем в HDD?

]]> https://rulinux.net/message.php?newsid=42720&page=1#218280 https://rulinux.net/message.php?newsid=42720&page=1#218280 Wed, 02 Nov 2016 14:16:50 +0300 Какую-то фигню вы написали, граждане, про кэш. Пишете про недозапись кэша диска при вырубании питания, и совсем забыли про буферы записи, которые управляются ядром самой оси и находятся в оперативе. Они уж по любому теряются при выключении питания

]]> https://rulinux.net/message.php?newsid=42720&page=1#218278 https://rulinux.net/message.php?newsid=42720&page=1#218278 Wed, 02 Nov 2016 14:09:59 +0300 мощно, внушает..

]]> https://rulinux.net/message.php?newsid=42720&page=1#218274 https://rulinux.net/message.php?newsid=42720&page=1#218274 Wed, 02 Nov 2016 12:50:58 +0300 > может поискать какие-нить тесты f2fs на разных накопителях? raw read/write ща даже на базёнках не очень популярно, как мне кажется.

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

]]> https://rulinux.net/message.php?newsid=42720&page=1#218272 https://rulinux.net/message.php?newsid=42720&page=1#218272 Wed, 02 Nov 2016 12:41:02 +0300 Так это ап ту вас, что вы с ним делаете. Задача БОРа - гарантированно положить процессор при "плохом" питании чтобы он чего плохого не вытворил. Если нужно что-то сверх того:

1. При запуске софтины проверять флаги сброса, если сброс произошёл по БОРу - можно и подождать скока надо, чтобы если питание не восстановилось успеть снова сброситься

2. Если нужно успеть что-то завершить до ресета, то поставить на входе питания камня диод Шоттки и конденсатор. Вход компаратора подключить перед диодом, по прерыванию от компаратора переводить все выводы в высокоимпедансное состояние, завершать там все свои записи в еепром и ждать пока не восстановится питание/сработает БОР.

Последнее в случае SSD, конечно, требует значительно более ёмких по сравнению с AVR конденсаторов поскольку у них потребление ваттами исчисляется.

]]> https://rulinux.net/message.php?newsid=42720&page=1#218271 https://rulinux.net/message.php?newsid=42720&page=1#218271 Wed, 02 Nov 2016 12:28:46 +0300 По идее SSD должен бы держать данные в кеше как можно дольше чтобы не перезаписывать один и тот же блок постоянно при последовательной записи

может поискать какие-нить тесты f2fs на разных накопителях? raw read/write ща даже на базёнках не очень популярно, как мне кажется.

]]> https://rulinux.net/message.php?newsid=42720&page=1#218268 https://rulinux.net/message.php?newsid=42720&page=1#218268 Wed, 02 Nov 2016 09:13:26 +0300 Ты про задержку после сброса забыл. А то от этого BOD только хуже будет. Олсо, eeprom один хер затирается. Хоть раз в год, но это происходит.

]]> https://rulinux.net/message.php?newsid=42720&page=1#218266 https://rulinux.net/message.php?newsid=42720&page=1#218266 Tue, 01 Nov 2016 21:47:07 +0300 > Из-за плавного понижения питания контроллер может несколько раз перезапуститься и навыполнять случайных команд, включая запись в случайный блок.

Ну так BOR в AVR-ках на тот случай и используется, сбрасывает контроллер как только напруга упала до рискованного уровня, чтобы не натворил чего. В защищенных SSD наоборот суперконденсатор ставят как минимум. И через это SSD начинает сразу минимум в два раза дороже стоить :(

]]> https://rulinux.net/message.php?newsid=42720&page=1#218262 https://rulinux.net/message.php?newsid=42720&page=1#218262 Tue, 01 Nov 2016 16:37:53 +0300 В своё время наебался с этой проблемой в говне от AVR. Они даже какой-то "brown out detection" прикрутили. Чуть лучше, но говно тоже. Допускаю, что в SSD для удешевления тоже забили хуй на это.

>По идее SSD должен бы держать данные в кеше как можно дольше чтобы не перезаписывать один и тот же блок постоянно при последовательной записи.
Из-за плавного понижения питания контроллер может несколько раз перезапуститься и навыполнять случайных команд, включая запись в случайный блок. Мну считает, что SSD говно по определению.

]]> https://rulinux.net/message.php?newsid=42720&page=1#218259 https://rulinux.net/message.php?newsid=42720&page=1#218259 Tue, 01 Nov 2016 16:16:27 +0300 Когда-то у меня безвозвратно сдохла USB-флешка в тот момент, когда нетбук окончательно разрядился и вырубился. Стандартные утилиты для оживления флешек не помогли. Мораль: как повезёт, может ничего и не попортиться при power loss.

]]> https://rulinux.net/message.php?newsid=42720&page=1#218258 https://rulinux.net/message.php?newsid=42720&page=1#218258 Tue, 01 Nov 2016 16:10:25 +0300 Встретил в сети срачик, что мол для SSD нужен этот самый протекшен. Там действительно всё так плохо и SSD в чём-то чувствительнее к пропаданию питания, чем обычный хард или народ просто с жиру бесится?

По идее SSD должен бы держать данные в кеше как можно дольше чтобы не перезаписывать один и тот же блок постоянно при последовательной записи.

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

Насколько всё ужасно? Есть бюджетные варианты накопителей с сабжевой защитой?

]]>