Control: tags -1 + moreinfo Control: forwarded -1 https://lore.kernel.org/ntfs3/[email protected]/
Hi Frank, On Tue, Jun 30, 2026 at 12:24:37PM +0200, Frank wrote: > Package: linux-image-amd6linux-image-7.0.13+deb14-amd64 > Version: 7.0.13-1 > Severity: important > X-Debbugs-Cc: [email protected] > > Dear Maintainer, > > * What led up to the situation? > > I was running a backup script using rsync to copy files from a BTRFS > filesystem (mounted via dm-crypt/LUKS) to an NTFS filesystem inside a > VeraCrypt-encrypted container (also backed by dm-crypt). The source files > included a mix of large and small files. > > * What exactly did you do (or not do) that was effective (or ineffective)? > > I ran the rsync backup multiple times across several days, on both kernel > 7.0.12+deb14.1-amd64 and 7.0.13+deb14-amd64. The crash occurred > reproducibly during sustained write operations to the NTFS3 filesystem, > always while rsync was actively writing files. I confirmed via process > state monitoring (ps aux) that after the crash, the rsync process entered > an uninterruptible sleep (D state) and could not be terminated even with > SIGKILL. > > I initially suspected USB disconnects or GPU driver issues (I also have > known amdgpu driver instabilities on this RX 9070 XT system), but kernel > log timestamps showed the "kernel BUG at fs/iomap/buffered-io.c:1061!" > message occurring within 1-2 seconds of the rsync write error > ("Broken pipe"), ruling out those other causes as the trigger for this > specific crash. > > * What was the outcome of this action? > > The kernel emitted: > kernel BUG at fs/iomap/buffered-io.c:1061! > Oops: invalid opcode: 0000 [#1] SMP NOPTI > RIP: 0010:iomap_write_end+... > > The rsync process(es) became permanently stuck in D state, requiring a > full system reboot to recover. The underlying BTRFS and EXT4 filesystems > performed automatic recovery/remount on the subsequent boot, suggesting > the filesystems themselves were left in an inconsistent state by the > crash. > > This appears to match publicly reported issues with the same crash > signature on other systems (CachyOS kernel 7.0.x), specifically > identified as occurring during buffered writes to NTFS3 filesystems > via ntfs_file_write_iter(). This is possibly related to https://lore.kernel.org/ntfs3/[email protected]/ . Can you please report back if you still can trigger the issue with 7.1.3-1 as landed in Debian unstable? Note we will likely switch from NTFS3_FS to NTFS_FS in near future. Regards, Salvatore
