generic: test for fsync after adding hard link to a file

This test is motivated by an issue found in btrfs.

It tests that after syncing the filesystem, adding a hard link to a file,
syncing the filesystem again, doing a write to the file that increases
its size and then doing a fsync against that file, durably persists the
data written to the file. That is, after log/journal replay, the data
is available.

The btrfs issue is fixed by the commit titled:

  "Btrfs: fix fsync data loss after append write"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This commit is contained in:
Filipe Manana
2015-08-04 14:10:48 +10:00
committed by Dave Chinner
parent d48469086a
commit 3cc93641da
3 changed files with 126 additions and 0 deletions
+17
View File
@@ -0,0 +1,17 @@
QA output created by 090
wrote 32768/32768 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 32768/32768 bytes at offset 32768
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
File content after fsync and before crash:
0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0100000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
*
0200000
File content after crash and log replay:
0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0100000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
*
0200000