Re: Interesting problem with write data.

[Tomasz Chmielewski <mangoo@wpkg.org>]

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