Виртуалка просирает данные.

Тогда уж fsync ставить сразу после write

fsync ставить сразу после write

плюсирую, ибо если этого не сделать после write, то не дождавшись close - оно всё похерит

плюсирую, ибо если этого не сделать после write, то не дождавшись close - оно всё похерит

Что кого похерит? С чего бы? Что значит «не дождавшись close», при чём тут это? После серии write стоит fsync(). write делаются друг за другом в одном потоке с одним файловым дескриптором. fsync(fd) обязан довести весь поток (всю последовательность байтов) до устройства (которое может буферизовать, но это щас неважно).

Разве ребут машин на хостинге не предполагает некоторое время, данное пользователям на завершение процессов? Или это аварийный сброс питания? Тогда этот момент надо тестировать.

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

P.S. А fflush где? Если поставить fflush перед fsync, я не знаю, может поможет, хз.

https://stackoverflow.com/questions/2340610/difference-between-fflush-and-fsync

Вкратце: fflush() - это херня, fsync() - это круче.

У меня такая ситуация была, на OpenSUSE 11.3. Жесткие диски были WD Blue на 500гб. Проявлялось на десятках компов после внезапного отключения питалова. fsync не помогал (если ничего не путаю). Было в 2010 году примерно. Так и не решил проблему. Потом стало не нужно.

P.S. А fflush где? Если поставить fflush перед fsync, я не знаю, может поможет, хз.

fflush это stdio, вообще сюда никаким боком.

Подобное я видел на некоторых промышленных SSD дисках, которые вроде как для жестких условий эксплуатации спроектированы. Тем не менее, там что-то клинило так, что даже журналируемая ФС не спасала даже от однократного неправильного выключения питания, при том что не было интенсивных процессов записи. Просто крутилась ОС на компе и он просто выключался внезапно. Слетели системные файлы, которые read only были. Такие дела.

Если это проблема диска - тогда капец. Поэтому, если ТС воспроизводит сценарий на рабочем компе и всё окей, а на хостинге пичалька - тогда это может даже и не лечится...

Не нужно никаких fflush, и не нужно fsync никуда двигать. Код правильный, за исключением того что нужно обязательно проверять статусы fsync и close.

Как будто его порубили на куски и немного подвигали эти куски с копированием, обрезанием и наслоением этих кусков

seek'и в коде есть? Если нет, так быть не может. Файл может не дописаться, но порядок блоков гарантирован. Иначе у хостера всё плохо, какое-то совсем больное дерьмо с хранилищем, возможно дедубликацией.

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

seek в коде нет. Код именно тот, что приведён. А точнее он такой:

bool posix_mem_to_file_buffchain(const char *_filename, const std::vector<fir::str::BuffPtr> &_buffchain, bool _fsync)
{
	int fd = open(_filename, O_CREAT | O_TRUNC | O_NOATIME | O_RDWR, S_IRUSR | S_IWUSR | S_IRGRP);
	if ( fd < 0 ) {
		LOG_ERROR("posix_mem_to_file, open(): " << strerror(errno));
		return false;
	}

	ssize_t r = 0;
	for ( auto &buff : _buffchain ) {
		r = write(fd, buff.ptr, buff.size);
		if ( r < 0 ) {
			LOG_ERROR("posix_mem_to_file, write(): " << strerror(errno));
			return false;
		}

		if ( r != (ssize_t)buff.size ) {
			LOG_ERROR("posix_mem_to_file, write(): " << r << " / " << buff.size);
			return false;
		}
	}

	if ( _fsync ) {
		r = fsync(fd);
		if ( r < 0 ) {
			LOG_ERROR("posix_mem_to_file, fsync(): " << strerror(errno));
			return false;
		}
	}

	r = close(fd);
	if ( r < 0 ) {
		LOG_ERROR("posix_mem_to_file, close(): " << strerror(errno));
		return false;
	}



	return true;
}

Да, в коде малость не хватает close(fd) на ошибках.

когда после этой процедуры через пару МИНУТ следует внезапный ребут

Внезапный ребут чего? Системы внутри виртуальной машины без перезапуска самого гипервизора (qemu-kvm, например)? Перезапуск гипервизора (killall -9 qemu-kvm) или всего хоста, на котором у хостера виртуалки крутятся? Во втором случае возможно у хостера стоят небезопасные настройки кеширования записи для блочных устройств, шобы у юзеров больше иопсов было =).

Порядок записи блоков на диск может отличатся от порядка вызова write. Тоесть похоже у вас ситуация такая:

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

Потом по немногу начинают сбрасыватся блоки на диск (не обязательно в том порядке в котором они записывались)

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

Нет, ребут происходит точно после fsync(). А если он произошёл до fsync(), значит он произошёл до rename() и этого временного файла никто не увидит - на него всем пофиг.

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

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

Файлу O_DIRECT и O_SYNC в open, виртуалке nocache/directio на диск.

Глюки с ренейм - выглядит как глюки твого линукса.

Глюки с порчей данных - это скорее всего глюки драйвера файловой системы на хосте или драйвера стораджа или самого стораджа.

Вообще неработоспособность fsync() это притча во языцех, и наиболее простым лекарством является umount().

Глюки с ренейм - выглядит как глюки твого линукса.

Что за «глюки с ренейм»?

// А пока не произойдёт этого rename, наша работа вообще никому не видна.
rename(filename_tmp, filename);

А вообще - напиши больше о файлухах, стораджах и всякое такое.

А вообще - напиши больше о файлухах, стораджах и всякое такое.

Чё?

Включи флаг синхронной записи в вызов open(). Там вроде есть какой-то, типа O_SYNC.

Уровень журналирования разный бывает. Обычно журналируют только структуру ФС, ибо перформанс.

Уровень журналирования разный бывает

Хм, интересно. А read-only файлы сдохли потому что соседний блоки заделись?

Как могут read-only похериться - хз. Может, во время записи файла директории. Но это лучше у спецов по накопителям и файловым системам спрашивать. Может, придумают сценарии.

Я думаю что у него на сервере какойто дешовый PCIe SSD, а рид-онли блоки были на томже секторе NAND что и RW.