Basic Postmark Test on Btrfs code on kernel 3.17-r3

Basic Postmark Test on Btrfs code on kernel 3.17-r3

[nick]

I ran a basic postmark today and the results are below for the btrfs code on a Seagate Constellation drive I 
have for testing. If any of the the btrfs developers read the kernel newbies list, please send me a list of 
tests with docs on how to run them on this drive ,I don't care about killing it :) and also since it's an
enterprise drive, you can test enterprise tests if wanted.
Nick   
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
	11 seconds total
	10 seconds of transactions (10000 per second)

Files:
	50516 created (4592 per second)
		Creation alone: 500 files (500 per second)
		Mixed with transactions: 50016 files (5001 per second)
	49827 read (4982 per second)
	49581 appended (4958 per second)
	50516 deleted (4592 per second)
		Deletion alone: 532 files (532 per second)
		Mixed with transactions: 49984 files (4998 per second)

Data:
	301.18 megabytes read (27.38 megabytes per second)
	304.49 megabytes written (27.68 megabytes per second)

Basic Postmark Test on Btrfs code on kernel 3.17-r3

[Greg Freemyer]

On September 6, 2014 11:52:20 PM EDT, nick <xerofoify@gmail.com> wrote:
>I ran a basic postmark today and the results are below for the btrfs
>code on a Seagate Constellation drive I 
>have for testing. If any of the the btrfs developers read the kernel
>newbies list, please send me a list of 
>tests with docs on how to run them on this drive ,I don't care about
>killing it :) and also since it's an
>enterprise drive, you can test enterprise tests if wanted.

I'm curious if many here know the difference between a consumer drive and a enterprise drive.

Obviously a lot of enterprise drives have higher performance and quality specs, but the biggest difference is how they treat media errors.

A consumer driver is targeted at standalone use, an enterprise drive is targeted at raid array use.

Thus when a consumer drive hits a media error the firmware is setup to re-read that sector repeatedly before it gives up and returns an error to the OS.

An enterprise drive's firmware on the other hand is setup to be in a fail fast mode.  The idea is from a system perspective it should be better to have the drive return an error immediately upon a media error and let the system get the data via raid-redundancy.  That also means the raid system has more granular knowledge of what's going on with the drive and can rewrite valid data as an example to that bad sector.  A rewrite can trigger an internal sector reallocation from the spare list.

The key thing to note is that in general an enterprise drive is a bad choice for standalone use.  The firmware is just setup wrong.

I've forgotten if hdparm can be used to switch between the two operating modes.

Greg

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.