LoGin
6a7c3656c6
* fix(fs): initialize ext4 block bitmaps and guard atomic truncation Treat BLOCK_UNINIT as uninitialized allocation state before validating or scanning a block bitmap. Previously, crossing into a lazily initialized ext4 group could fail delayed writeback with EIO, including when chmod forced pending CodeBuddy installation data to disk. Reuse the mounted system metadata ranges to construct the first bitmap, protect metadata and out-of-group bits, authenticate group descriptors, and verify the free-block count. Share this preparation between the transactional and direct allocators. Publish the initialized bitmap, cleared BLOCK_UNINIT flag, counters and checksums together through the existing transaction path, and retain the original direct rollback image. Keep initialized-bitmap checksum validation and unrelated group flags. Move the temporary O_TRUNC writer guard to the VFS open caller so it spans filesystem open hooks and post-open truncation. This prevents an atomic FUSE O_RDONLY|O_TRUNC open from modifying an executing image before the later ETXTBSY check. Release the temporary guard before returning a read-only descriptor; preserve writable descriptors' existing ownership. Add real-image ext4 regression coverage for both allocation paths, remount/data/fsck consistency, corrupt initialized checksums and an I/O failure during first-initialization preparation. Add dunitest coverage for cross-group write/chmod/fsync/remount and atomic FUSE truncation of a running ELF, including read-only descriptor lifetime. Validation: - make kernel and formatting/diff checks passed. - another_ext4 library: 168 tests passed. - Host ext4 image regression: both allocation paths, checksum rejection and preparation failure/retry passed, with clean e2fsck checks. - DragonOS Ext4InodeIdentity: 37 tests passed. - DragonOS exec write-access coverage: 8 tests passed. - Related FUSE tests: 15/17 passed; the two flag-mask failures also fail on the baseline with identical values. The new regression fails on the baseline and passes after this fix. The FUSE destructive-open behavior also reproduces on Linux 6.8; preserve ETXTBSY while preventing the destructive side effect. Fault injection covers preparation failure, not an exhaustive power-loss matrix. Signed-off-by: longjin <longjin@dragonos.org> * fix(fat): bound sequential reads and detach truncated cluster tails Cold page reads restarted FAT traversal at the first cluster. Reading the 32 MiB ext4 fixture exceeded the FAT entry cache and repeatedly scanned long prefixes, causing the Dunitest timeout before ext4 allocation began. Keep one logical/physical read cursor under the existing inode mutex and invalidate it when the chain can change. Forward reads now traverse only the remaining distance without extra locks or an unbounded index. The new fragmented-read regression also exposed an existing truncate bug: the retained chain still referenced freed clusters. Write EOC before freeing a nonzero truncated tail under the existing FAT lock, reuse the locked deallocation helper, and invalidate both cached chain positions. Correct the FAT16 EOC encoding to 0xffff. Cover cold forward/backward reads, tail reuse, shrink/regrow and rename. The new regression reproduces the truncate failure on the old kernel. Validation: kernel build and formatting checks; Linux FAT32 reference; all 3 DragonOS FAT32 tests; all 37 ext4 inode-identity tests. An independent 32 MiB cold read improved from 59.448 s to 0.311 s. FAT16 runtime testing remains blocked by its existing fixed-root-directory support limitation. Signed-off-by: longjin <longjin@dragonos.org> * fix(fat): retain unlinked files and publish truncation before reclaim Unlink and replacement rename freed cluster chains still owned by open files, mappings and asynchronous writeback. A live read cursor could then return another file's data. Detach the directory entry without freeing the chain, reuse VFS semantic retention, and reclaim only after admission closes and the last owner releases it. Perform fallible cleanup on the existing workqueue mechanism and integrate its completion/error state with sync and unmount. Never retry a partially freed chain. Centralize short-entry submission so detached files can still grow and truncate without writing a directory slot reused by another file. Remove a detached replacement victim from the directory cache even when a later rename step fails. Publish the smaller short entry before cutting and freeing the truncated tail. Keep the new size on reclamation failure and synchronize outer metadata on both outcomes. Continue flushing other files even when reclamation reports a sticky error. Add FAT regressions for cold reads after unlink/replacement, writes and truncate/regrow through the old fd, mmap retention after close, and space reclamation after final munmap and syncfs. Both lifetime cases fail on the old kernel and pass on Linux FAT32 and DragonOS. Final validation passed all five FAT tests, all 37 ext4 inode-identity tests, the kernel build and format checks. Identical post-EOC reclamation EIO injection changes the remounted length from the incorrect 32768 to the expected 4096 bytes. Signed-off-by: longjin <longjin@dragonos.org> * fix(vfs): release inode retention before final mount shutdown File dropped its mount pin before its writer guard. The latter still owns canonical inode Operation retention, so lazy unmount could seal the FAT eviction queue before the final writer release publishes reclamation. Release writer and open-description retention before the mount pin, matching Linux __fput access/dentry release before mntput. Audit and repair the same ordering across the other ownership boundaries: - ResolvedPath releases its operation pin before its mount pin. - Failed File construction releases the transferred operation pin inside the constructor, before its mount-pin parameter is destroyed. - A retained resolved-path owner covers temporary O_TRUNC admission even if File construction or post-open truncation fails. - Exec loading and MM executable-image ownership release deny-write protection before the associated File and its mount pin. Keep the eviction seal protocol and existing close callbacks unchanged; no new lifecycle framework is needed. Validation: kernel build and formatting; DragonOS exec 8/8, FAT32 5/5 and ext4 inode identity 37/37. A manual lazy-unmount/last-writer-close/remount check passed 64 rounds with reclaimed space. The baseline also passed 64 stress rounds, so the race is supported by the destruction-order and ownership audit rather than a claimed deterministic runtime reproduction. Independent agents reviewed the complete PR and follow-up before commit. Signed-off-by: longjin <longjin@dragonos.org> * fix(fat): isolate reclamation workers by filesystem The global single-worker FAT eviction queue made a fast filesystem's syncfs and unmount wait behind another device's slow chain reclamation. Give each FAT filesystem its own serial queue while retaining the existing FIFO epoch, error reporting and eviction seal contracts. Add an owned WorkQueue constructor whose worker waits with a weak queue reference. Pending FAT work retains the filesystem until completion; when the last queue owner disappears, Drop wakes the worker and it exits. This avoids leaking a permanent thread per mount without introducing a new stop protocol or changing existing global workqueues. Return worker creation failure to the mount caller. Validation: kernel build and formatting; FAT32 5/5 and ext4 inode identity 37/37; 64 lazy-unmount/remount rounds with no residual FAT workers. In the same two-volume sample, fast syncfs improved from 367.392 ms to 15.812 ms while slow reclamation continued for another 360.468 ms. Worker count returned from two mounted-filesystem workers to zero after unmount. Independent agents reviewed the complete PR and this follow-up before commit, including empty queues and last-job filesystem destruction. Signed-off-by: longjin <longjin@dragonos.org> --------- Signed-off-by: longjin <longjin@dragonos.org>
Lightweight Cloud-Native Kernel
DragonOS
Languages 中文|English
DragonOS is a 64-bit operating system with a completely independent kernel, designed for lightweight cloud computing scenarios, offering Linux binary compatibility. It aims to provide lightweight, high-performance solutions for containerized workloads. Developed using Rust for enhanced reliability.
The DragonOS open-source community was established in July 2022 and is entirely commercially neutral. We warmly welcome interested developers and enthusiasts to join us!
DragonOS features excellent and comprehensive architectural design. Compared to other systems of similar scale, DragonOS supports eBPF and virtualization. Currently, we are actively advancing container support, cloud platform compatibility, RISC-V support, as well as porting compilers and application software. Our goal is to achieve large-scale production environment deployment within five years.
DragonOS is rapidly evolving under community-driven development. Currently, DragonOS has implemented approximately 1/4 of Linux interfaces. In the future, we will provide 100% Linux compatibility along with new features.
🌟 Want to quickly experience DragonOS? Visit DragonOS Playground to launch DragonOS in the cloud with zero configuration and experience the latest nightly build!
📰 Community News
- 2025-12-17: ☁️ DragonOS Playground is now live! Experience DragonOS with zero configuration on CNB platform, with daily nightly build updates! Try it now →
- 2025-11-20: 🚀 DragonOS 0.3.0 has been released! Now supports running Go programs directly!
- 2025-11-18: 📊 DragonOS CI Dashboard is now live! Check out DragonOS Linux compatibility data now!
How to Run?
🌟 Method 1: Cloud-Native Development (Recommended)
Zero configuration, one-click launch! Experience DragonOS on the CNB cloud-native development platform - the simplest and fastest way, no local dependencies required!
Method 2: Local Build
If you prefer to build and run DragonOS locally, you can refer to the following documentation:
Want to Contribute?
Read the DragonOS Community Introduction Document carefully to understand how the community operates and how you can contribute!
If you'd like to join us, check out the issues and participate in discussions or share your ideas. You can also visit the DragonOS forum to stay updated on development progress and tasks: https://bbs.dragonos.org.cn
You can also bring your creativity and ideas to discuss with the community and contribute new features to DragonOS.
Sites
- Official Website: DragonOS.org
- Documentation: docs.dragonos.org
- Community Introduction: community.dragonos.org
- QQ Group: 476358494
How to Connect with the Community?
Please read the Contributor Guide~
- You can find contact details for members of various committees in the Community Management Team section.
- You can also locate the contact information for leaders of specific community groups via the SIGs and WGs pages.
Contributor List
Contributors to DragonOS-Community/DragonOS · GitHub
Sponsorship
DragonOS is a non-profit open-source project, and its development relies on financial support. All sponsors will be publicly acknowledged. Every contribution you make will help advance DragonOS!
Where Will Sponsorship Funds Be Used?
We guarantee that all sponsorship funds and items will be used for:
- Event organization, cloud service expenses, and any other purposes beneficial to the development and growth of the DragonOS community.
🌟 Sponsor List
Special thanks to these generous financial supporters (in reverse chronological order):
- 中国雅云 雅安大数据产业园 - 🥇 Long-term supporter (since 2023)
- Tencent Cloud EdgeOne EdgeOne CDN by TencentCloud
CDN Sponsor
This project's CDN acceleration and security protection are sponsored by Tencent EdgeOne.
Individual Sponsors List
See Supporters.md
Open Source License Notice
This project is open-sourced under the GPLv2 license. You are welcome to use the code in compliance with the open-source license!
If you encounter any violations of the open-source license, we encourage you to email pmc@dragonos.org to report them. Let's work together to build a trustworthy open-source community.
👩💻 Contributors
"Open source shines because of you!" ✨
Thanks to all developers who submitted code, fixed issues, or reviewed PRs: