SU+J

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Apr 18 14:31:52 по местному времени:

21 апр. 2018, суббота, в 13:19 NOVT, Slawa Olhovchenkov написал(а):

EG>>>> Ещё раз - проблема не в самом кеше на запись, а в корректности
EG>>>> отработки firmware диска команды сброса.
VS>>> То есть ИБП по-прежнему рулит?
EG>> ИБП безусловно рулит, но он не поможет в случае креша и ребута.
SO> ты хочешь сказать что при ребуте без сброса питания hdd может потерять данные?

Точнее сказать, может нарушиться консистентность, так как
для транзакций (включая журнальные) важно не только чтобы данные
сели на носитель, но и чтобы они это сделали в правильной
последовательности.

Диск с включенным кешированием, которое лжет об окончании записи
плюс "особенности" отработки команды RESET диском вполне могут
привести к нарушениям, с которыми последующая проверка журнала
транзакций не исправится. Собственно, об этом МакКузик и писал.

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Victor Sudakov в Apr 18 14:33:33 по местному времени:

21 апр. 2018, суббота, в 16:00 NOVT, Victor Sudakov написал(а):

EG>>>> Ещё раз - проблема не в самом кеше на запись, а в корректности
EG>>>> отработки firmware диска команды сброса.
VS>>> То есть ИБП по-прежнему рулит?
EG>> ИБП безусловно рулит, но он не поможет в случае креша и ребута.
VS> А в случае крэша и ребута диск не имеет способа узнать, что надо сбросить
VS> буфера? А в случае нажатия на ресет?

Во всех случаях имеет способ узнать, драйвер ему команду посылает
"общий сброс". Проблема в том, что в таком случае из-за вранья
диска о том, что все данные якобы записались на носитель,
можно сломать транзакции журнала.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Apr 18 19:18:45 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> Причина понятна - вдвое больше операций записи, два разных устройства,
EG> Параллельно по времени на два разных устройства.
последовательно, последовательно.
Или у нас кто-то научился multipath? (полагаю, если вдруг такое случится,
для него придумают целый отдельный кривой класс в geom со своими отдельными
глюками)

> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Eugene Grosbein в Apr 18 19:22:45 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> Так вот, на нём только UFS без SUJ, но с SU и background fsck
возможно, современный background fsck и не является источником проблем
на ровном месте сам по себе, без дополнительной помощи в виде спорадических
крэшей, но есть такая штука - зарабатывается годами. Называется "репутация".

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Apr 18 18:03:22 по местному времени:

22 апр. 2018, воскресенье, в 17:22 NOVT, Alex Korchmar написал(а):

EG>> Так вот, на нём только UFS без SUJ, но с SU и background fsck
AK> возможно, современный background fsck и не является источником проблем
AK> на ровном месте сам по себе, без дополнительной помощи в виде спорадических
AK> крэшей, но есть такая штука - зарабатывается годами. Называется "репутация".

ZFS её ещё не заработала и судя по этой логике уже никогда не заработает.

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Apr 18 18:03:22 по местному времени:

22 апр. 2018, воскресенье, в 17:22 NOVT, Alex Korchmar написал(а):

EG>> Так вот, на нём только UFS без SUJ, но с SU и background fsck
AK> возможно, современный background fsck и не является источником проблем
AK> на ровном месте сам по себе, без дополнительной помощи в виде спорадических
AK> крэшей, но есть такая штука - зарабатывается годами. Называется "репутация".

ZFS её ещё не заработала и судя по этой логике уже никогда не заработает.

Eugene
--- slrn/1.0.2 (FreeBSD)

Slawa Olhovchenkov написал(а) к Eugene Grosbein в Apr 18 16:56:40 по местному времени:

Нello Eugene!

22 Apr 18, Eugene Grosbein writes to Slawa Olhovchenkov:

EG>>>>> Ещё раз - проблема не в самом кеше на запись, а в корректности
EG>>>>> отработки firmware диска команды сброса.
VS>>>> То есть ИБП по-прежнему рулит?
EG>>> ИБП безусловно рулит, но он не поможет в случае креша и ребута.
SO>> ты хочешь сказать что при ребуте без сброса питания hdd может потерять
SO>> данные?

