Btrfs: make sure nbytes are right after log replay
authorJosef Bacik <jbacik@fusionio.com>
Fri, 5 Apr 2013 20:50:09 +0000 (20:50 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 26 Apr 2013 04:19:56 +0000 (21:19 -0700)
commit8fdeb71b5022b4578e3339b861019c5a00c77700
treecc4927db4b7ffea456e2df5e330e18bceb5e5aa7
parentb00919cd72ed9753390a9fbb5541cbba12e5e826
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>
fs/btrfs/tree-log.c