Просьба не пинать за некромантию. Чот вспомнилось...

kdvSiemargl,

да пофиг. Этот lazy writer иногда застревал, и при крахе ОС у людей пропадало много чего.
Тут ведь основная проблема в том, что при FW=ON ФБ пишет страницы на диск в определенном порядке. А при FW=OFF их пишет на диск ОС, в своем собственном порядке.
Например, в базе распределяется новая страница. На нее пишутся данные, она привязывается к страницам таблицы. После чего страница помечается в PIP как используемая.
То есть, примерно 3 страницы пишутся в базу в определенном порядке. Если в какой-то промежуточный момент нажать кнопку reset, то при FW=ON повреждений в базе не будет (например, orphan pages не считаются повреждением).
А вот если FW=OFF, может произойти такое - в кэш ОС уехало 3 страницы - PP, DP, PIP. Первой записалась измененная PIP, потом PP. И тут нажали reset. Результат - страницы нет, а она помечена как используемая.
В принципе, не катастрофа, но может быть и гораздо хуже.Если рассматривать кейс на SuperServer:
FW=OFF и DefaultDbCachePages >= FileSystemCacheThreshold (использование файлового кэша системы подавлено)
Как, в таком случае, будет вести себя запись? Будет ли соблюдаться правильный порядок записи страниц и как такая конфигурация скажется на производительности и устойчивости БД к повреждениям?

dimitrrdb_dev, такая конфигурация не гарантирует сброс кеша устройства.Это понятно. Но если не используется кэш файловой системы, то обеспечит ли кэш БД при FW=OFF правильный порядок скидывания страниц на носитель и, как следствие, исключение неустранимых сервером FirebirdSQL повреждений БД, если мы условимся, что наш носитель, к примеру - RAID контроллер с батарейкой или включенным WriteThrow? И получим ли мы существенный прирост производительности OLTP при интенсивных записях?

Ivan_Pisarevskyrdb_devоситель, к примеру - RAID контроллер с батарейкойвлияние асинхронного ВВ при этом устремляется к нулю. Смысл городить огород?Ну ёлы-палы... Не о том вопрос!
Меня интересует - обеспечивает ли кэш БД правильный порядок скидывания страниц на носитель?

Почему асинхронный ввод/вывод стремиться к нулю, если при FW=OFF сервер пишет в кэш БД?

hvladНа пальцах:
сервер меняет содержимое страниц в своём кеше
содержимое страничного кеша сохраняется на диск с помощью ОС
ОС может кешировать файлы, а может и не кешировать
движок по умолчанию даёт инструкцию кешировать файл БД (CachePages < FileSystemCacheThreshold)
кроме того, ОС может кешировать метаданные файлов
FW влияет на работу файлового кеша и кеша метаданных файловой системы.

Нет способа отключить careful writes в Firebird.Повторюсь:rdb_devЕсли рассматривать кейс на SuperServer:
FW=OFF и DefaultDbCachePages >= FileSystemCacheThreshold (использование файлового кэша системы подавлено)
Как, в таком случае, будет вести себя запись? Будет ли соблюдаться правильный порядок записи страниц и как такая конфигурация скажется на производительности и устойчивости БД к повреждениям?Чуствую, либо меня не понимают, либо я чего-то не понимаю... Попробую перефразировать вопрос - как ведёт себя менеджер кэша БД при необходимости сбросить страницы на носитель (при вытеснении страниц на диск)? Соблюдает ли менеджер кэша тот же порядок записи страниц на носитель, в котором эти страницы были записаны сервером FirebirdSQL в кэш БД (не системный кэш файлов)?

hvladкроме того, ОС может кешировать метаданные файлов
FW влияет на работу файлового кеша и кеша метаданных файловой системы.Иными словами, если мы подавили использование файлового кэша (DefaultDbCachePages >= FileSystemCacheThreshold), то FW вообще никак не влияет?

hvladНет способа отключить careful writes в Firebird.Это понятно!
И хорошо, что нет такого способа. Правда, в случае использования FW=OFF и файлового кэша операционной системы, последнему наплевать на careful writes.

dimitrrdb_devкак ведёт себя менеджер кэша БД при необходимости сбросить страницы на носитель (при вытеснении страниц на диск)?
в соответствии с политикой careful writes

rdb_devСоблюдает ли менеджер кэша тот же порядок записи страниц на носитель, в котором эти страницы были записаны сервером FirebirdSQL в кэш БД (не системный кэш файлов)?
нет никакого (значимого) "порядка записи в кеш БД", есть только "порядок записи из кеша БД на диск"Вот! Теперь мне понятно. :)