Re: File System Performance results

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

Chris Mason wrote:
> On Mon, 2008-10-27 at 09:28 -0500, Steven Pratt wrote:
>   
>> Andreas Dilger wrote:
>>     
>>> On Oct 22, 2008  15:06 -0500, Steven Pratt wrote:
>>>   
>>>       
>>>> We have set up a new page which is intended mainly for tracking the  
>>>> performance of BTRFS, but in doing so we are testing other filesystems  
>>>> as well (ext3, ext4, xfs and jfs).  Thought some people here might find  
>>>> the results useful.
>>>>
>>>>
>>>> The main page is here:
>>>>
>>>> http://btrfs.boxacle.net/
>>>>         
>
> I meant to ask if this is a permanent site for the results?  It might
> make sense to add a more generic fsperf.boxacle.net page.
>   
We hope the site is permanent, as long as traffic and volume does not 
get too high. I'll see what I can do about the new page.

>   
>>>> Information about the machine configuration, tests run, how to reproduce  
>>>> the run and link to graphs of all the results are provided off of this  
>>>> page.  When looking at any individual test, links are provided to the  
>>>> detail output from the tests including iostat, mpstat, oprofile data and  
>>>> more.
>>>>     
>>>>         
>>> Steve,
>>> thanks for posting the numbers.  They are definitely interesting.  On
>>> the surface, ext4 is doing quite well overall (yay!),
>>>       
>> Yes, that was good news.  Along these lines if there is anything else we 
>> can do to help out ext4, just let us know.
>>
>>     
>>>  but the important
>>> point to realize is that btrfs is also providing a lot of extra function
>>> under the covers so it isn't necessarily a clear-cut answer on which one
>>> to pick.
>>>
>>> The extra CPU cost of btrfs will become increasingly irrelevant in the
>>> future I think.
>>>   
>>>       
>> While I agree that CPU usage is becoming less and less of an issue, I 
>> think that at this point in the development cycle of btrfs, we still 
>> need to take a hard look at any areas where cpu usage is excessive, and 
>> see if we can keep that to a minimum.
>>     
>
> Very true, especially performance results with checksumming off (like
> the nodatacow results for random writes).
>
>   
>>   This is the main reason we did 
>> runs without checksumming, so we could see a better apple to apple 
>> comparison, not because it is not a useful feature.  It will be very 
>> interesting to see how much HW checksumming changes this with Nehelam.
>>     
>
> See the btrfs crc header file for the #define to enable the hw assist
> mode if you're got the hardware that can do it.  In my runs here, it
> makes the checksumming free aside from the time spent storing the extra
> metadata.
>
>   
Great, but you are making me jealous. I've been waiting for my Nehelam 
box for months!

Steve
> -chris
>
>