#fsync — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #fsync, aggregated by home.social.
-
[Перевод] Гейминг под Linux становится быстрее, потому что Windows API превращаются в фичи ядра Linux
В марте 2026 года доля пользовательской базы под Linux в Steam впервые перевалила за 5% — рекорд для операционной системы, гейминг для которой был чем-то непривычным два десятка лет. В октябре компания Microsoft объявила дедлайн завершения срока поддержки Windows 10, что заставило многих пользователей искать альтернативы, а Steam Deck втихомолку превратил миллионы людей в Linux-геймеров, что привело к ещё более широкому использованию этой ОС на десктопных машинах. Основной прогресс раньше происходил в ПО под названием Wine: слое трансляции, убеждающем игры для Windows в том, что они запущены под Windows. Steam Play и Steam Deck работают благодаря специализированной версии Wine под названием Proton , разрабатываемой Valve. Многие годы все существенные улучшения гейминга под Linux были связаны с изменениями в самих Wine и Proton. И это по-прежнему так, но всё больше важных изменений вносится и в слое уровнем ниже — внутри ядра Linux. Последним примером этого можно считать NTSYNC — драйвер уровня ядра, обеспечивающий огромный рост производительности по сравнению со старыми версиями Wine и загруженный по умолчанию во все современные Steam Deck.
-
Ah, the daring heroes at #FractalBits have valiantly declared war on fsync! 🚫💾 They’ve concocted a magical brew of preallocation and ODIRECT, sprinkled with #SSD pixie dust, to create a #storage engine that defies danger yet stands valiantly alone like the last kid picked for dodgeball. 🏆🥴
https://fractalbits.com/blog/remove-fsync/ #fsync #innovation #technology #heroics #HackerNews #ngated -
[Перевод] MariaDB 12.3: binlog внутри InnoDB
Коротко для ленивых В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb . Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency. В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x . Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения. Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo. Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.
https://habr.com/ru/articles/1011298/
#MariaDB_123 #InnoDB #binlog #GTID #репликация #производительность_SQL #crash_recovery #fsync #OLTP
-
[Перевод] MariaDB 12.3: binlog внутри InnoDB
Коротко для ленивых В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb . Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency. В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x . Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения. Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo. Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.
https://habr.com/ru/articles/1011298/
#MariaDB_123 #InnoDB #binlog #GTID #репликация #производительность_SQL #crash_recovery #fsync #OLTP
-
[Перевод] MariaDB 12.3: binlog внутри InnoDB
Коротко для ленивых В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb . Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency. В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x . Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения. Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo. Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.
https://habr.com/ru/articles/1011298/
#MariaDB_123 #InnoDB #binlog #GTID #репликация #производительность_SQL #crash_recovery #fsync #OLTP
-
[Перевод] MariaDB 12.3: binlog внутри InnoDB
Коротко для ленивых В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb . Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency. В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x . Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения. Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo. Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.
https://habr.com/ru/articles/1011298/
#MariaDB_123 #InnoDB #binlog #GTID #репликация #производительность_SQL #crash_recovery #fsync #OLTP
-
SQLite (with WAL) doesn't do
fsyncon each commit under default settings | Hacker NewsLink
SQLite WAL 模式下的 fsync 預設與實務影響分析
https://www.sqlite.org/pragma.html#pragma_synchronous
📌 Summary:
本文主要探討 SQLite 在啟用 Write-Ahead Logging（WAL）模式時，PRAGMA synchronous設定與fsync行為之間的關係，以及不同作業系統和編譯環境下的預設差異。SQLite 的 WAL 模式能提升寫入效能，但在預設的synchronous=NORMAL狀態下，交易提交並不會在每次操作時都呼叫fsync，導致系統崩潰或斷電時可能回滾部分已提交交易。相對地，設定為FULL會增加交易耐久性，確保每次提交後都執行同步操作，降低資料遺失風險。文中以 macOS 內建 sqlite 與 Homebrew 版本為例，指出兩者在此設定上的不同，且編譯階段的宏定義（SQLITE_DEFAULT_SYNCHRONOUS與SQLITE_DEFAULT_WAL_SYNCHRONOUS）通常預設為FULL，但發行版或包裝方式可能改變預設，產生行為差異。文章並輔以 Hacker News 社羣討論，引伸對於資料庫耐久性預設的安全性疑慮、不同檔案系統、fsync 性能影響以及應用場景需求的範例分析，提醒使用者必須理解底層配置與預設差異，並根據實務需求調整參數，而非盲目依賴默認設定。
🎯 Key Points:
→ 🔧 SQLite WAL 模式與同步機制：
★ WAL 模式預設 journal mode 為 WAL，優化寫入效能；
★PRAGMA synchronous控制fsync行為，影響資料耐久性與系統穩定性；
★synchronous=NORMAL（數值1）表示不對每次提交呼叫fsync，僅於檢查點前後同步，可能導致部分交易因斷電丟失；
★synchronous=FULL（數值2）確保每次交易提交後同步 WAL 檔案，提升耐久性；
→ 💻 系統與編譯差異：
★ macOS 內建 sqlite3 版本默認為 WAL 模式下同步為NORMAL；
★ Homebrew 版本默認為FULL，顯示編譯宏設定差異；
★ 編譯預設宏SQLITE_DEFAULT_SYNCHRONOUS和SQLITE_DEFAULT_WAL_SYNCHRONOUS皆預設值為FULL，但發行包裝可能自行調整；
★ 不同 Linux 發行版 Docker 映像大多維持FULL為預設；
→ 🗣 社羣討論與應用影響：
★ 斷電後資料持久性及交易一致性成為關鍵，尤其金融或加密貨幣等重要場景；
★ 許多應用為提升效能採用NORMAL，但犧牲了部分交易的耐久保障；
★ fsync 操作較耗費資源且影響性能，故預設採折衷策略；
★ 使用者應明確檢視並調整關鍵設定以符合應用需求，避免默認帶來資料遺失風險；
★ 針對 Apple 平臺 fsync 行為存在特殊處理，如使用 F_FULLFSYNC 或 F_BARRIERFSYNC ；
★ SQLite 不同默認設置的不透明性亦可能導致開發者誤解資料庫的安全保證；
🔖 Keywords:
#SQLite #WAL模式 #PRAGMA_synchronous #fsync #資料耐久性 -
SQLite (with WAL) doesn't do `fsync` on each commit under default settings
https://avi.im/blag/2025/sqlite-fsync/
#HackerNews #SQLite #WAL #fsync #performance #database #commit #storage
-
@linuxpoweruser @cosmic_happiness I know. But most #windows #gamers still don't!
And yes, for many #linuxgamers this kernel update will bring partly huge performance update, but not for those already using some #fsync kernel on #distros like #nobara for example.
-
I've been studying fsync() for a couple of years and I thought I'd seen every weird way that it could be used and misused, but this week I learned of one more that exists in the wild: if the program crashes between write() and fsync(), on restart, fsync() after open() to ensure those writes are on disk.
I am pretty sure this doesn't do what people think it does, and here's why:
https://despairlabs.com/blog/posts/2025-03-13-fsync-after-open-is-an-elaborate-no-op/
-
Синхронизация файлов при запуске экземпляра PostgreSQL
Если экземпляр PostgreSQL был некорректно остановлен, то перед восстановлением файлов выполняется синхронизаций всех файлов кластера. Способ синхронизации определяется параметром конфигурации recovery_init_sync_method . В статье рассматривается, как ускорить запуск экземпляра и резервирование, если в директории PGDATA имеется много файлов.
-
#NTsync (title not approved) is more "Correctness" and "Robustness" alternative implementation of synchronization primitives in #Wine from Zebediah Figura (the author of "#Esync" and "#Fsync"). https://github.com/Frogging-Family/wine-tkg-git/issues/936
-
So finally got the #ntsync #wine patches applied to #Proton and went to test it on #GuildWars2.
In the Omphalos chamber in the Grove, #fsync and #esync yielded about 74fps, both off yielded 84 (odd, I know).
After allowing my user to access the ntsync device...
Uhh, I'll have to disable my FPS limiter real quick..
146 fps. Holy.
I'm going to be testing this on #Planetside2 the coming days where it actually matters. The times of bad FPS in CPU-bound games on #Linux might be over soon lads.
