LINUX.ORG.RU

История изменений

Исправление sanyo1234, (текущая версия) :

Мне, честно говоря, в принципе непонятен смысл твоих изысканий.

Каких именно изысканий?

Ты готов отказаться от всего того, что было сделано для скорости и надежности за последние лет тридцать чтобы что?

Надеюсь, ты про компании Sun и Oracle, а не про Western Digital или Seagate?

Отключить обратный кеш, то есть фактически, задрочить диск раз в десять быстрее и сообразно снизить скорость его работы ради чего?

Ты из каменной пещеры только что выполз? :) Про кэширование на SSD и multi-temperature storage не слыхал?

Чтобы твоя база вообще накернилась через пару лет работы вместо пары десятков лет?

Накернилась база, на промышленной СУБД, от сбоя диска? Ахаха, чо правда, такое бывает?

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

И все это вместо того, чтобы использовать ионисторы для сброса кеша на диск?

Ионисторы - это для записи данных после отключения питания?

Режим синхронной записи даже для сменных флешек не так уж часто включают. Не 100%, хотя он там вполне полезен, как мера от резкого выдергивания.

Но смысл коммита вовсе не в том, что его результаты невозможно потерять, а в том, что это контрольная точка, которую имеет смысл восстанавливать. И все на этом. Сохранилась, хорошо, от нее и пляшут. Не сохранилась, берут предыдущую.

Нука, нука, покажика описание того, как в ACID РСУБД commit, выполненный без ошибки, может потеряться.

Исходная версия sanyo1234, :

Мне, честно говоря, в принципе непонятен смысл твоих изысканий.

Каких именно изысканий?

Ты готов отказаться от всего того, что было сделано для скорости и надежности за последние лет тридцать чтобы что?

Надеюсь, ты про компании Sun и Oracle, а не про Western Digital или Seagate?

Отключить обратный кеш, то есть фактически, задрочить диск раз в десять быстрее и сообразно снизить скорость его работы ради чего?

Ты из каменной пещеры только что выполз? :) Про кэширование на SSD и multi-temperature storage не слыхал?

Чтобы твоя база вообще накернилась через пару лет работы вместо пары десятков лет?

Накернилась база, на промышленной СУБД, от сбоя диска? Ахаха, чо правда, такое бывает?

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

И все это вместо того, чтобы использовать ионисторы для сброса кеша на диск?

Ионисторы - это для записи данных после отключения питания?

Режим синхронной записи даже для сменных флешек не так уж часто включают. Не 100%, хотя он там вполне полезен, как мера от резкого выдергивания.

Но смысл коммита вовсе не в том, что его результаты невозможно потерять, а в том, что это контрольная точка, которую имеет смысл восстанавливать. И все на этом. Сохранилась, хорошо, от нее и пляшут. Не сохранилась, берут предыдущую.

Нука, нука, покажика описание того, как в ACID РСУБД commit может потеряться.