https://bugzilla.kernel.org/show_bug.cgi?id=207729 Bug ID: 207729 Summary: Mounting EXT4 with data_err=abort does not abort journal on data block write failure Product: File System Version: 2.5 Kernel Version: 5.3.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 Assignee: fs_ext4@xxxxxxxxxxxxxxxxxxxx Reporter: rebello.anthony@xxxxxxxxx Regression: No Created attachment 289111 --> https://bugzilla.kernel.org/attachment.cgi?id=289111&action=edit TGZ containing shell script and c code to reproduce the bug Hi, I've been performing some experiments that involve fault injection in the ext4 file system and noticed something that might be a bug. According to [ext4 Documentation](https://www.kernel.org/doc/Documentation/filesystems/ext4.txt), `data_err=abort` should abort the journal if an error occurs in a file data buffer in ordered mode. The assumption I'm making is that the mount option `data_err=abort` will abort the journal if the file system fails to write a data block to disk (I'm not sure about my assumption since the documentation mentions a "file data buffer"). ### Overview I have noticed that when fsync fails due to a failed data block write, the journal is not aborted even when the file system is mounted with `data_err=abort`. The file system continues to accept and handle future writes and fsyncs. I've attached a tgz which contains a small C program along with a shell script to reproduce the problem. The C file is a simple workload that writes and fsyncs a file. The shell script uses losetup to create a loop device, configures the device mapper to fail certain sectors, mounts the ext4 file system, and runs the compiled C file to demonstrate the issue. Usage ``` tar -xvzf ext4-data-err-abort-bug.tgz cd ext4-data-err-abort-bug bash run_bug.sh ``` ### Steps to reproduce independently 1. Create a 1GB loopdevice and mkfs -t ext4 2. Create a file with 12K data on the mounted loopdevice 3. Using debugfs, identify the 3 blocks for the file 4. Create a device mapper device using the dmsetup create command, configure the 2nd block to use error target while everything else is a linear target 5. Open the file, write to the 2nd page, fsyncs (this fsync should fail) 6. Write to the 3rd page, fsync (This passes even though we expect it to fail because of the `data_err=abort` mount option) 7. close file, unmount, dmsetup remove, etc ### Actual results I observed that the first fsync fails because of the write failure. However, the journal is not aborted. The second write and fsync succeed. ### Expected results The first fsync should fail and the journal should be aborted. Any future write/fsync would cause the file system to detect an aborted journal and probably remount in read only mode. ### Other information I used an unmodified linux 5.3.2 from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.3.2.tar.gz on an Intel Xeon Silver 4114 deca core processor. ``` $ awk -f scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux my-hostname 5.3.2 #1 SMP Mon May 11 14:13:56 CDT 2020 x86_64 x86_64 x86_64 GNU/Linux GNU Make 4.1 Binutils 2.30 Util-linux 2.31.1 Mount 2.31.1 Module-init-tools 24 E2fsprogs 1.44.1 Xfsprogs 4.9.0 Nfs-utils 1.3.3 Linux C Library 2.27 Dynamic linker (ldd) 2.27 Linux C++ Library 6.0.25 Procps 3.3.12 Net-tools 2.10 Kbd 2.0.4 Console-tools 2.0.4 Sh-utils 8.28 Udev 237 Modules Loaded acpi_pad acpi_power_meter aesni_intel aes_x86_64 ahci autofs4 binfmt_misc coretemp crc32_pclmul crct10dif_pclmul cryptd crypto_simd dca drm drm_kms_helper drm_vram_helper fb_sys_fops fscache ghash_clmulni_intel glue_helper grace hid hid_generic i2c_algo_bit i40e ib_cm ib_core ib_iser input_leds intel_cstate intel_powerclamp intel_rapl_common intel_rapl_msr intel_rapl_perf ioatdma ipmi_devintf ipmi_msghandler ipmi_si ipmi_ssif ipod ip_tables irqbypass iscsi_tcp iw_cm ixgbe joydev kvm kvm_intel libahci libcrc32c libiscsi libiscsi_tcp lockd lpc_ich mac_hid mdio mei mei_me mgag200 mpt3sas nfit nfs nfs_acl nfsv3 pps_core ptp raid_class rdma_cm sch_fq_codel scsi_transport_iscsi scsi_transport_sas skx_edac sunrpc syscopyarea sysfillrect sysimgblt ttm usbhid wmi x86_pkg_temp_thermal xfrm_algo xfs x_tables ``` -- You are receiving this mail because: You are watching the assignee of the bug.
