From: Josef Bacik <jbacik@fusionio.com>
To: Miao Xie <miaox@cn.fujitsu.com>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH V3] Btrfs: remove btrfs_sector_sum structure
Date: Fri, 14 Jun 2013 11:27:12 -0400 [thread overview]
Message-ID: <20130614152712.GA28783@localhost.localdomain> (raw)
In-Reply-To: <51878334.4000807@cn.fujitsu.com>
On Mon, May 06, 2013 at 04:17:24AM -0600, Miao Xie wrote:
> Using the structure btrfs_sector_sum to keep the checksum value is
> unnecessary, because the extents that btrfs_sector_sum points to are
> continuous, we can find out the expected checksums by btrfs_ordered_sum's
> bytenr and the offset, so we can remove btrfs_sector_sum's bytenr. After
> removing bytenr, there is only one member in the structure, so it makes
> no sense to keep the structure, just remove it, and use a u32 array to
> store the checksum value.
>
> By this change, we don't use the while loop to get the checksums one by
> one. Now, we can get several checksum value at one time, it improved the
> performance by ~74% on my SSD (31MB/s -> 54MB/s).
>
> test command:
> # dd if=/dev/zero of=/mnt/btrfs/file0 bs=1M count=1024 oflag=sync
>
> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
> ---
> Changelog v2 -> v3:
> - address the problem that the csums was inserted into the wrong range, this bug
> was reported by Josef.
>
> Changelog v1 -> v2:
> - modify the changelog and the title which can not explain this patch clearly
> - fix the 64bit division problem on 32bit machine
> ---
Hit another bug with this patch. Doing a relocate it was screwing up csums for
data blocks we were relocating. I think this fixes the problem but I've only
just made sure it made my problem go away. Please look at it and do some extra
testing with relocation and if it is good re-submit. In the meantime I'm
dropping this patch from btrfs-next until you resubmit. Thanks,
Josef
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index df3c632..1209649 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -4473,11 +4473,13 @@ 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 = ordered->start;
+ sums->bytenr = disk_bytenr;
+ disk_bytenr += sums->len;
btrfs_add_ordered_sum(inode, ordered, sums);
}
next prev parent reply other threads:[~2013-06-14 15:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 10:17 [PATCH V3] Btrfs: remove btrfs_sector_sum structure Miao Xie
2013-06-14 15:27 ` Josef Bacik [this message]
2013-06-18 3:13 ` [PATCH] Btrfs: fix wrong csum clone when doing relocation Miao Xie
2013-06-18 12:23 ` Josef Bacik
2013-06-19 2:36 ` [PATCH V4] Btrfs: remove btrfs_sector_sum structure Miao Xie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130614152712.GA28783@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).