I've numbered the new test as 999 for the moment so as not to collide with
tests being added while I've been working on this. I can change that and
resend if this should go in.

I'm working on a set of kernel patches to change how writeback errors
are handled and reported in the kernel. Instead of reporting a
writeback error to only the first fsync caller on the file, I aim
to make the kernel report them once on every file description:


This patch adds a test for the new behavior, on local filesystems that
can handle journalling to a separate device. Basically, open many fds to
the same file, turn on dm_error, write to each of the fds, and then
fsync them all to ensure that they all get an error back. Then, flip the
device back to working, reopen the files and ensure that no error is

With the kernel patch series in place, ext4 and xfs now pass. btrfs still
clears the error after the first fsync, so it seems like it still needs a
bit of work.

Jeff Layton (3):
  generic: add a writeback error handling test
  ext4: allow ext4 to use $SCRATCH_LOGDEV
  btrfs: allow it to use $SCRATCH_LOGDEV

 common/dmerror        |  13 +++--
 common/rc             |   5 ++
 src/Makefile          |   2 +-
 src/fsync-err.c       | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/generic/999     |  75 +++++++++++++++++++++++++++
 tests/generic/999.out |   3 ++
 tests/generic/group   |   1 +
 tools/dmerror         |  47 +++++++++++++++++
 8 files changed, 278 insertions(+), 6 deletions(-)
 create mode 100644 src/fsync-err.c
 create mode 100755 tests/generic/999
 create mode 100644 tests/generic/999.out
 create mode 100755 tools/dmerror


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Jfs-discussion mailing list

Reply via email to