![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TerminateProcess
Суслик © (2005-04-25 14:53:00)Добрый день.
Есть такой псевдокод:
... запись в файл 200 мб из памяти
sleep(500);
TerminateProcess(GetCurrentProcess);
Вопрос: почему система ждет, когда файл запишется и только потом приложение закрывается? Вернее, почему файл оказывается записанным?
ЗЫ. win2000 server, диски ntfs и fat32.
Sha (2005-04-26 13:23:00) [81]Еще две: повторятьчтение элемента, покаразмер файла нулевой
Sha (2005-04-26 13:13:00) [82]> Суслик © (26.04.05 13:07) [54]
> Я в принциее так и делаю в 28, кроме работы с оглавлением.
> Что такое оглавление?
Каталог, директорий, FindFirst :)
Вкралась очепатка: повторить чтение элемента, если размер файла нулевой
Суслик (2005-04-26 13:07:00) [83]
> [51] Sha © (26.04.05 12:53)
> В твоем случае для W98 можно попробовать следующее:
> - новый файл (открыть, писать, закрыть),
> - прочитать элемент оглавления для нового файла,
> - повторить чтение элемента, если размер файла ненулевой,
> - удалить старый файл,
> - переименовать новый.
Можно подробней? :)
Я в принциее так и делаю в 28, кроме работы с оглавлением. Что такое оглавление?
Sha (2005-04-26 13:06:00) [84]> 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]
alpet (2005-04-26 12:54:00) [85]Суслик © (26.04.05 12:45) [48]
Не переживет он той ночи :). Так жестоко ни к чему, можно и программно спровоцировать сбой, без аппаратного вмешательство. Я здесь на форуме где-то приводил неправильный код с участием GetDIBits который довольно резко перезагружал Windows XP+SP2 без вопросов (у меня были даже ошибки в файла).
Sha (2005-04-26 12:53:00) [86]> Суслик © (26.04.05 12:28) [43]
В твоем случае для W98 можно попробовать следующее:
- новый файл (открыть, писать, закрыть),
- прочитать элемент оглавления для нового файла,
- повторить чтение элемента, если размер файла ненулевой,
- удалить старый файл,
- переименовать новый.
alpet (2005-04-26 12:49:00) [87]Имхо здесь все-таки достаточно CRC.
Примерный алгоритм может такой:
1. Записывается весь файл, вызывается FlushFileBuffers.
2. Рассчитывается CRC для записанных данных и пишется вместе с именем файла в другой файл.
При считывании можно будет убедится что данные в первом файле не повреждены (в т.ч. вирусами, повреждениями диска на физическом уровне и т.д.), заново рассчитав CRC и сравнив с той что записана во втором файле.
mgcr (2005-04-26 12:46:00) [88]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]
> На самом деле супер-пупер надежность не нужна.
Тогда не мучайся. А то, согласно известному закону: "система обеспечения надежности выведет из строя все остальные системы".
Суслик (2005-04-26 12:45:00) [89]
> [45] alpet © (26.04.05 12:38)
> не мешает устроить и несколько экспериментов.
Ты думаешь я смею постить их не устроив? :) Почему и впорос про terminateProcess возник - сначала хотел им моделировать сбой. Не вышло.
Потом даже пару раз доба комп из сети выдернул. Все работало. Но я думаю, что в момент нужные не попал. Сам поинимаешь - свой комп жалко. Сейчас на работе собирают тестовую машину с образами 98, xp и 2000. Буду ее мучать.
Наш сотрудник вспомнил, что у него диплмная работа была - ... что-то... там и контроллер выключения компа. Мы тут решили к этой тестовой машине это контроллер прикрутить. Пусть ночами падает, а потом проверяет себя :))
alpet (2005-04-26 12:44:00) [90]2 Sha
Гарантированно не теряют, только если используют
механизм прямой записи на диск
Такой механизм в API похоже не существует. У большинства жестких дисков IDE есть кэш 2-8 мбайт. Когда и как он сбрасывается узнать программно имхо никак.
Суслик (2005-04-26 12:41:00) [91]Александр, так что делать то? Как жить?
На самом деле супер-пупер надежность не нужна. Т.е. конечно я не полезу в низкоуровневое программирование режима ядра и прочего.
Нужно что-то разумное :)
alpet (2005-04-26 12:38:00) [92]FlushFileBuffers тебе необходима для обоих файлов - и основного бинарного и описательного. Вместе с задержкой зто даст относительно неплохую надежность. Впрочем ничто не мешает устроить и несколько экспериментов.
Sha (2005-04-26 12:33:00) [93]> mgcr © (26.04.05 12:24) [42]
> Если бы все было так плохо, любая СУБД и любая файловая
> система гарантировано теряли бы свои данные при отключении
> питания. Однако же, не всегда теряют.
Гарантированно не теряют, только если используют
механизм прямой записи на диск.
> Кроме того, при записи я предлагал сбрасывать буфер перед
> созданием файла, индицирующего завершение записи.
Буфер сбрасывается всего лишь в кэш, а не в файл.
Суслик (2005-04-26 12:28:00) [94]Я тут подумал, что надо описать, что вообще делается.
Есть продукт, производит и распространяет его наша фирма (www.vkkb.ru).
Данный продукт последний раз был обновлен в 2001 году. В связи с неослабевающим интересом к продукту его нужно обновить.
Требования такие:
1. Клиент/сервер - 1 сервер, до 10 клиентов, каждый из которых примерно раз в 20 сек спрашивает у сервера маааленкую часть информации.
2. Минимальные требования к оборудованию и админу.
3. Отстутствие необходимости что-то дополнительно ставить и администрить.
4. Использовать TCP\IP, т.е. без всяких сторонних разработок.
Естестно, данные нужно хранить. Требуется, чтобы вероятность сбоя при выключении компа была минимальной. В принципе целевым пользователем является ВУЗЫ, а они достаточно бедные. Поэтому у них частно одноранговая сеть из 98. Там тоже должно работать.
mgcr (2005-04-26 12:24:00) [95]
> Файловая система Windows имеет право обновлять данные на
> диске,
> сбрасывая кэш, в произвольной последовательности.
> Поэтому при отключении питания мы не можем гарантировать,
> что данные будут обновлены в обоих файлах. Индикатор может
> быть выставлен, а данные еще не записаны. При включении
> питания мы вполне можем обнаружить вместо данных файл нулевой
> длины.
Если бы все было так плохо, любая СУБД и любая файловая система гарантировано теряли бы свои данные при отключении питания. Однако же, не всегда теряют. Кроме того, при записи я предлагал сбрасывать буфер перед созданием файла, индицирующего завершение записи.
Суслик (2005-04-26 12:12:00) [96]
> [35] mgcr © (26.04.05 10:31)
> И потом, чем тебе мой ... способ не нравится ?
Может и нравится. Но интересно знать авторитетное мнение, чем мой способ из [28] хуже?
Способ Алекса я пока не изучал.
Господа.
1. Ответ на вопрос Игоря по поводу количества файлов.
Файлов мало. Каждый файл записывается в среднем раз в 10 мин. Причем! В 3 мб это "край". 90 процентов времени файл не более 1мб или того меньше.
2. Что общественность думает над способом из [28]? И в ntfs и в fat?
Sha (2005-04-26 12:03:00) [97]> Игорь Шевченко © (26.04.05 11:52) [38]
> Если не секрет, в чем именно ненадежность
> и в какой ситуации эта ненадежность себя проявит.
Файловая система Windows имеет право обновлять данные на диске,
сбрасывая кэш, в произвольной последовательности.
Поэтому при отключении питания мы не можем гарантировать, что данные будут обновлены в обоих файлах. Индикатор может быть выставлен, а данные еще не записаны. При включении питания мы вполне можем обнаружить вместо данных файл нулевой длины.
Игорь Шевченко (2005-04-26 11:52:00) [98]Sha © (26.04.05 10:43) [36]
> Тем, что способ [27] не гарантирует надежной работы.
Если не секрет, в чем именно ненадежность и в какой ситуации эта ненадежность себя проявит.
Sha (2005-04-26 11:52:00) [99]> Alex Konshin © (26.04.05 09:47) [31]
> Потом изменяешь соответствующий гиперблок (пишешь в него номер
> нового сектора данных) и опять-таки пишешь его на новое место.
Кстати, когда делал нечто подобное, чтобы обеспечить возможность
параллельной работы с несколькими файлами в файловой системе,
блоки FAT обновлял сразу по месту и вел отдельно список начал
подвешенных цепочек.
> Alex Konshin © (26.04.05 11:30) [37]
> CreateFileMapping
Как я понял, тут начало важнее, чем конец:
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.
Т.е. речь вроде идет о неизменяемых процессором данных.
Alex Konshin (2005-04-26 11:30:00) [100]Sha © (26.04.05 10:25) [33]
> Alex Konshin © (26.04.05 09:47) [31]
> Весь твой файл нужно открывать без кеширования
> или, еще лучше, организовать memory mapping.
Разве memory mapping гарантирует обновление секторов файла
в порядке обновления секторов в кеше?
Может я и не прав, но мне кажется это решается:
CreateFileMapping
SEC_NOCACHE Sets all pages of a section to non-cashable.
Applications should not use this flag except when explicitly required for a device. Using the interlocked functions with memory mapped by a SEC_NOCACHE section can result in an EXCEPTION_ILLEGAL_INSTRUCTION exception.
SEC_NOCACHE requires either the SEC_RESERVE or SEC_COMMIT to be set.