Changes in Kconfig

0eded739d8127d5a8c5cf370d3156b142383c6ed - btrfs: introduce support for huge folios

Wed, 13 May 2026 06:36:21 +0200

btrfs: introduce support for huge foliosWith all the previous preparations, it's finally time to enable thehuge folio support.- The max folio size Here we define BTRFS_MAX_FOLIO_SIZE, which is fixed at 2MiB. This will ensure we have a large enough but not too large folio for btrfs. This limit applies to all systems regardless of page size. Then we also define BTRFS_MAX_BLOCKS_PER_FOLIO, which depends on CONFIG_BTRFS_EXPERIMENTAL. If it's an experimental build, BTRFS_MAX_BLOCKS_PER_FOLIO is 512, otherwise it's BITS_PER_LONG. The filemap max order will be calculated using both BTRFS_MAX_FOLIO_SIZE and BTRFS_MAX_BLOCKS_PER_FOLIO. E.g. for 64K page size with 64K fs block size, the limit will be BTRFS_MAX_FOLIO_SIZE (2M), which limits the filemap max order to 5. This will be lower than the old order (6), but folios larger than 2M are rarely any better for IO performance. Meanwhile excessively large folios can cause other problems like stalling the IO pipeline for too long. For 4K page size and 4K fs block size, the limit will be increased to 2M from the old 256K. This new size is constrained by both BTRFS_MAX_FOLIO_SIZE (2M) and BTRFS_MAX_BLOCKS_PER_FOLIO (512 * 4K), allowing x86_64 to achieve huge folio support, and the filemap max order will be 9.- btrfs_bio_ctrl::submit_bitmap This will be enlarged to contain BTRFS_MAX_BLOCKS_PER_FOLIO bits, and this will be on-stack memory. This will increase on-stack memory usage by 56 bytes compared to the baseline (before the first patch in the series).- Local @delalloc_bitmap inside writepage_delalloc() Unfortunately we cannot afford to handle an allocation error here, thus again we use on-stack memory. Thus this will increase on-stack memory usage by 56 bytes again.So unfortunately this means during the delalloc window, the writeback pathwill have +112 bytes on-stack memory usage, and for other cases thewriteback path will have +56 bytes on-stack memory usage.The +56 bytes (btrfs_bio_ctrl::submit_bitmap) can be removedafter we have reworked the compression submission, so the currenton-stack submit_bitmap is mostly a workaround until then.Signed-off-by: Qu Wenruo Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

9bce95edb1b4d2802de9273b5170bfcff3090d24 - btrfs: move large data folios out of experimental features

Fri, 24 Apr 2026 02:50:25 +0200

btrfs: move large data folios out of experimental featuresThis feature was introduced in v6.17 under experimental, and we hadseveral small bugs related to or exposed by that: e9e3b22ddfa7 ("btrfs: fix beyond-EOF write handling") 18de34daa7c6 ("btrfs: truncate ordered extent when skipping writeback past i_size")Otherwise, the feature has been frequently tested by btrfs developers.The latest fix only arrived in v6.19. After three releases, I think it'stime to move this feature out of experimental.And since we're here, also remove the comment about the bitmap sizelimit, which is no longer relevant in the context. It will soon beoutdated for the incoming huge folio support.Reviewed-by: Neal Gompa Signed-off-by: Qu Wenruo Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

b2a9f217ad3fa8012940744059956b20a3971135 - btrfs: remove the COW fixup mechanism

Tue, 14 Apr 2026 05:35:26 +0200

btrfs: remove the COW fixup mechanism[BACKGROUND]Btrfs has a special mechanism called COW fixup, which detects dirtypages without an ordered extent (folio ordered flag).Normally a dirty folio must go through delayed allocation (delalloc)before it can be submitted, and delalloc will create an ordered extentfor it and mark the range with ordered flag.However in older kernels, there are bugs related to get_user_pages()which can lead to some page marked dirty but without notifying the fs toproperly prepare them for writeback.In that case without an ordered extent btrfs is unable to properlysubmit such dirty folios, thus the COW fixup mechanism is introduced,which do the extra space reservation so that they can be written backproperly.[MODERN SOLUTIONS]The MM layer has solved it properly now with the introduction ofpin_user_pages*(), so we're handling cases that are no longer valid.So commit 7ca3e84980ef ("btrfs: reject out-of-band dirty folios duringwriteback") is introduced to change the behavior from going throughCOW fixup to rejecting them directly for experimental builds.So far it works fine, but when errors are injected into the IO path, wehave random failures triggering the new warnings.It looks like we have error path that cleared the ordered flag butleaves the folio dirty flag, which later triggers the warning.[REMOVAL OF COW FIXUP]Although I hope to fix all those known warnings cases, I just can notfigure out the root cause yet.But on the other hand, if we remove the ordered and checked flags in thefuture, and purely rely on the dirty flags and ordered extent search, wecan get a much cleaner handling.Considering it's no longer hitting the COW fixup for normal IO paths, Ithink it's finally the time to remove the COW fixup completely.Furthermore, the function name "btrfs_writepage_cow_fixup()" is nolonger meaningful, and since it's pretty small, only a folio flag checkwith error message, there is no need to put it as a dedicated helper,just open code it inside extent_writepage_io().Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

