diff options
| author | Josef Bacik <jbacik@fusionio.com> | 2013-04-05 20:50:09 +0000 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2013-04-25 21:23:49 -0700 |
| commit | 7a860c4dfb8ebaf777a7df185df4436ea343189a (patch) | |
| tree | 8e96cc305860ccdfde5371e1bec3edae2014e5d6 /Makefile | |
| parent | 856398d852436111d5cdbf30374f576671903998 (diff) | |
Btrfs: make sure nbytes are right after log replay
commit 4bc4bee4595662d8bff92180d5c32e3313a704b0 upstream.
While trying to track down a tree log replay bug I noticed that fsck was always
complaining about nbytes not being right for our fsynced file. That is because
the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
nbytes are not necessarily updated properly when we log it. So to fix this we
need to set nbytes to whatever it is on the inode that is on disk, so when we
replay the extents we can just add the bytes that are being added as we replay
the extent. This makes it work for the case that we have the wrong nbytes or
the case that we logged everything and nbytes is actually correct. With this
I'm no longer getting nbytes errors out of btrfsck.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
Reviewed-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions