Will these components work?

[Rajahal]

Hmm, OK well I hope I do have the rails and have just forgotten about them.  Not that I would throw something like that away, I just don't remember them shipping with the case.  If I don't have them, then hopefully I can buy them somewhere (since I would need them for that Cooler Master 4-in-3 also, right?).

[SSD]

Hmm, OK well I hope I do have the rails and have just forgotten about them.  Not that I would throw something like that away, I just don't remember them shipping with the case.  If I don't have them, then hopefully I can buy them somewhere (since I would need them for that Cooler Master 4-in-3 also, right?).

 

Sometimes the rails are actually connected to the inside of the case. If you can't find them, look around inside the case.  They may be cleverly hiding.

[Rajahal]

OK, I'll check that too.  I forgot to look last night, so still no word.

[Rajahal]

Good news!  I found the rails - turns out I did had them all along, I had just forgotten about them.  I haven't actually tried them out yet, but I'm sure they'll work fine.

 

So what do you guys think, do you prefer the metal brackets or the 4-in-3 cage for adding more drives?  I really only need one more slot (since 8 HDDs is my mobo's max at the moment) but I'm still thinking about getting the 4-in-3 cage (and only using 2 of its slots) just to have the extra fan.  Of course I could probably just get one more metal bracket (since I now have one) and buy an extra fan for a few bucks, it would be cheaper.

[prostuff1]

Good news!  I found the rails - turns out I did had them all along, I had just forgotten about them.  I haven't actually tried them out yet, but I'm sure they'll work fine.

 

So what do you guys think, do you prefer the metal brackets or the 4-in-3 cage for adding more drives?  I really only need one more slot (since 8 HDDs is my mobo's max at the moment) but I'm still thinking about getting the 4-in-3 cage (and only using 2 of its slots) just to have the extra fan.  Of course I could probably just get one more metal bracket (since I now have one) and buy an extra fan for a few bucks, it would be cheaper.

 

I say go with the 4in3.  If you figure you are going to add more drives down the line then might as well do it right the first time.

[Rajahal]

That's probably a good call, thanks for the feedback.

 

This 4 GB "Dual Channel" Flash Drive is on sale at NewEgg today.  I've never heard of a dual channel flash drive, is it worth it for an unRAID build, or will it not matter?

[Rajahal]

Well, I finally did it.  I bought the hardware I needed to let me start my unRAID build, and let me say, I'm excited.  This server has been in the works since last summer, and mishap after mishap has pushed it back until now.  I messed around with it last night, and everything seems great...at least I know my motherboard and flash drive will work with unRAID.  I haven't actually added any drives yet, but soon...hopefully tonight.

 

A few questions: during the process of building my new desktop and the unRAID server, I had another hard drive fail on me.  When plugged into my unRAID server, it clicks loudly and isn't recognized.  However, when plugged into my desktop it runs just fine, no clicking, and it is recognized and usable.  Thankfully, I was able to get all the data off of it using the desktop.  I'm perplexed, though, why would it fail in the unRAID server and not in the desktop?  The unRAID server has an older motherboard, but a brand new PSU.  The desktop has a brand new motherboard, but a crappy old PSU (which I will replace as soon as I can afford it).

 

That drive is now the second 500 GB drive I've had fail (the other was months ago, but I still haven't sent it in yet).  I know I can RMA the older drive, but I'm not sure about the one that failed just recently since I bought it directly from a person, not from the company or from a retailer.  Anyone know if WD will still RMA my drive?

 

Also, since I'm down 1 TB in storage, at least temporarily, I don't have anywhere to move my data to clear off my 1 TB drive that I wanted to make my parity drive.  Instead, I think I'm going to set up my unRAID server with a 500 GB drive as a parity (I still have 2 functioning), then use only my 500 GB or smaller drives in the server, for now at least.  That leaves my 1 TB and my 640 GB drives for my desktop.  My question here is this: when I do eventually get my 2 dead 500 GB drives replaced and have room to clear my 1 TB drive of data, will I have any trouble swapping the 1 TB drive into the parity slot and the 500 GB drive out of it?  I figure it would just be a matter of installing the 1 TB drive, assigning it to be parity, then assigning the 500 GB drive to be a data drive.  Is there anything more to it than that?

 

So my unRAID server, as it currently stands, looks like:

-2.0 GHz Dual Core AMD processor

-Gigabit Motherboard

-1 GB DDR2 800 Corsair RAM

-450W Corsair PSU

-Antec P180 Case

-4 HDDs, all 7200 rpm: 2x500 GB (1 parity, 1 data), 2x250 GB (both data).

 

Other HDDs that are currently in my desktop but that I hope to add to my unRAID server eventually:

-1x1TB, 1x640GB, 1x320 GB

 

HDDs that need to be RMA'd, then added to the unRAID server:

-2x500 GB

[Joe L.]

If the hard-drive works in one PC, but not the other, I'd suspect a cabling issue before anything else. 

 

Try a different cable, try a different controller port. 

[Rajahal]

Thanks for the near immediate reply, damn you guys are fast.

 

The same SATA data cable and SATA power cable work for other drives in the unRAID server, just not for this particular one.  Also, the 500 GB drive that failed can take either standard SATA power or 4-pin molex power.  I tried both (individually, of course) in the unRAID tower, and both failed.  I tried both in the desktop, and both worked.  So the power at least doesn't seem to be the issue.  I've tried different SATA ports on the unRAID server (both on the motherboard and on my Promise card), and I get the same failure on all ports.  I haven't actually tried switching out the SATA data cable itself, since like I said it works fine for other hard drives, but I can try that when I get home tonight.

 

On a separate, unrelated note - I bought a new CPU (2.7 GHz Dual Core AMD Black) at Fry's for my desktop, and when I opened it, two of the pins were bent slightly.  I used the tip of a mechanical pencil to straighten them out as best I could.  When I dropped it into the AM2+ slot on the motherboard, it didn't slide in cleanly, but instead needed a little bit of pressure to fall into place.  Also, when installing the CPU heatsink/fan, I accidentally smudged the thermal compound, so it doesn't have a nice, clean surface anymore.  There might be a small air pocket between the heatsink and the CPU.  Do you guys think these problems are serious enough to warrant me returning the CPU and exchanging it for a new one?  Bear in mind that I live about 2 hours away from Fry's, so it isn't a matter of just popping into the store for the exchange, it will be somewhat of an ordeal.  The computer works fine and is quite fast right now, and the CPU temp (according to the mobo's hardware diagnostics screen during bootup) is between 20 C and 35 C, from what I've seen.  I may want to overclock this CPU in the future, so I guess I would rather deal with the problem now then have it come back to haunt me later.

