Skip to contentSkip to conversation

Basic Postmark Test on Btrfs code on kernel 3.17-r3

DISCUSSION nick 2 participants 2 messages Sep 7, 2014

lore
Share & tools
lore

nick

author
#0 lore raw

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)
#1 lore raw
Quoted 7 lines · 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.

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

Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.