RAID 5 - cluster size vs block size. Now with bonus partitioning question!

[Jeff7]

Yes, I did a search, and I've seen questions asked about each, but not about both.

I've got a 4-drive RAID 5 setup here, and I'm looking at re-creating the array, as I just upgraded it to newer drives. (Actually, the last drive is just synchronizing now.)

The block size of the array is currently 64KB, and the NTFS cluster size is 4KB. I seem to recall reading a review that said that if you have the cluster and block sizes equal, you get better performance. 32KB seems to be the largest cluster size that doesn't chew up loads of disk space. Questions then are:
1) Is that true, that equivalent cluster and block sizes optimizes performance?

2) 32KB - is that best for both? Should I do 16KB? Or go for the space-chewing 64KB?

This PC mainly works with video files over 6GB, sometimes up to 50GB if I need to filter a poorly encoded file through Virtualdub and compress it in Huffyuv format.



Ok, one additional question then:
When the new drives (200GB vs 160GB) are put in, the array rebuilds them as if they were 160GB. The 40GB remains unallocated. If I use a partitioning program (Acronis DiskDirector) to resize the partitions, will this cause the data to be fragmented? As in, will half of partition G: be at one part of the drive, while the newly created part will be stashed somewhere else?

 

[sharkeeper]

Stick with what you have - both nominal values. Do NOT increase your NTFS allocation unit size beyond the default of 4096 bytes. It's not necessary.

64KB is a default stripe size for the majority of HBA's. Stick with it unless you have a special need. Large transfers benefit slightly from a larger stripe size of 128KB or larger if your HBA supports it.

Cheers!

 

[Jeff7]

Ok, sounds good.

HBA......I'm coming up blank on what that means.
Google to the rescue - Host Bus Adapter?


Do larger block sizes affect access times? If so, I shall indeed stick with 64KB - seems like a good balance.



Bonus partition question added to the original post too!

 

[sharkeeper]

Access times remain unchanged.

I don't like partition resize utilities. If this (fragmentation issue) is of concern, check the disk after the resizing process completes.

Cheers!

 

[Jeff7]

Originally posted by: sharkeeper
Access times remain unchanged.

I don't like partition resize utilities. If this (fragmentation issue) is of concern, check the disk after the resizing process completes.

Cheers!

If the partition itself is fragmented though, I don't think that would show on a defragmenter utility though; it would be invisible, sort of the way a RAID array is invisible to the user. It doesn't look like 4 hard drives; it just looks like one gigantic drive. Or invisible the way the bad sectors are on a fresh drive from the factory. The user sees a pristine drive, but it's actually pocked with bad areas that are just never allowed to make their presence known.

 

[sharkeeper]

That would be unallocated space.

The safest way to resize is ghost it to another destination, create a new logical disk, rebuild, and send the ghost image back to the new logical disk.

Cheers!

 

[Jeff7]

Originally posted by: sharkeeper
That would be unallocated space.

The safest way to resize is ghost it to another destination, create a new logical disk, rebuild, and send the ghost image back to the new logical disk.

Cheers!

Wait, lost me - what would be unallocated space? There will be unallocated space, but it would be reallocated as a part of a partition when the existing partitions are resized. That might just leave half of the partition at one part of the drive, and the other at another part of the drive - permanent, invisible fragmentation.
That's just my theory though.


But the whole thing about copying the array's contents off, then recreating it - that's what I've been planning. I was just looking at alternative methods, as the recreating thing will take considerably more time. But I guess that's what it takes to do a job right. Right?

 

[sharkeeper]

In woodworking I always said do it nice not twice - measure twice and cut once.

The same can be said with computers but when data is involved, things become complicated.

Kind of like cars when women come into the picture, but I won't go there.

Cheers!

 

[Jeff7]

Originally posted by: sharkeeper
In woodworking I always said do it nice not twice - measure twice and cut once.

The same can be said with computers but when data is involved, things become complicated.

Kind of like cars when women come into the picture, but I won't go there.

Cheers!

Should say "measure accurately" too. I've measured twice already - and done it wrong both times. :roll:
Guess the exact moment I discover the mistake - right after it's too late to correct it. Doh!

So, I guess one this last drive is done synchronizing (sure is taking its time here, but it'll be done by the time I wake up tomorrow), time to begin the evacuation of the array, and wipe it clean.
Thanks for your input.