From: Tomasz Chmielewski <mangoo@wpkg.org>
To: Chris Mason <chris.mason@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Interesting problem with write data.
Date: Thu, 18 Nov 2010 17:00:16 +0100 [thread overview]
Message-ID: <4CE54D90.10005@wpkg.org> (raw)
In-Reply-To: <1290095654-sup-1115@think>
On 18.11.2010 16:54, Chris Mason wrote:
> Excerpts from Tomasz Chmielewski's message of 2010-11-18 10:39:05 -0500:
>> On 18.11.2010 16:07, Chris Mason wrote:
>>
>> (...)
>>
>>>> [27821.906513] btrfs-cache-8 D ffff88050c5fde98 0 8089 2 0x00000000
>>>> [27821.906517] ffff88051c3a9b60 0000000000000046 ffff88051c3a9b00 ffff88051c3a9fd8
>>>> [27821.906522] 00000000000139c0 00000000000139c0 ffff88051c3a9fd8 ffff88051c3a9fd8
>>>> [27821.906526] 00000000000139c0 ffff88050c5fde98 ffff88050c5fdea0 ffff88050c5fdb00
>>>> [27821.906530] Call Trace:
>>>> [27821.906534] [<ffffffff8159fc4e>] io_schedule+0x5e/0xa0
>>>> [27821.906538] [<ffffffff81109f15>] sync_page+0x45/0x60
>>>
>>> So, you're caching block groups. What you want to do is use Josef's new
>>> block group caching code.
>>>
>>> mount -o space_cache /dev/xxx
>>>
>>> Do the test and let the caching threads finish, then unmount and then
>>> your next run should be fast.
>>
>> # mount -o space_cache /dev/sdb4 /mnt/btrfs/
>> [29720.305741] btrfs: enabling disk space caching
>> [29720.305743] btrfs: force clearing of disk cache
>>
>>
>> I don't see any difference in behaviour with this mount option; it still
>> "hangs" for quite a bit at around ~1.8 GB (and reading with ~500 kB/s
>> when the hangs happens) on a subsequent dd run (several runs,
>> unmounts/mounts).
>
> Right, you have to wait for all the caching threads to finish before you
> unmount.
How do I find out? Is non changing reads/writes enough?
# vmstat -p /dev/sdb4 1
sdb4 reads read sectors writes requested writes
185104 1560696 114662 97396104
185104 1560696 114662 97396104
185104 1560696 114662 97396104
185104 1560696 114662 97396104
--
Tomasz Chmielewski
http://wpkg.org
next prev parent reply other threads:[~2010-11-18 16:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 12:03 Interesting problem with write data Tomasz Chmielewski
2010-11-18 14:23 ` Chris Mason
2010-11-18 14:57 ` Tomasz Chmielewski
2010-11-18 15:07 ` Chris Mason
2010-11-18 15:39 ` Tomasz Chmielewski
2010-11-18 15:54 ` Chris Mason
2010-11-18 16:00 ` Tomasz Chmielewski [this message]
2010-11-18 16:07 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2010-11-18 6:19 Magicloud Magiclouds
2010-11-18 10:36 ` Wout Mertens
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=4CE54D90.10005@wpkg.org \
--to=mangoo@wpkg.org \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.