Как происходит синхронизация при записи в файл?

@gGrn-7DA · Регистрация: 17.01.2010

Студворк — интернет-сервис помощи студентам

начало

Меня тоже вопрос мучал, но однажды (когда "потерял" курсовую) я смирился.

Вопрос вот в чем.

После исчезания окна копирования/перемщения, в тот момент когда вроде бы "уже все записано", фактически записаны далеко не все данные.
Они зависают на пути к устройству в ?системном? кеше, где ожидают своей очереди. И ожидать они там могут достаточно долго - несколько секунд.

В случае же отмонтирования устройства, выполняется очистка буфеорв и кешей устройства.
При этом данной задаче выдается повышенный приоритет(?), для скорейшего выполнения.

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

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

Так почему же при окончании копирования файлов не вызывается очистка кеша устройства? это напрягает.
Ведь всех на первом курсе учили вызывать метод flush перед закрытием дескриптора файла/потока?
Так почему? почему при "закрытии" файла, завершении приложения (или это только поток? - наврядли) данные все так же лежат в кеше???
_____________________________

Не по теме:

могу ошибаться в некоторых моментах

@_1_ · 21.04.2013, 17:38

Сообщение от gGrn-7DA

После исчезания окна копирования/перемщения, в тот момент когда вроде бы "уже все записано", фактически записаны далеко не все данные.
Они зависают на пути к устройству в ?системном? кеше, где ожидают своей очереди. И ожидать они там могут достаточно долго - несколько секунд.

Когда вызывается sys_read, ядро первым делом просматривает страничный кэш. И если находит в нём требуемый чанк, то не трогая устройства передаёт его пользователю(cache-hit). А если не находит, то считывает его в страничный кэш и даёт копию пользователю(cache-miss).
Когда вызывается sys_write, ядро пишет в страничный кэш и помечает соответствующие страницы как "грязные". Такие страницы копируются на диск если:
Если нет свободной памяти, но высрать её откуда то надо. /proc/sys/vm/min_free_kbytes /proc/sys/vm/dirty_background_bytes
Если страница была грязной дольше чем /proc/sys/vm/dirty_expire_centisecs сотых секунд, то при следуещем пробуждении синхронизирующих потоков, она будет копирована на диск.
Если пользователь сделал системный вызов типа sync, umount... /proc/sys/vm/drop_caches этого кстати не делает
После копирования на устройство они разумеется остаются и в страничном кэше. И могут "зависать" там ооооочень долго

Сообщение от gGrn-7DA

1)Во время записи больших файлов таки указывается скорость записи, значит сбор кешей периодически выполняется
2)(наверно тут дейстует ограничение на размер кеша для одного процесса.потока.устройства?)

1) если под "сбором кешей" имеется ввиду частота вызова потоков синхронизирующих диски с кешем, то это /proc/sys/vm/dirty_writeback_centisecs. если = 0, то по таймеру они не вызываются вообще
2)ограничения на размер кеша для процесса нет. Кеш привязан к данным, а не процессам, запрашивающим эти данные. Чему лежать в кеше решает LRU/n алгоритм, в линуксе n=2, то есть ключевую роль играет время последнего доступа. Есть ограничение на объём грязных страниц процесса, который производит записи /proc/sys/vm/durty_bytes

Сообщение от gGrn-7DA

Так почему же при окончании копирования файлов не вызывается очистка кеша устройства? это напрягает.

"Конец копирование" это я так понимаю закрытие файла-копии. С чего бы кеш должен очищаться? Если под очисткой имелся ввиду процесс синхронизации страничного кеша и дисков, то примерно такого поведения можно добиться, смонтировав диск с параметром flush. А просто так при закрытии файла ничего не синхронизируется. Некоторые неразумные программисты к примеру любят закрыть и открыть файл, чтобы переместиться таким образом на начало. Так что нет нужды в этом

Сообщение от gGrn-7DA

Ведь всех на первом курсе учили вызывать метод flush перед закрытием дескриптора файла/потока?

fflush(FILE) или любые его аналоги в iostream из C++ не синхронизируют содержимое страничного кеша с диском. Пример

C
1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>
 
int main ()
{
  FILE * pFile;
  char buffer[] = { 'x' , 'y' , 'z' };
  pFile = fopen ( "myfile.bin" , "wb" );
  for (int i = 0; i < 10; i++) {
    fwrite (buffer , 1 , sizeof(buffer) , pFile );
  }
  fclose (pFile);
  return 0;
}

Bash
1
2
3
4
5
6
7
8
strace ./a.out
 
