TerminateProcess

← →
Sha © (2005-04-26 12:03) [40]

> Игорь Шевченко © (26.04.05 11:52) [38]
> Если не секрет, в чем именно ненадежность
> и в какой ситуации эта ненадежность себя проявит.

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

← →
Суслик © (2005-04-26 12:12) [41]

> [35] mgcr © (26.04.05 10:31)

> И потом, чем тебе мой ... способ не нравится ?

Может и нравится. Но интересно знать авторитетное мнение, чем мой способ из [28] хуже?

Способ Алекса я пока не изучал.

Господа.

1. Ответ на вопрос Игоря по поводу количества файлов.
Файлов мало. Каждый файл записывается в среднем раз в 10 мин. Причем! В 3 мб это "край". 90 процентов времени файл не более 1мб или того меньше.

2. Что общественность думает над способом из [28]? И в ntfs и в fat?

← →
mgcr © (2005-04-26 12:24) [42]

> Файловая система Windows имеет право обновлять данные на
> диске,
> сбрасывая кэш, в произвольной последовательности.
> Поэтому при отключении питания мы не можем гарантировать,
> что данные будут обновлены в обоих файлах. Индикатор может
> быть выставлен, а данные еще не записаны. При включении
> питания мы вполне можем обнаружить вместо данных файл нулевой
> длины.

Если бы все было так плохо, любая СУБД и любая файловая система гарантировано теряли бы свои данные при отключении питания. Однако же, не всегда теряют. Кроме того, при записи я предлагал сбрасывать буфер перед созданием файла, индицирующего завершение записи.

← →
Суслик © (2005-04-26 12:28) [43]

Я тут подумал, что надо описать, что вообще делается.

Есть продукт, производит и распространяет его наша фирма (www.vkkb.ru).

Данный продукт последний раз был обновлен в 2001 году. В связи с неослабевающим интересом к продукту его нужно обновить.

Требования такие:
1. Клиент/сервер - 1 сервер, до 10 клиентов, каждый из которых примерно раз в 20 сек спрашивает у сервера маааленкую часть информации.
2. Минимальные требования к оборудованию и админу.
3. Отстутствие необходимости что-то дополнительно ставить и администрить.
4. Использовать TCP\IP, т.е. без всяких сторонних разработок.

Естестно, данные нужно хранить. Требуется, чтобы вероятность сбоя при выключении компа была минимальной. В принципе целевым пользователем является ВУЗЫ, а они достаточно бедные. Поэтому у них частно одноранговая сеть из 98. Там тоже должно работать.

← →
Sha © (2005-04-26 12:33) [44]

> mgcr © (26.04.05 12:24) [42]
> Если бы все было так плохо, любая СУБД и любая файловая
> система гарантировано теряли бы свои данные при отключении
> питания. Однако же, не всегда теряют.

Гарантированно не теряют, только если используют
механизм прямой записи на диск.

> Кроме того, при записи я предлагал сбрасывать буфер перед
> созданием файла, индицирующего завершение записи.

Буфер сбрасывается всего лишь в кэш, а не в файл.

← →
alpet © (2005-04-26 12:38) [45]

FlushFileBuffers тебе необходима для обоих файлов - и основного бинарного и описательного. Вместе с задержкой зто даст относительно неплохую надежность. Впрочем ничто не мешает устроить и несколько экспериментов.

← →
Суслик © (2005-04-26 12:41) [46]

Александр, так что делать то? Как жить?

На самом деле супер-пупер надежность не нужна. Т.е. конечно я не полезу в низкоуровневое программирование режима ядра и прочего.

Нужно что-то разумное :)

← →
alpet © (2005-04-26 12:44) [47]

2 Sha

Гарантированно не теряют, только если используют
механизм прямой записи на диск

Такой механизм в API похоже не существует. У большинства жестких дисков IDE есть кэш 2-8 мбайт. Когда и как он сбрасывается узнать программно имхо никак.

← →
Суслик © (2005-04-26 12:45) [48]

> [45] alpet © (26.04.05 12:38)

> не мешает устроить и несколько экспериментов.

Ты думаешь я смею постить их не устроив? :) Почему и впорос про terminateProcess возник - сначала хотел им моделировать сбой. Не вышло.

Потом даже пару раз доба комп из сети выдернул. Все работало. Но я думаю, что в момент нужные не попал. Сам поинимаешь - свой комп жалко. Сейчас на работе собирают тестовую машину с образами 98, xp и 2000. Буду ее мучать.

Наш сотрудник вспомнил, что у него диплмная работа была - ... что-то... там и контроллер выключения компа. Мы тут решили к этой тестовой машине это контроллер прикрутить. Пусть ночами падает, а потом проверяет себя :))

← →
mgcr © (2005-04-26 12:46) [49]