EG> Точнее сказать, может нарушиться консистентность, так как
EG> для транзакций (включая журнальные) важно не только чтобы данные
EG> сели на носитель, но и чтобы они это сделали в правильной
EG> последовательности.

EG> Диск с включенным кешированием, которое лжет об окончании записи
EG> плюс "особенности" отработки команды RESET диском вполне могут
EG> привести к нарушениям, с которыми последующая проверка журнала
EG> транзакций не исправится. Собственно, об этом МакКузик и писал.

т.е. ты все же хочешь сказать, что по комманде RESET некоторые диски могут терять данные без сброса питания?

... Ходють тут всякие, а потом каталоги пропадают
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Eugene Grosbein в Apr 18 16:54:25 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> крэшей, но есть такая штука - зарабатывается годами. Называется
AK>> "репутация".
EG> ZFS её ещё не заработала и судя по этой логике уже никогда не заработает.
zfs в солярке и иллюмосе работает уже десяток лет, и в общем примерно известно,
где работает, а где рыбу заворачивали, и что делать когда пул не импортится.

с zfs на фре отдельная песня.

про zol очень хотелось бы услышать начальников транспортного цеха.
(я вот надысь узнал, что ее использует masterhost, но им данные юзеров вряд
ли особенно жалко, да и время ночной смены тоже)


> Alex
P.S. кстати, солярка научилась освобождать ненужные vdev'ы
Это еще не shrink, но уже неплохой вариант.

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Apr 18 23:25:59 по местному времени:

23 апр. 2018, понедельник, в 14:56 NOVT, Slawa Olhovchenkov написал(а):

SO> т.е. ты все же хочешь сказать, что по комманде RESET некоторые диски могут
SO> терять данные без сброса питания?

Я не смог навскидку найти детали, но я помню, что совершенно точно
были такие firmware у НDD, которые при перезагрузке операционной системы
могли приводить к потере консистентности файловой системы даже и без креша
(и без сброса питания), и даже Microsoft выпускала хотфикс, который
за счёт тупого дополнительного sleep вносил искусственную задержку
при ребуте, которая каким-то образом решала проблему.

Вроде как при сбросе диск вместо того, чтобы записать содержимое кеша,
по которому он уже раньше отрапортавал об успешной записи,
тупо чистил кеш.

Eugene
--
Научить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Научить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Apr 18 00:29:33 по местному времени:

22 апр. 2018, воскресенье, в 17:18 NOVT, Alex Korchmar написал(а):

AK>>> Причина понятна - вдвое больше операций записи, два разных устройства,
EG>> Параллельно по времени на два разных устройства.
AK> последовательно, последовательно.

Параллельно. Вот тест в один поток записи блоками в MAXPНYS:

# swapoff /dev/mirror/gm0s1b
# time dd if=/dev/zero bs=128k of=/dev/mirror/gm0s1b count=8000
8000+0 records in
8000+0 records out
1048576000 bytes transferred in 10.477047 secs (100083159 bytes/sec)

real 0m10,479s
user 0m0,042s
sys 0m0,205s

Диски - обычные SATA.

ada0: <WDC WD2003FYYS-02W0B1 01.01D02> ATA8-ACS SATA 2.x device
ada1: <WDC WD2003FYYS-02W0B1 01.01D02> ATA8-ACS SATA 2.x device

AK> Или у нас кто-то научился multipath? (полагаю, если вдруг такое случится,
AK> для него придумают целый отдельный кривой класс в geom со своими отдельными
AK> глюками)

Я не понял вопроса насчет multipath, но GEOM внутри давно
на асинхронных очередях построен. gmirror раскидывает BIO-запросы
по низлежащим дискам и в случае обычных запросов на запись
рапортует завершение только тогда, когда асинхронно приходит
последний ответ от самого медленного компонента.

Eugene
--- slrn/1.0.2 (FreeBSD)