diff options
author | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2014-02-22 00:32:40 -0200 |
---|---|---|
committer | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2014-02-22 00:32:40 -0200 |
commit | 9dfbbdbf5a9c355cd43ecd5df344bd165c3cc7fc (patch) | |
tree | bf7b73d7578fc62944332d180390438ecc40629c /kernels/linux-libre-pae/3.12-btrfs-relocate-csums.patch | |
parent | ea746bf4d7ef50743c8b8d3544c3cb373047274e (diff) |
linux-libre-{pae,xen}-3.13.4-1: updating version
Diffstat (limited to 'kernels/linux-libre-pae/3.12-btrfs-relocate-csums.patch')
-rw-r--r-- | kernels/linux-libre-pae/3.12-btrfs-relocate-csums.patch | 63 |
1 files changed, 0 insertions, 63 deletions
diff --git a/kernels/linux-libre-pae/3.12-btrfs-relocate-csums.patch b/kernels/linux-libre-pae/3.12-btrfs-relocate-csums.patch deleted file mode 100644 index 7209276ef..000000000 --- a/kernels/linux-libre-pae/3.12-btrfs-relocate-csums.patch +++ /dev/null @@ -1,63 +0,0 @@ -From 4577b014d1bc3db386da3246f625888fc48083a9 Mon Sep 17 00:00:00 2001 -From: Josef Bacik <jbacik@fusionio.com> -Date: Fri, 27 Sep 2013 13:33:09 +0000 -Subject: Btrfs: relocate csums properly with prealloc extents - -A user reported a problem where they were getting csum errors when running a -balance and running systemd's journal. This is because systemd is awesome and -fallocate()'s its log space and writes into it. Unfortunately we assume that -when we read in all the csums for an extent that they are sequential starting at -the bytenr we care about. This obviously isn't the case for prealloc extents, -where we could have written to the middle of the prealloc extent only, which -means the csum would be for the bytenr in the middle of our range and not the -front of our range. Fix this by offsetting the new bytenr we are logging to -based on the original bytenr the csum was for. With this patch I no longer see -the csum errors I was seeing. Thanks, - -Cc: stable@vger.kernel.org -Reported-by: Chris Murphy <lists@colorremedies.com> -Signed-off-by: Josef Bacik <jbacik@fusionio.com> -Signed-off-by: Chris Mason <chris.mason@fusionio.com> ---- -diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c -index dec4f5a..0359eec 100644 ---- a/fs/btrfs/relocation.c -+++ b/fs/btrfs/relocation.c -@@ -4472,6 +4472,7 @@ int btrfs_reloc_clone_csums(struct inode *inode, u64 file_pos, u64 len) - struct btrfs_root *root = BTRFS_I(inode)->root; - int ret; - u64 disk_bytenr; -+ u64 new_bytenr; - LIST_HEAD(list); - - ordered = btrfs_lookup_ordered_extent(inode, file_pos); -@@ -4483,13 +4484,24 @@ int btrfs_reloc_clone_csums(struct inode *inode, u64 file_pos, u64 len) - if (ret) - goto out; - -- disk_bytenr = ordered->start; - while (!list_empty(&list)) { - sums = list_entry(list.next, struct btrfs_ordered_sum, list); - list_del_init(&sums->list); - -- sums->bytenr = disk_bytenr; -- disk_bytenr += sums->len; -+ /* -+ * We need to offset the new_bytenr based on where the csum is. -+ * We need to do this because we will read in entire prealloc -+ * extents but we may have written to say the middle of the -+ * prealloc extent, so we need to make sure the csum goes with -+ * the right disk offset. -+ * -+ * We can do this because the data reloc inode refers strictly -+ * to the on disk bytes, so we don't have to worry about -+ * disk_len vs real len like with real inodes since it's all -+ * disk length. -+ */ -+ new_bytenr = ordered->start + (sums->bytenr - disk_bytenr); -+ sums->bytenr = new_bytenr; - - btrfs_add_ordered_sum(inode, ordered, sums); - } --- -cgit v0.9.2 |