Linus just now announced v6.19-rc1 kernel release on a usual Sunday afternoon.
This brings a number of features across various subsystems. This article tries
to cover some of the filesystem, storage and block level updates:

• EXT4 filesystem updates

  • EXT4 continues to march towards iomap conversion, which is a modern filesystem framework providing generic filesystem centric block mapping abstractions to efficiently handle I/O.

    In v6.19, EXT4 got some good optimizations for it’s online de-fragmentation code by moving away from PAGE_SIZE based data movement and extent swapping move_extent_per_page to folio based mext_move_extent().

    EXT4 had added large folio support in v6.16 kernel. That means, this new interface allows for iterating over and copying the data based on the extents of the original file instead of PAGE_SIZE thereby utilizing large folios. This makes ext4 a step closer towards iomap conversion. Additionally there are some good performance improvements too as mentioned by the author in this patch series.

  • EXT4 also got the support for large blocksize (bs > ps) in v6.19.

    Since large folios are already supported for regular files, the required

    changes are not substantial, but they are scattered across the code. The

    changes primarily focus on cleaning up potential division-by-zero errors,

    resolving negative left/right shifts, and correctly handling mutually

    exclusive mount options.

• BTRFS Updates

  • Added shutdown ioctl support as experimental similar to other filesystems

  • Suspend trigger will now cancel scrub and device replace. scrub state will be saved and will be initiated from where it left off. Device replace however will have to be re-started from the beginning.

  • zone stats exported in sysfs, from the perspective of the filesystem this includes active, reclaimable, relocation etc zones

  • improvements when processing space reservation tickets by optimizing locking and shrinking critical sections, cumulative improvements in lockstat numbers show +15%

  • Added more filesystem operations for blocksize > pagesize support

  • Prep work for fscrypt support

  • Other bug fixes and improvements

• XFS had no major changes except few cleanups, bug fixes and documentation update

• VFS/iomap updates

  FUSE added iomap support for it’s buffered read and readahead operation:
  FUSE had adopted iomap for buffered write operations in v6.17. In this release, it extended that support by adopting iomap for it’s buffered read and readahead operations too.

  • Background: v6.17 buffered write support:
    In v6.17, FUSE transitioned its buffered write operations to use iomap,
    unlocking two key advantages:

    Granular large folio synchronous reads: For example, with a 1 MB large folio,

    a write issued from position 1 to position 1 MB - 2 only requires reading and

    marking the head and tail pages as uptodate, rather than reading the entire

    folio. Non-relevant trailing pages are also skipped.

    Granular large folio dirty tracking: During writeback, only the dirty portions

    of a large folio need to be written instead of the entire folio. For instance,

    if only 2 bytes in a 1 MB large folio are dirty, only the page containing those

    bytes gets written out.
    In v6.19 Updates

    FUSE now extends iomap support for buffered reads and readahead operations. To enable this, struct iomap_read_ops and struct iomap_read_folio_ctx were added.
    struct iomap_read_ops: Allows callers to provide custom →read_folio_range and →submit_read callbacks

    struct iomap_read_folio_ctx: Context structure for managing read operations with caller-specific behavior
    
    FUSE now implements fuse_iomap_read_folio_range to handle buffered reads through iomap, enabling more granular non-uptodate reads when large folios are enabled. Instead of reading the entire folio, only the non-uptodate portions need to be read from the server, which improves performance.

    As per the pull request this feature is also needed for:

    It also is needed in order to turn on large folios for servers that use the

    writeback cache since otherwise there is a race condition that may lead to data corruption if there is a partial write, then a read and the read happens before the write has undergone writeback, since otherwise the folio will not be marked uptodate from the partial write so the read will read in the entire folio from disk, which will overwrite the partial write.

    For those who are curious, FUSE still hasn’t turned on the large folio support yet.

  • iomap also added folio batch support for iomap_zero_range() to handle dirty

    folios over unwritten mappings.

  • DIO Write Completions from Interrupt Context
    iomap improved latencies in case of direct-io for high performance workloads like ScyllaDB: iomap instead of running the DIO completion processing inline, it used to offload it to a workqueue. This added a lot of context switching which at least on older kernels with workqueue scheduling issues caused really high tail latencies. This series queued in v6.19 ensures that the write completions can run inline (e.g. for pure overwrites) instead of being deferred to workqueues.

• VFS/directory locking updates

  Directory locking: NeilBrown continues to work towards adding support for

  concurrent directory updates. The ultimate goal is to lock the target dentry(s) rather than the whole parent directory. To help with changing the locking protocol, this series centralizes locking and lookup in new helper functions.

• VFS/writeback

  Allow filesystems to increase the minimum writeback chunk size: To ensure fairness when flushing dirty pages, writeback logic switches between inodes after writing a minimum chunk of data. The default minimum writeback chunk size is 4 MiB. In v6.19, a new superblock field “s_min_writeback_pages” allows filesystems to override this default and increase the minimum writeback chunk size per inode. This could come beneficial for:

  Rotational media: Reduces seeks by writing larger contiguous chunks before switching between files

  Zoned storage devices (SMR HDDs and ZNS SSDs): Prevents file fragmentation and prevents unnecessary runs of GC!
  

  XFS sets s_min_writeback_pages to the zone size for zoned filesystems,

  ensuring that writeback writes at least one complete zone’s worth of data per

  inode before switching, thereby eliminating spurious fragmentation and the

  associated garbage collection overhead.

