Message-ID: <bug-200753-13602@https.bugzilla.kernel.org/>
Date:   Tue, 07 Aug 2018 00:47:15 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200753] New: write I/O error for inode structure leads to
 operation failure without any warning or error

https://bugzilla.kernel.org/show_bug.cgi?id=200753

            Bug ID: 200753
           Summary: write I/O error for inode structure leads to operation
                    failure without any warning or error
           Product: File System
           Version: 2.5
    Kernel Version: 4.17.0-rc3+
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@...nel-bugs.osdl.org
          Reporter: shehbazjaffer007@...il.com
        Regression: No

Created attachment 277725
  --> https://bugzilla.kernel.org/attachment.cgi?id=277725&action=edit
printAllBlocks.sh script that generates block trace of all blocks accessed

Hello!

Background
==========

I am performing block level Write I/O error injection on ext4 file system using
 device mapper. I try the following commands: truncate, chmod, chown, utimes,
symlink, creat. Each of these commands update the inode structure by writing to
the inode data structure on one of the inode blocks.

Observation
===========
If the underlying device returns an EIO error, the operation does not give any
warning or error either in the user space or in the logs, however the operation
fails to undergo completion.

Steps to Reproduce
==================

Create 2 identical QEMU disks, each of 1.5GB. in my case these are /dev/sdc
(backup disk) and /dev/sdb (primary disk). I create the image on backup disk
and record block trace there. I then copy the image from backup to primary
(using pv command) and replay the command by injecting block error on a
specific inode block.

1. please create 2 qemu images /dev/sdb (primary image) and /dev/sdc (backup
image)
2. please install pv command, compile dm-io.c with the Makefile attached.
please download all attached files in 1 folder, as some commands are helper
commands.
3. please run ./printAllBlocks.sh <cmd> where cmd is truncate, chmod, chown,
utimes, symlink, creat. this would print a list of blocks with READ/WRITE
operation. choose the inode block WRITE operation that is either the 3rd or 4th
last block to be written to disk. the block type can be verified using dumpe2fs
or debugfs command. In my disk image
4. now, with the target inode block number, run ./injectError.sh <cmd>
<errBlkNo> where cmd is one of the 6 commands mentioned above, and errBlkNo is
the inode block obtained in step 3.

5. analyse results:

truncate - fails to truncate the file size to 40960 bytes. the original size of
the file continues to remain the same, no error is reported in either syslog,
fsck or user space.

chmod - fails to correctly change the mode of the file to 777. the original
mode of the file continues (644 in my case), no error is reported in either
syslog, fsck or userspace.

chown - fails to correctly change the ownership of the file to shehbaz:shehbaz.
the original ownership of the file continues (root:root in my case), no error
is reported in either syslog, fsck or userspace.

utimes - fails to update last access and modification times to 1979.

symlink - while corrupting the target inode, no error is reported (this is okay
for the source path but here corrupting target inode leads to an unreported
error). a subsiquent ls on the created target says file system structure needs
cleaning.

creat -  fails when parent inode block update encounters a write I/O error. no
error is reported in userspace or kernel space.

Please find all programs attached for your reference.
Please let me know if any other details regarding setup is required to
reproduce the issue.

Thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists