Какие функции для работы с файлами на си вы предпочитаете?

bzip2

Смотрите что-нибудь нормальное

По стандарту

Интересна реальность.

а ты попробуй на практике жать гигабайты

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

я чётко сказала про HTTP. что-то непонятно?

Да, не понятно. В моём мире нет такого понятия как «HTTP пакет». Приведи, пожалуйста, номер RFC и страницу, на которой описывается структура этой сущности.

Гарантируют, иначе приложение надёжно записывающее данные сделать было бы принципиально невозможно.

Так ведь так и есть, невозможно его сделать в общем виде. Для какой-то заранее зафиксированной комбинации железа и ОС - можно (там где ты всё проверишь тщательно), для абстрактного линукса на неизвестно каком железе - нельзя. Максимум что делают - ведут журналы и надеются, что, во-первых, длины журнала хватит на нейтрализацию неизвестной writeback-самодеятельности на всех уровнях, а во-вторых - последняя значимая запись в журнале успеет записаться до того, как начнут записываться соответствующие ей записи основных данных. Иногда и это не помогает, и хранилище разваливается после какого-нить неожиданного жёсткого ребута.

Так ведь так и есть, невозможно его сделать в общем виде.

Я не знаю что вы хотите сказать этой фразой. Невозможно сделать корректно работающую систему на некорректно работающих примитивах, да. Но такой задачи и не стоит. Задача - построить корректно работающую систему на корректно работающих примитивах. Для этого достаточно полагаться на закреплённое в стандарте поведение fsync.

Максимум что делают - ведут журналы и надеются

При построении хранилищ никто ни на что не надеется (и журналы совершенно не обязательны, есть ещё MVCC).

Для этого достаточно полагаться на закреплённое в стандарте поведение fsync.

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

И учти что диски не обязательно локально видны операционной системе. Они могут быть спрятаны за слоем виртуалочного гипервизора, они могут быть сетевыми на отдельной железке, у которой внутри ещё пачка слоёв абстракций, или же и то и другое вместе. Да что там говорить, я сам на zfs-based nas-е в проде отключил sync т.к. с ним тормозит. Так что даже если ОС думает что она записала данные «на диск» - на самом деле они висят в оперативной памяти схд в кеше zfs и ждут записи. Но, если что, уверен, что это совсем не единственное место в цепочке абстракций, где запись может оказаться молчаливо отложенной.

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

я просто в это не верю. потому что лично гоняла много тестов со сжатием данных. и в 99% случаев оно приводи только к проседанию.

Надеюсь, ты хоть в этом веке тестировала сжатие в файловой системе? И не помирающее легаси в виде gzip/bzip2, а современные типа lz4, zstd-fast + на современном железе с SIMD-инструкциями проца.

При распаковке, на процах, к примеру, AMD EPYC 64c128t или Intel Xeon 56c112t, можно достичь суммарных скоростей в десятки и даже сотни гигабайт в секунду при сжатии lz4 или zstd-fast. Ограничивающим фактором чаще всего становится скорость памяти и I/O подсистемы, а не сам алгоритм. Нынче DDR5 дают суммарную пропускную способность ~150–200 GB/s, так что на практике потолок будет около этого уровня. При таких скоростях и аппаратной акселерации, даже на сверхбыстрых nvme имеет смысл юзать сжатие по причинам, которые прекрасно расписал аноним выше.

Что касается сжатия уже сжатых данных, как уже выше аноним упомянул, на тех же btrfs и ZFS давным давно есть эвристика. К примеру, ZFS сначала делает пробное сжатие и если результат не уменьшился хотя бы на 12,5%, блок сохраняется несжатым. В btrfs – аналогично. Даже в F2FS есть что-то подобное.

П.С: Когда-то давно тестировал работу 100гиговой БД на сжатом lz4 ZFS датасете и быстрых nvme дисках. И каково было мое удивление, когда я заметил прирост скорости выполнения запросов (с непрогретыми кешами, естественно) на 15-20% при несущественно-увеличенной нагрузке на проц.