open("myfile.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f76a8e98000
write(3, "xyzxyzxyzxyzxyzxyzxyzxyzxyzxyz", 30) = 30
close(3)                                = 0
munmap(0x7f76a8e98000, 4096)            = 0

То есть fwrite при первом вызове выделил страницу памяти под буффер, а на всех последующих вызовах просто писал в него и в конце одним write'ом всё это дело записал. А fflush вообще ничего не сделал, не вызвал ни sync ни fsync. То что записано write'ом, будет записано в кеш, а когда эти данные попадут на диск, описано в начале сообщения. Это может случиться очень нескоро. Но если смонтирована фс с опцией sync тогда сразу данные попадают на диск

А если fflush поставить так

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <stdio.h>
 
int main ()
{
  FILE * pFile;
  char buffer[] = { 'x' , 'y' , 'z' };
  pFile = fopen ( "myfile.bin" , "wb" );
  for (int i = 0; i < 10; i++) {
    fwrite (buffer , 1 , sizeof(buffer) , pFile );
    fflush(pFile);
  }
  
  fclose (pFile);
  return 0;
}

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
open("myfile.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6ce219b000
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
write(3, "xyz", 3)                      = 3
close(3)                                = 0
munmap(0x7f6ce219b000, 4096)            = 0

то есть fflush всего лишь "сбрасывает кеш" сишной библиотеки, которая никакого отношения к страничному кешу не имеет. Данные на диск реально не записываются. Это делает fsync

Сообщение от gGrn-7DA

Так почему? почему при "закрытии" файла, завершении приложения (или это только поток? - наврядли) данные все так же лежат в кеше???

Данные лежат в кеше пока они кому то нужны. "Нужность" определяется LRU/2 алгоритмом, а закрытия каких то файлов или завершение каких то приложений на это особо не влияет. Они и после записи на диск ещё долго могут лежать в кеше

accept · 22.04.2013, 06:28

Сообщение от _1_

То есть fwrite при первом вызове выделил страницу памяти под буффер, а на всех последующих вызовах просто писал в него и в конце одним write'ом всё это дело записал.

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

Сообщение от _1_

C
1
FILE * pFile;

потом fclose() вызывает fflush()

@_1_ · 22.04.2013, 08:45

Сообщение от _1_

То есть fwrite при первом вызове выделил страницу памяти под буффер, а на всех последующих вызовах просто писал в него и в конце одним write'ом всё это дело записал.

Сообщение от accept

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

К чему относится "не"? Где здесь противоречие? Я ничего и не говорил про местонахождение буффера. Но выделил его именно fwrite именно mmap'ом. А где указатель на буффер хранится для данного примера не более чем маловажная деталь реализации

Сообщение от accept

потом fclose() вызывает fflush()

И поэтому из моего первого примера fflush перед fclose исчез? Спасибо конечно за перенос сообщения и добавления тегов, когда я забываю добавлять их сам. Но внутреннее содержание попрошу не редактировать. Я взял пример с http://www.cplusplus.com/reference/cstdio/fwrite/ добавил цикл и вставил fflush перед fclose, чтобы всем было очевидно что он вызывается, а не только задротам читающим мануалы. Но вроде я сейчас смотрю, а он куда то исчез. Или может быть меня память подводит, и я сам забыл его написать? Чудеса какие то вообщем происходят

accept · 22.04.2013, 10:26

Сообщение от _1_

Но выделил его именно fwrite именно mmap'ом.

а, ну да, проверил: если буфер не выделен, то выделяет его первая записывающая функция
я думал, его выделяет fopen()
(вообще, от реализации зависит, когда он выделяется)

Сообщение от _1_

И поэтому из моего первого примера fflush перед fclose исчез?

его там и не было

Сообщение от _1_

добавил цикл и вставил fflush перед fclose

не, ты что-то перепутал
код не редактировался вообще

fflush() ты вставлял только во втором примере

Сообщение от _1_

Или может быть меня память подводит, и я сам забыл его написать?

я думаю, ты его хотел написать, и не написал

вот из этой фразы следует

Сообщение от _1_

А fflush вообще ничего не сделал, не вызвал ни sync ни fsync.

@_1_ · 22.04.2013, 18:43

ну ладно тогда

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@gGrn-7DA мну довольно <(-__-)l 217 / 206 / 15 Регистрация: 17.01.2010 Сообщений: 2,462

	Как происходит синхронизация при записи в файл? 21.04.2013, 10:14. Показов 2362. Ответов 5 Метки нет (Все метки) начало Меня тоже вопрос мучал, но однажды (когда "потерял" курсовую) я смирился. Вопрос вот в чем. После исчезания окна копирования/перемщения, в тот момент когда вроде бы "уже все записано", фактически записаны далеко не все данные. Они зависают на пути к устройству в ?системном? кеше, где ожидают своей очереди. И ожидать они там могут достаточно долго - несколько секунд. В случае же отмонтирования устройства, выполняется очистка буфеорв и кешей устройства. При этом данной задаче выдается повышенный приоритет(?), для скорейшего выполнения. Вопрос, почему же данные висят в памяти в течении секунд меня тоже мучал, ведь, это же флешка. Скорость записи порядка нескольких мегабайт, но даже при копировании маленьких файлов можно этот файл потерять.. Во время записи больших файлов таки указывается скорость записи, значит сбор кешей периодически выполняется (наверно тут дейстует ограничение на размер кеша для одного процесса.потока.устройства?) Иначе скорость записи может оказаться заоблочной (если хватит оперативной памяти). Так почему же при окончании копирования файлов не вызывается очистка кеша устройства? это напрягает. Ведь всех на первом курсе учили вызывать метод flush перед закрытием дескриптора файла/потока? Так почему? почему при "закрытии" файла, завершении приложения (или это только поток? - наврядли) данные все так же лежат в кеше??? _____________________________ Не по теме: могу ошибаться в некоторых моментах 0

@_1_ deleted 177 / 50 / 5 Регистрация: 29.03.2013 Сообщений: 365
	22.04.2013, 18:43
	ну ладно тогда 0