Sha © (26.04.05 12:33) [44]

> Гарантированно не теряют, только если используют
> механизм прямой записи на диск.

> Буфер сбрасывается всего лишь в кэш, а не в файл.

"The WriteFile and WriteFileEx functions typically write data to an internal buffer that the operating system writes to disk on a regular basis. The FlushFileBuffers function writes all of the buffered information for the specified file to disk.

To open a file for unbuffered I/O, call the CreateFile function with the FILE_FLAG_NO_BUFFERING flag. This prevents the file contents from being cached. However, the file metadata may still be cached. To flush the metadata to disk, use FlushFileBuffers."

Это из ремарков к FlushFileBuffers.

Суслик © (26.04.05 12:41) [46]

> На самом деле супер-пупер надежность не нужна.

Тогда не мучайся. А то, согласно известному закону: "система обеспечения надежности выведет из строя все остальные системы".

← →
alpet © (2005-04-26 12:49) [50]

Имхо здесь все-таки достаточно CRC.
Примерный алгоритм может такой:
1. Записывается весь файл, вызывается FlushFileBuffers.
2. Рассчитывается CRC для записанных данных и пишется вместе с именем файла в другой файл.

При считывании можно будет убедится что данные в первом файле не повреждены (в т.ч. вирусами, повреждениями диска на физическом уровне и т.д.), заново рассчитав CRC и сравнив с той что записана во втором файле.

← →
Sha © (2005-04-26 12:53) [51]

> Суслик © (26.04.05 12:28) [43]

В твоем случае для W98 можно попробовать следующее:
- новый файл (открыть, писать, закрыть),
- прочитать элемент оглавления для нового файла,
- повторить чтение элемента, если размер файла ненулевой,
- удалить старый файл,
- переименовать новый.

← →
alpet © (2005-04-26 12:54) [52]

Суслик © (26.04.05 12:45) [48]

Не переживет он той ночи :). Так жестоко ни к чему, можно и программно спровоцировать сбой, без аппаратного вмешательство. Я здесь на форуме где-то приводил неправильный код с участием GetDIBits который довольно резко перезагружал Windows XP+SP2 без вопросов (у меня были даже ошибки в файла).

← →
Sha © (2005-04-26 13:06) [53]

> alpet © (26.04.05 12:44) [47]
> Такой механизм в API похоже не существует.

FILE_FLAG_WRITE_THROUGH

> У большинства жестких дисков IDE есть кэш 2-8 мбайт. Когда и
> как он сбрасывается узнать программно имхо никак.

Забота производителя сбросить кэш на диск при отключении питания.

> mgcr © (26.04.05 12:46) [49]

Ну и что из этого следует?

> Суслик © (26.04.05 12:41) [46]
> Александр, так что делать то? Как жить?

[51]

← →
Суслик © (2005-04-26 13:07) [54]

> [51] Sha © (26.04.05 12:53)

> В твоем случае для W98 можно попробовать следующее:
> - новый файл (открыть, писать, закрыть),
> - прочитать элемент оглавления для нового файла,
> - повторить чтение элемента, если размер файла ненулевой,
> - удалить старый файл,
> - переименовать новый.

Можно подробней? :)
Я в принциее так и делаю в 28, кроме работы с оглавлением. Что такое оглавление?

← →
Sha © (2005-04-26 13:13) [55]

> Суслик © (26.04.05 13:07) [54]
> Я в принциее так и делаю в 28, кроме работы с оглавлением.
> Что такое оглавление?

Каталог, директорий, FindFirst :)

Вкралась очепатка: повторить чтение элемента, если размер файла нулевой

← →
Sha © (2005-04-26 13:23) [56]

Еще две: повторять чтение элемента, пока размер файла нулевой

← →
Alex Konshin © (2005-04-26 13:25) [57]

Sha © (26.04.05 11:52) [39]
> Alex Konshin © (26.04.05 09:47) [31]
> Потом изменяешь соответствующий гиперблок (пишешь в него номер
> нового сектора данных) и опять-таки пишешь его на новое место.
Кстати, когда делал нечто подобное, чтобы обеспечить возможность
параллельной работы с несколькими файлами в файловой системе,
блоки FAT обновлял сразу по месту и вел отдельно список начал
подвешенных цепочек.

Это потому, что ты использовал цепочки, а не гиперблоки. Гиперблоки в этом плане существенно надежнее и проще. Честно говоря, я не знаю, как устроена NTFS, но знаю FAT (которая цепочечная) и знаю файловую систему CMS из VM SP (которая гиперблочная). И я слышал, что при создании OS/2 IBM пошла именно по второму пути, потому думаю, что у NTFS оттуда же ноги растут.

