Poor Mans Raid and Disk Tips

[WarDad]

I started this piece of work to satisfy my own curiosity. Last year I wanted to RAID 0 on my new AMD 965 system, but ended up dual booting because W7-64 was too young. It's going to be a Christmas gift this year. I already have this years Sandy Bridge system up and running.

What a mix:
Crucial M4 SSD,
Two 1TB WD Caviar Blacks,
Two 2TB Hitachi Cool Spin 5K3000 green drives,
AMD SB850 + GigaByte SATA controllers, on a GA-890GPA-UD3H
Intel South Bridge and Marvell SATA controllers, on a ASUS P8P67 Deluxe
One Lab Rat professional IC evaluator

I present to you a link to Poor Mans Raid and Disk Tips.pdf Poor Mans Raid and Disk Tips.pdf

]

Tip: Intel P67 South Bridge combining one SSD and a HDD RAID. Tip changing SATA drivers in XP.

 

[Steevo]

I just updated firmware and hit almost 1Gbps on my RAID array in read. Buy a cheaper board and a better disk subsystem.

 

[WarDad]

Steevo, are you comparing apples to oranges? My RAIDS were two HDDs, 2 x 137 MBs does not equal 1GB. My benchmarks file space was much larger than disk cache.

 

[Steevo]

Agility 3 don't have a cache.

 

[WarDad]

Ok, I meant OS (W7) disk cache. The Agility 3 is an SSD, not a HDD and it will have some cache on it, even if it is not an advertized feature.

This was editied after some useful comments on another forum. It took a while to get around to it. Now is a good time as HDD prices are finally falling some.

If you like it, bump it.

 

[Deleted member 3]

Please read the forum guidelines. No double posting, you can post all pictures in a single post. Also, if you'd post them as text it's actually searchable by users and google.

As for the article itself:
Why would south bridge SATA controllers have better drivers? Source?
Windows write cache is unrelated to disk cache
NCQ doesn't work at the file level, it queues read/write operations
What is the link between block size and unallocated space?
2 disks also give the option of Intels matrix RAID.
SATA controllers have nothing to do with GPT.
Why do you conclude arrays made of consumer disks should be limited to 2 drives?
Why do you imply RAID 5 is unreliable with large disks?

Also note that RAID 0 technically isn't RAID, hence the 0.

 

[Aquinus]

Please read the forum guidelines. No double posting, you can post all pictures in a single post. Also, if you'd post them as text it's actually searchable by users and google.

As for the article itself:
Why would south bridge SATA controllers have better drivers? Source?
Windows write cache is unrelated to disk cache
NCQ doesn't work at the file level, it queues read/write operations
What is the link between block size and unallocated space?
2 disks also give the option of Intels matrix RAID.
SATA controllers have nothing to do with GPT.
Why do you conclude arrays made of consumer disks should be limited to 2 drives?
Why do you imply RAID 5 is unreliable with large disks?

Also note that RAID 0 technically isn't RAID, hence the 0.

You're not the only person who has expressed concern about the article itself. There was similar reception on tomshardware.com.

 

[WarDad]

Please read the forum guidelines. No double posting, you can post all pictures in a single post. Also, if you'd post them as text it's actually searchable by users and google..

As for the article itself:

"Why would south bridge SATA controllers have better drivers? Source?"
Source: Experience and Benchmarks. I read it somewhere.
Also, Intel and AMD have more resources to spend on chip sets.

"Windows write cache is unrelated to disk cache."
Just try finding a reference or link on windows write cache.
The write cache is mostly in the HDD.

"NCQ doesn't work at the file level, it queues read/write operations."
OK, now BRIEFLY try explaining that difference to a newbie.

"What is the link between block size and unallocated space?"
Huh? Are you refering to my work around for a specific SSD issue?
Partioning an SSD on block boundries has been a topic on many SSD forums.

"2 disks also give the option of Intels matrix RAID."
What? Did you not understand the conumdrum?

"SATA controllers have nothing to do with GPT."
The SATA controller is not just hardware, there's BIOS and OS Drivers.
I only want to raise awarness of possible HDD size issues.
There is plenty of GPT advice out there.

"Why do you conclude arrays made of consumer disks should be limited to 2 drives?"
It's a WD recommendation. Read their reasons for it.

"Why do you imply RAID 5 is unreliable with large disks?"
Why is RAID 6 replacing Raid 5? Review some articles on it.
I thought I did a good job of briefly covering that.

"Also note that RAID 0 technically isn't RAID, hence the 0."
Yea, so what? Technically "COLD" does not exsist, but I do say "It's cold out.".

 

[Disparia]

Perhaps the best thing you could do is add an intro to your document, addressing the scope and target audience. Otherwise we're a nitpicky bunch

 

[Aquinus]

