Files
apfstests/tests/generic/057.out
T
Filipe Manana 7e03b714f3 generic: Another fsync after adding hard link test
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously
fsync'ed successfully, if we end up adding a hard link to our
inode and then persist the fsync log later via an fsync of other
inode for example. This is similar to my previous test, except
that in this test the inode that ends up losing data was created
(with some data) in a transaction different from the one we made
an fsync.

The btrfs issue was fixed by the following linux kernel patch:

   Btrfs: fix fsync data loss after adding hard link to inode

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-02-16 10:14:15 +11:00

18 lines
503 B
Plaintext

QA output created by 057
wrote 8192/8192 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 4096/4096 bytes at offset 8192
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
File content before:
0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0020000 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
*
0030000
File content after:
0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0020000 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
*
0030000