Программирование[11]

Думаю хули грогуфа сегодня мало в политпомойках, а его тут уже ебут

GoldRobot написал 9 минут назад:

Но ведь все наоборот...

Я даже не представляю, какая должна быть реализация в gcc, чтобы было наоборот.

Grohuf написал 1 минуту назад:

GoldRobot написал 10 минут назад:

Но ведь все наоборот...

Я даже не представляю, какая должна быть реализация в gcc, чтобы было наоборот.

У тебя просто ОС неправильная.

ГЦЦ для винды ведь есть, проверь с ним, вангую у тебя как было так и останется.

И БТВ я не уверен что твой тест покрывает все кейсы. Скорее всего увиличи ты объемы записи, то на лине оба теста провалятся.

А Грохуф на винде запускал?

Там вообще хз какие гарантии даются 

Но дата рейсы на самом деле не тестируются никак. Даже если  всевозможные случаи прерываний сгенерировать. Из-за того что исполнение машинной инструкции неатомарно. 

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

GoldRobot написал 6 минут назад:

Grohuf написал 12 минут назад:

GoldRobot написал 21 минуту назад:

Но ведь все наоборот...

Я даже не представляю, какая должна быть реализация в gcc, чтобы было наоборот.

У тебя просто ОС неправильная.

ГЦЦ для винды ведь есть, проверь с ним, вангую у тебя как было так и останется.

 

И БТВ я не уверен что твой тест покрывает все кейсы. Скорее всего увиличи ты объемы записи, то на лине оба теста провалятся.

Скорее всего в твоей реализации gcc открывает файл на запись без буферизации и использует свой непотокобезопасный буфер. Единственное возможно объяснение.

besteady написал Только что:

Там вообще хз какие гарантии даются 

Как раз-таки там все понятно.

Если бы у меня не заработало с fstream, то я бы просто использовал системные функции и там 100% все бы отработало как ожидается.

Увы но нет, наоборот что бы без буферов работать это нужно очень постараться. Тот же флуш только из твоего буффера приложения вытолкнет, но никто не гарантирует что система решит прям щас что-то записать, а не через несколько секунд.

GoldRobot написал 3 минуты назад:

Увы но нет, наоборот что бы без буферов работать это нужно очень постараться. Тот же флуш только из твоего буффера приложения вытолкнет, но никто не гарантирует что система решит прям щас что-то записать, а не через несколько секунд.

Интересная у вас операционка, которая выходит из flush до того, как произведена запись на диск. Впрочем, после небольшого знакомства с линукс я ее странностям не удивляюсь.

Grohuf написал 2 минуты назад:

GoldRobot написал 7 минут назад:

Увы но нет, наоборот что бы без буферов работать это нужно очень постараться. Тот же флуш только из твоего буффера приложения вытолкнет, но никто не гарантирует что система решит прям щас что-то записать, а не через несколько секунд.

Интересная у вас операционка, которая выходит из flush до того, как произведена запись на диск. Впрочем, после небольшого знакомства с линукс я ее странностям не удивляюсь.

Не, такого не должно быть 

Флаш должен дождаться записи в физическую память диска 

besteady написал Только что:

Grohuf написал 3 минуты назад:

GoldRobot написал 7 минут назад:

Увы но нет, наоборот что бы без буферов работать это нужно очень постараться. Тот же флуш только из твоего буффера приложения вытолкнет, но никто не гарантирует что система решит прям щас что-то записать, а не через несколько секунд.

Интересная у вас операционка, которая выходит из flush до того, как произведена запись на диск. Впрочем, после небольшого знакомства с линукс я ее странностям не удивляюсь.

Не, такого не должно быть 

Флаш должен дождаться записи в физическую память диска 

Так и знал. Очередная наебка от ГР.

флаш должен дожидаться пока ос вернет вызов флаша назад

но если ос наебывает, язык ничего не поделает

Grohuf написал 24 минуты назад:

выходит из flush до того, как произведена запись на диск

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

А ты уверен что на винде std::fstream::flush прям на диск записывает?

besteady написал 20 минут назад:

Флаш должен дождаться записи в физическую память диска 

Ах если бы 

Kant said 9 minutes ago:

флаш должен дожидаться пока ос вернет вызов флаша назад

но если ос наебывает, язык ничего не поделает

Очень трудно верить твоим словам, ведь ты играешь в геншин импакт

ты кто вообще?

GoldRobot написал 3 минуты назад:

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

А ты уверен что на винде std::fstream::flush прям на диск записывает?

Без понятия, ни разу в реальной работе std стримы не использовал.

GoldRobot написал 5 минут назад:

Grohuf написал 29 минут назад:

выходит из flush до того, как произведена запись на диск

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

А ты уверен что на винде std::fstream::flush прям на диск записывает?

 

besteady написал 26 минут назад:

Флаш должен дождаться записи в физическую память диска 

Ах если бы 

 

Приду домой чекну сорсы stdlibc++ 

Grohuf написал Только что:

Без понятия, ни разу в реальной работе std стримы не использовал.

Ну прост в посиксе у тебя есть fflush и fsync. Я думал на винде тоже.

besteady написал 25 минут назад:

Не, такого не должно быть 

besteady написал Только что:

Приду домой чекну сорсы stdlibc++ 

https://en.cppreference.com/w/cpp/io/basic_ostream/flush

Описание ostream::flush, зовет pubsync, которое уже зовет sync буфера

Буфером в остриме является

https://en.cppreference.com/w/cpp/io/basic_filebuf

И собственно вот описание его синка.

https://en.cppreference.com/w/cpp/io/basic_filebuf/sync

Цитата

If a put area exists (e.g. the file was opened for writing), calls overflow() to write all pending output to the file, then flushes the file as if by calling std::fflush.

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

а в чем вообще смысл в посиксе флаша, если он не синхронизирует с диском?

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

Потому что ОС лучше знает когда собственно писать на диск. Ты флуш обычно зачем зовешь? Что бы если в корку упадешь или кто-то kill -9 позовет быть увереным, что в файил все записалось что ты собственно пытался записать. Что бы там были целые данные типа (в теории, мне не помогло, но может где-то в другом месте косяк был). Позвал флуш, и все, ты свободен, ты знаешь что данные скинулись в буффер и в ближайшее время ОС запишет. Даже если ты в корку упадешь. Это довольно быстро и не парит систему.

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

Я так понял идея была в этом. Ну и плюс где-то упоминания видел что fsync и аналоги не кросплатформено. Не ебу почему fflush кросплатформено, а fsync нельзя было.

Kant написал 23 минуты назад:

но не получить при этом никаких гарантий записи этих данных?

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

бтв на винде все тоже самое

https://docs.microsoft.com/en-us/cpp/c-runtime-library/stream-i-o?view=msvc-170

Цитата

Use fflush or _flushall to ensure that the buffer associated with a specified file or all open buffers are flushed to the operating system, which can cache data before writing it to disk. The commit-to-disk feature ensures that the flushed buffer contents are not lost in the event of a system failure.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fflush?view=msvc-170

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/commit?view=msvc-170

Пиздец сколько у меня опечаток а. Постоянно буквы местами путаю. Как вы всю эту кашу читаете не представляю.

Это не говоря о грамматике и прочем.

не ну ос конечно всегда умная, но в итоге я дождавшись флаша считаю что файл записан, а тут диск подвис и комп к хуям крашится, а я уже отправил по сети ответ, что всё ок

итого я наебал

то есть я понимаю, что две разных функциональности и два разных метода, но нахуя хоть кому-то нужен флаш без фсинка, мне не понятно всё равно

так можно и транзакции в бд не делать, а просто верить, что дальше всё запишется успешно

Ну допустим логи. Их часто флушат, что бы если ты сигфолт получишь, ты мог по ним хоть что-то разобрать.

А вот писать на диск каждую строчку лога будет слишком жирно.

Или вот другая ситуация, мне нужно CDR файлы писать. Это важно, и хотелось бы что бы оно было записано по возможности максимально корректно и полно все, только без фанатизма, это не критичные данные. И опять же на 10 тысяч рач в секунду звать запись в диск, на каждое сообщение, будет ну слишком жирно. Ладно, буду реже звать fsync сделая счетчик там таймер. А как часто можно звать? 2 тысячи раз? Тысячу? А если диск другой? А на другой инсталяции? А если конфигурации ФС сменится или виртуалку в другой датацентр перевезут? А если рядом со мной один мой инстанс подымут, идти и на всех модулях конфигурацию менять?

Вот что бы все эти вопросы не решать, я позову флаш и ОС имея полную информацию о происходящем максимально оптимально запишет потом на диск мои данные. И я не встану в лок на fsync потому что там кто-то начал файлики в большом каталоге сканить. Или греп по логам сделал.

Я думаю наши специалисты грофухи и вованы могут еще много тоже реальных кейсов из своей практики рассказать когда fsync будет дорого, а флуш уже покрывает задачи.