Actually, I'm more concerned on the entire document as a whole. It is written like a paper but there isn't a single reference. Are you claiming all of this work as your own? There are a lot of missing things and quite frankly it's a lot of unsupported claims, a bunch of screen shots, no tabular data, no charts with comparisons, and worse of all, not a single reference.

Otherwise we're a nitpicky bunch

I'm more than nit picky. I'm just an ass that finds every cloud where ever there is a silver lining.

"SATA controllers have nothing to do with GPT."
The SATA controller is not just hardware, there's BIOS and OS Drivers.
I only want to raise awarness of possible HDD size issues.
There is plenty of GPT advice out there.

Right, but the BIOS and OS drivers for the SATA controller doesn't impact what partition table is used, that is 100% the OS.

"Also note that RAID 0 technically isn't RAID, hence the 0."
Yea, so what? Technically "COLD" does not exsist, but I do say "It's cold out.".

Except RAID-0 is a real raid level, it's just not redundant.

"NCQ doesn't work at the file level, it queues read/write operations."
OK, now BRIEFLY try explaining that difference to a newbie.

Every time data is written or read on a computer, what is being added, remove, or updated is added to a queue that gets used by the hard disk controller to determine that fastest way to execute all of the commands in the queue. That wasn't too hard...

"Windows write cache is unrelated to disk cache."
Just try finding a reference or link on windows write cache.
The write cache is mostly in the HDD.

Windows write caching uses system memory to cache reads and writes, the drive itself handles caching, the firmware handles that.

All in all, I don't think you know what you're talking about. I don't want to give an "I know everything" impression, but I also have a degree in Computer Science, I'm a Systems Admin and Developer professionally, and honestly architecture was one of my more favorite topics. What I can tell you that you is that you have a lot to learn, not just as looking at numbers and putting a computer together, but actually understanding how the hardware works and why it works that way.

 

[Disparia]

Hopefully defining a scope would help shape the document towards that goal

Otherwise this thread could go several pages into changes lol! Much of it though might be unnecessary because it is about things that shouldn't be there in the first place or a different approach should be taken.

 

[WarDad]

All in all, I don't think you know what you're talking about. I don't want to give an "I know everything" impression, but I also have a degree in Computer Science, I'm a Systems Admin and Developer professionally, and honestly architecture was one of my more favorite topics. What I can tell you that you is that you have a lot to learn, not just as looking at numbers and putting a computer together, but actually understanding how the hardware works and why it works that way.

Actually, I do know computer architecture, electronics, and earn a good living at it. I only dabble with PCs, and I am surprised at how much of the inside info is not readily available on the web. MS windows cache document is many OS's old, so no telling off hand exactly how it's applied to later flavors and their updates. If the info I do glean is not totally correct, then complain about Marketing departments nixing meaningfull engineering data.

Hopefully defining a scope would help shape the document towards that goal

Otherwise this thread could go several pages into changes lol! Much of it though might be unnecessary because it is about things that shouldn't be there in the first place or a different approach should be taken.

Good Point.

Except RAID-0 is a real raid level, it's just not redundant.

OK now... Everyone is right.. RAID 0 is and is not a real raid level.
(as I quickly duck and cover, then head for the exits)

 

[Albuquerque]

I am surprised at how much of the inside info is not readily available on the web.

It is my interpretation that you simply do not know where to look. For example...

MS windows cache document is many OS's old, so no telling off hand exactly how it's applied to later flavors and their updates. If the info I do glean is not totally correct, then complain about Marketing departments nixing meaningfull engineering data.

Microsoft Software Developers Network contains data all the way down to kernel calls for everything in the OS stack. The freely available technical library and resources are appalling in scope, depth, and topics. Here is a link that touches the very very tip of the epic file system caching iceberg that took me about nine seconds on MSDN to find: http://msdn.microsoft.com/en-us/library/windows/desktop/cc644950(v=vs.85).aspx They may not give you the specific algorithms or raw source code, but they provide a monumental amount of resources for people who know to ask.

I agree with posters above that your document is critically flawed in a multitude of points, to the extent that it gives bad advice based on bad data. Even worse, and to your own admission, you seemingly "made stuff up" when faced with a perceived lack of data. If you're trying to come to the topic in an authoritative sense, you need authoritative sources to back your claims. And you have none.

 

[WarDad]

It is my interpretation that you simply do not know where to look. For example...


Microsoft Software Developers Network contains data all the way down to kernel calls for everything in the OS stack. The freely available technical library and resources are appalling in scope, depth, and topics. Here is a link that touches the very very tip of the epic file system caching iceberg that took me about nine seconds on MSDN to find: http://msdn.microsoft.com/en-us/library/windows/desktop/cc644950(v=vs.85).aspx They may not give you the specific algorithms or raw source code, but they provide a monumental amount of resources for people who know to ask.

