[Comm] Kmail. Серьезная бага. sim

Алексей Синицын =?iso-8859-1?q?asinitsinster_=CE=C1_gmail=2Ecom?=
Пт Мар 21 19:04:23 MSK 2008


21.03.08, Sergey<a_s_y на sama.ru> написал(а):
> On Thursday 20 March 2008, Алексей Синицын wrote:
>
>  >   Первое что приходит - не начинать писать при заполненной ФС. Но
>  > против этого нам аргумент что оно заполнится во время записи.
>
>
> При пересоздании файла писать надо в _новый_ файл. В случае успешной
>  записи удалять старый и переименовывать. Но это дело приложений.
>  Возможно, для KDE достаточно переделать соответствующие функции в QT...
>

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

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

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

 Возможно описанное - это утопия.


Подробная информация о списке рассылки community