304076527c38efaf68a17f9e4837834ac66cfc1a - btrfs: move shutdown and remove_bdev callbacks out of experimental features

Fri, 27 Feb 2026 04:33:44 +0100

btrfs: move shutdown and remove_bdev callbacks out of experimental featuresThese two new callbacks have been introduced in v6.19, and it has beentwo releases in v7.1.During that time we have not yet exposed bugs related that two features,thus it's time to expose them for end users.It's especially important to expose remove_bdev callback to end users.That new callback makes btrfs automatically shutdown or go degradedwhen a device is missing (depending on if the fs can maintain RW), whichis affecting end users.We want some feedback from early adopters.Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

8620da16fb6be1fd9906374fa1c763a10c6918df - btrfs: allow mounting filesystems with remap-tree incompat flag

Wed, 07 Jan 2026 15:09:08 +0100

btrfs: allow mounting filesystems with remap-tree incompat flagIf we encounter a filesystem with the remap-tree incompat flag set,validate its compatibility with the other flags, and load the remap treeusing the values that have been added to the superblock.The remap-tree feature depends on the free-space-tree, but no-holes andblock-group-tree have been made dependencies to reduce the testingmatrix. Similarly I'm not aware of any reason why mixed-bg and zoned would beincompatible with remap-tree, but this is blocked for the time beinguntil it can be fully tested.Reviewed-by: Boris Burkov Signed-off-by: Mark Harmstone Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

ae23fee41b36a39f8e163580fe273ca3f88f2413 - btrfs: remove experimental offload csum mode

Thu, 08 Jan 2026 05:01:03 +0100

btrfs: remove experimental offload csum modeThe offload csum mode was introduced to allow developers to compare theperformance of generating checksum for data writes at different timings:- During btrfs_submit_chunk() This is the most common one, if any of the following condition is met we go this path: * The csum is fast For now it's CRC32C and xxhash. * It's a synchronous write * Zoned- Delay the checksum generation to a workqueueHowever since commit dd57c78aec39 ("btrfs: introducebtrfs_bio::async_csum") we no longer need to bother any of them.As if it's an experimental build, async checksum generation at thebackground will be faster anyway.And if not an experimental build, we won't even have the offload csummode support.Considering the async csum will be the new default, let's remove theoffload csum mode code.There will be no impact to end users, and offload csum mode is stillunder experimental features.Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

fe11ac191ce0ad910f6fda0c628bcff19fcff47d - btrfs: switch to library APIs for checksums

Fri, 05 Dec 2025 08:04:54 +0100

btrfs: switch to library APIs for checksumsMake btrfs use the library APIs instead of crypto_shash, for allchecksum computations. This has many benefits:- Allows future checksum types, e.g. XXH3 or CRC64, to be more easily supported. Only a library API will be needed, not crypto_shash too.- Eliminates the overhead of the generic crypto layer, including an indirect call for every function call and other API overhead. A microbenchmark of btrfs_check_read_bio() with crc32c checksums shows a speedup from 658 cycles to 608 cycles per 4096-byte block.- Decreases the stack usage of btrfs by reducing the size of checksum contexts from 384 bytes to 240 bytes, and by eliminating the need for some functions to declare a checksum context at all.- Increases reliability. The library functions always succeed and return void. In contrast, crypto_shash can fail and return errors. Also, the library functions are guaranteed to be available when btrfs is loaded; there's no longer any need to use module softdeps to try to work around the crypto modules sometimes not being loaded.- Fixes a bug where blake2b checksums didn't work on kernels booted with fips=1. Since btrfs checksums are for integrity only, it's fine for them to use non-FIPS-approved algorithms.Note that with having to handle 4 algorithms instead of just 1-2, thiscommit does result in a slightly positive diffstat. That being said,this wouldn't have been the case if btrfs had actually checked forerrors from crypto_shash, which technically it should have been doing.Reviewed-by: Ard Biesheuvel Reviewed-by: Neal Gompa Signed-off-by: Eric Biggers Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

64dd1caf88f96146edee24e82834cf2a11c3932b - btrfs: update the Kconfig string for CONFIG_BTRFS_EXPERIMENTAL

Fri, 09 Jan 2026 04:31:14 +0100

btrfs: update the Kconfig string for CONFIG_BTRFS_EXPERIMENTALThe following new features are missing:- Async checksum- Shutdown ioctl and auto-degradation- Larger block size support Which is dependent on larger folios.Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

e8513c012de75fd65e2df5499572bc6ef3f6e409 - btrfs: implement ref_tracker for delayed_nodes

Wed, 13 Aug 2025 01:04:39 +0200

btrfs: implement ref_tracker for delayed_nodesAdd ref_tracker infrastructure for struct btrfs_delayed_node.It is a response to the largest btrfs related crash in our fleet. We'reseeing soft lockups in btrfs_kill_all_delayed_nodes() that seem to be aresult of delayed_nodes not being released properly.A ref_tracker object is allocated on reference count increases and freedon reference count decreases. The ref_tracker object stores a stacktrace of where it is allocated. The ref_tracker_dir object is embeddedin btrfs_delayed_node and keeps track of all current and some old/freedref_tracker objects. When a leak is detected we can print the stacktraces for all ref_trackers that have not yet been freed.Here is a common example of taking a reference to a delayed_node andfreeing it with ref_tracker. struct btrfs_ref_tracker tracker; struct btrfs_delayed_node *node; node = btrfs_get_delayed_node(inode, &tracker); // use delayed_node... btrfs_release_delayed_node(node, &tracker);There are two special cases where the delayed_node reference is "longlived", meaning that the thread that takes the reference and the threadthat releases the reference are different. The 'inode_cache_tracker'tracks the delayed_node stored in btrfs_inode. The 'node_list_tracker'tracks the delayed_node stored in the btrfs_delayed_rootnode_list/prepare_list. These trackers are embedded in thebtrfs_delayed_node.btrfs_ref_tracker and btrfs_ref_tracker_dir are wrappers that eithercompile to the corresponding ref_tracker structs or empty structsdepending on CONFIG_BTRFS_DEBUG. There are also btrfs wrappers forthe ref_tracker API.Signed-off-by: Leo Martins Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

cba7c35fec267188a9708deae857e9116c57497b - btrfs: move ref-verify under CONFIG_BTRFS_DEBUG

Wed, 13 Aug 2025 01:28:27 +0200

btrfs: move ref-verify under CONFIG_BTRFS_DEBUGRemove CONFIG_BTRFS_FS_REF_VERIFY Kconfig and add it as part ofCONFIG_BTRFS_DEBUG. This should not be impactful to the performanceof debug. The struct btrfs_ref takes an additional u64, btrfs_fs_infotakes an additional spinlock_t and rb_root. All of the ref_verify logicis still protected by a mount option.Signed-off-by: Leo Martins Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

cc38d178ff33543cdb0bd58cfbb9a7c41372ff75 - btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTAL

Wed, 23 Apr 2025 10:58:02 +0200

btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTALWith all the preparation patches already merged, it's pretty easy toenable large data folios:- Remove the ASSERT() on folio size in btrfs_end_repair_bio()- Add a helper to properly set the max folio order Currently due to several call sites that are fetching the bitmap content directly into an unsigned long, we can only support BITS_PER_LONG blocks for each bitmap.- Call the helper when reading/creating an inodeThe support has the following limitations:- No large folios for data reloc inode The relocation code still requires page sized folio. But it's not that hot nor common compared to regular buffered ios. Will be improved in the future.- Requires CONFIG_BTRFS_EXPERIMENTAL- Will require all folio related operations to check if it needs the extra btrfs_subpage structure Now any folio larger than block size will need btrfs_subpage structure handling.Unfortunately I do not have a physical machine for performance test, butif everything goes like XFS/EXT4, it should mostly bring single digitspercentage performance improvement in the real world.Although I believe there are still quite some optimizations to be done,let's focus on testing the current large data folio support first.Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

c16b984cdbaf3a96c671bc2952c1064af983683d - btrfs: update Kconfig option descriptions

Tue, 06 May 2025 13:04:26 +0200

btrfs: update Kconfig option descriptionsExpand what the options do and if they are OK to be enabled.Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