Ограничивающим фактором чаще всего становится скорость памяти

ты же понимаешь, что это чушь. для DDR4 это примерно 20-25 гб/с ты с такой скоростью распаковывать точно не сможешь. хотя бы потому, что тебе по этой же шине надо ещё и читать входные данные.

Когда-то давно тестировал работу 100гиговой БД на сжатом lz4 ZFS датасете и быстрых nvme дисках. И каково было мое удивление, когда я заметил прирост скорости выполнения запросов (с непрогретыми кешами, естественно) на 15-20% при несущественно-увеличенной нагрузке на проц.

возможно, плохо тестировал. тесты тоже надо уметь писать.

з.ы. чудес не бывает.

для DDR4 это примерно 20-25 гб/с ты с такой скоростью распаковывать точно не сможешь

DDR5-6400 дает 6400 MT/s что примерно 51,2 GB/s. На сокете с 4 каналами примерно 150–200 GB/s. 8-миканальные Xeon/EPYC до 800 GB/s. Распаковывая многопоточно, на мощном камне, можно достичь скоростей существенно больше 20-25 GB/s.

возможно, плохо тестировал. тесты тоже надо уметь писать.

Нормально тестировал, и не один раз.

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

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

та же фигня, как с «ИИ», когда за какими-то втюханными юзерам «параметрами» они не видят элементарной лажи с мусорными данными.

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

нельзя ничего ускорить или улучшить, не потеряв при этом в ресурсах

А я разве утверждал противоположное? За ускорение операций файловой системы я плачу небольшим приростом потребления ЦПУ. Чем новее железо и «оптимизированнее» алгоритм сжатия/распаковки (для тех данных, с которыми работаю) – тем эта плата меньше.

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

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

Про ожидание в состоянии D я уже писал.

Чем новее железо и «оптимизированнее» алгоритм сжатия/распаковки (для тех данных, с которыми работаю) – тем эта плата меньше.

Я несколько лет назад с радостью заметил, что скорость работы с шифрованным разделом на nvme больше не упирается в проц, запись/чтение идет со максимальной скоростью, с которой nvmе может работать. А один поток на 128 потоковом проце с восьмиканальной памятью на остальную систему практически не влияет.

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

На самом деле бывают чудеса: в вычислительной системе очень много разных ресурсов, живущих одновременно и весь цимес в том, что один разработчик умеет их припахать одновременно, а второй разработчик использует их последовательно. Ну например в процессоре все транзисторы существуют физически одновременно в любой момент времени, вопрос только в том, сможете вы им найти работу прямо сейчас или заставите одни транзисторы ждать других транзисторов, так и со всеми остальными системами/подсистемами. Тут главное, чтобы блоки питания выдерживали максимальные токи)

А я разве утверждал противоположное? За ускорение операций файловой системы я плачу небольшим приростом потребления ЦПУ.

Да и не сильно-то ты платишь чаще всего. Чаще всего это всё бесплатно, потому что не загружен у тебя процессор этими действиями всё время и чаще всего просто молча грустит.

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

я считаю, что это хорошо, когда процессор «молча грустит». по крайней мере, на юзерском компе точно. для себя я всегда имела негласное правило, что если мой софт на юзерском компе отжирает больше 1% проца, то это плохо и с софтом надо что-то делать, как-то его оптимизировать. но это, конечно, не относится ко всяким молотилкам с перекодированием, математикой, криптографией и прочим подобным на серверах, которые специально под эти задачи выделены. там надо нагружать проц по максимуму, для максимальной производительности.

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

Не «очень сложно», а «неоправданно дОрого для определённого класса задач». Вы упорно проецируете свой опыт на всех и напрочь игнорируете цену переключений контекста, а она ох какая ненулевая…

Хотел принести два чая под комент. Но Лор запретил. Потому на правах сообщения выражаю поддержку.

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

что явная манипуляция

нисколько.

что это параллельные потоки создают переключения контекстов.

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

но если ваш однопоточный софт работает на машине не монопольно (что обычно и происходит), то там точно так же переключаются контексты и вот это всё.

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