• VFS/folio update

  Add a new folio_next_pos() helper function that returns the file position of the first byte after the current folio. This is a common operation in filesystems when needing to know the end of the current folio. This helper is lifted from btrfs which already had its own version, and is now used across multiple filesystems and subsystems

• Block Layer

  • Enables per-cpu bio cache by default:

    block layer manages a per-cpu bio cache mainly for usecases like polling mode io-uring which can be latency criticial workloads. This caches allows to quickly recycle the bios instead of going through the slab allocator. This series now enables the per-cpu bio cache by default to all bio based I/O submissions.

  • Zoned device caching support: Added zone information caching to avoid unnecessary repeated zone report queries, improving performance for zoned

    block devices (SMR/ZNS)

  • Polled I/O performance: Improved polled I/O handling speed by manually managing hardware context (hctx) lookups instead of using xarray

  • Block integrity improvements: Enhanced the auto-integrity code to be less

    deadlock-prone and better handle Protection Information (PI) generation/validation

  • REQ_NOWAIT fixes: Corrected NOWAIT handling in loop/zloop drivers. The NOWAIT flag is now properly cleared when requests are punted to threads for handling. Also reverted loop DIO nowait support due to excessive stack usage issues

  • blk-throttle fixes: Improvements for SSD device throttling

  • ublk driver updates: Series of cleanups and simplifications to the user copy

    code, laying groundwork for future batching support MD/RAID updates

  • Scheduler switching improvements: Restructured elevator I/O scheduler switching logic & fixing lockdep warnings.

  • Block tracing for zoned devices: Added support for zoned device information in block layer tracing

  • Various other fixes and improvements.

• F2FS updates (as per cover letter)

  This series focuses on minor clean-ups and performance optimizations across sysfs, documentation, debugfs, tracepoints, slab allocation, and GC. Furthermore, it resolves several corner-case bugs caught by xfstests, as well as issues related to 16KB page support and f2fs_enable_checkpoint.

  Enhancement:

  - wrap ASCII tables in literal blocks to fix LaTeX build

  - optimize trace_f2fs_write_checkpoint with enums

  - support to show curseg.next_blkoff in debugfs

  - add a sysfs entry to show max open zones

  - add fadvise tracepoint

  - use global inline_xattr_slab instead of per-sb slab cache

  - set default valid_thresh_ratio to 80 for zoned devices

  - maintain one time GC mode is enabled during whole zoned GC cycle

  - Other bug fixes and improvements

• NTFS3 updates (as per cover letter)

  - support timestamps prior to epoch

  - do not overwrite uptodate pages

  - disable readahead for compressed files

  - setting of dummy blocksize to read boot_block when mounting

  - the run_lock initialization when loading $Extend

  - initialization of allocated memory before use

  - support for the NTFS3_IOC_SHUTDOWN ioctl

  - check for minimum alignment when performing direct I/O reads

  - check for shutdown in fsync
  - Other bug fixes and improvements

Registeration link:
https://my.weezevent.com/bangalore-kernel-meetup-december-2025

Event venue & other Details:
• Date: Dec 6, 2025
• Time: 9:00 a.m. – 2:30 p.m.
• Venue: Red Hat India Pvt. Ltd.
• Address: Carina Building, 10th Floor East,
Bagmane Constellation Business Park,
Doddanekkundi, Bengaluru, Karnataka 560037.

