Short Stroke & Stripe Size

T

ToddW2

2[H]4U
2FA
Joined
Nov 8, 2004
Messages
4,021
I have 3 x 640gb WD Blacks I want to setup in RAID0.
And a 4th I plan to use for a 'backup' drive.

What should I short stroke my 640gb drives to, and also what should stripe size be for optimal performance?

For reference right now my 150gb raptor has only 75gb used, and this system is 2.5 years old.

I want the best performance out of my RAID0 setup!

My 4th drive will be for picture storage, and backup, and I have a NAS for true-backup too.
 
well, short stroking will only be useful if you are using that particular raid volume for OS or games, is that what you plan to do?

if so, i'd run something like:

raid vol1 - 144gb with 32 - 64kb stripe. 32kb if it's just windows and other software, 64kb if it includes games

vol2 - remainder with 128kb stripe

keep stuff you use actively on the first volume and leave the second for storage to get the full benefits of short stroking
 
Why should you want to use a stripesize lower than 128KiB? That would more or less guarantee you lose all random I/O performance increase offered by RAID0.
 
The only reason to use a lower stripe size is for highly transactional data, where the data being transferred is really small.

For instance if your database is transferring 32kb of data, the you would not want to use 128kb stripe because during a read/write operation you would not be getting the benefit of RAID and because your data would only be accessed from a single drive in the array.

For your Desktop just use the largest stripe size.
 
For example, if you put your OS on a RAID0 drive with a 64K stripe you will lose performance over a single drive. This is because by far the majority of files in the OS are <20KB. If each stripe on the hard disk is 64KB then that means each 20KB file will sit in a 64KB block of its own on one hard disk. Effectively you are only reading the file from 1 hard disk and it is spaced out in 64KB blocks from the neighbouring files. This will increase seek times and decrease performance. If you have a 128KB file and use a 64KB stripe size your read time should be about the same. Basically the drives can read 2 64KB blocks from each drive simultaneously but there is am increased delay for each drive to find the file, so you get an improvement in read time, but a decrease in seek time which balances it out to average. As the files get larger so the advantages increase accordingly.

If you have a 16KB stripe size the advantages start increasing earlier, with a 32KB file you are already reading from 2 disks. But the problem is increased file fragmentation and hence read/write delays due to writing a large file into tiny pieces.

So there is no win/win situation. What you need to ask yourself is what is causing you the most performance delay. Usually it is writing out those big files, no one worries about how long it is taking to save a 4KB Word file, RAID can't help you there anyways. So if you are looking to improve the writing of 32MB .tiff files give your array a 64KB or 128KB stripe size. Saving of 4KB Word files won't be any faster, hell, it might even be a tad slower, but that's already so fast you won't even notice. But copying 100 32MB .tiff files or saving 1GB of streaming video will be a hell of alot easier.
Click to expand...

stolen from tom's hardware
 
Good info.

What software do I use to short stroke, and set the stripe size?
 
You select both the size of the volume (making it small is what causes the short stroking) and stripe size in the on-board RAID manager.
 
nitrobass24 said:
The only reason to use a lower stripe size is for highly transactional data, where the data being transferred is really small.
Click to expand...
I'm not sure this is correct. My own tests confirm the opposite; for small files a large stripesize is beneficiary, for large files a smaller stripesize is beneficiary - though with write buffering and read-ahead sequential speeds should be the same regardless stripesize.

For instance if your database is transferring 32kb of data, the you would not want to use 128kb stripe because during a read/write operation you would not be getting the benefit of RAID and because your data would only be accessed from a single drive in the array.
Click to expand...
Forgive me, but that's exactly what you DO want. If you let all physical disks in a striping RAID work on ONE I/O request at a time, you would stick to single-disk random I/O performance.

Instead, you would want to ensure that each I/O done by the Operating System covers only ONE physical disk. So that disk can handle the request, and other disks are available to accept any other queued I/O requests that they can process. This way, you have multiple drives working on two different I/O request simultaneously; that's where you get higher random IOps performance from your RAID0.

The only pitfall is that this requires multiple queued I/O's. If your application only reads or writes in one I/O stream that is not sequential, it may not be enough to let both disks work at the same time and you may get close to single-disk performance. However, as we're talking database applications there would be many queued I/O's so all the potential for parallel I/O processing using RAID0.

Bad alignment can also cause a 128KiB stripesize RAID0 to lose all its random IOps advantages, because due to the alignment one I/O request would cover parts of both disks; thus disabling any opportunity to let the disks work on parallel I/O at any time.

To make RAID0 improve random read/write IOps:
- you need alignment
- you need a large stripesize to ensure each I/O is handled by one physical disk
- you need proper bandwidth so each disk is not waiting on the other like with Parallel ATA/PCI.
- you need multiple queued I/Os to get a random IOps benefit.
- sequential transfers need buffering/read-ahead; don't test the raw RAID instead test on filesystem level that uses these optimizations.
 
sub.mesa said:
Forgive me, but that's exactly what you DO want. If you let all physical disks in a striping RAID work on ONE I/O request at a time, you would stick to single-disk random I/O performance.
Click to expand...

Thats the point i was trying to make.

You want full stripe reads or you are missing out on the benefits of RAID.
 
I can support my theories with benchmarks, i'm currently setting up a nice test server to do some RAID benches again. They'll be on FreeBSD and use geom_stripe RAID0 driver, testing with ordinary SATA HDDs.

When doing RAID0, you can have two philosophies:
- involve all disks in a single I/O request; so each disk process a part of that single I/O request
- ensure a single I/O requests is handled by a single drive in the RAID-array; having others free for other requests to process other I/O requests in parallel

The first philosophy seems predominant, but i never saw good RAID0 benefits from it. Both philosophies should give you maximum sequential read and write speeds; when buffered; meaning you perform these tests on a real filesystem not with a synthetic benchmark connecting directly to the raw RAID device.

The first philosophy won't give you any higher random I/O performance, while the second philosophy does if there are multiple queued I/O requests available such as in database workloads. So you lose nothing by opting for the second philosophy, while you lose all random IOps benefits of RAID0 if you opt for the first philosophy.

There are reports of windows FakeRAID drivers that always transfer the contents as large as the stripesize; so if your stripesize is 128KiB and you read a 4KiB file; the RAID driver would read the 128KiB block anyway. this will hamper random IOps performance as the driver is performing unnecessary read-ahead. the BSD drivers don't do this; though i have no information about actual windows products that work this way. I'm thinking Silicon Image/JMicron/Promise/etc.

In that case, using a large stripesize might actually hurt performance. But otherwise, it shouldn't. The vinum project also sees no objection in using stripesizes of multiple megabytes; this would mean you have higher multi-stream sequential performance than when using a default 128KiB stripesize.

I hope we can see things in perspective as soon as i can produce any real numbers to look at. I can setup the RAID using either philosophies:
- 4 disks, 32KiB stripesize, random read with 128KiB (should be close to 1-disk performance)
- 4 disks, 128KiB stripesize, random read with 128KiB (should show increased IOps over single disk)
 
I`ll do some tests too.

I want to test the above items, and also # of drives for optimal performance to cost/energy usage.

I have:
4x640gb WD black new in box
2x1TB WD Black new in the box
1x500gb WD Black new in the box

to test configs on.

I think I also have 2x150gb Raptors, and maybe some other drives.

I plan to test on my new i7 mobo with the onboard RAID ich10 or something, and also an older P4/Core2 Duo mobo.

Oh the fun :D
 
Daaaaamn! You have so many HDs you're not even sure if you got a pair of Raptors sitting around?!

Donate to my charity, I need some HD space :D
 
NoForgiveness said:
Daaaaamn! You have so many HDs you're not even sure if you got a pair of Raptors sitting around?!

Donate to my charity, I need some HD space :D
Click to expand...

LOL!

In the last couple months I think I've ordered like 9 HDs, I have another 2x1TB in my NAS.

The other 2x1TB are for my Raid1 backup server.

And I know I have 2 raptors they are in my systems right now not sure if I will want to yank them to do tests, they are getting re-formated anyway, so I just may ;) but the issue too is I think 1 may be dieing, that's why I got the 500gb black a few months ago. Just no time to set any of these up lately.!!
 
You must log in or register to reply here.
Back
Top