Long story short...I've got 3 sticks of 2GB Corsair Dominator RAM from an old i7-920 gaming rig.

 

Is there any point in keeping/using them as part of a rebuild, or would I be limiting the choice of mobo/CPU components to the point that any cash saving would be insignificant? I can't see any gain from using the i7-920 itself as an unRaid build (due to power usage and the fact that the CPU has been worked hard over the years). But the RAM was some of the best you could buy once upon a time.

 

The next build will be a drastic step up from what I have already - and as I understand it, a Xeon build would mean ECC RAM (and this RAM wouldn't work). But I'd appreciate some thoughts....especially as this i7 rig seems destined for the scrapheap. Quite sad really

 

http://www.corsair.com/en-gb/tr3x6g1600c8d

If you already had or were planning to buy used components then it might make some sense. Otherwise no.

Probably not - whilst the existing HDDs will remain in use, the rebuild would see a new CPU/mobo with the Ram needed to run the extra services. I read that DDR3 will work with LGA 1150, but if I end up not upgrading components until next year (entirely possible) then holding onto that RAM becomes even more pointless. Helps that my current build has been offline for quite some time so it's almost as new.

 

Short term: add an extra 1GB of RAM, but I don't think even that will enable this build to run Dockers (a topic i need to do a lot of research on).

The Core i7-920 and 6GB of DDR3 would make a decent small unRAID server for a few Dockers if the rest of that machine is running.  And yes, DDR3 1600 is the standard for Haswell RAM. 2 GB modules aren't that flexible to work with anymore in an era where we throw 8, 16, and more at a server though.

The Core i7-920 and 6GB of DDR3 would make a decent small unRAID server for a few Dockers if the rest of that machine is running.  And yes, DDR3 1600 is the standard for Haswell RAM. 2 GB modules aren't that flexible to work with anymore in an era where we throw 8, 16, and more at a server though.

 

Hmm, interesting. Could this form a test server for me experimenting with deploying VMs, Dockers and the like?

 

I can set up a network with the i7 as an unRaid server (I've got a pair of 320GB drives plus an old GTX260 already installed). Deploy unRaid onto it and hook up to an old router I've got to a test laptop. One of the things I want to do is to create a VM lab within my unRaid server - my main production server clearly won't cut it. But this i7 would be a good place to test and experiment on - if it breaks....who cares. Using that i7 in production long-term is perhaps not the best idea, given that it's been overclocked for years (I used a great 3rd party air cooler). But for shorter-term testing? Not an outrageous idea to be honest...and it's not like I'm going to be able to sell it for much as it is.

 

There's two pains to deal with: one is the MASSIVE Cosmos S case that it's currently in. The second, more serious, issue is that I'm half convinced that the PSU on this unit is starting to fray around the edges (I had a couple of BSODs before deciding to retire it). I think it'll be a case of test it and see what happens.

 

But a very interesting idea - thank you!

The i7-920 is clearly dated, but it's still a nice system.  PassMark about half of what a current i7 provides, but that's still a very respectable 4995 ... plenty of "horsepower" for a fairly nice server running a couple of Plex streams.

 

And although the density of your old RAM is fairly low, that's still 6GB and with 3 modules it will run in triple-channel mode, so you'll have plenty of memory bandwidth.

 

Finally, the chip supports vt-x, and most likely your motherboard has chipset support for vt-d (that wasn't an on-chip feature in that generation), so it should work just fine as a virtualization test bed.

 

I wouldn't change a thing -- just use the system as is if you want a nice UnRAID test box ... the only thing you might want to add is additional disk capacity.

 

Motherboard is a Gigabyte EX58-UDR3 - a quick Google search suggests it will support vt-d but with a BIOS update (I'd appreciate a 2nd opinion on that).

 

(and wasn't there a problem with Gigabyte boards way back when? Something to do with the BIOS saving some info onto the Parity drive?)

Motherboard is a Gigabyte EX58-UDR3 - a quick Google search suggests it will support vt-d but with a BIOS update (I'd appreciate a 2nd opinion on that).

 

(and wasn't there a problem with Gigabyte boards way back when? Something to do with the BIOS saving some info onto the Parity drive?)

 

Yes, the UDR3 supports vt-d ... simple enough to just flash the latest BIOS.

 

As for Gigabyte boards and automatic BIOS backups via a HPA created on a disk ... Yes, some of their boards do this.  They create a small HPA (Host Protected Area) on the first disk they encounter during POST and backup the BIOS to this location.

 

This is NOT necessarily the parity disk ... it's created on the first disk that's enumerated during POST -- and not on any others.    It IS an issue if that happens to be the parity disk, as that will now be smaller than any other disks of the same size, so can't be used as parity.    I'm not sure if this is a feature of your board or not (it doesn't appear to be, but I'd check the BIOS to be sure) ... but if it is all you have to do is disable "BIOS Backup to Hard Disk" in the BIOS settings and it wont' do this [Gigabyte has likely changed the wording in the BIOS over time, so it may not have that exact title ... but it should be fairly clear if it's on your board].

 

It's also easy to be sure you don't have the problem, even if it's not turned off in the BIOS => just boot the system with ONE drive in the system that you do NOT plan to use as parity ... then shut down and add the rest of the drives.  Once the BIOS backup has been written to a drive, it won't be repeated on any others -- so that will ensure the backup isn't on the parity drive.

 

Note that while many folks have complained about this feature on Gigabyte boards, it DID have a very nice attribute:  if you had a corrupted BIOS (which could render many boards inoperable), you could select the recovery mode and it would automatically restore the BIOS from the hard drive image.

 

It's also easy to be sure you don't have the problem, even if it's not turned off in the BIOS => just boot the system with ONE drive in the system that you do NOT plan to use as parity ... then shut down and add the rest of the drives.  Once the BIOS backup has been written to a drive, it won't be repeated on any others -- so that will ensure the backup isn't on the parity drive.

That's not totally foolproof. If that drive fails or is removed for whatever reason, then another drive will be corrupted with HPA, possibly the parity drive. Also, best to make sure the BIOS backup function is disabled by default, that way if the BIOS CMOS battery fails and the defaults get loaded, you won't be in for a nasty surprise.

 

All this is easily manageable like Gary says, IF YOU REMEMBER THE BOARD HAS THE ISSUE. Problems can occur of you have years of no issues, and you conveniently forget about it until it jumps up and bites you. I've had systems with uptime measured in years, so it's easy to forget you even had an issue at all.

 

If I was dealing with a board that had a BIOS backup option, I'd write myself a nice fat note and stick it in the case, and another note on the outside of the case. That way anytime I needed to manage that box, I would be reminded. 

Given that this particular board has dual Bios I'm hopeful that the HPA won't be an issue.

 

Should be an interesting project however. There's quite a few things I want to explore with UnRaid - I've had the idea of deploying something like IPFire as a VM to provide IDS within a network - but it's obviously way smarter to experiment on a test bed.

From Page 51 of your motherboard's manual:

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

Backup BIOS Image to HDD

Allows the system to copy the BIOS image file to the hard drive. If the system BIOS is corrupted, it will be recovered from this image file. (Default: Enabled)

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

 

So it DOES backup the BIOS to an HPA, but you CAN disable the feature very easily by simply setting this to Disabled 

 

 

Haha - I remember that I still had the Mobo box in the loft (I had to go up to get extra Sata power cables ) and found the manual...

 

Was planning on going through it tonight looking for just that information....and there it is on page 51.

So I've reconnected everything, cleaned out a LOT of dust, adjusted the BIOS....and it all booted up into a command line prompt.

 

Not put it onto a network yet (one step at a time), but I pulled back the SMART reports for the pair of 320GB drives I'm using in this experiment. As I understand them they read fine (value should always be well above threshold) but again I'd welcome a 2nd opinion - especially since one of the drives has seen a lot more action (looks like Seek Error Rate is an issue)....

 

I need to pre-clear both drives (not done that for ages) - not sure if that's a good move or not given that these are used drives. Again, this will be a non-operational server

smartsdb.txt

smartsdc.txt

Did it boot to the UnRAID flash drive?    ... if so it should show a command line with "Tower Logon"

 

THEN you access it from a browser on another computer -- you don't configure it from the server itself.

 

[Just go to //Tower/ ]

... if it's not booting to the UnRAID flash drive you need to adjust the boot options in the BIOS.

 

Did it boot to the UnRAID flash drive?    ... if so it should show a command line with "Tower Logon"

 

THEN you access it from a browser on another computer -- you don't configure it from the server itself.

 

[Just go to //Tower/ ]

 

Yeah I know this (it's a good reminder for others new to unRaid however). This was just an initial test to see if things booted up ok - now I can remove the connection to the monitor and go headless. The rest of the configuration and testing will be via Putty and the GUI.

 

(Including changing the tower name - as this will be a 2nd server - so the browser lookup needs to be unique?)

... this will be a 2nd server - so the browser lookup needs to be unique?)

 

Yes, the name needs to be unique.  What you need to do is boot up this server with the other one turned off (so there are no address conflicts);  then change the ID of the server to whatever you want -- "Tower2", "BackupServer", etc. => then reboot and you can turn on your primary server.

 

Cheers Gary - test box up and running on the network.

 

Next stage is pre clearing (these are old drives so this may be a dumb idea in the long run. But I'd rather know these drives are going to fail now than after a few months of experimenting). First pre-clear has just been started.

 

NB: I needed to set up a new config in unMenu first (see this forum post) before disk.cfg could see the pair of HDDs that are in this build. This is probably not a smart thing to do if you're adding a new drive to an existing setup!. I also noticed in the System Log a mention of HPA. I have set the BIOS correctly not to save BIOS data onto the HDD, but triple check to make sure before committing data onto the array.

 

(Mods - a lot of these notes are for my own benefit, but I'd like to think they'll be useful for others thinking of getting more out of unRaid. Where's the best place to put my rambling comments? )