Re: New experimental btrfs branch ready for testing

[Steven Pratt <slpratt@austin.ibm.com>]

Chris Mason wrote:
> On Thu, Jun 04, 2009 at 02:02:20PM -0500, Steven Pratt wrote:
>   
>> Chris Mason wrote:
>>     
>>> Hello everyone,
>>>
>>> Yan Zheng has been doing some major surgery to the back references and
>>> extent allocation code, tackling bottlenecks in the code that tracks
>>> extents.  It scales better with many snapshots and performs better in
>>> the common case of no snapshots at all.
>>>
>>> THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE.  This means it is
>>> compatible with the current btrfs disk format, but once you mount a
>>> filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD
>>> KERNELS.  Old kernels spit out an error message when you try them on new
>>> format filesystems.
>>>
>>> This is a large change, and I'm hoping to have it stable in time for the
>>> 2.6.31 merge window.  I've been testing it for about a week now, and
>>> haven't been able to cause major problems yet.  But, testing the
>>> compatibility with old format filesystems is the hard part, and
>>> everyone that pulls the new code should backup their data first.
>>>
>>> I've setup git branches called newformat where you can pull the new code.
>>>
>>> For the kernel (based on 2.6.30-rc7):
>>>
>>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat
>>>
>>>   
>>>       
>> So I started the performance runs on this. The base tests completed fine  
>> on the raid system and I will post results as soon as I can finish  
>> postprocessing, but when I tried to do nodatacow that machine it crashed  
>> pretty early. Here is console log:
>>     
>
> Hi Steve,
>
> Thanks again for hammering on these.  Yan Zheng and I have both been
> trying to reproduce problems with nodatacow and with the database random
> write run.
>   
So now that the raid machine is actually up, I discovered it got further 
than I thought on nodatacow. It did all the read tests, but appeared to 
died on 16 thread random write(not odirect). There were no messages 
logged to var/log/messages at all. Last I saw was :

Jun  4 03:14:24 btrfs1 kernel: [65856.065491] btrfs: setting nodatacow
Jun  4 15:24:45 btrfs1 syslogd 1.4.1: restart.

Just dead until we rebooted machine later that day.

> But, so far we haven't been able to trigger any crashes.    Do you see
> anything in your config or setup that is unusual?
>   
No, other than using the old mkfs with the new format.  I've kicked off 
new runs to see if I hit the same issues

Steve
> -chris
>