Main Area and Open Discussion > Living Room

Windows software RAID

<< < (2/3) > >>

40hz:
40hz:[/b] server and desktop windows versions should have the same RAID implementation, really - there's a lot of code shared between the two, so really the difference mostly comes down to different registry defaults and some add-on stuff for the server editions.
-f0dder (December 12, 2008, 12:30 PM)
--- End quote ---

True. But Microsoft has become quite adept at limiting (i.e. crippling) features between the various versions of Windows; so I'm not sure it would work the same on all versions despite the fact that the underlying code may be identical. "Vee haf vays..." as the saying goes.

I've also seen complaints on various forums bemoaning how RAID is nowhere near as simple to set up on Vista as it is on Windows Server, so I suspect there might be something else going on. It probably has something to do with Vista's UAC, but again I don't know for sure. I only have Vista on one test machine, and I don't use it very much. I'm one of those people doing the "hold-on-XP-and-wait-for-Win7" thing.

Maybe this will help out. Here's a short article for newbies about going through the setup of a mirror on a small Win2k3 server. You could compare it to what you need to do for RAID on Vista:

http://technet.microsoft.com/en-us/magazine/cc160781.aspx

Basically, you install your drives ; format them as NTFS; install Windows Server; do your WSUS updates; convert your NTFS volumes to dynamic volumes (and you will get sick of rebooting when you do this step); mirror the first drive to the second; reboot and test.



And that's all there is to it if you use Windows Server. Easy.

f0dder:
True. But Microsoft has become quite adept at limiting (i.e. crippling) features between the various versions of Windows; so I'm not sure it would work the same on all versions despite the fact that the underlying code may be identical. "Vee haf vays..." as the saying goes.-40hz (December 12, 2008, 01:25 PM)
--- End quote ---
Well, playing around in vmware, I just found out how the Pro version is crippled compared to the Server version: XP Pro only supports striped volumes, you need a server edition to set up mirror or raid5- bollocks! After seeing this limitation, I do recall reading about it previously - and yeah, you can gain ability to create mirrors and parity volumes if you hack some system files, but I don't really feel like doing that.

The thing is, I have 2x74gig raptor drives in my system. On drive#1 I have a 16gig system partition for XP64 + apps, a 4gig partition for source code, data files, etc (all the "important stuff"), and a 50gig "dump" partition (for games). On drive#2, I have a single big 70gig "dump" partition for downloads, messing around with ISO files, etc.

Considering that the two "dump" partitions are expendable, I'd like to stripe them. Both for the additional speed, as well as consolidating the drive space to one volume (I've often had situations where I had something like three gigabytes left on both volumes, but needed a single volume with ~4.3gig free space for manipulating an ISO file). Since I was planning this stripe business, I though I might as well set up a mirror for OS and data partitions, to avoid having a ~20gig partition on drive#2 (stripes take two identical-sized partitions).

I guess a workaround would be resizing the system partition to 6 gigabytes, thus ended up with the following layout:


--- ---disk#1: system (6GB) | data (4GB) | stripe-part1 (60GB)
disk#2: system2 (10GB)            | stripe-part2 (60GB)

Then I could mount "system2" as a junction - problem is, apart from the windows folder, system consumption is split up between "c:\dev" (visual studio, eclipse, MSDN, DDK, SDK, ...), "c:\usr" (portable apps, minor tools, various libraries and header files, etc), and program files. I don't really feel like consolidation everything under "program files" :/

Then again, I've been considering giving Vista a spin on my workstation, and that would allow me to use symlinks instead of simply junctions... I wonder how easy it is to move "program files" to another volume on a running instance of windows, though :)

f0dder:
OK, I managed to find the time to mess around with all this the other night, and this is what I ended up with:


It was "pretty interesting" moving things around, since I had a lot of stuff referencing the "D:\" source partition - once I had emptied disk#1, I made a new source partition there and copied all the old stuff over. Getting the drive letter changed involved killing most running processes, and then doing a superfast "pskill explorer.exe" and removing the drive letter before the explorer shell reloaded... and again, "pskill explorer.exe" and adding the drive letter to the new partition before explorer (again) reloaded. This gave an error message which scared me a bit, but fortunately a reboot solved the problem.

As you can see, the picture looks a bit weird - I wasn't able to match up the sizes of the C: and D: partitions exactly. I presume this is because disk#0 had a primary partition (for C:) and an extended (for D: and E:) before it was converted to a dynamic disk. This annoys me a bit since I'm a perfectionist, but I don't really feel like reinstalling Windows from scratch just to have a prettier picture - and stuff seems to work fine.

Unfortunately, HD Tach doesn't want to benchmark the RAID partition, and only wants to deal with the physical drives. Running md5sum.exe on a 4GB ISO file seems to do about 130MB/s though, but the md5sum I have is pretty inefficient disk-wise, and I measured using Process Explorer... will have to find some more accurate benchmarking tool. The main reason for striping was getting continuous storage though, and it does seem like I got some performance improvement as well (duh :P) - I'd still like to know just how much, though.

Stoic Joker:
Crap, I wish I hadn't been tied up with an emergency server migration last week, I could have saved you a lot of time.

Dynamic Disk is something I've played with extensively in the past. It's a little wasteful space-wise as the cluster allocation size tends to be high even if the drive is prepped right so I generally try to avoid it. But it is fun.

Type hello (or some other short single word) in a text file and then check the size on disk. with plain NTFS it will generally be 4KB. With DD if the drive isn't prepped properly it could be as high as 16KB.

f0dder:
Cluster size has to do with formatting, not with dynamic disk partitions, really. Default cluster size is based on partition size though, and I imagine dynamic disks are often used for huge partitions, so it would make sense having large cluster sizes there. 16kb clusters isn't that bad anyway, if you're doing a stripe (or just huge partitions) you really ought to have relatively large files and not a crapload of smaller ones :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page