Организация записи в лог-файл

[IvanLis]

На удаленном компьютере работает программа.
Ее действия записываются в лог-файл. События могут происходить с частотой от нескольких раз в секунду до десятков минут.
Принцип сохранения следующий:

LOG.vi

lv2010

(12.48 КБ) 123 скачивания

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

Все было бы хорошо, но есть НО.
Файл создается с "0" размером и это логично. В процессе записи размер файла не увеличивается, а соответственно я не могу отследить состояние в котором находится программа в режиме реального времени. Реально данные записанные в файл, а соответственно и размер файла, изменяются только после закрытия ссылки на файл (закрытия сессии).
Возможно это особенности файловой системы Ext4 (Linux), на Windows не проверял, но думаю там аналогично все происходит.

Собственно вопрос: Каким образом можно обойти описанную проблему не используя закрытие файла? А то мне не очень нравится идея его периодического открытия и закрытия.

[Borjomy_1]

Не очень хорошо долго держать открытый файл. Практика показывает, что это чревато проблемами. Например, при нештатном закрытии программы файл может оказаться недоступным до перезагрузки компа. Также, пока файл не закрыт, его невозможно просмотреть, это неудобно.
Решая подобную задачу я пришел к следующим вещам:
1. необходима буферизация данных на запись. По достижении определенного количества записей в буфере, открывается файл, буфер скидывается и файл закрывается.
2. таймаут добавления данных в буфер, при достижении которого выполняется пункт 1. Предотвращает ситуацию, когда данные лежат в буфере, например, час и приложение завершается нештатно, в результате чего данные пропадают.
3. по команде завершения программы также выполняется пункт 1

[dadreamer]

Возможно это особенности файловой системы Ext4 (Linux)

Думаю, что так и есть.
Одна из особенностей ext4:

Отложенное выделение блоков (англ. delayed allocation). Выделение блоков для хранения содержимого файла происходит непосредственно перед записью на диск (например, при вызове sync), а не при вызове write. Из-за этого блоки можно выделять не по одному, а группами, что в свою очередь минимизирует фрагментацию и ускоряет процесс выделения блоков. С другой стороны, увеличивается риск потери данных в случае внезапного пропадания питания.

Почитайте:
https://ru.wikipedia.org/wiki/Ext4
http://habrahabr.ru/post/58183/
Отложенное выделение места
Что касается Windows, то это уже обсуждалось здесь. Попробуйте использовать Flush FIle.

[IvanLis]

Попробуйте использовать Flush FIle.

Это, то что доктор прописал

Zx_K9fAtIT8

И к стати, это не зависит от файловой системы, по крайней мере сейчас проверил на Windows.
NTFS и FAT32 ведут себя аналогично.
Видимо это именно буфер создает.

[dadreamer]

И к стати, это не зависит от файловой системы, по крайней мере сейчас проверил на Windows.

На маленьких объёмах данных (< 4 КБ) нет смысла проверять, т.к. данные могут лежать в кэше ОС и просто не записываться на жёсткий диск. Когда размер блока данных становится более или равен 4 КБ, то он точно должен скидываться на диск, по крайней мере на NTFS в Windows.

[dadreamer]

Проверьте вот такой :

LOG.vi

(12.07 КБ) 102 скачивания

На Windows размер файла и количество записанных данных строго совпадает. Это означает, что даже несмотря на небольшой размер файла, сведения о нём обновляются в MFT при каждой операции записи. Интересно, что будет показывать в Linux.

[Vitekkz88]

dadreamerПопробуйте использовать Flush FIle.На маленьких объёмах данных (< 4 КБ) нет смысла проверять, т.к. данные могут лежать в кэше ОС и просто не записываться на жёсткий диск.

IvanLis писал(а):Это, то что доктор прописал

IvanLis, а ты не обратил внимание, что скорость записи падает в десятки раз, если ставить Flush File? Если это не кретично, то используйте.
У меня лично стоит Win7 x64 Ultimate и у меня нет проблем с Вашим первым вариантом. То есть я пишу данные и постоянно отслеживаю размер файла - он меняется. И меняется, даже если его размер менее 4 кБ(то есть меньше размера кластера на диске).

IvanLis писал(а):Реально данные записанные в файл, а соответственно и размер файла, изменяются только после закрытия ссылки на файл (закрытия сессии).

А ты не пробовал использовать функцию Get File Size Function? Прекрасно определяет размер файла в текущий момент. Проводи опрос каждые N мс при необходимости.

[dadreamer]

Не факт, что у него будет так же, в ext4 вообще нет MFT: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout А что касается винды, то когда файл или его сектор меньше 4 КБ, то он болтается в кэше и обновляется только запись в MFT (размер, в том числе). Как только сектор превысил 4 КБ, то он копируется в область файловых данных, запись MFT обновляется и снова по кругу. Сейчас нет времени разбираться, как работает ext4, для проверки я выложил выше .

[Vitekkz88]

Не факт, что у него будет так же, в ext4 вообще нет MFT

Я написал, что происходит на моей машине под Windows. Я наблюдаю изменение размера файла через свойства файла и через Get File Size Function.vi в LabVIEW.
Чет я не понял на счет кэша. Получается что запись ведется и в файл и в кэш-память что ли? Или из кэша данные копируются тогда и только тогда, когда размер данных равен размеру кластера? А до этого что, файл пустым находится?

