From: Liu Bo <liubo2009@cn.fujitsu.com>
To: Myroslav Opyr <myroslav@quintagroup.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog
Date: Wed, 26 Oct 2011 09:12:32 +0800 [thread overview]
Message-ID: <4EA75E80.8080601@cn.fujitsu.com> (raw)
In-Reply-To: <loom.20111026T010743-539@post.gmane.org>
On 10/26/2011 07:18 AM, Myroslav Opyr wrote:
> liubo <liubo2009 <at> cn.fujitsu.com> writes:
>
>> On 04/22/2011 09:28 AM, Chris Mason wrote:
>>> Right, at the very least we want to just use one bit of that field
>>> instead of all 8. But keeping a sub-transid and putting that in the
>>> generation field of the file extent instead can get us the same benefits
>>> without stealing the bits.
>>>
>> Nice. This is the first step of my plan.
>>
>>> As we push the sub transid into the btree blocks as well, we'll get much
>>> faster tree walks too. The penalty is in complexity in the logging
>>> code, since it will have to deal with finding extents in the log tree
>>> and merging in the new extents from the file.
>> I've been thinking of this extent buffer with sub transid stuff for a while,
>> and will give it a try. :)
>
> Hi,
>
> any progress upon this patch? We started experimenting with btrfs and were
> immediately hit by the large file fsync issue.
>
The patchset has been done and queued for merge, and you can try it with the newest version:
http://marc.info/?l=linux-btrfs&m=131262353801288&w=2
http://marc.info/?l=linux-btrfs&m=131262353701285&w=2
http://marc.info/?l=linux-btrfs&m=131262357201359&w=2
http://marc.info/?l=linux-btrfs&m=131262353301276&w=2
http://marc.info/?l=linux-btrfs&m=131262356501328&w=2
http://marc.info/?l=linux-btrfs&m=131262352901267&w=2
http://marc.info/?l=linux-btrfs&m=131262355001313&w=2
http://marc.info/?l=linux-btrfs&m=131262357201356&w=2
http://marc.info/?l=linux-btrfs&m=131262354201304&w=2
http://marc.info/?l=linux-btrfs&m=131262355801321&w=2
http://marc.info/?l=linux-btrfs&m=131262355001310&w=2
http://marc.info/?l=linux-btrfs&m=131262354001293&w=2
http://marc.info/?l=linux-btrfs&m=131262353301279&w=2
thanks,
liubo
> Each fsync operation to 3.3Gb file that is having several dozens of bytes
> appended is being visualized as 55-58sec long freeze of all filesystem
> operations altogether with 99.9% CPU utilization in the process that caused the
> fsync. Removing fsync calls made several magnitudes difference in operations
> speed.
>
> FYI, we are running 2.6.38.8-32.fc15.i686.PAE with Btrfs v0.19 as XEN DomU and
> btrfs considers virtual xvd device (backed by HDD file on Dom0) to be SSD
> (according to dmesg) if that matters.
>
> Regards,
>
> m.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-10-26 1:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 7:58 [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog liubo
2011-04-21 13:16 ` Chris Mason
2011-04-22 0:55 ` Li Zefan
2011-04-22 1:28 ` Chris Mason
2011-04-25 9:58 ` liubo
2011-10-25 23:18 ` Myroslav Opyr
2011-10-26 1:12 ` Liu Bo [this message]
[not found] <4DAD7957.6070505@cn.fujitsu.com>
[not found] ` <4DAE3787.8050602@cn.fujitsu.com>
[not found] ` <4DAE9C00.2020705@cn.fujitsu.com>
2011-05-06 2:36 ` liubo
2011-05-06 12:51 ` Josef Bacik
2011-05-06 14:59 ` Chris Mason
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=4EA75E80.8080601@cn.fujitsu.com \
--to=liubo2009@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=myroslav@quintagroup.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).