5f9b394e3295ed82af8da81d3326e5577a140cc8 - btrfs: update list of features built under experimental config

Tue, 06 May 2025 13:04:25 +0200

btrfs: update list of features built under experimental configThe list is out of date, the extent shrinker got fixed in 6.13. Add newentries: the COW fixup warning in 6.15, rund robin policies in 6.14.Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

b261d2222063a9a8b9ec284244c285f2998ee01e - lib/crc: remove CONFIG_LIBCRC32C

Wed, 02 Apr 2025 00:16:00 +0200

lib/crc: remove CONFIG_LIBCRC32CNow that LIBCRC32C does nothing besides select CRC32, make every optionthat selects LIBCRC32C instead select CRC32 directly. Then removeLIBCRC32C.Reviewed-by: Christoph Hellwig Reviewed-by: "Martin K. Petersen" Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250401221600.24878-8-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/fs/btrfs/Kconfig

67cd3f22176904e7445fea5f307f6fa2ad1d89e4 - btrfs: split out CONFIG_BTRFS_EXPERIMENTAL from CONFIG_BTRFS_DEBUG

Mon, 16 Sep 2024 10:48:25 +0200

btrfs: split out CONFIG_BTRFS_EXPERIMENTAL from CONFIG_BTRFS_DEBUGCurrently CONFIG_BTRFS_EXPERIMENTAL is not only for the extra debuggingoutput, but also for experimental features.This is not ideal to distinguish planned but not yet stable featuresfrom those purely designed for debugging.This patch splits the following features into CONFIG_BTRFS_EXPERIMENTAL:- Extent map shrinker This seems to be the first one to exit experimental.- Extent tree v2 This seems to be the last one to graduate from experimental.- Raid stripe tree- Csum offload mode- Send protocol v3Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

732fab95abe2510560c8158e0d2e94460d38b2f4 - btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY option

Fri, 08 Sep 2023 08:42:17 +0200

btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY optionSince all check-integrity entry points have been removed, let's alsoremove the config and all related code relying on that.And since we have removed the mount option for check-integrity, we alsoneed to re-number all the BTRFS_MOUNT_* enums.Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

5facccc9402301d67d48bef06159b91f7e41efc0 - MAINTAINERS: remove links to obsolete btrfs.wiki.kernel.org

Tue, 22 Aug 2023 23:47:47 +0200

MAINTAINERS: remove links to obsolete btrfs.wiki.kernel.orgThe wiki has been archived and is not updated anymore. Remove or replacethe links in files that contain it (MAINTAINERS, Kconfig, docs).Signed-off-by: Bhaskar Chowdhury Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

16c3a47648383efa625f771999182db9f34fb8d9 - btrfs: deprecate integrity checker feature

Mon, 26 Jun 2023 11:55:25 +0200

btrfs: deprecate integrity checker featureThe integrity checker feature needs to be enabled at compile time(BTRFS_FS_CHECK_INTEGRITY) and then enabled by mount options check_int*.Although it provides some unique features which can not be provided byany other sanity checks like tree-checker, it does not only have highCPU and memory overhead, but is also a maintenance burden.For example, it's the only caller of btrfs_map_block() with@need_raid_map = 0.Considering most btrfs developers are not even testing this feature, I'mhere to propose deprecation of this feature.For now only warning messages will be printed, the feature itself wouldstill work.Removal time has been set to 6.7 release.Reviewed-by: Christoph Hellwig Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

2c275afeb61dab732353aae2c7de01b6a87dcefc - block: make blkcg_punt_bio_submit optional

Mon, 27 Mar 2023 02:49:53 +0200

block: make blkcg_punt_bio_submit optionalGuard all the code to punt bios to a per-cgroup submission helper by anew CONFIG_BLK_CGROUP_PUNT_BIO symbol that is selected by btrfs.This way non-btrfs kernel builds don't need to have this code.Reviewed-by: Jens Axboe Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba Signed-off-by: David Sterba List of files: /linux/fs/btrfs/Kconfig

cfa71bb282d09556673a62fbdc3d23d9e4df3fa0 - fs/btrfs: Remove "select SRCU"

Wed, 23 Nov 2022 02:49:29 +0100

fs/btrfs: Remove "select SRCU"Now that the SRCU Kconfig option is unconditionally selected, there isno longer any point in selecting it. Therefore, remove the "select SRCU"Kconfig statements.Signed-off-by: Paul E. McKenney Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: Acked-by: David Sterba Reviewed-by: Qu Wenruo Reviewed-by: John Ogness List of files: /linux/fs/btrfs/Kconfig