Comments on: Picking the right stripe size http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/ Storage Solutions for Real World IT Professionals Fri, 29 Aug 2008 01:54:37 +0000 http://wordpress.org/?v=1.5.2 Comment on Picking the right stripe size by: Skip http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-83621 Sat, 27 Oct 2007 15:17:44 +0000 http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-83621 WOW! You guys are awesome.... I have a Sun SE610 and a Sun ST5320 (NAS Gateway). We will be setting up the SE6130 to serve disks to the NAS gateway and then provide NFS export/CIFS shares to all the users. The CIFS shares will primarily be used for home directories and office size files (30K-800k) and the NFS shares will primarily be accessed by Unix systems with 1M-1G files. My plan is: The SE6130 has 2 controllers (1 controller tray with 10 146GB FC drives and an expansion tray with 10 146GB FC drives (20 drives total). My Plan (Please feel free to chastise me, as I am not married to it) I will create 4 RAID-5 vdisks (each 4+1) with a stripe size of 512k On each vdisk I will create five equally sized "volumes" (~100GB each). I will assign each volume in alternating sequence to a controller allowing access to the ST5320 (which is direct fibre attached). For example vdisk1vol1 will be assigned to controller A and vdisk1vol2 wil be assigned to controller B. I will do this until all 20 ~100GB volumes are assigned to the ST5320. (The assignment to a controller is somewhat arbitrary as both controllers have access to all volumes, but use the assignment as priority (I think)). From the ST5320 I will create my initial "base volume" for each export/share starting with a different vdisk for each share. For example share 1 will use vdisk1vol1, share2 will use vdisk2vol1, share3 will use vdisk3vol1, and share4 will use vdisk4vol1, share5 will start again at vdisk1vol2, etc.... I will continue this until I have all of the shares created (about 12 shares) Obviously not all shares are going to be the same size. The way the 5320 works, as I understand it, is the base volume is shared, then I grow that base volume(share/export) by simply adding LUNS as extents to the share. This is done on the fly without interruption to the end users accessing the shares. As each share/export needs additional space I will simply add space using the same "round-robin" fashion as I created them. Sorry so long... My question is what do you think? very simple. :-) WOW! You guys are awesome….

I have a Sun SE610 and a Sun ST5320 (NAS Gateway). We will be setting up the SE6130 to serve disks to the NAS gateway and then provide NFS export/CIFS shares to all the users. The CIFS shares will primarily be used for home directories and office size files (30K-800k) and the NFS shares will primarily be accessed by Unix systems with 1M-1G files. My plan is:

The SE6130 has 2 controllers (1 controller tray with 10 146GB FC drives and an expansion tray with 10 146GB FC drives (20 drives total).

My Plan (Please feel free to chastise me, as I am not married to it)
I will create 4 RAID-5 vdisks (each 4+1) with a stripe size of 512k
On each vdisk I will create five equally sized “volumes” (~100GB each). I will assign each volume in alternating sequence to a controller allowing access to the ST5320 (which is direct fibre attached). For example vdisk1vol1 will be assigned to controller A and vdisk1vol2 wil be assigned to controller B. I will do this until all 20 ~100GB volumes are assigned to the ST5320. (The assignment to a controller is somewhat arbitrary as both controllers have access to all volumes, but use the assignment as priority (I think)).

From the ST5320 I will create my initial “base volume” for each export/share starting with a different vdisk for each share. For example share 1 will use vdisk1vol1, share2 will use vdisk2vol1, share3 will use vdisk3vol1, and share4 will use vdisk4vol1, share5 will start again at vdisk1vol2, etc…. I will continue this until I have all of the shares created (about 12 shares)

Obviously not all shares are going to be the same size. The way the 5320 works, as I understand it, is the base volume is shared, then I grow that base volume(share/export) by simply adding LUNS as extents to the share. This is done on the fly without interruption to the end users accessing the shares. As each share/export needs additional space I will simply add space using the same “round-robin” fashion as I created them.

Sorry so long… My question is what do you think? very simple. :-)

]]> Comment on Picking the right stripe size by: Tim http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-80811 Sun, 14 Oct 2007 18:20:33 +0000 http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-80811 What about for games and multimedia? I primarily use my computer as a media server (movies approx: 700megs, music: 3-4megs) and for gaming, CS:Source, CnC, WoW, etc. What Stripe size would work best for this scenario? What about for games and multimedia? I primarily use my computer as a media server (movies approx: 700megs, music: 3-4megs) and for gaming, CS:Source, CnC, WoW, etc. What Stripe size would work best for this scenario?

]]> Comment on Picking the right stripe size by: Andy http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-76022 Sat, 22 Sep 2007 19:17:50 +0000 http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-76022 Hi folks, I've read this whole thread with great interest... I've been scouring the web for an answer to the following question - looks like I've found the right place to ask... I am trying to get the best performance out of the following raid set up: Adaptec SATA 2410SA raid controller 4x WD SATAII 500GB drives Windows Vista (32 bit, but will be moving to 64 bit soon) Raid 5 Stripe size is 512k I have formatted the drive under Vista with a 2048k allocation unit size... I have been getting write speeds of 26-30 MB/s - I'm sure I could improve this with a better combination of stripe size/a.u, size... I am a photographer, so most of my data comprises 8MB+ image files - I'd obviously like the best combo for this type of data transfer. Any advice much appreciated. Hi folks,

I’ve read this whole thread with great interest… I’ve been scouring the web for an answer to the following question - looks like I’ve found the right place to ask…

I am trying to get the best performance out of the following raid set up:

Adaptec SATA 2410SA raid controller
4x WD SATAII 500GB drives
Windows Vista (32 bit, but will be moving to 64 bit soon)
Raid 5 Stripe size is 512k
I have formatted the drive under Vista with a 2048k allocation unit size…

I have been getting write speeds of 26-30 MB/s - I’m sure I could improve this with a better combination of stripe size/a.u, size…

I am a photographer, so most of my data comprises 8MB+ image files - I’d obviously like the best combo for this type of data transfer.

Any advice much appreciated.

]]> Comment on Picking the right stripe size by: StorageGuy http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-72517 Wed, 29 Aug 2007 03:40:48 +0000 http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-72517 Tom, I read this post with interest. I'm confused about why Microsoft, EMC etc are advising to 'align' the data with the stripe boudaries. It seems futile to me. Sure you can use diskpart to offset the alignment initially and have a perfect alignment. Say your stripe size is 64k (amount of data written per disk at a time), if you write a 64k file great, you're still only utilizing one spindle. Now on the next write you get 4k worth of data...guess what even if your next write is 64k you're out of alignment because you'll write 60k to the second disk and 4k to the 3rd disk. Now EMC arrays etc that utilize cache can minimize this happening often by using write back cache but still once you're out of alignment who knows what random i/o pattern you'll need to get back on track. Microsoft issued a document as well as EMC has written whitepapers on setting alignment offset to 64k using diskpart. http://sqlblog.com/blogs/linchi_shea/archive/2007/02/01/performance-impact-of-disk-misalignment.aspx Tom, I read this post with interest. I’m confused about why Microsoft, EMC etc are advising to ‘align’ the data with the stripe boudaries. It seems futile to me. Sure you can use diskpart to offset the alignment initially and have a perfect alignment. Say your stripe size is 64k (amount of data written per disk at a time), if you write a 64k file great, you’re still only utilizing one spindle. Now on the next write you get 4k worth of data…guess what even if your next write is 64k you’re out of alignment because you’ll write 60k to the second disk and 4k to the 3rd disk. Now EMC arrays etc that utilize cache can minimize this happening often by using write back cache but still once you’re out of alignment who knows what random i/o pattern you’ll need to get back on track.

Microsoft issued a document as well as EMC has written whitepapers on setting alignment offset to 64k using diskpart.

http://sqlblog.com/blogs/linchi_shea/archive/2007/02/01/performance-impact-of-disk-misalignment.aspx

]]> Comment on Picking the right stripe size by: Tom http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-71807 Thu, 23 Aug 2007 14:08:47 +0000 http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/#comment-71807 Hi, Mike. It sounds like your IO will be most random. So your only goal will be to make sure that the stripe size isn't small enough to cause many of your IOs to cross stripe boundaries (and therefore double the number of IOs). In other words, having a small stripe size could hurt performance, but once that stripe size is big enough, having a larger stripe size will not help performance. About the only time you need to worry about keeping the stripe size small is if you need to have the host write IOs build up in the cache in order to generate efficient RAID-5 full stripe writes rather than inefficient read/modify/writes. But as you point out, you're using RAID-10 so this isn't an issue for you. Now, with all that said, I took a look at the HP link that you included. That link is talking about (I think) software striping in Linux. Are you using hardware RAID-1 or software RAID-1? If the former, then I'll stand by my comments. But if the latter, well, I admit I'm just not that sure. There may be an interaction between the OS page size and the stripe size, and the HP link may be correct. Sorry I can't be of more help. Good luck. TT Hi, Mike.

It sounds like your IO will be most random. So your only goal will be to make sure that the stripe size isn’t small enough to cause many of your IOs to cross stripe boundaries (and therefore double the number of IOs). In other words, having a small stripe size could hurt performance, but once that stripe size is big enough, having a larger stripe size will not help performance.

About the only time you need to worry about keeping the stripe size small is if you need to have the host write IOs build up in the cache in order to generate efficient RAID-5 full stripe writes rather than inefficient read/modify/writes. But as you point out, you’re using RAID-10 so this isn’t an issue for you.

Now, with all that said, I took a look at the HP link that you included. That link is talking about (I think) software striping in Linux. Are you using hardware RAID-1 or software RAID-1? If the former, then I’ll stand by my comments. But if the latter, well, I admit I’m just not that sure. There may be an interaction between the OS page size and the stripe size, and the HP link may be correct.

Sorry I can’t be of more help. Good luck.

TT

]]>