Это я к тому, что цепочечную файловую систему трудно сделать надежной, гиперблочная же делается на раз без всяких ухищрений.

Как я понял, тут начало важнее, чем конец:

All pages of a section are to be set as non-cacheable.
This attribute is intended for architectures requiring various
locking structures to be in memory that is never fetched into
the processor"s. On 80x86 and MIPS machines, using the cache for
these structures only slows down the performance as the hardware
keeps the caches coherent.

Т.е. речь вроде идет о неизменяемых процессором данных

Не знаю откуда ты это взял - на msdn этого нет. В описании функции именно то, что я написал.
И потом, вполне возможно, что нужно просто еще при CreateFile запросить некеширования, может этого и будет достаточно. Я уверен, что это решается, потому что базы всегда мапятся на память и с ними были бы проблемы, если бы это не решалось.

← →
alpet © (2005-04-26 13:30) [58]

Sha © (26.04.05 13:06) [53]
FILE_FLAG_WRITE_THROUGH

Instructs the system to write through any intermediate cache and go directly to disk.

Во общем это альтернатива FlushFileBuffers полностью исключающая появления данных в системном кэше, но имхо при записи в несколько приемов (вызовов WriteFile) на производительность (немного) повлияет не в лучшую сторону.

← →
Sha © (2005-04-26 13:35) [59]

> Alex Konshin © (26.04.05 13:25) [57]
> Это я к тому, что цепочечную файловую систему трудно сделать надежной

Делал, и даже на ЕС.

> Не знаю откуда ты это взял - на msdn этого нет.

From Borland D6 Help , а они у MS.

> Я уверен, что это решается,
> потому что базы всегда мапятся на память

Хотелось бы узнать, как это сделать через mapping.
Представь, если обновление идет автоматически при каждом
обращении на запись к странице, то были бы жуткие тормоза.
Значит, они это делают ручками, или не используют mapping.

← →
Sha © (2005-04-26 13:36) [60]

> alpet © (26.04.05 13:30) [58]
> на производительность (немного) повлияет не в лучшую сторону

за все надо платить

← →
alpet © (2005-04-26 13:40) [61]

Sha © (26.04.05 13:36) [60]

Согласен. Но где преимущество, за которое платить надо?
Использование FlushFileBuffers позволяет использовать кэш даже если файл записывается маленькими кусочками, и ничуть не влияет на производительность при чтении. Тогда как прямой доступ всего этого лишен.

← →
mgcr © (2005-04-26 13:55) [62]

Sha © (26.04.05 13:06) [53]

> Ну и что из этого следует?

Да там в ремарках слово "диск" употребляется. А не кэш...

← →
Sha © (2005-04-26 13:56) [63]

> alpet © (26.04.05 13:40) [61]
> Согласен. Но где преимущество, за которое платить надо?

Данные на диске всегда в согласованном состоянии.

← →
alpet © (2005-04-26 14:03) [64]

Sha © (26.04.05 13:56) [63]
>Данные на диске всегда в согласованном состоянии.

Поясни пожайлуста отличия - если файл размером 1мб записывается с участием системного кэша и сбрасывается FFB или если он же пишется напрямую. Как это отражается на файле и надежности его записи ?

← →
Alex Konshin © (2005-04-26 14:05) [65]

Sha © (26.04.05 13:35) [59]
> Alex Konshin © (26.04.05 13:25) [57]
> Это я к тому, что цепочечную файловую систему трудно сделать надежной
Делал, и даже на ЕС.

Все возможно для человека с интелектом, при желании и зайца можно научить курить (c)
Еще скажи, что это было просто. Я кстати, тоже делал, правда так и не реализовали до конца - проект умер, да и ЕС тоже.
В цепочка проблема в том, что при обновлении нескольких блоков в одной транзакции нужно обновлять сразу много блоков FAT в непонятном порядке, получается проще сбрасывать его весь. Отсюда получаются две копии FAT. Конечно, можно попытаться это оптимизировать, но сделать это надежно сложно. Я помню, что я тоже какие-то дополнительные цепочки вводил, но тонкостей в упор не помню.

По поводу маппинга: по косвенным признакам видно, что на mapview влияют аттрибуты открытия файла:
When flushing a memory-mapped file over a network, FlushViewOfFile guarantees that the data has been written from the local computer, but not that the data resides on the remote computer. The server can cache the data on the remote side. Therefore, FlushViewOfFile can return before the data has been physically written to disk. However, you can cause FlushViewOfFile to return only when the physical write is complete by specifying the FILE_FLAG_WRITE_THROUGH flag when you open the file with the CreateFile function.

