Архив форумов ЦИТФорума

[Vladgul]

Как заставить Windows записать файловые буфера на диск.

Есть система (Client-Server) на Delphi из нескольких программ, которые собирают данные, затем перед отправкой по сети сохраняют накопленные данные в файлах
(в целях повышения сохранности информации. Информация не должна потеряться ни в каком случае, только вместе с компьютером ).
Файлы создаются с помощью потоков TFileStream. При восстановлении (повторном запуске) программы, она считывает файл, проверяет контрольную сумму и только тогда считает файл "целым".

Так вот, если в процессе работы программы и передачи данных резко выгрузить программу из памяти (т.е. сбой питания или еще что-то т.п., хотя мне кажется, что если будет действительно сбой питания, то потери могут быть больше), то теряются несколько записей в файлах.
ИМХО это из-за того, то винды имеют файловый кеш и не сразу записывают данные на винт.

ЧТО МОЖНО СДЕЛАТЬ?
Опять же ИМХО если делать запись файловых буферов на диск, то это должно помочь.

Как записать файловые буфера?

[and3008]

Это тебя не спасет. Делай как все путные люди механизм транзакций.
Ну и бесперебойники вроде еще продают. ))

[Vladgul]

Какой механизм транзакций, если это просто файловые операции (без использования БД).
Ну и согласись, UPS вещь хорошая, но если программа расчитана на огромную надежность сохранности данных, то UPS ее только дополнит и исключит проблемы с питанием (и то на некоторое время).

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

Если можешь что посоветовать буду признателен.

[Борис]

В досах и виндах до 95 сбросить буфера на диск можно было командой SMARTDRV /R. Возможно, современные винды сохранили этот атавизм. Если нужно сбросить данные на диск в программе, которую сам делаешь, то нужно использовать небуферируемую запись. А если действительно нужна гарантированная сохранность данных, то выбрось винды в форточку и поставь юникс.

[grayrat]

Ставь QNX. Кстати, с железом на ней работать - одно удовольствие и вся документация внутри в HTML.

[Sclis]

Господа! Какой *никс? ) там что операции с хардом не кэшируются?
Копить информацию в оперативке до обращения к харду - политика ОС вполне обычная для нормальной ОС. отключать (даже если получится такое) его значит сильно тормозить систему. Да и как быть с кэшем самого харда? Причем толку от этого не будет.
Если на машинке ресет нажать что будет? она при следующей загрузке начнет хард проверять и найдет потеряные кластеры! - это как раз незакрытые файлы! значит, если тебе и удасться отключить кэширование данных для конкретного файла (что вобще вряд ли), то во много раз возрастет вероятность потери всего файла => надо делать архивную копию... а поскольку даже самая свежая копия младше оригинала, то ты будешь терять как раз те самые несколько записей, что и сейчас.
Вывод: наверно люди не зря придумывали базы данных, транзакции, УПС, отказоустойчивые конфигурации. не пытайся все это засунуть в одну процедуру Дельфи.
А что касается систем высокой надежности - облом-с: как пишут некоторые производители РС-комплектухи: "не для систем связанных со спасением людей и не для медицины"(с)-почти цитата так что это даже другое железо.
Все же оптимальный вариант - серверБД с УПСом и запасом прочности и отдельная добротная физическая подсеть до клиента.

[grayrat]

В QNX 4.25 вообще отсутствует своп. Но это наоборот, не добавляет а исключает возиожность тормозов связанных со свопингом.
Вообще, это ОС реального времени, построена по архитектуре микроядра, компактная, простая и надёжная, предсказуемая. Операции же с дисками кэшируются на уровне библиотеки stdio, которую никто не заставляет использовать. Кстати, в ней есть такая функция - flush, как, впрочем, и в любой другой (я так думаю) кэшируемой системе/библиотеке работы с файлами. QNX как раз и используют когда важно не потерять поступающие с большой скоростью данные. Пока есть питане, можно быть уверенным что система не войдёт в своп и пропустит пакет(ы) данных. Время реакции на прерывания тоже известное и постоянное (ок. 20 тактов). Это касательно самой системы, а касательно того что механизм транзакций незря придуман, конечно, согласен безусловно.

[Sclis]

нет. стоп. своп и кэширование - суть вещи сильно разные, даже противоположные. о свопе речи не идет...
своп держит на харде, то, что не влезло в оперативку, а кэширование держит в оперативке то, что еще не записано на хард. Отключить своп в виндах - не проблема, (правильно? галочка где надо ставится и перезагружается машина, только будут большие проблемы, если вдруг оперативки понадобится больше, чем физически ее стоит - это значит никаких клиентских программ... никаких документов... ничего лишнего)
Если уж сильно приспичит - можно и в виндах написать драйвер режима ядра, который будет использовать (например) выделенный раздел для записи критически важного файла. И там можно будет /flash использовать так же как в QNX. При этом не потеряется знакомость интерфейса... ну и т.д. но все это сильно выходит за рамки "уже написанная программа на дельфи" и получается слишком сложно.
Клиентская машина должна оставаться клиентской. QNX, как видно - прекрасная вещь, но как встроенная ОС в самостоятельный прибор (без программ и документов... для одного дела), а для архитектуры клиент-сервер, все же предпочтительней более простые средства, и более используемые... и универсальные.
а что может быть проще вложений в надежность оборудования (сеть и УПС) и проверенный SQL-сервер на серваке с запасом прочности?)