RAID question

[gaz_l]

A quick one, people. Can you add a disc to a RAID array? I have set up arrays in the past, but always with new discs.

What I'm trying to do now - I have a workstation with a single disk in, I would like to upgrade to RAID 0 to hopefully increase the performance of the drive sub-system. Can I shove another drive in, switch on the RAID controller and expect it to build an array from one disc with data and one blank one? Or will I have to start with two blank discs, make an array and then clone the original drive onto this? It's a common or garden HP workstation (xw4400) running XP, nothing exotic.

Cheers,

Gaz

 

[Sp!ke]

You have to start again and build it from fresh is the short answer. There may be some software about that would allow you to do this in a software raid configuration but I wouldnt even bother with software raid.

I wouldnt recommend using just raid 0 either as you've just trebled your chances of failure and data loss over a single disk. Once from the raid controller (assuming hardware raid) and then doubled because of the reliance of two disks over one. (and from experience, disks die regularly if you push them)

You need some kind of parity if you're concerned at all about reliability.

What is your aim and why do you need to extra speed of a raid 0 configuration?

 

[whitenemesis]

IIRC Some raid controllers will allow you to add disks to an array. Check your hardware website.
But you don't actually have an array at the moment, soo what you want to do is create an array. I would say Sp!ke has the answer

 

[gaz_l]

You have to start again and build it from fresh is the short answer.

Pretty much what I'd assumed, but you never know..

What is your aim and why do you need to extra speed of a raid 0 configuration?

I have a couple of users in our design office who work with large assemblies. Whatever they're given is never fast enough - and I'm starting to run out of things to do with a PC. The machines all have 4GB of RAM and the XP /3GB switch enabled to maximise the amount available to the application. I'm building another box with all the toys I can think of including - in this case - RAID 0 to see if it gives us any kind of performance gain worth having. The actual part files are held on a common NAS device which is a RAID 5 array.

Cheers,

Gaz

 

[andy_k]

switch to a 64 bit system - and then spend all your money on vast amounts of RAM and a twin GFX card system

That should stop them complaining for a while.

As others have said RAID 0 is a recipe for disaster

Andy

 

[Sp!ke]

Am I understanding this right? They are working on data stored on a NAS device?

Is the NAS device using fibre or copper cable? Either way, it sounds like the bottle neck is the remote data. What sort of data throughput have you currently got in this current config?

 

[gaz_l]

Data is stored on the NAS, copper cabled over a 100Mb Ethernet link. When an assembly is opened, the data is read across the network and this can be slow - but this isn't the issue, as they don't open or close large assemblies very often. If it takes a minute or two to open then so be it. I'm sure I could upgrade to Gigabit without too much trouble and speed that up.

When the assembly is opened, data is cached on the user machine, eating up RAM until it's all gone, at which point it resorts to paging and any operation on the assembly slows down to a crawl. The machines in question have recently been upgraded from 2.5 to 4GB RAM, which has helped matters - we had one general assembly that has grown to such a size that it couldn't be opened without crashing the user machine. With the extra RAM and the /3GB switch enabled, it's cured the problem for now.

But, that won't last for ever, so now I'm looking for any further improvements I can put in place. The problem is the application is 32-bit only and doesn't currently support multi-threading. So, I'm limited on addressable memory space and quad core processors are just a waste of money at the moment..

In the near term, all I'm trying to do is keep the plates spinning while I look for a better solution. Alternatively, I could cross my fingers and hope the software vendor ports the app to 64 bit and implements multi-threading before I run out of headroom..

Cheers,

Gaz

 

[timskemp]

From memory the XW4400 on board raid is not that clever, however I think you can build a raid set from two new drives then software mirror the partition from the old drive onto the new set, remove the old drive, then make an additional partition in the remaining space on the raid set. You'll need to hack XP to activate mirroring, and personally I'd not bother, just get some quicker drives - a SAS setup with 15k RPM drives will work just nicely.

Raid 0 is false economy if you value your data, a decent raid controller will do interleaved reads from a raid1 set at similar speeds and your data stays put in the event of drive failure.

 

[stevesey]

Data is stored on the NAS, copper cabled over a 100Mb Ethernet link. When an assembly is opened, the data is read across the network and this can be slow - but this isn't the issue, as they don't open or close large assemblies very often. If it takes a minute or two to open then so be it. I'm sure I could upgrade to Gigabit without too much trouble and speed that up.

When the assembly is opened, data is cached on the user machine, eating up RAM until it's all gone, at which point it resorts to paging and any operation on the assembly slows down to a crawl. The machines in question have recently been upgraded from 2.5 to 4GB RAM, which has helped matters - we had one general assembly that has grown to such a size that it couldn't be opened without crashing the user machine. With the extra RAM and the /3GB switch enabled, it's cured the problem for now.

But, that won't last for ever, so now I'm looking for any further improvements I can put in place. The problem is the application is 32-bit only and doesn't currently support multi-threading. So, I'm limited on addressable memory space and quad core processors are just a waste of money at the moment..

In the near term, all I'm trying to do is keep the plates spinning while I look for a better solution. Alternatively, I could cross my fingers and hope the software vendor ports the app to 64 bit and implements multi-threading before I run out of headroom..

Cheers,

Gaz

If 4Gb isn't enough how about a local 16Gb solid state disk with just the swap file on it? Not flash (write times to slow) - but something like this (I'm sure tomshardware reviewed something like this a year or so ago).

 

[Sp!ke]

I just think you need faster disks... or at least point the swap file on a separate (really fast disk array).

 

[timskemp]

When the assembly is opened, data is cached on the user machine, eating up RAM until it's all gone, at which point it resorts to paging and any operation on the assembly slows down to a crawl. The machines in question have recently been upgraded from 2.5 to 4GB RAM, which has helped matters - we had one general assembly that has grown to such a size that it couldn't be opened without crashing the user machine. With the extra RAM and the /3GB switch enabled, it's cured the problem for now.

But, that won't last for ever, so now I'm looking for any further improvements I can put in place. The problem is the application is 32-bit only and doesn't currently support multi-threading. So, I'm limited on addressable memory space and quad core processors are just a waste of money at the moment..

In the near term, all I'm trying to do is keep the plates spinning while I look for a better solution. Alternatively, I could cross my fingers and hope the software vendor ports the app to 64 bit and implements multi-threading before I run out of headroom..

Cheers,

Gaz

Caching raid controller running some SAS drives will be your friend. Spendy but worth it. If you don't want to reinstall then keep your apps and OS on the current drive and use the SAS for temp / swap etc.

Daft question, but you have got write caching turned on on the hard drive?

 

[stevesey]

If 4Gb isn't enough how about a local 16Gb solid state disk with just the swap file on it? Not flash (write times to slow) - but something like this (I'm sure tomshardware reviewed something like this a year or so ago).

Doh - this (and fast swap drive or swap file on a caching controller) may not help that much as each process has 4Gb address space limit so if most of the 4Gb is being used by a single process there shouldn't be that much swaping going on (also I remember from somewhere there is supposed to be a 2Gb allocated memory limit per process).

Of course if other processes are using large chunks of memory as well it may help.

 

[dsolds]

Similar issue with Microstation and AutoCAD a while back. Stevesy is correct. Under a 32 bit O/S the maximum memory that can be addressed natively is 4GB. This will be reduced somewhat by various hardware options that you have fitted so in reality you will see something like 3.5GB useable memory under 32 bit XP. Linux will allow the HUGEMEM option and is basically page address extension daemon comtrolled, not available under windows unless you use Server 2003 Enterprise.
Firstly, try the machine with no pagefile. Matters will probably improve. With 4GB RAM the machine should never be paging stuff out to disk anyway.
Disks - SCSI 15krpm with lots of CACHE. Twice as fast as SATA. Downside is noise.
RAID. Avoid RAID-0 like you would avoid a dose of the flu. RAID-5 is best suited to read operations, database etc. RAID-1 is quicker than R5 for writes usually but depends on the number of disks in the raid set.
For a workstation you are best off using 2 of the 15krpm SCSI disks on a dual channel controller, one on each channel. Install the OS on one and the main programs on the other. Data files should always be stored on the network but make sure the NAS device can deliver the data throughput, most cannot when you load them up with a few users. If this is the case (and you can test by checking the saturation of the NIC on the workstation) then a decent network fileserver is the only option. If the NAS box cannot max out a 100MB ethernet card then it is definitely not up to the job.
So, 1st - check NAS box is up to the job. Bet it's the bottleneck!
2nd, remove the pagefile from the wkstn
3rd, if it is the wkstn which is still slow then use a SCSI disk. Much faster and more reliable than SATA.
Hope this helps.
Dom

 

[ibrar]

What sort of raid?
Bank raid?
Post office raid?
Shop raid?

 

[richard]

Theres 2 issues with adding storage to RAID
(a) Making the 'logical disk bigger
(b) Making the operating system understand that the disk got bigger

In your case, you dont want to make the disk bigger (I think), just add a 2nd disk to add speed/resilence (although that may be raid 1)

People have covered (a). - the raid controller needs to store its raid info somewhere, so I doubt you can just convert a single non-raid disk into part of a raid array - but you may be able to set up a genuine raid 0 initially with 1 disk (new one). copy the data to it, then add the old one as a 2nd disk
(b) depends on the operating system and file system format. NTFS (windows XP/Server etc) can be told to 'extend the logical disk to cover the larger size). I dont know whether UNIX file systems can do (I should, I just forgot now)

R.