diff options
| author | Josef Bacik <jbacik@fusionio.com> | 2013-04-05 20:50:09 +0000 |
|---|---|---|
| committer | Chris Mason <chris.mason@fusionio.com> | 2013-04-13 07:35:06 -0400 |
| commit | 4bc4bee4595662d8bff92180d5c32e3313a704b0 (patch) | |
| tree | 69a58ddb7716fc17f515690b90de8dc928802c99 /mm/huge_memory.c | |
| parent | d8fe29e9dea8d7d61fd140d8779326856478fc62 (diff) | |
| download | linux-3.10-4bc4bee4595662d8bff92180d5c32e3313a704b0.tar.gz linux-3.10-4bc4bee4595662d8bff92180d5c32e3313a704b0.tar.bz2 linux-3.10-4bc4bee4595662d8bff92180d5c32e3313a704b0.zip | |
Btrfs: make sure nbytes are right after log replay
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.
Cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Diffstat (limited to 'mm/huge_memory.c')
0 files changed, 0 insertions, 0 deletions