Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TerminateProcess

Страницы: < 1 2 3 4 5 6 7 >
Суслик © (2005-04-25 14:53:00)
Добрый день.

Есть такой псевдокод:

... запись в файл 200 мб из памяти sleep(500); TerminateProcess(GetCurrentProcess);

Вопрос: почему система ждет, когда файл запишется и только потом приложение закрывается? Вернее, почему файл оказывается записанным?

ЗЫ. win2000 server, диски ntfs и fat32.

Суслик (2005-04-26 16:09:00) [61]

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

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

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

mgcr (2005-04-26 16:06:00) [62]
alpet © (26.04.05 15:44) [74]

Копий должно быть нечетное число. А если еще старину Хэмминга вспомнить...

alpet (2005-04-26 15:44:00) [63]
Я всеже советую задуматься о применении CRC. Даже если все будет гладко записываться - повреждение файла после его записи исключать нельзя. Если рассчет контрольной суммы сложен - можно обойтись созданием копии файла (маловероятен сбой который одинаково испортит два файла).

mgcr (2005-04-26 15:24:00) [64]

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

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

Sha (2005-04-26 15:16:00) [65]
> Суслик © (26.04.05 15:11) [71]
Ну уж если удаленно работает, то локально обязано.

Суслик (2005-04-26 15:11:00) [66]

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

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

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

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

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

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

Суслик (2005-04-26 14:56:00) [69]
Господа.

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

mgcr (2005-04-26 14:46:00) [70]
Sha © (26.04.05 14:29) [66]

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

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

Sha (2005-04-26 14:29:00) [71]
> 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.

Alex Konshin (2005-04-26 14:05:00) [72]
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 умеет свою партишн создавать. Видимо и из-за этого тоже.

alpet (2005-04-26 14:03:00) [73]
Sha © (26.04.05 13:56) [63]
>Данные на диске всегда в согласованном состоянии.

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

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

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

mgcr (2005-04-26 13:55:00) [75]
Sha © (26.04.05 13:06) [53]

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

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

alpet (2005-04-26 13:40:00) [76]
Sha © (26.04.05 13:36) [60]

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

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

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

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

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

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

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

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

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

alpet (2005-04-26 13:30:00) [79]
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) на производительность (немного) повлияет не в лучшую сторону.

Alex Konshin (2005-04-26 13:25:00) [80]
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 запросить некеширования, может этого и будет достаточно. Я уверен, что это решается, потому что базы всегда мапятся на память и с ними были бы проблемы, если бы это не решалось.

Страницы: < 1 2 3 4 5 6 7 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »