Windows software RAID

[f0dder]

Before anybody says "software RAID sucks, go hardware", let me start by saying that you need expensive 3ware or adaptec adapters with on-board battery-backed RAM in order to have any big advantage over software raid (and most "hardware" RAID solutions are partially software anyway, usually just with an XOR accelerator engine).

So, the question is: does anybody here have experience with Windows' built-in software RAID? AFAIK it requires that you do 'dynamic' disk partitioning, has support for 0,1,5 levels, and is only supported on the pro/business versions... but that's as far as my knowledge of it goes.

So I'm wondering... can windows boot from a mirror RAID partition? And what is performance like? (I have a quadcore CPU, I don't suppose there's going to be much CPU strain unless you go RAID-5 which I'm not interested in). Does it offer the "striped read" optimization for mirrors (like intel raid matrix), or does it read from both disks and do compare?

[Shades]

I have a software raid....but on linux.  Because of power failures here that the UPS is unable to catch, that system crashes. Sometimes it crashes so badly that it has to 'rebuild' the data. The problem is that it can easily take two/three days (as in 48/72 hours!) to rebuild 1 TByte. The machine is in all this time inaccessible.

The setup is 4 250GB SATA2 harddisks (maxtor), 2GB RAM, OpenSuse 10.1 server, Athlon64 3400+, Asus K8N-E Deluxe motherboard. In it 4 years of service it has crashed like this more times than there are fingers on both of my hands.

Given the same choice today, I would go for hardware raid solution. In the end it is cheaper and a whole lot less hassle. Likely you will not encounter as much power failures as I do. Even if the rebuilding takes half the time under windows, I still would advise against going for a software raid. They sound nice in theory, but that is it.

[40hz]

I'm not laughing! I've had RAID hardware (Adaptec) malfunction and take out an entire array. The only way it could be 'fixed' was to do a recovery from external backups.

Windows mirroring provides acceptable performance on the server side.  I've got some departmental/small office installations (i.e. <= 25 users on WinServer2k3) that are performing quite nicely using software RAID-1. It does require you use 'dynamic' disk partitions. AFAIK, it does boot from the actual mirror partition.

Can't vouch for the desktop implementation since I'd rather just have a sane "recovery image & backup" procedure for those. I avoid RAID on desktops because it's expensive for what it gets you (unless you need striping for video or related media use) - and it tends to give you a false sense of security. Everybody I ever met who has RAID on their desktop box doesn't do backups because they think they're already protected.

[f0dder]

Shades: is it the RAID rebuild or the filesystem fsck that takes the time, though? And what RAID level are you running? (RAID-5 would take a long time to rebuild, but I'm only considering a mirror and a stripe). I run a mirror on my linux fileserver, btw.

40hz: 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. I'm not seeing mirror as alternative to backups, but as a supplement. I was thinking of mirror for OS install + documents/source partition, and a stripe for messing with ISOs, game installs, etc - ie, the data that I wouldn't weep if I lost.

I don't want to lose data to anything but a disk crash, though.

So, how does the windows raid work? Does it create a "virtual disk" that you can then partition, or do you set up "per-partition" kind of raid?

[Shades]

No it is definitely the rebuilding of the RAID (10) that requires that time. That system boots from a separate harddisk, the set of RAID disks even has its own power supply and is always started before the computer itself starts.

[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.

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.

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:

Code

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:
[attachimg=#]

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 ) - 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

[Stoic Joker]

Cluster size has to do with formatting, not with dynamic disk partitions, really. Default cluster size is based on partition size though,

I thought that went out the window when LBA showed up?

and I imagine dynamic disks are often used for huge partitions, so it would make sense having large cluster sizes there.

No actually they're for many small ones. With DD you're not limited to only 4 primary partitions (or the 3+extended with logical madness). It was designed to make segregating data easier so the stuff that constantly fragments can be isolated from the more static data, while allowing space to be reallocated with out complication. Resizing, merging, etc. can be done without reboots or 3rd party software with DD volumes...and you can create a virtually unlimited number of "partitions" (volumes) using folder mount points if you run out of (26...) drive letters. ...Not saying it's wise, just saying that's what it's for.

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

16KB is an atrocity no matter how you slice it. I've got a 500GB partition I use for backup storage on my server and it still gives only a 4KB size on disk for the hello file test.

...on 2nd thought, I may have been thinking about the oformat utility prep which was part of the early Win2k Fat to NTFS conversion process on the 4-16 point. ...or maybe it was FAT32 that did that *shrug* I'm over due for a vacation.

[f0dder]

Cluster size has to do with formatting, not with dynamic disk partitions, really. Default cluster size is based on partition size though,

I thought that went out the window when LBA showed up?

I think you're thinking of Cylinder/Head/Sector mapping - cluster size has to do with the filesystem, no the disk addressing method.

and you can create a virtually unlimited number of "partitions" (volumes) using folder mount points if you run out of (26...) drive letters. ...Not saying it's wise, just saying that's what it's for.

You can use mount points with classical partitions (BASIC disk) as well

16KB is an atrocity no matter how you slice it. I've got a 500GB partition I use for backup storage on my server and it still gives only a 4KB size on disk for the hello file test.

I don't see 16kb clusters as bad if you deal mainly with large files. Reduces fragmentation, and possibly means less filesystem metadata overhead for huge files as well (though I have to look at how NTFS uses extents to be sure).

...on 2nd thought, I may have been thinking about the oformat utility prep which was part of the early Win2k Fat to NTFS conversion process on the 4-16 point. ...or maybe it was FAT32 that did that *shrug* I'm over due for a vacation.

Sounds likely that using convert.exe to go from FAT32 to NTFS could leave you with large cluster sizes - ie. FAT32 quickly requires large cluster sizes for large drives, and convert only converts the FS metadata, it doesn't mess with cluster size.