|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 20 Oct 2002 13:34:44
To : Mihail Badin
Subject : Re: scandisk
--------------------------------------------------------------------------------
>>> Mihail Badin wrote:
>> ядро посылает блоки в журнал, ждет пока они запишутся, потом кладет
>> по своим местам. теперь ситуация: блоки до журнала не добрались и
>> болтаются в кэше hdd. в то же время, ядро думает, что блоки в журнале
>> и начинает писать блоки по своим местам. здесь случился 'oops'.
MB> правильный hdd ДОЛЖЕH успеть скинуть кэш на диск при пропадании питания
Ему может не хватить энергии на перемещение головок и другие подобные
механические действия.
Во freebsd-hackers был тред о том, как сочетать write cache внутри HDD
и ATA command tags. Там приводился ряд не сильно забавных данных про то, что:
1. Часть HDD не выключает write-back cache даже если отдана прямая
команда на его отключение (ATA_C_F_DIS_WCACHE, 0x82). Откуда тут ноги растут -
понять было сложно, предположили, что это у производителей такая защита
на случай глупого драйвера в ОС.
2. Часть HDD содержит испорченный алгоритм сброса буферов из write-back
cache - скорее всего, построенный не по нормальному лифтовому алгоритму
и не по комбинации методов, а выбором блока для следующей записи по принципу
минимального перемещения головок. Кто-то нашел ситуацию, когда блок из кэша
не ушел за час (!) и при пропадании питания не был сброшен.
Приводились, естественно, конкретные модели. Я запомнил то, что у IBM
такого никогда не было и можно продолжать сидеть на них :)
Из-за подобных ситуаций, в итоге решили оставить дефолтной настройкой
hw.ata.wc: 1
hw.ata.tags: 0
я себе поставил все наоборот (write cache - нафиг, рассчитывать на него
не нужно, tags - включить) и доволен.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