[RobJ]

Does the clicking begin as soon as power is turned on, or after the BIOS finishes posting, or after the particular OS begins to initialize?  A different OS could possibly be accessing a different part of the drive, perhaps faulty sectors.  I assume you have had to format the drive for each, either under Windows or under unRAID?  You could eliminate OS differences suspected, by booting from your unRAID flash drive plugged into your desktop machine.  You would need to adjust the BIOS to boot from the USB drive, and you would want to be careful not to assign any drives.

 

You may also want to try SpinRite on the drive, while installed in the desktop machine.

 

I don't see a mention of SMART.  What does a SMART report look like for the drive?  (for Windows, I like SpeedFan, but there are other tools with SMART capabilities)

[Rajahal]

I just got home, and I'm going to start working on this now.

 

The clicking begins immediately upon power up, before the BIOS or OS finish loading.  Both the desktop (where the drive works) and the server (where it doesn't work, booting from a HDD, not from the unRAID flash drive), are running Vista x64, so no difference in OS.  I haven't formatted the drive as whatever unRAID likes yet, its still formatted NTFS for Windows.

 

I haven't run any SMART diagnostics yet, I'll do that soon.

 

[SSD]

If you are getting clicking before the BIOS starts, it certainly sounds like the drive itself is bad.  You could try disconnecting the data cable completely and see if merely applying power causes the clicking.  That would definitely mean that the clicking has nothing to do with the signal from the controller.

 

I've had a number of clicking drives in my lifetime, and normally it has indicated a bad or loose data cable.  But they will click when they are failing too.

[Rajahal]

I still haven't done the SMART checks, so sorry, nothing to report there.  What is really perplexing me is that this drive fails consistently in my server (even with just power plugged in, no data cable), but performs flawlessly in my desktop.  I've tried every combination of cabling and motherboard/promise card slots, and nothing changes.  So weird.

[RobJ]

If it is clicking with only a power cable connected, that would seem to conclusively indicate a power problem, not a motherboard issue.

 

Just a very long shot, have you tested the ground for this machine?  That is, can you use one of those electrical testers that indicate that hot, neutral, and ground are correctly installed at the wall?

 

If that passes, I would get a power supply tester, they aren't expensive, to test all power outputs of that PSU.  If you are in the U.S., see this Newegg list of PSU testers:  http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&Description=power+supply+tester&x=0&y=0

 

The CoolMax ones are decent, the cheaper one does not have an LCD so you can't see actual voltages, but can at least determine if things are installed correctly.  If the PSU works at all and you can boot the machine to the CMOS settings, you can usually view the 'PC Health' screen for the voltages.

[SSD]

When a drive spins up it does make some clicking noises as it comes up to speed.  Any drive will do this.  But if click continues past that, it is a problem

 

If you hook the drive to PSU1 in Machine1 (with no data cable) and get no unusual clicks, but hook it to PSU2 in Machine2 (wth no data cable) and get unusual clicks, your PSU is certainly looking guilty.  Would be the weirdest symptom of a PSU problem I've ever seen.

 

RobJ's suggestions are good ones if this is truly the symptom.  I'd recommend rerunning your tests in a controlled environment, however, to confirm you observations.

[Rajahal]

I'm familiar with 'normal' drive clicks, these are definitely not normal.  They are quite loud, I can hear them from across the room.  When I listen closely, it goes like this: I press the power button, hear the drive spin up, click loudly 3 or 4 times, then spin down dramatically (more loudly than normal spin downs from the other drives).  Then it will sit for a second or so, then spin up, click, spin down, and repeat until I kill the power.  I never let it go for too long, since I'm afraid I'm causing more damage to the drive (the clicks are the magnetic cushion failing and causing the head to bounce off the platter, right?  Physical damage = scary). 

 

I agree that the PSU seems to be the most likely culprit, but it's odd since the PSU in question is the brand new Corsair 450W I bought for the unRAID server (discussed earlier in this thread).  Plus, the same PSU provides power to the seven other hard drives in the server without issue.  Even weirder is that the same PSU provided power with no issues to this same clicking drive just a few days ago.  It wasn't until I started messing around with stuff, switching drives between the server and the desktop, that the drive started clicking.  The clicking started before I installed unRAID, back when I just had two Windows machines and was shuffling data around trying to clear a drive to start off the unRAID array. 

 

I haven't tested the ground.  I do have a simple outlet tester, so I'll try that tonight.  I'll buy a power supply tester if I need to, but even if I had one, I'm not sure if I would know how to read it or what all the voltages mean.  I guess I'll cross that bridge if I come to it.

 

While I don't see how it could be causing one individual hard drive to fail, I feel I should mention the following: My house's electrical system is far from ideal.  First of all, its old-school.  The house owner (I rent) claimed that he re-did all the wiring in the walls, but still the house is on fuses, not circuit breakers.  Also, I don't have a dedicated area to work on computers (yet), so right now I'm forced to work on the floor of my living room.  The room only has one three-pronged (hence, grounded) outlet, so I'm running all my heavy electronics off that single outlet - TV, Xbox, speakers, Desktop, and unRAID server.  Once I'm done working on the server, I'm going to move it into a different room, so it at least will be on a different circuit.  Even worse, the outlet is too far from my work/computer area for a single surge protector to reach it (and I'm using one surge protector with an 8 foot cord), so I either have to use an extension cord, or I have to daisy chain two surge protectors, which is what I'm currently doing.  So it goes: wall outlet>1st surge protector (powering TV and Xbox)>2nd surge protector (powering desktop, server, PC speakers, and peripherals).  I'm sure this is some kind of big no-no, but I really don't know what else I can do. 

 

Despite persistent problems with this particular hard drive, I'm happy to report that the rest of the unRAID server is humming along happily.  I've got my Pro license and I'm in the process of transferring data from the desktop to the server, then installing the empty drives into the server, then adding them to the array.  I could save a lot of time if I could add all the drives at once, but I don't have enough spare space to do that without losing data, so I have to do it the slow way.  No matter, I'm enjoying myself.  The only mishap thus far is that I lost about a third of my 300+ GB of music during the transfer from my desktop to the unRAID server.  I'm pretty sure what happened is that sometime during the transfer a dialog box popped up saying that if I transferred this desktop.ini (or some other lame Windows system file) that it would lose some properties.  It also mentioned that it found 3000+ files in the same situation.  I figured they were all .DS_STORE, .m3u's, .sfv's, and other files that are often found in music folders that I don't care about, so I told it to skip them all.  Then once the transfer was complete I compared the sizes of the original and destination folders and noticed a huge (~100 GB) difference.  However, considering that I have tens of thousands of music folders, there's no way I was going to go through all of them and see which ones were missing files.  So I just decided not to worry about it - if I'm really missing something, I can always get it again.  Plus I such a media pack rat that without catastrophic media losses like that my collection would never be pruned.

 

Two quick questions: in my network shares, I see folders labeled 'disk1', 'disk2', etc.  If I put a file in one of those folders, does it mean that file will only reside on the folder's corresponding hard drive?  If not, then what's the point of those folders?

 

Also, is there a quick and easy way to see how much free space the entire array has, without manually adding it up?

[SSD]

I'm familiar with 'normal' drive clicks, these are definitely not normal.  They are quite loud, I can hear them from across the room.  When I listen closely, it goes like this: I press the power button, hear the drive spin up, click loudly 3 or 4 times, then spin down dramatically (more loudly than normal spin downs from the other drives).  Then it will sit for a second or so, then spin up, click, spin down, and repeat until I kill the power.  I never let it go for too long, since I'm afraid I'm causing more damage to the drive (the clicks are the magnetic cushion failing and causing the head to bounce off the platter, right?  Physical damage = scary). 

 

I agree that the PSU seems to be the most likely culprit, but it's odd since the PSU in question is the brand new Corsair 450W I bought for the unRAID server (discussed earlier in this thread).  Plus, the same PSU provides power to the seven other hard drives in the server without issue.  Even weirder is that the same PSU provided power with no issues to this same clicking drive just a few days ago.  It wasn't until I started messing around with stuff, switching drives between the server and the desktop, that the drive started clicking.  The clicking started before I installed unRAID, back when I just had two Windows machines and was shuffling data around trying to clear a drive to start off the unRAID array. 

 

I haven't tested the ground.  I do have a simple outlet tester, so I'll try that tonight.  I'll buy a power supply tester if I need to, but even if I had one, I'm not sure if I would know how to read it or what all the voltages mean.  I guess I'll cross that bridge if I come to it.

 

While I don't see how it could be causing one individual hard drive to fail, I feel I should mention the following: My house's electrical system is far from ideal.  First of all, its old-school.  The house owner (I rent) claimed that he re-did all the wiring in the walls, but still the house is on fuses, not circuit breakers.  Also, I don't have a dedicated area to work on computers (yet), so right now I'm forced to work on the floor of my living room.  The room only has one three-pronged (hence, grounded) outlet, so I'm running all my heavy electronics off that single outlet - TV, Xbox, speakers, Desktop, and unRAID server.  Once I'm done working on the server, I'm going to move it into a different room, so it at least will be on a different circuit.  Even worse, the outlet is too far from my work/computer area for a single surge protector to reach it (and I'm using one surge protector with an 8 foot cord), so I either have to use an extension cord, or I have to daisy chain two surge protectors, which is what I'm currently doing.  So it goes: wall outlet>1st surge protector (powering TV and Xbox)>2nd surge protector (powering desktop, server, PC speakers, and peripherals).  I'm sure this is some kind of big no-no, but I really don't know what else I can do. 

 

It sounds like the drive is never getting fully up to speed and is sort of giving up and retrying.  I agree that having the drive constantly spin up and click is likely not a good thing for the drive.  If this is happening without any data cable connected, though, and it not happening with anohter PSU - it has to be the PSU.  Either that or the drive is a power hungry and the one PSU is just giving a bit more power.  Based on the fact that the other drives are all working fine, I'm tending to blame the drive.  But more research is needed.  I'd recommend a smartctl report on the drive if that's possible.

 

Despite persistent problems with this particular hard drive, I'm happy to report that the rest of the unRAID server is humming along happily.  I've got my Pro license and I'm in the process of transferring data from the desktop to the server, then installing the empty drives into the server, then adding them to the array.  I could save a lot of time if I could add all the drives at once, but I don't have enough spare space to do that without losing data, so I have to do it the slow way.  No matter, I'm enjoying myself.  The only mishap thus far is that I lost about a third of my 300+ GB of music during the transfer from my desktop to the unRAID server.  I'm pretty sure what happened is that sometime during the transfer a dialog box popped up saying that if I transferred this desktop.ini (or some other lame Windows system file) that it would lose some properties.  It also mentioned that it found 3000+ files in the same situation.  I figured they were all .DS_STORE, .m3u's, .sfv's, and other files that are often found in music folders that I don't care about, so I told it to skip them all.  Then once the transfer was complete I compared the sizes of the original and destination folders and noticed a huge (~100 GB) difference.  However, considering that I have tens of thousands of music folders, there's no way I was going to go through all of them and see which ones were missing files.  So I just decided not to worry about it - if I'm really missing something, I can always get it again.  Plus I such a media pack rat that without catastrophic media losses like that my collection would never be pruned.

 

When I first copied my data over, I found that I had some deeply nested directories and some very long directory names casused by some downloads that I did years ago.  These directories sometimes affected unRAID's ability to copy some of the data.  Some of your missing data may actually be caused by this.  I don't think I even got warnings.  I also think that there used to be (maybe still is) a bug that you can create longer pathnames in RFS than Windows will display.  Just editing the pathnames would cause the data to suddenly show up!

 

To find files that didn't copy, you might try breaking up the size checks into chunks.  So if you have 500 directories, you could check the corresponding sizes of the first 100.  If they are close to the same size, go on the the next 100, if not, look ar the first 50 and compare those sizes. You'll pretty quickly narrow down on where tje bulk of the missing files are.

 

Two quick questions: in my network shares, I see folders labeled 'disk1', 'disk2', etc.  If I put a file in one of those folders, does it mean that file will only reside on the folder's corresponding hard drive?  If not, then what's the point of those folders?

 

Also, is there a quick and easy way to see how much free space the entire array has, without manually adding it up?

 

I'm assuming that you are using "user shares".  User shares provide a nice mechanism for looking at corresponding directories on multiple disks as though they were all on one disk.  But the files are stored on the disks themselves.  You can either copy data to the user share or directly to one of the disks.  Either way the files will show up on the user share.  You can turn off the disk level shares if you like.

 

You might want to look at unmenu (see this thread).  The myMain plugin ( ) provides lots of different data views and includes the ability to see available space on the entire array.

[Rajahal]

Thanks so much, it looks like unMenu is just what I need.  I was reading this:

For those disks that are not in the protected array you can see the individual disk partitions' date=' their file-system types, and if mounted, their free space.  (The disk-management page on the improved interface will let you mount, un-mount, share, and un-share unprotected disks, even if they are from your PC and do not have a reiserfs file-system.)  The unprotected disks will not be part of the "user-shares" merge of disks, but you will be able to browse them, read, and (if you enable it) write to them.  This feature in the improved interface is there to allow you to easily migrate and access your old data.[/quote']

So that means I can add my NTFS formatted data drives to the unRAID server now, then migrate the data off them, then add them to the array?  That would save me far more time...SATAII transfers vs. Gigabit LAN.

 

I'm sure you're right about the file name length causing problems, I remember seeing that before the other issue.  I've already added the previously designated 'Music' drive over to the unRAID array, so it's been zeroed and overwritten.  Even if I could get the data back, I won't bother.  At this point I think its easier to just to replace the music as I discover it's omissions.

 

I am using User Shares, it's great.  It's one of the reasons I chose unRAID in the first place.  Where is the option to turn off the disk shares?  Also, let's say I wanted to add 100 GB to the disk1 share folder but that drive doesn't have enough free space.  Will it spill over into the rest of the array's free space, or will it give an error message?

[Rajahal]

OK, a few more questions:

 

Yesterday I was playing some music on my desktop (streaming from the unRAID server) and at the same time I tried to copy some files (also music) from the unRAID server to a flash drive plugged into my desktop.  Once the transfer started, the streaming music became very choppy.  I'm already using Gigabit LAN, so I don't think my bandwidth can get any better.  So what would solve this problem?  More RAM (I currently have 1 GB)?  Adding a cache drive?  Both?

 

Also, concerning the cache drive, does it follow the same restrictions as the parity drive?  As in, does it have to be as big or bigger than any of the other drives in the array?  Or can it be any size?

 

When using my laptop, the unRAID server network share pops up under 'Network' as soon as the unRAID server finishes booting up, no lag at all.  On my desktop, however, it is far more finicky.  The unRAID server network share won't pop up sometimes for 5 to 15 minutes after the unRAID server fully boots.  I can access the server via the web interface immediately and see that it is online, but there is significant lag in accessing the data.  Both laptop and desktop are running Vista, though different versions, I believe (home and ultimate, respectively).  I will be accessing the server from my desktop far more often, so it's important to me.  Is there anything I can do about this lag? 

[prostuff1]

Yesterday I was playing some music on my desktop (streaming from the unRAID server) and at the same time I tried to copy some files (also music) from the unRAID server to a flash drive plugged into my desktop.  Once the transfer started, the streaming music became very choppy.  I'm already using Gigabit LAN, so I don't think my bandwidth can get any better.  So what would solve this problem?  More RAM (I currently have 1 GB)?  Adding a cache drive?  Both?

Was the other stuff you were trying to copy over another disk and that disk was spun down?  I think there have been some posts on the forums about this kind of stuttering happening when a disk is spinning up.

 

Also, concerning the cache drive, does it follow the same restrictions as the parity drive?  As in, does it have to be as big or bigger than any of the other drives in the array?  Or can it be any size?

The cache drive will not help with reads but it will help with writes.  The cache drive does not have to be any particular size.  It is not technically part of the array and is sort of simulated. When doing a parity calculate/check it is the drive that is left out of that procedure.

 

When using my laptop, the unRAID server network share pops up under 'Network' as soon as the unRAID server finishes booting up, no lag at all.  On my desktop, however, it is far more finicky.  The unRAID server network share won't pop up sometimes for 5 to 15 minutes after the unRAID server fully boots.  I can access the server via the web interface immediately and see that it is online, but there is significant lag in accessing the data.  Both laptop and desktop are running Vista, though different versions, I believe (home and ultimate, respectively).  I will be accessing the server from my desktop far more often, so it's important to me.  Is there anything I can do about this lag? 

This might have something to do with the workgroup that the vista computer and the unRAID server are on. Check to make sure the all of them workgroups match.

[SSD]

It is not technically part of the array and is sort of simulated. When doing a parity calculate/check it is the drive that is left out of that procedure.

 

The cache drive can be used in different ways depending on your preference.

 

1.  Its primary intended purpose is to be a part of user shares, and when you copy data to the user share, the data is copied to the cache disk.  Then, overnight, the data is invisibly copied to a disk in the array using the "mover".

2.  It can be a location where actual data is stored.  This could include anything you want, including swap space, log files, programs, music files or movies.  You just need put the data in directories that start with a "." in order to avoid the mover.

3.  The mover can be disabled and you can use it for any reason.  For example, a person might manually copy data there and then set it up to move to specific disks overnight.  People that don't use user shares have to do something like this because there is no mover functionality for disk or custom samba shares.

 

It is a little confusing that the cache disk is not a part of the protected array but is a part of user shares.  But that's how it works.

[Rajahal]

Was the other stuff you were trying to copy over another disk and that disk was spun down?  I think there have been some posts on the forums about this kind of stuttering happening when a disk is spinning up.

 

I assume both were accessing the same disk - I was streaming music and trying to copy different music to a flash drive simultaneously.  So no, I don't think the disk was spun down.  To test that, I suppose I could manually force all the disks to spin up and try to recreate the situation.

 

This might have something to do with the workgroup that the vista computer and the unRAID server are on. Check to make sure the all of them workgroups match.

 

All the computers are on the default 'WORKGROUP'.  I just reformatted (again) and I haven't had this problem since, so maybe it has taken care of itself.

 

------------------------------

 

I read up on cache drives and I think I get it.  I only have one question: since the mover is scheduled to run once a day (3:40 am by default), what does that mean for a user who doesn't run their server 24/7?  If the server is powered down during a scheduled move, will the move start immediately once the server starts up again? 

 

I may want to add a cache drive later, but for now I don't have any drive space to spare, and I would prefer that all my data be in the protected array.  It sounds like a great use for a small drive (<100 GB), however.  Maybe I'll assign one of my disused 2.5" hard drives to the task...if I can figure out how to mount it in server's case.  I wonder, though, if the cache drive is slower speed (5400 rpm, IDE) than the rest of the array (7200 rpm, SATAII), will the benefits of using a cache drive be somewhat mitigated due to slower write speeds?

 

I'm in the process of transferring data from my 1 TB drive currently in my desktop over to the unRAID server.  Once I have emptied it, I will make it the server's new parity drive (I'm currently using a 500 GB drive as a parity).  The 500 GB drive will then become another data drive.  I've had the following thoughts/concerns with this process:

 

Conceptually, I know of two ways to swap the 1 TB drive for the 500 GB drive to function as the parity drive:

1- run a parity check

2- stop the array

3- power down

4- install the 1 TB drive into a different slot from the 500 GB drive

5- boot up

6- stop (or don't start) the array

7- change the parity drive to 'unassigned'

8- assign the 1 TB drive as the parity drive

9- assign the 500 GB drive as a data drive

10- rebuild the parity.

 

or

 

1- run a parity check

2- stop the array

3- power down

4- install the 1 TB drive into the same slot as the 500 GB drive, leave the 500 GB drive temporarily unconnected

5- boot up (I expect to see some kind of parity error at this point)

6- start the array (don't hit restore)

7- wait for the parity to be rebuilt on the 1 TB drive

8- stop the array

9- power down

10- connect the 500 GB drive to some other slot

11- boot up

12- expand the array to the 500 GB drive

13- run a parity check.

 

I've read it's a good idea to run parity checks before and after major hardware operations, so that's why I keep repeating that step.  As I understand it, the second procedure is basically like pretending that the 500 GB parity drive failed, and replacing it with the 1 TB drive, then adding the 500 GB drive back in as a data drive (a new drive as far as unRAID is concerned).  My concern with both of these methods is that while the parity is being rebuilt onto the 1 TB drive (which I expect will take hours and hours), the rest of the array will be temporarily unprotected, correct?  Considering I half-expect one of my data drives to be on it's last legs, I would rather avoid my data drives being unprotected for any extended length of time. 

 

Also, just curious, but what are appropriate read/write transfer speeds between my unRAID server and my desktop?  Currently, writing hundreds of GBs to the unRAID server, I'm getting about 8 - 12 MB/sec (according to Windows explorer), peaking at maybe 12.5 MB/sec or so.  I haven't tested the read speeds yet.  The write speeds seem a little slow to me, but I understand that the process is slowed by the unRAID server having to calculate parity for every bit of data that I transfer, plus I'm so new to unRAID that I don't have a feel for what normal performance should look like.  All my hard drives (in both server and desktop) are SATAII 7200 rpm drives, and I'm transferring over Gigabit LAN.

 

It seems I am utterly incapable at responding with reasonably-sized posts, sorry about that, and thanks for taking the time to read it all.  This thread's title should be changed to 'Rajahal's musings on unRAID' 

 

edit: cleaned this post up a bit, in case this thread makes it to the wiki.  I think its easier to read now...

[SSD]

I'm in the process of transferring data from my 1 TB drive currently in my desktop over to the unRAID server.  Once I have emptied it, I will make it the server's new parity drive (I'm currently using a 500 GB drive as a parity).  The 500 GB drive will then become another data drive.  I've had the following thoughts/concerns with this process:

 

It is impossible to replace the parity disk (or any disk) without losing protection while the rebuild occurs.  But here is a procedure that comes close.

 

Run a full parity check before you begin (you may have already done that).  Assuming it is 100% clean, do the following ...

 

*** THIS IS ONLY THE PROCEDURE FOR UPGRADING A PARITY DISK, NOT FOR REPLACING A DATA DISK ***

 

(Do not write ANYTHING to the array until this whole process is complete - at least through step 5)

 

1- Stop the array

2- Go to the devices page and set your new 1T as parity and assign the old parity disk to the next data slot

3- Go back to the main page and press "restore" (normally a very bad idea but okay if replacing parity after a clean parity check)

4- Start the array

*** The old parity disk will show unformatted, but do NOT press the format button yet ***

5- After parity build is complete, run a full parity check (buliding parity will take a while as will checking parity - I estiamte 4-8 hours each for your array)

(assuming all that is clean, now your array is protected)

6- Now press the format button (ONLY the old parity disk should show unformatted - if anything else is showing unformatted DO NOT PRESS IT)

(the format should happen very quickly and your array should be fully usable)

 

A few questions I anticipate ..

 

Q - Why did I have you assign the old parity disk to the array, but hold off on formatting it? 

A - If, during the parity build or the parity check, you have a drive failure, that old parity disk is still intact (we didn't format it).  With some instructions that I am not posting at this time can be found 2 posts down in this thread, you could move that disk back to the parity slot and rebuild the failed disk.  If you had formated it, you would update at least some of the disk, making recovery much more difficult.  By waiting until the array is protected to format it, you keep it pristine you give yourself an ability to recovery if this very unlikely scenario occurs (drive fails during parity update).

 

Q - And why can't I write to the array during the parity build, the unRAID manual says that I can?

A - For similar reasons, you don't want to write anything to the existing data disks.  If you should need to put your old parity drive back in place. ALL of the data disks need to look exactly the same as they did when that old parity disk was in place.  Updating the disks will result in an inaccurate build should you need to put the old parity disk in place.

 

Q - Why put the old parity disk in the array at all until after the new parity is built?  Can't I just leave it unassigned and add it later?

A - By keeping it in the array during the parity build, you avoid the need to add it later and endure a lengthy (automatic)  "clear the data disk" procedure.  You certainly can leave it out and add it later - it will just elongate the process by a few hours.

 

Make sense?

 

BTW, you might want to consider running a burn in test on the new 1T drive before adding it to the array.  Joe L create a preclear script (see user customizations section) that does a good job of running it through its paces (note that the fact that the drive will be cleared at the end is not important for this particular procedure).

[prostuff1]

I read up on cache drives and I think I get it.  I only have one question: since the mover is scheduled to run once a day (3:40 am by default), what does that mean for a user who doesn't run their server 24/7?  If the server is powered down during a scheduled move, will the move start immediately once the server starts up again?

That I am not sure about.  I do not think that the mover script is that "smart."  The way around this is a guess to just be diligent in hitting the "move now" button.

 

I may want to add a cache drive later, but for now I don't have any drive space to spare, and I would prefer that all my data be in the protected array.  It sounds like a great use for a small drive (<100 GB), however.  Maybe I'll assign one of my disused 2.5" hard drives to the task...if I can figure out how to mount it in server's case.  I wonder, though, if the cache drive is slower speed (5400 rpm, IDE) than the rest of the array (7200 rpm, SATAII), will the benefits of using a cache drive be somewhat mitigated due to slower write speeds?

You should still see a benefit from a older laptop drive, even if it is IDE.  The drive I use as my cache drive is an old 160GB SATA1 drive. It is not "new" by any means.

 

a lot of stuff…

What I usually do is run the preclear script for two or three runs on the new disk (in this case your 1TB parity drive).  I then unassign the 500GB parity,  shut down the server, and then unplug the 500GB disk.  Then I plug the new parity in and start the server back up.  Assign the 1TB as the new parity and let it do its business by calculating parity and then running a parity check.  After I have determined the new parity drive to be performing well I shut the server back down and reattach the old parity drive.  I DO NOT assign it in the interface though.  I run the preclear script on it for 2-3 runs to make sure it is in good working order and then assigning it to the array.

 

Also, just curious, but what are appropriate read/write transfer speeds between my unRAID server and my desktop?  Currently, writing hundreds of GBs to the unRAID server, I'm getting about 8 - 12 MB/sec (according to Windows explorer), peaking at maybe 12.5 MB/sec or so.  I haven't tested the read speeds yet.  The write speeds seem a little slow to me, but I understand that the process is slowed by the unRAID server having to calculate parity for every bit of data that I transfer, plus I'm so new to unRAID that I don't have a feel for what normal performance should look like.  All my hard drives (in both server and desktop) are SATAII 7200 rpm drives, and I'm transferring over Gigabit LAN.

The read speed should be just fine and you should not have any problems with it.  Your write speed is about normal for an unRAID server that has a parity drive assigned.  We usually advice people to not assign a parity drive when they do the initial transfer as that will increase the write speed to the server.

[SSD]

I'm in the process of transferring data from my 1 TB drive currently in my desktop over to the unRAID server.  Once I have emptied it, I will make it the server's new parity drive (I'm currently using a 500 GB drive as a parity).  The 500 GB drive will then become another data drive.  I've had the following thoughts/concerns with this process:

 

It is impossible to replace the parity disk (or any disk) without losing protection while the rebuild occurs.  But here is a procedure that comes close.

 

Run a full parity check before you begin (you may have already done that).  Assuming it is 100% clean, do the following ...

 

*** THIS IS ONLY THE PROCEDURE FOR UPGRADING A PARITY DISK, NOT FOR REPLACING A DATA DISK ***

 

(Do not write ANYTHING to the array until this whole process is complete - at least through step 5)

 

1- Stop the array

2- Go to the devices page and set your new 1T as parity and assign the old parity disk to the next data slot

3- Go back to the main page and press "restore" (normally a very bad idea but okay if replacing parity after a clean parity check)

4- Start the array

*** The old parity disk will show unformatted, but do NOT press the format button yet ***

5- After parity build is complete, run a full parity check (buliding parity will take a while as will checking parity - I estiamte 4-8 hours each for your array)

(assuming all that is clean, now your array is protected)

6- Now press the format button (ONLY the old parity disk should show unformatted - if anything else is showing unformatted DO NOT PRESS IT)

(the format should happen very quickly and your array should be fully usable)

 

A few questions I anticipate ..

 

Q - Why did I have you assign the old parity disk to the array, but hold off on formatting it? 

A - If, during the parity build or the parity check, you have a drive failure, that old parity disk is still intact (we didn't format it).  With some instructions that I am not posting at this time, you could move that disk back to the parity slot and rebuild the failed disk.  If you had formated it, you would update at least some of the disk, making recovery much more difficult.  By waiting until the array is protected to format it, you keep it pristine you give yourself an ability to recovery if this very unlikely scenario occurs (drive fails during parity update).

 

Q - And why can't I write to the array during the parity build, the unRAID manual says that I can?

A - For similar reasons, you don't want to write anything to the existing data disks.  If you should need to put your old parity drive back in place. ALL of the data disks need to look exactly the same as they did when that old parity disk was in place.  Updating the disks will result in an inaccurate build should you need to put the old parity disk in place.

 

Q - Why put the old parity disk in the array at all until after the new parity is built?  Can't I just leave it unassigned and add it later?

A - By keeping it in the array during the parity build, you avoid the need to add it later and endure a lengthy (automatic)  "clear the data disk" procedure.  You certainly can leave it out and add it later - it will just elongate the process by a few hours.

 

Make sense?

 

BTW, you might want to consider running a burn in test on the new 1T drive before adding it to the array.  Joe L create a preclear script (see user customizations section) that does a good job of running it through its paces (note that the fact that the drive will be cleared at the end is not important for this particular procedure).

 

UPDATE:

 

I decided to go ahead and post instructions in this same thread if you did have a drive failure during this process.  (That will allow this thread to act as a full "how to" which can be referenced from the wiki.)

 

*** DO NOT DO THIS UNLESS YOU HAD A DRIVE FAILURE DURING THE PARITY BUILD OR PARITY CHECK PROCESS DESCRIBED ABOVE ***

 

1 - Immediately capture a syslog (see Troubleshooting link in my sig for instructions).

2 - ... Also capture smartctl reports on each disk

3-  Take a screenshot of the unRAID main page showing all the disks and their slots - print for later reference

4 - Post them on the forum and get advice as to what has happened

5 - Determine which disk failed. Should be obvious if it has a red ball next to it, but it could be more difficult to figure out which drive failed.  The forum can help, or if you may know enough to read the syslog to figure it out.

6 - Power down the system (using unRAID GUI or powerdown script).

7 - ... Install the new replacement disk.  It needs to be >= size of failed disk and <= size of OLD parity.  (I don't think parity swap is possible in this scenario.)

8 - ... Also disconnect / remove the failed disk.

9 - Boot the server

10- The array should not start, but if it does, stop it.

 

*** The following steps are extremely important to be performed in one sitting.  Once you start them, you can't shutdown the array and plan to come back later.  ***

 

11 - Go to the devices page and unassign the new parity disk (leave it unassigned)

12- ... Also unassign the OLD parity disk from the data slot and assign it to the parity slot

13- ... Also assign the replacement disk to the same slot that the failed disk used to be in (e.g. disk3)

14- Go back to the main page and press restore (usually a bad idea for okay in this case)

15- Open a telenet session and enter the command ...

 

   set invalidslot n   (where n is the SLOT number of the failed disk, e.g., 3 (if disk3 failed).  That slot should now contain a replacement disk as described above in step 7)

 

16- Go back to the unRAID GUI and start the array.  The disks will all have "blue balls" next to them and it will be scarey to press the start button, but if you've done everything in these instructions, press it.  What will happen is that unRAID will now rebuild the data disk onto the replacement disk in slot n.  Normally when you start an array after pressing "restore", it will rebuild parity.  But that "set invalidslot" command tells unRAID to not rebuild parity, but instead rebuild the specified data disk.  You can confirm by watching / refreshing the unRAID GUI.  The write counts on the replacement disk should be growing, while the other disks read counts should be growing but write counts holding steady.

17- Wait until the rebulid is complete.  Your data should be fully restored on the replacement data disk.

18- Now go to paypal and send bjp999 $100 for this lifesaving post (just kidding here - but do send me a note if you ever actually follow these steps to let me know how it went!)

 

Now you can go back and try to update parity again.