Я думаю, что в MS SQL либо вообще пользуются недокументироваными задними дверями, либо просто создают вью и флашают их когда надо. Проблема отключения питания их не волнует - нужно имет UPS на серверах, что, в принципе, верно.
Кстати, это можно проверить. У кого под рукой есть MS SQL сервер? Посмотрите в WinObj какие объекты в памяти создаются. Нет ли там кучки секций?
Видно не даром MS SQL умеет свою партишн создавать. Видимо и из-за этого тоже.

← →
Sha © (2005-04-26 14:29) [66]

> mgcr © (26.04.05 13:55) [62]

Только FILE_FLAG_WRITE_THROUGH дает гарантию при работе в сети.

> alpet © (26.04.05 14:03) [64]

Тут вот какое дело.
Если ты работаешь с локальным файлом один и хочешь по завершении какой-то работы отразить результаты на диске, то FlushFileBuffers предпочтительнее. Но когда приложение работает с файлом в сети, или с локальным файлом, но обслуживает нескольких клиентов, данные которых должны сохраняться в произвольном порядке, то остается только FILE_FLAG_WRITE_THROUGH или свои буфера в комбинации с несколькими FlushFileBuffers, что по существу эквивалентно.

> Alex Konshin © (26.04.05 14:05) [65]
> По поводу маппинга...

Ага, тоже нашел уже FILE_FLAG_WRITE_THROUGH + FlushViewOfFile.

← →
mgcr © (2005-04-26 14:46) [67]

Sha © (26.04.05 14:29) [66]

> Только FILE_FLAG_WRITE_THROUGH дает гарантию при работе
> в сети.

Гарантию чего, Саша ? Пакет IRP_MJ_FLUSH_BUFFERS отправится драйверу сетевого редиректора при вызове FlushFileBuffers, данные для сброса по моему разумению, должны находиться на удаленном компьютере (чтобы он когерентность обеспечивал с локальными открытиями файлов), поэтому, если питание отключится на удаленном компьютере во время операции, то данные не запишутся всяко, а если питание отключится на локальном, то потеря данных, по идее, должна зависеть от того, успел ли редиректор отправить сетевой пакет сброса на удаленный компьютер.
Или я где-то здорово ошибаюсь ?

← →
Суслик © (2005-04-26 14:56) [68]

Господа.

Конкрентый вопрос - делал ли кто-то сам то, что мне нужно на win98 и win2000?

mgcr © (26.04.05 14:46) [67]
Вопрос в том, в какой момент к тебе вернется управление и что означает код возврата.
Без FILE_FLAG_WRITE_THROUGH, если не ошибаюсь, гарантируется только доставка данных до адресата, но не запись на его диск.

> Суслик © (26.04.05 14:56) [68]
> Конкрентый вопрос - делал ли кто-то сам то, что мне нужно на win98

Я делал.
Проверено в условиях сети.
Файл располагался на удаленной W98 или Novel(не помню какая).

> [70] Sha © (26.04.05 15:05)

Не, мне удаленно не надо. Мне исключительно локально, без всякой сети. Т.е.:
1. Бинарный файл (до 3 мб) локально
2. Файловая система - ntfs или fat.

Точно такое кто-то делал?

> Конкрентый вопрос - делал ли кто-то сам то, что мне нужно
> на win98 и win2000?

Жаль, что мы так и не услышали начальника транспортного цеха.

Я всеже советую задуматься о применении CRC. Даже если все будет гладко записываться - повреждение файла после его записи исключать нельзя. Если рассчет контрольной суммы сложен - можно обойтись созданием копии файла (маловероятен сбой который одинаково испортит два файла).

> [73] mgcr © (26.04.05 15:24)

> Жаль, что мы так и не услышали начальника транспортного
> цеха.

Ты о чем? Какого цеха?

Суслик © (26.04.05 16:09) [76]

> Конкрентый вопрос - делал ли кто-то сам то, что мне нужно
> на win98 и win2000?

А что тебе нужно, ты как гимназистка, объясняешь туманными полунамеками.

> [77] mgcr © (26.04.05 16:14)

Да я вроде все объяснил где-то выше.
Дабы не искать повторю:
Сохранение раз в 10 минут файла до 3 мб таким образом, чтобы при аппаратных сбоях (выключение компьютера) при последующем восстановлении либо было понятно, что произошел сбой (т.е. новый файл не дописался), либо новый файл дописался и информации о сбое нет. В первом случае происходит восстановление старого файла.

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

Должно работать в 98 и 2000, на ntfs и fat.

Суслик © (26.04.05 16:23) [78]

Если не в сети, то должно может будет достататочно FlushFileBuffers, как советовал mgcr ?

> Если не в сети, то должно может будет достататочно FlushFileBuffers,
> как советовал mgcr ?

Да я тоже так думаю, что достаточно.
Т.е. ты тоже думаешь, что достаточно?

TerminateProcess Найти похожие ветки