(Follow the google group page for more details: https://groups.google.com/g/kernel-meetup-bangalore)

Couple of days before Linus quietly marked Bcachefs as “Externally Maintained”. This means bcachefs will continue to stay in Linux Kernel for it’s existing users but won’t see any updates from here on.
Bcachefs maintainer would mostly maintain it externally as an out-of-tree filesystem module.

Linus released a smaller-than-usual 6.17-rc2 this week, calling it "one of the smaller rc2 releases we've had lately." The release focuses primarily on driver fixes with the largest change being removal of the drbd page pool code from the block subsystem.

Key areas addressed:

• Drivers: Block, GPU, networking, sound, SCSI, and FireWire fixes

• Filesystems: Updates to SMB, XFS, EROFS, and Btrfs

• Networking: Core networking fixes plus new selftests

• Architecture: Mainly x86 fixes

Linus released 6.17-rc1 on August 10 and with that the merge window for 6.17 is now closed. We had earlier covered the memory management and filesystems updates from the initial merge window.
Here are some of the other core subsystem updates for 6.17-rc1.

Block layer
Read‑ahead tuned for hard drives: Rotational disks that don’t report an “optimal I/O size” now get a larger, smarter default read‑ahead based on max I/O size.

For a SCSI disk, this defaults to 2560 KB, which significantly improve performance for buffered reads. Using XFS and sequentially reading randomly selected (large) files stored on a SATA HDD, the maximum throughput achieved with 8 readers reading files with 1MB buffered I/Os increases from 122 MB/s to 167 MB/s (+36%). The improvement is even larger when reading files using 128 KB buffered I/Os, with a throughput increasing from 57 MB/s to 165 MB/s (+189%).

F2FS:
- Folio conversion
- added several sysfs entries to tune GCs for ZUFS
- Conversion to new mount apis

ARM:
Host driver for GICv5, the next generation interrupt controller for arm64, including support for interrupt routing, MSIs, interrupt translation and wired interrupts

S390:
- Enable THP swapping and THP migration

MM (new):
- Optimizations for khugepaged: Improve khugepaged throughput by batching PTE operations for large folios. This gain is mainly for arm64.

Misc:
- Make kdump more reliable by providing an extra crashkernel=XX,cma option to allow crashkernel to reserve extra memory from CMA area for it’s runtime overhead.
More details can be found here.
- A new struct netmem_desc is introduced. This allows the page pool of netstack to refer to netmem_desc instead of struct page. This effort is a step towards memdesc world.

Bcachefs:
- No bcachefs pull request was merged this cycle. As some of you might know that expectations had already been tempered by a 6.16-rc4 note from Linus -

I have pulled this, but also as per that discussion, I think we’ll be parting ways in the 6.17 merge window…

In the 6.17 Bcachefs pull request thread, Kent added that he’d received an email from Linus saying “we’re now talking about git rm -rf in 6.18”. Things definitely aren’t looking good for bcachefs users, given that this isn’t the first time bcachefs users have faced a setback. Linus hasn’t responded anything on that thread yet. So we will have to wait until something is publicly announced on the future of bcachefs.

That wraps up the rest of 6.17’s merge window. As always with -rc1 now out, expect the usual shakedown and fixes over the next few weeks.

Linux kernel v6.16 was released just last week, and the merge window for v6.17 is now open. This release brings numerous improvements across various subsystems. In this article, we’ll provide more detail on the memory management and filesystem updates. A follow up article will cover changes in other areas like architecture, storage, drivers, etc.

Memory Management Updates

• Optimize memory block registration to reduce boot time:

  This patch series optimizes the memory blocks registration needed during bootup. As per the patch series, this has improved bootup time for large memory systems with discontiguous memory ranges by around ~78% (From 1min 16sec to 17sec).
  

• Optimize mprotect() & mremap() for large folios:
  mremap() & mprotect() has been converted to make use of folio_pte_batch() & set_ptes() call which provides PTE batching instead of set_pte_at(), which gets called for each pte of a folio.
  

• Adds numa node notifier similar to memory notifier:
  This allows to convert the following consumers to register for numa node state change instead of state change for every {online,offline}_pages(). memory-tier, slub, cpuset, hmat, cxl & autoweight-mempolicy are converted to use numa node notifier instead.
  

• Introduces a per-node proactive reclaim interface:
  A new per-node proactive reclaim interface has been added to help systems with memory tiers. Use cases that do not use memcg can utilize this interface for proactive reclaiming. The memcg interface is anyways not NUMA aware and there are usecases that focuses on NUMA balancing rather than workload memory footprint. Proactive reclaim on top tiers will trigger demotion and reclaiming on the bottom nodes will trigger evicting to swap.
  

• mm: introduce snapshot_page:
  This provides (and uses) a means by which debug-style functions can grab a copy of a pageframe and inspect it locklessly without tripping over the races inherent in operating on the live pageframe directly.
  

• /proc/pid/maps read is now converted to use per vma locks:
  Instead of using mmap_lock which will block on the entire address space, reads to /proc/pid/maps is now converted to use per-vma locks. This has shown around 2x latency improvements in few of the microbenchmarks.
  

• More preparation work for separating struct slab from struct page:
  Convert struct slab to use its own flags instead of referencing page flags, which is another preparation step before separating it from struct page completely.
  

• DAMON (Data Access MONitor) Improvements:

  • DAMON_STAT module for production use: A new kernel module that simplifies DAMON setup and usage in production environments, making memory access monitoring more accessible for real-world deployments.

  • Enhanced sysfs interface: The DAMON sysfs interface now supports periodic and automated statistics updates with tunable intervals, extending beyond the previous manual userspace-requested model and reducing monitoring overhead.

  • Improved NUMA migration support: DAMON's memory migration actions (DAMOS_MIGRATE_HOT/COLD) now support interleaving policies, allowing dynamic alteration of inter-node allocation strategies for better NUMA-aware memory management.
    

Filesystem Updates

• EXT4 block allocation scalability improvements:
  This series brings significant scalability improvements to ext4 when running upto ~96 containers, all executing fallocate2 + will-it-scale workloads. The primary bottleneck identified with this workload was block group lock contention during block group scanning, for allocation purposes. The core changes in this series include:

  • Introducing ext4_try_lock_group() API to check if a block group is busy, allowing the allocator to skip locked groups instead of waiting.

  • Converting free group order lists to XArrays, which enables linear group scanning across multiple order XArrays rather than non-adjacent block group scanning caused by the previous linked-list implementation. This approach significantly reduces contention on block group locks.

  These changes, along with few other optimizations included, improved workload scalability by approximately 1400%.
  

• Uncached buffered I/O support added to EXT4:
  EXT4 now supports the IOCB_DONTCACHE flag through refactored address_space_operations write_begin() and write_end() callbacks. Uncached buffered I/O allows applications to use buffered I/O while instructing the kernel not to retain pages in the page cache after the I/O operation completes (if these pages were newly instantiated for doing RWF_DONTCACHE I/O). This is particularly useful for applications that manage their own caching mechanisms or want to avoid polluting the page cache with large sequential writes that won't be reused.
  

• EROFS metadata compression support:
  EROFS filesystem now supports compressing metadata blocks, which can be particularly useful for embedded use cases or when archiving large numbers of small files. Additionally, readdir performance has been improved by enabling readahead for directory blocks.
  

• New file_getattr/file_setattr system calls:
  Introduces extensible successors to the FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR ioctls. These new syscalls allow userspace to set filesystem inode attributes on special files (FIFO, SOCK, BLK, etc.), which was previously impossible. This is particularly useful for XFS quota projects where special files need to inherit project IDs.
  

• FALLOC_FL_WRITE_ZEROES fallocate support:
  A new fallocate() flag has been introduced that zeroes a specified file range in such a way that subsequent writes to that range do not require further changes to file mapping metadata, making them pure overwrites. This is particularly beneficial for flash-based storage devices that support efficient write zeroes commands (SCSI UNMAP bit or NVMe DEAC bit), as it avoids write amplification and improves performance. This allows users to leverage the new fallocate() flag for issuing zeroes instead of using "dd" with large block sizes, which can consume unnecessarily large disk bandwidth.
  

• PIDFS persistent information and extended attributes:
  PIDFS now persists exit and coredump information independent of whether anyone holds a pidfd for the struct pid. The lifetime of information is now bound to the struct pid itself rather than the pidfs inode/dentry. Additionally, pidfs now supports extended attributes, allowing userspace to attach meta information to tasks. Also introduces autonomous pidfs file handles that can function as full replacement for storing PIDs in files.
  

• NFSD write delegations and compound operation improvements:
  NFSD can now offer write delegations to clients that open files with O_WRONLY, which should accelerate certain corner cases as per the patch series.
  

• IOMAP writeback refactoring and FUSE support:
  The iomap writeback code has been refactored to split generic and ioend/bio based writeback code. FUSE now has iomap support for buffered writes and dirty folio writeback, enabling granular uptodate and dirty tracking with large folios. This means only relevant portions need to be read instead of entire folios, and only dirty portions need to be writeback. IOMAP supports dirty blocks tracking since v6.6
  

• VFS mmap_prepare() conversion:
  Major conversion of filesystems from the legacy f_op->mmap() hook to the new f_op->mmap_prepare() interface. This allows mmap logic to invoke the hook much earlier, prior to inserting a VMA into the virtual address space, enabling simpler error unwinding and preventing manipulation of incompletely initialized VMA state. Most filesystems including ext4, xfs, and many others have been converted.

This concludes memory management and filesystem changes which have been pulled in Linus tree for 6.17 merge window so far. The window will remain open until 10th of August, so expect more changes to follow.

pdflush to per-bdi writeback

Design of writeback mechanism evolved from global pdflush threads in early 2.6 kernels to per-BDI (backing device info) writeback threads. This per-bdi model eliminated problems like contention and request starvation but was designed for an era when storage devices were still largely spinning hard drives or SSDs but mainly with single HW queue. A single writeback thread per backing device made sense back then.

While the per-BDI approach improved upon the global pdflush model, performance limitations remained as storage hardware continued to evolve. Recent developments in memory management have begun addressing some of these bottlenecks. E.g. large folios in filesystems have significantly improved writeback efficiency by allowing writeback thread to process more data per operation.

Example showing writeback processing for a page v/s folio:

This transformation reduces CPU overhead and enables larger I/O operations that better match modern storage capabilities. All filesystems are now planning to enable use of large folios in their buffered-io path to gain from this benefit.

However, large folios only addresses the efficiency of sequential processing within a single thread. They do nothing to address the fundamental serialization bottleneck of having a single writeback thread per block device, which becomes increasingly problematic as storage devices gain parallel processing capabilities.

The Parallel I/O Stack

The Linux I/O stack has been steadily modernized to exploit parallelism at every layer. Multiple applications can issue write requests to different inodes simultaneously without lock contention, thanks to the virtual file system. Local filesystems such as ext4 and XFS divide their on-disk layout into different allocation groups thus enabling parallel block allocations and metadata operations.

Nearly a decade ago, block layer adopted the multi-queue design with per-CPU submission queues and parallel hardware dispatch queues based on the underlying disk device capabilities. As a result I/O requests can flow concurrently from applications through VFS, filesystem and block layer all the way to the storage drives.

However one notable exception remains: the writeback path still drains dirty pages with a single thread per backing device. Because modern NVMe drives can handle millions of I/O operations per second, optimizing writeback has become the next priority for kernel engineers to fully exploit NVMe throughput for buffered I/O.

Parallelizing Writeback

Now in order to just parallelize writeback, the first thought that would come to anyone’s mind is to add per-CPU parallelism to the per-BDI writeback flusher and then evenly distribute, the amount of work (number of dirty pages) across these per-CPU per-BDI threads.
However there is a subtle problem with this approach. It could cause severe filesystem fragmentation, since dirty pages belonging to the same inode might get written concurrently by multiple per-CPU, per-BDI flushers, thereby negating the purpose of the delayed-allocation techniques that filesystems employ to improve performance and reduce fragmentation. Delayed allocation lets the filesystem wait to allocate blocks until writeback time. At that point contiguous in memory dirty pages can be coalesced into finding a larger on disk extent. This approach avoids allocating individual blocks at the time when write requests are submitted which otherwise can lead to filesystem fragmentation.

So instead what this patch series does is, it creates nr_wb_ctx parallel writeback contexts instead of a single bdi_writeback and affine the inode to only a given writeback context: ensuring that all writeback operations for a specific inode are handled by the same writeback context. Each inode is assigned to a context using inode->i_ino % bdi->nr_wb_ctx logic.
This can preserves delayed allocation effectiveness while distributing different inodes across parallel per-BDI writeback contexts.

This series introduces a new struct bdi_writeback_ctx which is same as bdi_writeback structure along with few other writeback state information moved into it.
The essential changes made to struct backing_dev_info are:

• A new integer nr_wb_ctx denoting how many parallel contexts will be used.

• A dynamically allocated array of pointers to each bdi_writeback_ctx.

• Each bdi_writeback_ctx embeds its own struct bdi_writeback and links back to its parent context via a bdi_wb_ctx pointer.

This should allow the kernel to spawn and manage multiple parallel writeback context per-BDI, thus eliminating the old single writeback thread per-BDI bottleneck. These two are the heart of the design changes made to make per-BDI writeback mechanism gain parallelism. Rest of the changes are mostly mechanical trying to use bdi_writeback_ctx structure instead of bdi_writeback.

Here is the performance improvement data posted in the patch series which is quite interesting:

IOPS and throughput
===================
We see significant improvement in IOPS across several filesystem on both
PMEM and NVMe devices.

Performance gains:
  - On PMEM:
	Base XFS		: 544 MiB/s
	Parallel Writeback XFS	: 1015 MiB/s  (+86%)
	Base EXT4		: 536 MiB/s
	Parallel Writeback EXT4	: 1047 MiB/s  (+95%)

  - On NVMe:
	Base XFS		: 651 MiB/s
	Parallel Writeback XFS	: 808 MiB/s  (+24%)
	Base EXT4		: 494 MiB/s
	Parallel Writeback EXT4	: 797 MiB/s  (+61%)

We also see that there is no increase in filesystem fragmentation
# of extents:
  - On XFS (on PMEM):
	Base XFS		: 1964
	Parallel Writeback XFS	: 1384

  - On EXT4 (on PMEM):
	Base EXT4		: 21
	Parallel Writeback EXT4	: 11

Conclusion

Although the current proposal addresses one of the most fundamental serialization points in the storage stack but the question still remain about whether the current approach will adequately serve diverse filesystem characteristics or whether a more sophisticated strategy considering filesystem specific geometry (e.g. parallelizing based on per allocation group) will also be needed?
The kernel community's reception of this patch series will likely influence the direction of subsequent buffered I/O optimizations.

Lately through various mailing discussions happening in the filesystems and storage community it is evident that the kernel engineers are finally realizing that there is a need to improve the Linux buffered I/O performance.
Recent developments in this space like filesystems gaining large folio support, introduction of Uncached Buffered I/O also demonstrate that there is definitely a lot to improve in this space, to meet the demands of modern high speed storage hardware.

Well, it sure wasn’t a knee-jerk decision. The kernel community discussed deprecating ReiserFS back in 2022, and it was officially marked as deprecated then. Removing it in Linux’s first 2025 release felt like a natural progression, leading to its removal in 6.13-rc1.

But that still doesn’t answer the real question: why was it marked as deprecated in the first place?

Linux is evolving at an incredible pace, with widespread adoption across everything from the tiniest embedded devices to supercomputers and hyperscalers powering the world’s largest data centers. This rapid growth brings a constant influx of new features, making it challenging for developers to deal with unmaintained subsystems that can’t keep up with the development pace.

ReiserFS fell into this category, remaining unmaintained after its lead developer, Hans Reiser, was convicted of murdering his wife. Recently, Hans wrote a letter to the kernel community, leaving it up to them to decide what’s best and to take action accordingly.

For those interested, the design of ReiserFS-4 is still maintained and available online at internet archive. Hans Reiser’s letter to the kernel community, along with images of the original handwritten note, can be found on the LKML archives.

What does this mean for users still using ReiserFS?

Most users have likely already migrated their data to other filesystems. However, for those who haven’t, the best advice would be, to stick to 6.12 kernel and start planning a migration to a filesystem supported by Linux 6.13.

Linux 6.13-rc1 is out and with that this cycle's merge window is now closed. Feel free to give it a spin on your shiny new machines and try taking some time off during Christmas and New Year!

So two weeks have passed, the merge window is over, and -rc1 is pushed out.

And for once - possibly the first time ever(*) - it looks like the
release cycle doesn't clash horribly up with the holiday season, and
we'll have time both to stabilize this release, _and_ the work for
6.14 won't be starting until well into January. Sure, I'd not be at
all surprised if 6.14 ends up being smaller than average just because
people hopefully take a rest over the holidays, but that sounds like a
good thing. I don't think we need to stretch the release timing out,
but we most certainly can just relax a bit and make the next release
smaller.

Anyway, below is my "short mergelog" as usual, since the full log is
way too big. I feel like we had more core VFS changes than usual, but
that obviously doesn't really show up in the diff stats, since those
are - as always - dominated by drivers.

Linus

(*) Almost certainly not the first time, but it feels like we always
tend to hit Christmas head on with some timing issue.

Linux kernel development thrives on fostering an open-source community, and its success depends on bringing more people into the fold. To create and maintain an open and welcoming environment, certain ground rules have been established. A Code of Conduct has been put in place to ensure these rules are upheld and respected by everyone in the community.

In one notable incident on the LKML mailing list, Bcachefs maintainer Kent Overstreet might have crossed certain boundaries by using inappropriate language toward senior and well-regarded kernel developer Michal Hocko. Such behavior potentially violates the Code of Conduct guidelines, which can lead to serious repercussions.

Disagreements over design choices or kernel development processes are not uncommon in the Linux kernel community. However, these conflicts need to be addressed constructively. Many a times, Kent has even advocated for relaxing certain strict rules that he feels hinder Bcachefs development, such as sending large pull requests mid-release cycle.

One such disagreement with Kent prompted Linus Torvalds to respond with the following:

"You're a smart person. I feel like I've given you enough hints. Why don't you sit back and think about it, and let's make it clear: you have exactly two choices here:

(a) play better with others
(b) take your toy and go home

Those are the choices."
— Linus Torvalds

What does this mean for Bcachefs though

The Linux Foundation's Technical Advisory Board (TAB), acting on recommendations from the Code of Conduct committee, has issued a decision regarding Kent's participation in the kernel development process:

– Restrict Kent Overstreet's participation in the kernel development process during the Linux 6.13 kernel development cycle.
– Scope: Decline all pull requests from Kent Overstreet during the Linux 6.13 kernel development cycle.

As a result, no pull requests for Bcachefs will be accepted during the 6.13 merge window. This decision significantly impacts the progression of Bcachefs, delaying any major updates or improvements planned for inclusion in the kernel during this cycle. In response, Kent has issued an apology of sorts, somewhat in his own way.

Bcachefs is an impressive modern filesystem, packed with features that Linux users have long desired. There’s no doubt that both the broader Linux community and the kernel developers want to see Bcachefs succeed. However, its future will ultimately depend on what the maintainers choose to prioritize.
We hope this incident provides an opportunity for reflection and a chance to reassess these priorities. Given its potential, Linux would greatly benefit from a filesystem like Bcachefs, and we sincerely wish the project every success moving forward.

Inode Timestamps

Linux filesystems maintain a set of timestamps to track key events for each file:

• Access Time (atime): Updated when the file is read.

• Modification Time (mtime): Updated when the file’s contents are modified.

• Change Time (ctime): Updated when the file’s metadata (such as permissions or ownership) changes.

These timestamps are stored in the file’s inode. One notable behavior is that any mtime update also implicitly triggers a ctime update. However, the resolution of these timestamps is coarse—typically at the granularity of a jiffy (around milliseconds). While this level of precision suffices for most applications, it presents challenges for certain filesystems and use cases.

Problems with existing coarse-grained timestamps

Network File System (NFS), especially versions like NFSv3, is one area where this limitation becomes problematic. When a server experiences frequent file updates within a single jiffy, the client cannot reliably determine whether its cached file contents have become stale. Modern NFS implementations aim to cache file contents more aggressively to improve performance, but this requires accurate mechanisms to invalidate stale data. Since NFS clients rely on mtime and ctime comparisons to detect changes on the server side, coarse-grained timestamps hinder their effectiveness. Similar issues affect backup applications like rsync, which also depend on precise timestamps to detect file modifications.

A natural question arises: why not simply switch to higher-resolution timestamps across the board?
The answer lies in filesystem performance. Updates to mtime and ctime involve changes to inode metadata. If every read or write operation triggered frequent, fine-grained timestamp updates, it would significantly increase the volume of metadata writes. These metadata updates are often journalled to ensure filesystem integrity, adding further overhead. This tradeoff explains the kernel's reliance on coarse-grained timestamps by default: they strike a balance between functionality and performance.

For example, the on-disk structure of ext4 inodes (struct ext4_inode) reflects this design, with dedicated fields for atime, mtime, and ctime timestamps.

/*
 * Structure of an inode on the disk
 */
struct ext4_inode {
	__le16	i_mode;		/* File mode */
	__le16	i_uid;		/* Low 16 bits of Owner Uid */
	__le32	i_size_lo;	/* Size in bytes */
	__le32	i_atime;	/* Access time */
	__le32	i_ctime;	/* Inode Change time */
	__le32	i_mtime;	/* Modification time */
        <...>
};

Coarse-grained timestamps strike a balance by reducing the frequency of metadata updates, thereby improving performance. However, as discussed NFS and certain applications require more finer grained timestamp updates. This is where the multi-grain timestamp updates can be helpful.

Multi-grain Timestamp

The feature addresses this limitation by dynamically adjusting the resolution of timestamps. When an inode’s attributes are being actively observed via ->getattr(), the kernel uses a higher-resolution timestamp for mtime and ctime. For inodes that are not being actively monitored, coarse-grained timestamps remain in use. This adaptive approach provides finer granularity where needed while preserving the performance benefits of coarser timestamps for other cases.

Problems with multi-grain 6.6 implementation

The initial implementation, however, exposed a significant problem. If two files, f1 and f2, are modified in close succession, but f1 receives a fine-grained timestamp while f2 is updated with a coarse-grained timestamp, the result could imply that f2 was modified before f1, violating the VFS ordering guarantees. This issue was one of the primary reasons for reverting the feature during the 6.6 merge window.

6.13 multi-grain timestamp fix and filesystem documentation

After discussions at LSFMM 2024, Jeff revisited the feature and proposed a rather simple fix to the problem. Christian Brauner described the fix in the pull request as:

To prevent this, a floor value is maintained for multigrain timestamps. Whenever a fine-grained timestamp is handed out, record it, and when later coarse-grained stamps are handed out, ensure they are not earlier than that value. If the coarse-grained timestamp is earlier than the fine-grained floor, return the floor value instead.

This approach preserves the integrity of VFS ordering guarantees while allowing the kernel to use multi-grain timestamps effectively. Jeff Layton has since converted most major filesystems to support the feature.

The documentation outlines how filesystems can opt into multi-grain timestamps with minimal changes. i.e.

For most filesystems, it's sufficient to just set the FS_MGTIME flag in the fstype->fs_flags in order to opt-in, providing the ctime is only ever set via inode_set_ctime_current(). If the filesystem has a ->getattr routine that doesn't call generic_fillattr, then it should call fill_mg_cmtime() to fill those values. For setattr, it should use setattr_copy() to update the timestamps, or otherwise mimic its behavior.

Conclusion

The inclusion of multi-grain timestamps in kernel 6.13 is a significant milestone for Linux filesystem community. For filesystems like NFS, this feature will enable more efficient caching behavior, improving performance and addressing long-standing issues with timestamp granularity.

References:
[1]: https://lore.kernel.org/all/20241115-vfs-mgtime-1dd54cc6d322@brauner/
[2]: https://lwn.net/Articles/975863/
[3]: https://lwn.net/Articles/946394/
[4]: https://lore.kernel.org/all/20240711-mgtime-v5-0-37bb5b465feb@kernel.org/
[5]: https://www.kernel.org/doc/html/next/filesystems/multigrain-ts.htm

The $? Variable and Exit Statuses

In our previous discussion, we explored the subtleties between [[ ... ]] and [ ... ] in Bash scripting and when to use each. However, a common mistake is always using [[ ]] or [ ] with if conditions, even when it's not appropriate. Remember, [[ ]] and [ ] are used for evaluating conditional expressions such as string comparisons, pattern matching, or file tests - not for checking the exit status of commands or functions.

Common Mistake: Misusing [[...]] or [...] to Check Command Exit Status

Let's consider an example to illustrate this point:

function myfunc() {
    echo "myfunc ran"
    [[ $# -eq 0 ]] && return 1 || return 0
}

if [[ myfunc ]]; then
    echo "return success"
else
    echo "return failure"
fi

What Is the Output?

return success

Explanation

In this example, myfunc never runs in the if condition. This is because [[ myfunc ]] is evaluating the conditional expression with the string "myfunc", not executing the function. In Bash, any non-empty string inside [[ ]] evaluates to true, so the then branch is always executed, regardless of the function's existence or its return value.

Attempting to Fix with Command Substitution

Now, let's try using command substitution:

function myfunc() {
    echo "myfunc ran"
    [[ $# -eq 0 ]] && return 1 || return 0
}

if [[ $(myfunc) ]]; then
    echo "return success"
else
    echo "return failure"
fi

What Is the Output?

return success

Explanation

Here, $(myfunc) executes myfunc and captures its output, not its exit status. The if [[ ... ]] condition now evaluates the output of myfunc, which is the string "myfunc ran". Since this is a non-empty string, the condition evaluates to true, and "return success" is printed.

However, this still doesn't correctly check the function's exit status.

The Correct Way to Check Function Exit Status

To properly check whether myfunc succeeds or fails based on its exit status, you should call the function directly in the if condition without [[ ]] or [ ]. In Bash, if statements can directly evaluate the exit status of a command or function.

Corrected Script

function myfunc() {
    echo "myfunc ran"
    [[ $# -eq 0 ]] && return 1 || return 0
}

if myfunc; then
    echo "return success"
else
    echo "return failure"
fi

if myfunc "arg"; then
    echo "return success"
else
    echo "return failure"
fi

Output:

myfunc ran
return failure
myfunc ran
return success

Explanation

• First if myfunc; then block:

  • myfunc is called without arguments, so $# -eq 0 is true.

  • The function executes return 1, indicating failure.

  • The if condition evaluates the exit status 1 (non-zero), which is considered false.

  • "return failure" is printed.

• Second if myfunc "arg"; then block:

  • myfunc is called with one argument, so $# -eq 0 is false.

  • The function executes return 0, indicating success.

  • The if condition evaluates the exit status 0, which is considered true.

  • "return success" is printed.

Key Takeaways

• Use if myfunc; then to check a function's exit status.

  • The if statement directly evaluates the exit status of the command or function.

  • An exit status of 0 is true; any non-zero exit status is false.

• Do not use [[ ]] or [ ] when you intend to check the exit status of a command or function.

  • [[ ]] and [ ] are for evaluating conditional expressions, not for executing commands.

  • Placing a command inside [[ ]] or [ ] does not execute it; it treats it as a string or expression.

• Command substitution $(...) captures the output of a command, not its exit status.

  • Using $(myfunc) inside [[ ]] captures the output of myfunc.

  • If the output is non-empty, the condition will be true, regardless of the function's exit status.

• What about using [ ] (the test command)?

  • Similar to [[ ]], using if [ myfunc ]; then checks if the string myfunc is non-empty.

  • It does not execute the myfunc function.

• Using the $? Variable:

  • Alternatively, you can capture the exit status using $? immediately after the function call. This method works but is less concise than calling the function directly in the if condition.

myfunc
if [ $? -eq 0 ]; then
  echo "return success"
else
  echo "return failure"
fi

Conclusion

Bash has many such gotchas due it’s subtle nature. These gotchas can be significantly time consuming to debug if you don’t know them. Have you encountered other "gotchas" in Bash scripting?
Share them with us—we’d love ❤ to discuss more!

Let’s explore one such "gotcha" scenario.

The Confusing Behavior

Consider this simple Bash script:

Note: man page of test

• -n STRING: the length of STRING is nonzero

• -z STRING: the length of STRING is zero

VAR_STR=""
if [[ -n $VAR_STR ]]; then
    echo "var str is nonzero with [["
else
    echo "var str is zero with [["
fi

if [ -n $VAR_STR ]; then
    echo "var str is nonzero with ["
else
    echo "var str is zero with ["
fi

When executed, the output is:

var str is zero with [[
var str is nonzero with [

Wait, what? Why is the behavior different? Why does [[ -n $VAR_STR ]] correctly detect the empty string, but [ -n $VAR_STR ] behaves as though the string is non-empty?

Let’s break it down.

What’s Happening Here?

1. [[ ... ]] in Bash:

   [[ ... ]] is a Bash keyword designed for more robust and predictable conditional expressions. When you use [[ ... ]]. Bash treats the entire expression as a syntactic construct. It handles variables safely, even when they are unquoted or empty. -n $VAR_STR checks if $VAR_STR is non-empty, and since $VAR_STR is an empty string, the condition evaluates to false.

2. [ ... ] in Bash (POSIX Test):

   [ ... ] is a POSIX-compliant command (an alias for test) that behaves like a standard utility. When you use [ ... ]. Bash expands the condition and passes the resulting arguments to the test command. If $VAR_STR is empty and unquoted, the resulting expression becomes[ -n ]. Here, -n is treated as a literal non-empty string, so the condition evaluates to true.

The Root Cause: Unquoted Variables

In the [ ... ] test, failing to quote $VAR_STR causes it to expand to nothing
( [ -n ] ), which leads to unexpected behavior. This is why quoting variables is essential when using [ ... ].

How to Fix This

To make your code work consistently, always quote variables when using [ ... ]. Here’s the corrected script:

VAR_STR=""

if [[ -n $VAR_STR ]]; then
    echo "var str is nonzero with [["
else
    echo "var str is zero with [["
fi

if [ -n "$VAR_STR" ]; then
    echo "var str is nonzero with ["
else
    echo "var str is zero with ["
fi

Output:
var str is zero with [[
var str is zero with [

Now both [[ ... ]] and [ ... ] behave as expected.

Best Practices

1. Prefer [[ ... ]] in Bash Scripts

   • It’s safer and easier to use for most scenarios.

   • Quoting variables is optional but still good practice.

2. Always Quote Variables in [ ... ]

   • Quoting ensures your script behaves predictably, even with empty or special characters.

3. Know Your Shell: Understand whether you’re targeting Bash or a generic POSIX shell (/bin/sh). Use the appropriate construct accordingly.

In modern Bash scripting, [[ ... ]] is almost always the better choice. But if you need to use [ ... ]: always quote your variables!

Conclusion

Bash has many such gotchas due it’s subtle nature. These gotchas can be significantly time consuming to debug if you don’t know them. Have you encountered other "gotchas" in Bash scripting?

Share them with us—we’d love to discuss more!

Last Bangalore Kernel Meetup of 2024

The final Bangalore Kernel Meetup of 2024 is just around the corner, and it's shaping up to be an important event for the Linux kernel enthusiast community in the city. Here are the important details you need to know about this exciting gathering.

An email from Vinod Koul was sent out yesterday with all the following details.

Key Details

• Date: Saturday, 23rd November 2024

• Time: 9:00 AM - 4:30 PM

• Location:
  Texas Instruments India Pvt. Ltd.
  66/3, Bagmane Tech Park Rd, Opposite LRDE Post,
  Byrasandra, C V Raman Nagar,
  Bengaluru, Karnataka 560093
  

Registration Information

For those who submitted talk proposals, your registrations have already been processed. General registration will open in two slots on Wednesday, 20th November 2024. Be sure to register quickly to secure your spot for this exciting event!

How to Register:
• Registration Link:  https://my.weezevent.com/bangalore-kernel-meetup-1
• Deadline: Until all seats are filled

Looking Ahead

The Bangalore Linux Kernel Meetup has always been about more than just technical talks—it's a platform for connecting, learning, and growing as a community. Whether you're a veteran kernel developer or someone curious about the Linux ecosystem, this event offers something for everyone.

Make sure to check out this exciting opportunity to engage in knowledge sharing, networking, and community building. The organizers are pulling out all the stops to make the last meetup of 2024 an event to remember!