LINUX.ORG.RU

Многократное переписывание двух участков небольшого файла

 


0

1

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

При этом есть пара нюансов:

1) участки сначала надо найти, и они лежат в разных местах файла. Известно, что за неск. строк до каждого участка лежат строки с фиксированным содержанием типа «sS'progress'» или что то вроде того. С предыдущей перезаписи их позиция может не измениться, а может и измениться (в принципе это можно отследить).

2) текущей длины строк может и не хватить для нового содержимого.

Пока что в голову приходит только дубовое (и м.б. и самое правильное KISS) решение - прочитать по строчкам полностью, обновить нужные, записать по строчкам.

★★★★★

Последнее исправление: AIv (всего исправлений: 2)

Я думаю, что файл размером в килобайт не имеет смысла записывать частями. Прочитать полностью в память, изменить, записать обратно.

Deleted
()
Последнее исправление: renjumin (всего исправлений: 1)

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

anonymous
()
Ответ на: комментарий от anonymous

Да, это понятно, хотя Вы меня натолкнули на мысль - при каждом полном обновлении файла находить позиции этих двух строк и расширять их (нулями, там дабл лежит так что макс размер известен).

Вопрос с обновлением данных ин-плейс? Открывать файл в режиме rw, позиционироваться seek-ом и писать? Или маппировать?

И насколько это даст профиту, скажем для 1Кб, 10Кб, 100Кб? Про уперся сказать то сложно - это библиотека, дурной юзер может упереться в это сразу.

AIv ★★★★★
() автор топика

Насколько часто должно происходить переписывание файла? Сколько разных программ одновременно работают с этим файлом? Они все в этот файл пишут или только одна программа (твоя) пишет, а все остальные читают?

justAmoment ★★★★★
()
Ответ на: комментарий от justAmoment

Насколько часто должно происходить переписывание файла?

От раза в неск минут, до неск сотен раз в секунду.

Одна пишет, остальные читают. Возможно та что пишет пишет по сети (через NFS или SSHFS). Те что читают, не расстраиваются если файл неполный - ждут и читают еще раз.

AIv ★★★★★
() автор топика
Ответ на: комментарий от ansky

Например в базу данных писать?

Это и есть сама база, только специифическая и нереляционная;-)

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

Насколько часто должно происходить переписывание файла?

От раза в неск минут, до неск сотен раз в секунду.
Одна пишет, остальные читают. Возможно та что пишет пишет по сети (через NFS или SSHFS). Те что читают, не расстраиваются если файл неполный - ждут и читают еще раз.

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

super.db (--> split -->) = slow_refresh_part_1 + fast_refresh_part_1 + slow_refresh_part_2 + fast_refresh_part_2 + slow_refresh_part_3
fast_refresh_part_* - это быстрообновляемые десятибайтовые идентификаторы. Твоя программа ведёт запись только в эти файлы. Для уменьшения износа диска я бы их разместил на отдельно созданном ram диске в «/mnt/ram».

Так как программы потребители нетребовательны в плане скорости получения обновлённой информации, то создаём отдельного демона для склеивания через определённые промежутки времени всех частей в результирующий файл. Либо просто в crontab пишем наподобие такого (раз в 10 секунд):

cat slow_refresh_part_1 fast_refresh_part_1 slow_refresh_part_2 fast_refresh_part_2 slow_refresh_part_3 > super.db

justAmoment ★★★★★
()
Ответ на: комментарий от justAmoment

Ээээ... спасибо, но слишком заморочно -> потенциально нестабильно. Там и так проблем хватает, файл должен быть один и лежит он там где лежит.

Насколько я понимаю, с износом диска больших проблем нету - при частой записи оно все равно все в кэше диска болтается и до пластины не доходит?

AIv ★★★★★
() автор топика

С предыдущей перезаписи их позиция может не измениться, а может и измениться (в принципе это можно отследить).

Это значит что в файл пишут более одного процесса. Значит файл надо прочитать «распарсить», изменить, сохранить. Другого не дано.

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

anonymous
()
Ответ на: комментарий от anonymous

Это значит что в файл пишут более одного процесса.

Это значит, что один процесс может писать файл по разному.

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

А вот это тоже мысль, спасибо. Правда читать его не обязательно - я могу перехватить то, что сбрасывается в момент записи.

А чем это лучше переписывания фрагментов файла «прямо на диске»?

AIv ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.