@CCWTech No support for 16GB modules according to this doc. That's why I'm thinking there might be different hardware revisions on the motherboard and different BIOS versions might support different memory configs. Or there are sockets on the motherboard that doesn't work.
@black3dynamite said in What Are You Watching Now:
@Pete-S Wow!
Yeah, they are extremely well built. I had to look up the weight just now because I remembered it was so heavy. There a few version but they all weight about the same - 400 lbs.
Fun stuff! Guy needs to learn the difference between a server rack and a network rack though. 
I used to have one of these Sun server racks in the apartment we lived in. Wasn't popular with the family, that's for sure. Mine was loaded with stuff but even empty they are really heavy.
IMHO the machine is just too old to mess around with. Should have bought a new or if money was tight, a refurbished server.
T410 has a Xeon 5500 series CPU. Then we had the Xeon 5600. Then the E5-2600 generation came followed by the E5-2600V2. Then the V3 and the V4. And now the Xeon Scalable.
That's a lot of water under the bridge. A nine year old computer is just not worth upgrading.
PS. The good thing is that the 4x16GB RDIMMs will work in everything up to a E5-2600 V2. Then everything became DDR4. A single E5-2600 V2 will be much faster than a dual 5500 series CPU. Use a lot less energy too.
@CCWTech said in DELL PowerEdge T410 - Memory Configuration Issues:
I have a client with a DELL PowerEdge T410. He has Dual Processors and (4) 16 GB RAM Sticks.
The memory is Samsung M393B2G70BH0-CK0 Samsung 16GB PC3-12800 DDR3-1600MHz ECC Registered CL11 240-Pin DIMM Dual Rank Memory Module Mfr P-N that was spec'ed out by PCM.
When he puts in 32 GB it works great. When he goes to 64 bit (32 on each CPU) the system blue screens/very unstable. He has swapped positions of the memory and only used 1 stick at a time to see if there is a bad module. The server is running Windows Server 2016 Standard.
Each memory stick passes the memory diagnostic.
This document says with 16 GB modules on Dual Processors that slots 1 and 2 (on each processor) should be populated for Optimized memory. https://downloads.dell.com/manuals/all-products/esuprt_ser_stor_net/esuprt_poweredge/poweredge-t410_user's guide6_en-us.pdf
The bios is set at Optimizer for the memory settings.
In the Dell Poweredge T410 Technical Guidebook it says 8GB RAM modules max.
There could be different hardware revisions of the motherboard. I assume you have the latest BIOS installed?
@PhlipElder said in DELL PowerEdge T410 - Memory Configuration Issues:
As a rule, the primary slot in each channel should be populated. So, 4 sticks per CPU.
Make sure Memory RAS settings are default and not stripe or mirror. That may be part of the problem.
Make sure the sticks are in the primary slot for each channel which is usually a different colour than the secondary and furthest from the CPU.
T410 is old 5500 series chipset which is triple channel, so I don't think you gain anything with 4 per CPU.
@DustinB3403 said in Redundancy is building a bridge and an identical one immediately next to it:
@Pete-S said in Redundancy is building a bridge and an identical one immediately next to it:
@DustinB3403 said in Redundancy is building a bridge and an identical one immediately next to it:
Redundancy is just about improving the odds.
No, redundancy is not about improving the odds. Redundancy is about having a redundant item.
Let me rephrase it. The purpose of redundancy is to improve the odds.
But in your very example of evolution. If redundancy is such a great thing, certainly we would have 2 of literally organ.
Better odds if one dies, right? Not quite true as @scottalanmiller has mentioned.
I don't think redundancy is a great thing. I think you should do a risk assessment and then come up with a plan how to mitigate the risk. IT isn't different than anything else in this regard.
Regarding evolution we are probably more geared towards surviving external threats than we are towards surviving internal organ failures by old age and a sedentary lifestyle.
@scottalanmiller said in Safe to have a 48TB Windows volume?:
@Pete-S said in Safe to have a 48TB Windows volume?:
The drive doesn't mechanically fail because it's build to work under high load. It can't be thermal because drives would slow down if they get too hot. It's not electrical because the drive doesn't die. So what is it then?
This statement makes no sense. The theory here is that drives don't experience stress, because they are "designed to work under high load." This is simply untrue. Are they "designed to work under high load", sure, whatever that means. But that doesn't change the fact that higher loads create higher stress.
My car's engine is "designed to work up to the red line". Whatever that means. But running the car near red line creates a lot more stress than running it at slower speeds. So engines running near red line regularly die much earlier than ones that do not. And they are mostly likely to die when at their highest RPMs.
Basically you are missing two key facts. The first that designed to work under high load is a meaningless phrase, it tells us nothing other than that some stressful situation is planned for, but failures are planned for, too. So that is not useful in determining anything else. And the second is that higher stress is higher stress regardless of what the drive is intended to handle.
Otherwise, drive failures would be impossible, since no drive is "designed to fail." Since drives do fail, we know that your statement doesn't indicated what you were saying.
If we look at the mechanical stress a rebuild is not so bad because it's sequential reading and writing. The disks are spinning regardless if you are reading or writing or doing nothing so that makes no difference. And the arms don't have move all over the place when you're doing sequential block operations.
But what I was implying is that the second drive doesn't fail for a mechanical reason because that would be the end of the drive. Isn't that your experience as well, that you end up with bad blocks but not dead drives?
@scottalanmiller said in Safe to have a 48TB Windows volume?:
@Pete-S said in Safe to have a 48TB Windows volume?:
@Obsolesce said in Safe to have a 48TB Windows volume?:
@Pete-S said in Safe to have a 48TB Windows volume?:
Just a side note but if you get a double failure on an array all is not lost.
Thing is that most drives are not dead, they have some bad blocks and they get kicked out of the array and when you don't have enough redundancy the array is shut down.
So you remove the bad drive and clone it to a new drive on another machine. For instance using
dd conv=sync,noerrorwhich means that the drive will cloned as good as it can be and any bad blocks are overwritten with zeroes. Now you can put the new drive back in the array and rebuild the array.It will rebuild fine but the file or files that had bad blocks in them will be corrupted and will have to be restored from backup. However the vast majority of the files will be fine.
In theory you could clone both failed drives. And it's unlikely that both drives have bad blocks in the same location. So theoretically speaking it is very likely that all your data is intact. You would need to use the data from the cloning process to know what blocks where bad on each drive and then the rebuild process would have to take that information into into consideration when rebuilding. Or come to think of it, if you could tell the array that all drives are fine and then do a data scrub and the array would be repaired correctly.
If it's a parity RAID, you don't have files on the drive. It's all parity. You get a URE and it's over. If any of that parity data is gone, you can't restore some random parity bit from backup.
If you mean recovering as good as possible from a double failure I wasn't talking about copying files. I was talking about cloning drives - bit by bit.
That can work. But often fails. How often have you seen a parity array recover from that?
And when you do see it happen, how long does that typically take? Time to recover is a factor that is often overlooked in reliability equations. But in the real world, especially with parity, we often have to discuss with customers "given how long this is expected to take to recover, would it not be better to have just lost the data and started over?"
When downtime is days, or weeks, or even months to "protect against data loss", often you just have to give up because it took too long.
I've only had to do it once myself. RAID5 with six drives I think. I think it was 4 TB drives so I guess a 20TB array. The second drive failed during rebuild. Cloned the second failed drive and rebuilt again. There was a problem with the backup so it was more a question of getting as much as possible up again and then figure things out.
But speed is interesting and that should be one of the primary factors when coming up with a strategy on how to backup and restore.
@scottalanmiller said in Safe to have a 48TB Windows volume?:
@Pete-S said in Safe to have a 48TB Windows volume?:
I'm not convinced about the "stress" for a rebuild.
It's easy to say. But decades of industry knowledge have accepted it as a known stress. I would not go against that without solid reasoning for it.
Parity rebuilds quite obviously do a lot more work than mirrored copies, over a longer period of time. So that there is additional stress both per drive and across the array is just common sense. That the evidence of this was so strong that it is common knowledge is just expected given the obvious additional wear and tear that hits it all at once.
Yes, it more drives involved as well which increases the risk but is the second failure really more statistically prone to happen during the rebuild process than if you would read the same amount of data from the same number of drives?
Have there been so many double failures during rebuild that there is actual data on this? The only thing I've seen has been calculations involving just the number of bits and the likely hood of URE.