[dadreamer]

Я написал, что происходит на моей машине под Windows. Я наблюдаю изменение размера файла через свойства файла и через Get File Size Function.vi в LabVIEW.

У меня так же:

На Windows размер файла и количество записанных данных строго совпадает. Это означает, что даже несмотря на небольшой размер файла, сведения о нём обновляются в MFT при каждой операции записи.

Винда такая же точно - W7 x64 Ultimate.

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

Да.

А до этого что, файл пустым находится?

Физически да, пуст или недозаписан на тот объем информации, что некратен 4 КБ. Если в такой момент выдернуть питание компьютера, то данные потеряются.

[Vitekkz88]

dadreamer, чет я запутался
Скорее он недозаписан до размера кластера, чем просто пуст.
Размер файла увеличивается до значения, кратного 4 кБ(размер кластера). То есть если мы записали 4 байта данных, то размер файла будет 4 кБ. Если записали 4.1 кБ, то размер файла выравнивается до 8 кБ и т.д.
Тем не менее, если данные копируются из кэша по 4 кБ, а до этого момента файл "как бы" пустой, то что тогда мы видим в файле? А видим там реально записанные данные. Значит файл просто недозаписан на объем информации размера кластера. И данные из кэша выгребаются более мелкими порциями вплоть до байта, не? Вон, я записал 2 числа uint32 - в итоге в файл положилось 8 байт.
То есть если в процессе записи этих скудных байт я вырублю питание - то всё пропало? А если я просто LabVIEW из диспетчера задач закрою - тоже всё пропало? Или убив процесс - данные будут продолжать выгребаться из памяти в файл?

[Borjomy_1]

Уважаемые коллеги! Хочу обратить ваше внимание на то, что в данном случае файл содержит логи. Для того, чтобы набрать 4кб логов, надо долго работать. Не факт что за сутки столько информации наберется. Поэтому лично я считаю, что в данном случае держать открытый файл - не лучшее решение.

[Vitekkz88]

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

Просматривать я могу без проблем(именно что касается текстового файла). Открываю и смотрю, какие данные записались->закрываю файл-> открываю вновь->смотрю. В это время запись данных из LabVIEW не прекращается.
Другое дело, если я этот файл пытаюсь переместить в другую директорию в процессе записи - это да, не получится.
Вы предлагали буферизировать данные совместно с таймаутом. Это рабочее решение, единственный недостаток - необходимость подобрать тайм-аут и учесть как часто могут прилетать сообщения. Тут же возникает вопрос: не возникнет ли каких-либо коллизий при постоянном открытии/записи/закрытии файла?
В целом за свою практику не встречал проблем с долго открытым или занятым файлом...Единственно, что не удавалось его перетащить сразу на флешку...приходилось делать копию.

[IvanLis]

Уважаемые коллеги! Хочу обратить ваше внимание на то, что в данном случае файл содержит логи. Для того, чтобы набрать 4кб логов, надо долго работать. Не факт что за сутки столько информации наберется. Поэтому лично я считаю, что в данном случае держать открытый файл - не лучшее решение.

За сутки набирается порядка 30кб .
Сделал следующим образом: в EventCase по таймеру, раз в 30 секунд выполняю Flush FIle.
Открытым его держать не очень, согласен, т.к. потери данных возможны при аварийном завершении, но в последнем случае мы потеряем данные только за последние 30 сек.
А вот открывать и закрывать его мне вообще не нравится, т.к. локальная папка в которой расположен файл постоянно синхронизируется с облаком, а это черевато косяками, можно потом его и не отыскать вообще, по этому и описал проблему.

В теорию работы файловой системы сейчас тоже не хочется вникать, да и времени нет.

[dadreamer]

Vitekkz88, да, я похоже поторопился с ответом. Физически на диск пишется каждый байт, просто маленькие файлы (до 4 КБ) хранятся прямо в MFT, а побольше - в основной файловой области. Так что ваша правда:

данные из кэша выгребаются более мелкими порциями вплоть до байта

Похоже, что не использует внутреннюю программную буферизацию, и для работы с файлами используются только стандартные вызовы WinAPI. Если, к примеру, взять другие IDE, например Delphi, то там данные в файл не пишутся, пока не накопится некоторый объем данных. Для физической записи на диск нужно делать FlushFile или сразу CloseFile.

То есть если в процессе записи этих скудных байт я вырублю питание - то всё пропало? А если я просто LabVIEW из диспетчера задач закрою - тоже всё пропало? Или убив процесс - данные будут продолжать выгребаться из памяти в файл?

Оказалось, что нет. Во всех трёх вариантах файл физически пишется на диск. Похоже, что закон сохранения энергии справедлив и для файлов (по крайней мере на NTFS под Windows): "Ничто не появляется из ниоткуда, и не исчезает в никуда"

Есть ещё один интересный момент - если выставить вход Open/Create/Replace File disable buffering в True, то файл будет писаться на диск, минуя кэш Windows. В некоторых случаях это даёт прирост в производительности. Однако запись должна производиться блоками, кратными размеру сектора диска (512 байт), иначе выдаст ошибку.