Дописывание в файл, взгляд изнутри.

[Пойманый_маньяк]

Дописываем строку в конец текстового файла, заурядное действие.

Что при этом меняется?
И в какой памяти (на диске / в ОЗУ) это что-то находится?

Разумеется не считая изменений в самом файле - с ними вроде все понятно

Размер файла в FAT таблице?
Записи в журнале об изменении файла?
Флаги какие-нибудь?
Контрольные суммы?
...

ОС Linux, файловая система вроде какая-то из ext, при необходимости можно уточнить.

[Corwin]

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

[BIL]

Указатель чтения-записи смотрит за последний байт файла.
ОС по записи о файле в каталоге получает номер первого кластера и размер.
По FAT перебирает кластеры в поисках последнего, заодно вычитая из размера файла пройденные кластеры.
Читает последний кластер. Точнее, вычисляет номер цилиндра, головку и сектор на устройстве с использованием геометрии устройства и номера кластера. Читает несколько секторов - размер кластера.
Контроллер устройства читает дорожку целиком (зависит от устройства). Передает секторы из нее, содержащие кластер, операционке.
ОС от начала кластера в памяти откладывает остаток от размера файла и по этому адресу копирует записываемый кусок. Предварительно захватив под это дело память.
Записывает этот же кластер на то же место.
Контроллер устройства считывает дорожку, накладывает записываемые секторы на место считанных. Записывает дорожку. (Возможна оптимизация операции в зависимости от устройства)
-
Если все в кластер не влезло, ОС ищет в FAT первый от ее начала свободный кластер. В адрес текущего кластера в FAT записывает номер найденного. Записывает кластер. Контроллер тупит как описано выше.
Повторяется пока данные не кончатся.
-
Новый размер файла фиксируется в каталоге с информацией о файле.
В случае ошибки занятые кластеры освобождаются. Размер восстанавливается.
В FAT журналирование не предусмотрено.
Пока ОС не решит, что пора (мало памяти, делать нечего или другие критерии) информация о содержимом FAT и каталогов останется в буферах в памяти. Следовательно, выключение компьютера приведет к несоответствию FAT и информации на диске.
Описанные операции чтения с диска не будут проводиться, если аналогичные операции уже производились. То есть, все уже закэшировано. Уж FAT-то точно. Ессно, и запись просто так не будет выполняться пока драйвер не решит, что накопилось достаточно для более-менее ёмкой операции, чтобы не гонять устройство.
В линуксе, примерно аналогично. Файловые системы более совершеннее (FAT не одна и не только в начале логического диска, область для записи проведенных операций и т.п.), смысл тот же.
Ну, флаги на FAT просто изменяются - если файл открывается для записи, при закрытии тупо поднимается атрибут Archive. Остальные вручную.
Контрольные суммы в FAT не хранятся. Суммы хранятся в "неинформационном" размере каждого физического сектора и следит за ними контроллер устройства аппаратно. Для ОС прозрачно.
Ну, и ессно, файловой системе параллельно текстовый файл или нет. Все лежит одинаково ровно.
По памяти...

[Пойманый_маньяк]

Перечитал, виноват - действительно многое не указал.
Лучше все опишу, во избежание...

Файловая система - ext3.
Диск - видимо SSD, точно на корпусах Samsung K9WAGO...
SSD вроде до 1 000 000.
K9WAGO... до 100 000 перезаписей.
Что в реале пока не понятно.
Необходимы архивы, заполняемые из C++ например.

Срез архива - байт 50 допустим.
Периодичность архивирования - 1 сек.
Файл FIFO соответственно отпадает - раз в секунду переписывать весь регистр 100 000 / (24 *60 * 60) = 100 000 / 86 400 ~ 1,2 суток.
Или для 1 000 000 перезаписей он продержится в таких условиях 12 суток.

Соответственно предполагалось создать файл с фиксированным размером, например 1 Мб.
И дописывать в него кусками архивные срезы.

Но при этом раз в секунду будут меняться его атрибуты
Например (проверили в 2-х консолях, в одной vi во второй stat) менялось время модификации файла.
Впрочем проверка не совсем чистая. Редактор это все-таки не запись в конец файла на С++.

Или я гоню? Такую возможность тоже ни в коем случае нельзя сбрасывать со счетов!

[MadBiker]

3: Пойманый_маньяк:
> Или я гоню?

Да, ты гонишь. Не для SSD эта задача

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

[Пойманый_маньяк]

4: MadBiker:

> Не для SSD эта задача

Знаю. Что дали...
Вопрос я поднял - дальше от меня мало что зависит.

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

Конкретики бы еще найти...
А то с одной стороны оптимизирует, а с другой виндовозный своп рекомендуют все-таки убить
И это настораживает.

[Пойманый_маньяк]

Будет этот контроллер постоянно смещать метаданные единожды открытого (раз в секунду его открывать и закрывать точно смысла нет) файла под Linux'ом?
Честно говоря не знаю

[MadBiker]

5: Пойманый_маньяк:

А объемы инфы большие должны хранится? А то в случае мегабайт - я бы попробовал бы что-то на FeRAM сделать.

Ну и флеше не метр бы перезаписывать, а один ее блок.

[MadBiker]

6: Пойманый_маньяк:
> Честно говоря не знаю

Тоже не знай. Но точно знаю, что каждая запись данных идет в новый блок, до тех пор, пока есть чистые.

[Пойманый_маньяк]

7: MadBiker:

> А то в случае мегабайт - я бы попробовал бы что-то на FeRAM сделать.

Там немного совсем.
Предложить - в любом случае можно

> Тоже не знай. Но точно знаю, что каждая запись данных идет в новый блок, до тех пор, пока есть чистые.

офтоп
Получается не исключено влияние имеющихся объемов свободной памяти...
/офтоп

[sister]

1. Для начала, я бы организовал RAM диск. (если это линух то всё просто)
2. Выбрать размер временного файла в RAM = размеру кластера.
3. Отключить журнал в ext3 (ext4 вообще нельзя использовать для ssd)
4. Копировать с RAM на SSD.

З.Ы. Сомневаюсь я, что контроллер SSD оптимизирует запись.

[Burg]

10: sister:
> З.Ы. Сомневаюсь я, что контроллер SSD оптимизирует запись

Зря )

[MadBiker]

9: Пойманый_маньяк:
> офтоп
>Получается не исключено влияние имеющихся объемов свободной памяти...
>/офтоп

Да, естественно. Именно это и отмечается во всех обзорах и тестах SSD.

10: sister:
> З.Ы. Сомневаюсь я, что контроллер SSD оптимизирует запись.

Не сомневайся. Это одна из основных его задач.

[Пойманый_маньяк]

Касательно SSD (будь они неладны)

Оптимизация SSD.

1. Для того, чтобы диск прослужил вам долго, нужно всё, что часто меняется (временные файлы, кеш браузера, индексирование) необходимо перенести на HDD, отключить обновление времени последнего доступа к папкам и каталогам (fsutil behavior set disablelastaccess 1). Отключить в ОС дефрагментацию файлов.
2. Перед установкой на SSD Windows XP, при форматировании диска рекомендуется выполнить «выравнивание» разделов кратным степени двойки (например, утилитой diskpart), иначе SSD придется делать 2 чтения вместо одного. Кроме этого у Windows XP есть некоторые проблемы с поддержкой секторов более 512кб (в SSD по умолчанию используется 4кб) и вытекающие отсюда проблемы с производительностью. Windows Vista, Windows 7, последние версии Mac OS и Linux выравнивают диски уже правильно.
3. Обновить прошивку контроллера, если старая версия не знает команду TRIM. Установить последние драйвера на SATA контроллеры. Например, если у вас контроллер от Intel, вы можете на 10-20% увеличить производительность, включив режим ACHI и установив Intel Matrix Storage Driver в операционной системе.
4. Не следует использовать последние 10-20% свободного пространства от раздела, потому что, это может отрицательно сказаться на производительности. Это особенно важно, когда работает TRIM, поскольку ему необходимо пространство для перегруппировки данных: для примера, похоже, работают утилиты дефрагментации, ведь им тоже нужно не менее 10% процентов от объема диска. Поэтому очень важно следить за данным фактором, ведь из-за небольшого объема SSD они очень быстро заполняются.

(c) http://www.storelab-rc.ru/ssd-review.htm

В общем при любом раскладе изменения времен доступа раз в секунду надо убивать к чертям свинячьим.
Пытаемся отключить сейчас...
И соответственно сидим и думаем дальше - есть ли в метаданных еще какая-нибудь постоянно меняющаяся гадость?

[Пойманый_маньяк]

12: MadBiker:

Я с ними до сих пор толком не сталкивался.
Слава Будде Сиддхартхе Гаутаме Шакьямуни Сигейт Вестерндиджитал...

[Burg]

13: Пойманый_маньяк:
Ставишь семерку и современные драйвера. Она уже корректно умеет работать с SSD. WinXP просто про SSD ничего не знает, отсюда и танцы с бубном.

[MadBiker]

15: Burg:
> Ставишь семерку и современные драйвера.

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

[Burg]

16: MadBiker:
Ну да, XP она конечно лучше

[MadBiker]

17: Burg: Я так понял, что изначально речь шла о чём-то линуксовообразном
А ХРюшка - чисто попытка разобраться, взята для примера.

[Hunter007]

Судя по размеру среза архива это, какой то микроконтроллер?
Тогда, можно вот это прикрутить http://elm-chan.org/fsw/ff/00index_e.html и допилить под себя.

[Пойманый_маньяк]

15: Burg:

Не, не получится.
X-Linux version 2.6.29.

[Burg]

19: Пойманый_маньяк:
ну так замечательно... на 2.6 уже есть ReiserFS в полный рост... он как раз для мелких файликов идеален с частыми перезаписями...

[Пойманый_маньяк]

20: Burg:

А откуда мне взять маленьких файлов?
[пытается соображать]
Можно конечно раз в секунду один создавать, другой удалять,
но это имхо как-то уж совсем...

Боюсь не понял тебя.

[Burg]

Да, ступил... Вообщем оптимально сделать файловую систему в памяти, а оттуда кидать раз в сколько-то времени... Хотя у тебя 1 раз в секунду... в принципе не нужно ничего промежуточного тогда. Достаточно настроить файловую систему так, чтобы она не меняла время последнего обращения к файлу и буфер побольше сделать... ну и журналирование тебе ни к чему там вообще.

[Пойманый_маньяк]

22: Burg:

Я все боюсь что кроме времени еще какая-нибудь пакость есть...


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

Вот и думаю - что там еще может такого быть... или не быть? Вот в чем метаданные...

[уходит с ребенкой в больницу, бубнит]
Пусть раненый журнал ревет,
А FAT16 скачет...
Где DOS, а где Open Enterprise Server, охренеть в общем.
Кому что hard назначит.

[djdance]

2: BIL:
> Указатель чтения-записи смотрит за последний байт файла.
>ОС по записи о файле в каталоге получает номер первого кластера и размер.
>...
абалдеть, сам писал?

[BIL]

ессно