I agree with posters above that your document is critically flawed in a multitude of points, to the extent that it gives bad advice based on bad data. Even worse, and to your own admission, you seemingly "made stuff up" when faced with a perceived lack of data. If you're trying to come to the topic in an authoritative sense, you need authoritative sources to back your claims. And you have none.

OK now, from that info give the size of the Windows Write Buffer. Also since apps can set FILE_FLAG_NO_BUFFERING, and use their own buffering how does a user know? Why would the omission of this info affect any of the data taken, and be missleading? I would think that too much data is a problem in it's self.

 

[Aquinus]

OK now, from that info give the size of the Windows Write Buffer. Also since apps can set FILE_FLAG_NO_BUFFERING, and use their own buffering how does a user know? Why would the omission of this info affect any of the data taken, and be missleading? I would think that too much data is a problem in it's self.

When your program issues a write command to the file system (assuming that file system buffering is enabled), the write goes into the operating system disk cache, and periodically, the data from the operating system disk cache is flushed to the hard drive. As we saw above, the hard drive lies to the operating system and says "Yeah, I wrote it," even though it hasn't really done it yet. The data the operating system requested to be written is just sitting in a RAM buffer on the hard drive, that in turn gets flushed out to the physical medium by the hard drive firmware.

Source - MSDN Blogs

 

[Albuquerque]

OK now, from that info give the size of the Windows Write Buffer. Also since apps can set FILE_FLAG_NO_BUFFERING, and use their own buffering how does a user know? Why would the omission of this info affect any of the data taken, and be missleading? I would think that too much data is a problem in it's self.

The size of the Windows write buffer is dynamic; it depends on a multitude of circumstances. Obvious things, like the quantity of ram installed in your machine, the quantity of available (unallocated) ram left after the OS and applications have taken their reservations, and the setting for "Background" versus "Foreground" application priority are the biggest factors. Also factored in are how many writes and reads you've been doing (in total bytes, and over total time.)

Windows isn't SMARTDRV.SYS; it doesn't just "decide" a value and stick to it - nor does any other modern operating system. If you want to know how big the disk cache is, open up Perfmon and dig through the cache counters.

And again, you want to talk about misleading? Howabout telling people that the Windows disk cache really isn't anything except the built in harddrive cache? That's outright lying. If you think "too much data" is the problem, then you need to stop the outright fabrication of even more data.

Edit: Regarding apps that purposefully disable write-back cache: that doesn't mean they disabled read cache, nor does it mean they disabled write-through cache either. Operations that use this are typically high availability, high reliability applications that the purported target of your document wouldn't be using. If in fact they DID use such an application, Windows is smart enough to tell the physical disk to force the actual HDD cache buffer as well, bypassing both levels of cache.

Thus, again, your document is purposefully misleading for absolutely no reason whatsoever. In what way is your misleading document helping someone trying to learn? In what way is your misleading document helping someone optimize their system? The things that you are fabricating destroy any remaining credibility that your document might have.

 

[WarDad]

OK, I challenge you all to write your own brief guide for newbies, and motherboard raid with benchmarks. I have not seen much of anything on the web for it.

That the OS should have a stagging area or funnel (cache) for the slower HDD is not a relevation.

 

[Albuquerque]

Howabout if you write your own, but this time, don't make stuff up? A newbie guide shouldn't be 10 pages, it should be perhaps two (obviously a bit more for pictures, but whatever.) It should cite references that can be used for more in-depth reading for those who want to read it.

The crux of this whole thread and your defense of this document is that you claim it's targeted at people who don't know but want to start learning. Unfortunately you populate your document with a monumental amount of opinion and nonfactual data spun as a defacto guide. Do you not see the cognitive dissonance in what you've done? Your willingness to ignore these glaring contradictions has now forced you onto some defensive tactic that is even less useful.

Look at your claims even in this simple thread: you say there's too much data for newbies to understand, but then you go off and make up even more answers that aren't true. You say newbies who need to know about caching, but then you wave it off like everyone already knows about OS cache. You go on a mini-tirade about how Microsoft hasn't talked about Windows internals in decades due to marketing and you can't find anything online. And then we point you to MSDN; a public, google-indexed, oft-referenced on this site and many others online repository of knowledge spanning two decades of Microsoft operating system technology.

Rather than trying to defend a provably broken document, howabout you (the author) fix it so that newbies who find your broken document don't make a bunch of bad decisions and/or create a whole set of bad assumptions going forward?

That seems, you know, far more logical. But hey, what do I know? Other than, well...

 

[theeldest]

OK, I challenge you all to write your own brief guide for newbies, and motherboard raid with benchmarks. I have not seen much of anything on the web for it.

That the OS should have a stagging area or funnel (cache) for the slower HDD is not a relevation.

If this is supposed to be for newbies, then please say that explicitly in the first post.

An authoritative commentary on RAID and SATA controllers is quite a bit different from an introduction to using multiple drives for a first time user.