Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Matt Gulick <gulickconsulting@direcway.com>
To: "Jason C. Leach" <jleach@ocis.net>
Cc: RAID Linux <linux-raid@vger.kernel.org>
Subject: Re: Stripe Block Size.
Date: Mon, 05 Apr 2004 13:05:59 -0500	[thread overview]
Message-ID: <1081188358.4745.20.camel@localhost.localdomain> (raw)
In-Reply-To: <40719048.70705@ocis.net>

On Mon, 2004-04-05 at 11:58, Jason C. Leach wrote:
> Matt Gulick wrote:
> 
> >On Mon, 2004-04-05 at 10:51, Jason C. Leach wrote:
> >  
> >
> >>hi,
> >>
> >>I have a Promise SX6000 in a RAID5 using Linux Debian on an AMD 
> >>AthelonXP 2500+.  This array will store mostly GIS data. So about 30% 
> >>large files (a few hundred megs) and 70% small files (several megs).  I 
> >>am curious what stripe block size to use 4-64k (the fs is reiserfs).  I 
> >>was thinking 32k for the stripe block size.
> >>
> >>Thanks,
> >>J.
> >>    
> >>
> >
> >J,
> >
> >If the large files are Audio/Video for streaming, then you will want a
> >larger stripe size.  If not, go with the smallest that you can (a small
> >~.h or text file will take the same amount of space as your stripe
> >size).
> >
> >The best way to set this is to consider the total volume size.  What
> >will be the allocation block size be for that size of volume if it were
> >on a single disk for that OS?.  Set you allocation size to be the same
> >or some multiple of that value.
> >
> >  
> >
> Thanks for the reply. The total volume size will be 800G. I'm not sure 
> what reiserfs/Linux would use for the block size if that were on one 
> disk.  Can you give me some tips? 
> 
> A significant portion of the files will be a few megs and above, not 
> really any .h or other small text files (say 1%).  No streaming 
> audio/vid. The GIS data will be csv files, shape files, large TIF 
> files.  Is it better to go smaller then larger with the stripe block size?
> 

J.

The stripe size really is dependent on the usage.

For streaming content, large stripes result in fewer head seeks which
take a relatively large amount of time and can impact throughput.

For use with data base type access, a stripe size equal to the record
size would be best.

For what you describe, I would use a stripe size that is no more than
1-2 X the allocation block size.

An example of a bad stripe size:

	Stripe Size = 64K
	Allocation Size = 48k

	Each Stripe read will read 2 or more allocation blocks and have
	to extract the correct data.  This gets real messy when
	allocation blocks require more than a single read.  Writes
	are even worse because now you need to do a read-modify-write
	for each block access unless the data is in a cached block.
	Even then, the fs still has to buffer move the data into the
	cached block before writing the data.

The same is also true where the Strip is smaller than the allocation
blocks.

What I would do is create the stripe using the smallest stripe allowed
by whatever tool you use.

Create a directory or two and save a small (2-3 text bytes with gedit or
vi will do) file.

Do an ls -al on the volume and look at what the size of the directories
and the text file are.  This will be a good indication of the allocation
size.  Now, reformat the RAID with that as your smallest stripe size. 
You can make the stripes larger if you want, but always make them an
integral multiple of the allocation size.

Good luck.

Matt


----------------------------------------
Matt Gulick
Sr. Staff Engineer
Adaptec, Inc.
gulickconsulting@direcway.com
matt_gulick@adaptec.com
(715) 426-0884



      reply	other threads:[~2004-04-05 18:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-05 15:51 Stripe Block Size Jason C. Leach
2004-04-05 16:03 ` Matt Gulick
2004-04-05 16:58   ` Jason C. Leach
2004-04-05 18:05     ` Matt Gulick [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1081188358.4745.20.camel@localhost.localdomain \
    --to=gulickconsulting@direcway.com \
    --cc=jleach@ocis.net \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox