how-to block ads
|
-
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
 ·Comcast
| reply to Ugly
Re: [SSD RAID-0] This will be so stupid fast! Anyone done this?
Over at the Intel Support Community forum I found this: said by Jozsef Dubravszky :
Hello!
I would like to know if Intel is aware of the issues with SSD's and RAID arrays regarding the lack of TRIM capability. More and more SSD drives support the block cleaning/optimising method aka. TRIM. Windows 7 has the operating system level support for it. As far as the user useres his SSD's in normal SATA/Legacy IDE mode this TRIM methid works because the OS can send the TRIM method calls directly to the drive itself. But if the user's SSD drives are in a RAID0 array TRIM capabilities are gone, because the Intel RAID controller does not pass through the TRIM method calls.
My question is that whether Intel is aware of this problem and if is there any effort to solve this issue? Are we seeing any driver updates soon?
Thank you in advance!
Regards Here's the rest of the threadsaid by zulishk :
Jozsef,
I personally wouldn't be too concerned with the TRIM capability to begin with, especially in a RAID configuration. There won't be a whole lot of performance gain since these SSDs are already very fast. Aside from that, your RAID controller is where the performance enhancements should be looked at. Are you using a RAID controller with a built-in cache? If it's an on-board RAID controller, probably not, and you won't see much performance gain by using RAID on these controllers -- just redundancy gains. I currently have an Intel-based RAID ICH10R and under all configurations of RAID 0 or 1 with two X25-E drives, the performance didn't change much from using just a single drive. I ended up buying an Adaptec card (the 5045) (sic: 5405) to see true gains. Perhaps it was a combination of the chipset and motherboard, but unless you are writing hundreds of thousands of tiny files, I don't see where your benefit for this feature would amount to much.
Personally, I feel the TRIM command defeats the purpose of wear-leveling, sacrificing lifespan for very little performance gains (there have been exceptions). Maybe there's still a significant difference for the X25-M series, but I've never used those. Anybody have links to some more information regarding TRIM benefits on the M series with the updated firmware? Other brands of SSDs wouldn't fit this topic.
Hope this helps. And it goes on. Skipping a couple posts.said by Jozsef Dubravszky :Thank you for your response but I think you might not get my point. I am not too muck into performance gains. The problem is that SSD write speeds degrade as you write more data on the drive. It is no concern with NAND chips wearout it is a matter of the method that SSD's use for writing and overwriting data. You can describe it as a kind of defragmentation but it is not that simple. You should check on this article if you are not sure what is TRIM: » anandtech.com/storage/showdoc.as···531&p=10. If you do not get any performance increase with RAID0 you have obviously going wrong. TRIM support is more likely to be solved on the RAID controller's side. Which brings us to the RAID controller.
Recall that zulishk had recommended a $400 Adaptec raid card to solve this issue.
Well, in a different thread at that same forum he is asking for a "zeroing tool" to reset his SLC drives.
Makes one think, "hum" about zulish's experience with SLC's.
Is it not as good as he is telling others, perhaps?
Meanwhile over on the Newegg forums m.oreilly has put it all together. (He posted in BOTH the Intel Support Community forum AND the Newegg forum.)said by m.oreilly at Intel :
william, it seems you are unawares of the multitude of mlc drives that are available do experience performance degradation w/o the sort of "cleanup" trim offers. regarding raid, i certianly notice the speed difference between using a single drive and 4 in a raid0 array, and would really like to have discard/trim support on my intel based workstation ich (which uses system ram for cache, if i'm not mistaken), which by the way offers very good performance (up to and including x4 ssd) compared to the adaptec you stated you have (i also run one, and the ich option performance is quite close). mlc drives are a bit different than the slc, and can really benefit from trim/discard. even slc can experience similar performance degradation effects over time w/o it's implementation. .. and ..said by m.oreilly at Newegg :the ticket...(referring here to the Adaptec 2258100-R PCI-Express x8 SATA / SAS (Serial Attached SCSI) 5405 Kit Controller Card RAID levels 0, 1, 1E, 5, 5EE, ... - Retail) » www.newegg.com/Product/Product.a···16103096Pros: tapping 900 reads and 680 writes w/this and 4x 30gig vertex drives. this is "the little card that could": 1.2ghz intel 348 iop, barebones card at stupid low price, one of the few inexpensive hba options that handles multiple raided high throughput ssds. nice to see newegg has this card in stock. Cons: might not be for everyone's system, as your particular mobo bios/irq headroom/smb situation may not play well w/the 5 series or similar cards from other manufacturers. Other Thoughts: that said, these are selling like hotcakes, and being used in high performance ssd raid arrays on varying system platforms with very positive results. until sata III/sas 6/pci-e drives are available, this is the ticket, and an inexpensive one at that... My read (pun) on all this is simple.
Intel is in BOTH the motherboard chipset and the hardware (SSD), so they have the most work to do on this.
(And the most to lose if it were to be somehow crappy.)
At the Intel forums (obviously, since it is hosted by Intel) there is a disciplined adherence to the company line of not giving hints or predictions of new product releases, firmware updates, etc.
Whenever this is finally resolved, given that Intel just dominates this (both of them, chipset and SSD, at the server level for sure) market; then it will be like someone had dynamited a dam.
The chipset updates, firmware revisions, BIOS updates, and new product announcements will burst forth in a torrent.
I'm not buying a $400 card to do through great effort what may become a free (and easier) standard feature of newer hardware within a few months.
And do not forget the fact that whatever performance one does gain from a tricked-out rig today will inexorably decline, so long as there is no TRIM.
Anand sums this up very well.said by Anand Lal Shimpi :
Every controller manufacturer I’ve talked to intends on supporting TRIM whenever there’s an OS that takes advantage of it. The big unknown is whether or not current drives will be firmware-upgradeable to supporting TRIM as no manufacturer has a clear firmware upgrade strategy at this point.
I expect that whenever Windows 7 supports TRIM we’ll see a new generation of drives with support for the command. Whether or not existing drives will be upgraded remains to be seen, but I’d highly encourage it. And this is THE greatest factor driving the entire process along.said by Anand Lal Shimpi :
with support for TRIM hopefully arriving close to the release of Windows 7, it may be very tempting to wait. Given that the technology is still very new, the next few revisions to drives and controllers should hold tremendous improvements. Anand sounds like he's on it. -- I'm holding off on any new SSD until fall, when Win7 is a commercial product.
As is so often the case, software is driving the hardware.
And finally, with MS, for good or bad, the leader in this regard, hardware manufacturers have a clear timeline (October 22) for SSDs to become compliant, if they wish to be ready for Win7.
»windows.microsoft.com/en-US/wind···=nonwin7
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to koitsu
The t13.org website is not a lot of help for dates.
I was somewhat surprised, shocked even, by v.1.3 being over a year old already!
The reasonable approach would expect TRIM in the next version, but that is not yet said anywhere explicitly, that I know of anyway.
This situation simultaneously raises the expectations for next version and incents t13.org to take its sweet time to do the job right, given the broad implications of TRIM upon manufacturers, SW, and OSs.
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
| reply to Ugly
Ah, I just replied to your private message before reading this post of yours. Sorry Ugly  . 
Yeah, that sounds likely, but it really depends whether or not TRIM remains purely a disk-level (read: ATA spec) thing. If so, then AHCI should work just fine with it as long as the OS submits the applicable TRIM commands. If not, then yes, AHCI would need to have native support for it, and who knows when that will be (as you said). 
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to koitsu
said by koitsu : I've also yet to find any actual specification details of said TRIM command; I can't find anything on t13.org, nor is there anything in Intel's official AHCI 1.3 spec. Short of contacting an engineer (as you kindly suggested) who is not at all likely to be willing to, so to speak, "make news" for Intel in such a dramatic fashion; let's consider another approach instead. My reasoning for not asking an engineer about the timeline for TRIM implementation is not important, except to say that I am skeptical in the extreme that he/she would know or, even if he/she did know, that he/she would directly answer such a question. Employers have rules on these things.
Now if there were an Intel engineer posting here at DSLR.com under a pseudonym, THAT might be different.
I have followed your link and found the various standards for ACHI: 0.95, 1.1, 1.2, and the current v.1.3.
Yet the dates of these prior releases are unclear. said by Intel :
The latest revision of the specification is Revision 1.3. Subsequent Revision 1.x levels of the specification will be completed by Intel at its discretion as time and circumstances permit. Not a word on the past version issue-dates!
And the t13.org website has not given anything that would suggest a decision date for v1.4 either.
So, the simplest question that I had considered over this weekend is:
• "What are the past release dates for the prior ACHI standards, please?"
One reasonably thinks this past timeline, were it known, might give a clue on the interval to release of the next version.
Frankly, it is looking highly likely that TRIM will be part of the new revision, whenever THAT comes.
So this becomes a reduced problem of only, when?
Hence the question on dates for the past version releases. Thank you, Ugly
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to koitsu
I found this at the Gigabyte Support website: Home > Support&Download > Motherboard > GA-EP45-UD3 > FAQ
said by GigabyteSupport :
Customer Q: After updating to latest bios there is a new option in Bios setup menu called the “SATA AHCI mode”, does this mean Intel ICH8 supports AHCI function?
Support A: Only Intel Southbridge chipset model names that include a R/DO/DH will support AHCI and RAID functions. The function ICH8 AHCI can only be enabled under Vista. If you are using Windows XP/2000 please disable the function “SATA AHCI mode” in bios. Now I know the fellow was asking about his ICH8 chipset and my mobo has the Intel ICH10R.
But this support answer does strongly hint or imply that Gigabyte anticipates AHCI to be implemented soon.
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
1 edit | reply to Ugly
T13 is the official organisation responsible for the ATA spec (this includes SATA).
Intel is the official organisation responsible for the AHCI spec.
I'm not sure if there's a timeframe for the next draft to become standard. You can look at the working drafts if you wish, as well as T13 committee minutes to see what's been discussed recently.
Footnote: no, I'm not a member of T13. I'm just one of those crazy (Aquarian) sysadmins who spends way too much time with ATA/SATA.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to koitsu
said by koitsu : It's a really great feature, so I can understand everyone's enthusiasm, but it's not standardised yet! Wow, great post!
It there a target date or timeline for the TRIM standard to be finished?
What organization is the authority on this, please?
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
3 edits | reply to Ugly
Not exactly. I've re-written the below quite a few times trying to explain it, because it's not something you can just write tersely and have it all make sense.
SATA devices such as hard drives and SSDs all speak a form of ATA protocol. This is often referred to by revision, e.g. ATA-4, ATA-6, ATA-7, ATA-8, etc... You can see what ATA revision applies to what kind of devices over at Wikipedia. The ATA protocol revision defines what commands (see below) a device should ("can") support.
SATA ATAPI devices (CD/DVD drives) speak the ATAPI protocol, but we're not going to talk about those.
Certain drive features are only available via AHCI. Commonly, these are: hot-swap functionality (which can also be achieved through a custom OS driver) and NCQ. Again, Wikipedia explains some of what AHCI provides.
You might be wondering: "why do I need AHCI to use NCQ?" This is a little off-topic, but I'll describe it anyway. NCQ is actually something that has to be supported on the SATA controller as well as the disk itself. Instead of the OS submitting one request at a time to the controller ("I want to read this LBA from device X" "Please wait. Okay here's your data" "Thanks, now I want to write this LBA to device X" "Please wait..."), the OS can actually submit multiple requests (called commands) to the SATA controller. The controller and/or disk can then re-order those commands based on where on the disk (physically) you're trying to access, so that things are accessed in a more rotational-disk-friendly order -- otherwise you have to wait until the platters make another revolution before being able to get your data, which wastes time. Wikipedia documents the feature quite well. NCQ plays a huge role in server environments, where you might have a server submitting tons of read/write requests all at once, and you want all those read/write requests optimised in proper order based on the above.
And now TRIM (see the link for a pretty awesome walk-through from t13 about what it's solving):
I haven't read anything in the specifications that indicates TRIM is a controller-driven or controller-centric feature. Meaning, I have no indication that a SATA controller needs "support for TRIM". On the other hand, all of the specifications I've read so far indicate that the 1) device (disk) and 2) host OS have to support TRIM. There's an article over at ibm.com with regards to Linux supporting TRIM, and all I see there is mention of it being required on the device and in the OS -- no mention of SATA controller involvement.
This could change. TRIM could become something that requires AHCI, leaving the OS (mostly, but not entirely) out of the picture. In this situation, an AHCI specification update would be required, and that could be provided via a SATA controller BIOS upgrade or a PC BIOS upgrade (for on-board SATA).
There simply isn't enough evidence at this point. This sounds harsh (especially given that I'm posting on a forum), but I can't trust what I read over on the OCZ forums -- those are just residential users blabbing about what's better and lots of mumbo jumbo. I'd really have to talk to an *actual engineer* familiar with both the in-draft ATA specification as well as SSDs to determine where the focus point is.
Bottom line: the world doesn't know enough about TRIM at this point to make it a deciding factor when purchasing an SSD, a SATA controller / motherboard, or an OS. It's a really great feature, so I can understand everyone's enthusiasm, but it's not standardised yet!
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to koitsu
said by koitsu :Meaning: with ATA, it's up to 1) the OS (We assume here - Win7 RC) to know what commands to send to the drive, and 2) the drive to understand said commands. But with regards to AHCI, that might be a different story altogether. AHCI does appear to define a list of permitted commands per specification revision, and (usually) a controller can support a newer AHCI revision assuming its microcode can be updated. Usually this is done via a PC BIOS upgrade.But as I mentioned, I can't find any confirmation of TRIM existing in the AHCI 1.3 specification, nor on t13.org (who's responsible for the ATA command set, e.g. ATA-8 and so on). EDIT: Ah ha, I found it! The TRIM command isn't part of any official standard at this point -- it's defined in a working draft over at t13:» www.t13.org/Documents/UploadedDo···CS-2.pdf"So how do I do this?" Well, not easily. ... On Windows, it's probably possible too, but I have no idea how to interface with an ATA drive at such a low level on Windows. But remember, this is a working draft, which does not guarantee any existing devices (on market or in development) support it. Some can, but they don't have to; it's not an official published standard yet, hence "working draft". For all we know, the word offset at 169 could be moved to some other offset in the next draft. *shrug* This is much like vendors releasing 802.11n WiFi devices on the market when the specification isn't even out of draft yet. Hum, I think the point here is that one should not even think about finding TRIM as a standard mobo feature for a while.
And I'm certainly NOT going to try hacking this myself!
Whenever it DOES become available, (assuming by then one's mobo is not too old for the manufacturer to even bother) the addition of the TRIM functionality will be done via offering a new BIOS update file to download from the mobo manufacturer's website. Of course, newly manufactured mobos will ship with TRIM already installed in the shipping BIOS.
Frankly, I am happy to wait for a coherent standard and do not need a manufacturer to try a rushed rogue implementation by itself.
• Have I got this right koitsu ?
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
4 edits | reply to Ugly
I don't think the motherboard/chipset (specifically southbridge) would be responsible for TRIM. Well, sort of. I'd better explain.
The ICH10 acts as a controller, but does not act as an ATA command filter device. You can submit invalid ATA commands to a disk attached to the SATA bus, and you'll get back an error from the drive if the command isn't supported -- this happens all the time with OSes like Solaris and Linux which do SATA-to-SCSI emulation (drive appears in the OS as a SCSI drive, uses SCSI utilities and kernel features, but when sending actual commands to the drive, go through a software (kernel) "translation" layer which maps SCSI commands to ATA).
Meaning: with ATA, it's up to 1) the OS to know what commands to send to the drive, and 2) the drive to understand said commands.
But with regards to AHCI, that might be a different story altogether. AHCI does appear to define a list of permitted commands per specification revision, and (usually) a controller can support a newer AHCI revision assuming its microcode can be updated. Usually this is done via a PC BIOS upgrade.
But as I mentioned, I can't find any confirmation of TRIM existing in the AHCI 1.3 specification, nor on t13.org (who's responsible for the ATA command set, e.g. ATA-8 and so on).
EDIT: Ah ha, I found it! The TRIM command isn't part of any official standard at this point -- it's defined in a working draft over at t13:
»www.t13.org/Documents/UploadedDo···CS-2.pdf
Relevant sections:
- Section 7.10.3.2
- Section 7.18.7.1
- Section 7.18.7.30 (defines "indeterminate behaviour", e.g. if capabilities don't match)
Based on Section 7.18.7.1, issuing command 0xEC (IDENTIFY DEVICE) to the device attached to the ATA bus, and examining bit #0 of word 169, we can determine whether or not the device supports TRIM (1 == available, 0 == not available).
"So how do I do this?" Well, not easily. I think Linux offers a way to submit custom ATA commands to the device and get back all the raw data returned. FreeBSD offers this capability but only through SCSI (using "camcontrol cmd"). It's definitely possible to modify FreeBSD's ata(4) driver and atacontrol(8) command to support something similar. On Windows, it's probably possible too, but I have no idea how to interface with an ATA drive at such a low level on Windows.
But remember, this is a working draft, which does not guarantee any existing devices (on market or in development) support it. Some can, but they don't have to; it's not an official published standard yet, hence "working draft". For all we know, the word offset at 169 could be moved to some other offset in the next draft. *shrug* This is much like vendors releasing 802.11n WiFi devices on the market when the specification isn't even out of draft yet.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to sdgthy
said by sdgthy :
Nice find, I was wondering what exactly TRIM was...
I think if you check the 2CPU thread it's mentioned that a later firmware version for the Intel X25-E added TRIM support.
OK, so that only leaves the mobo chipset as being unclear on whether it does or does NOT support the TRIM command.
• Any ideas on the mobo supporting TRIM, please?
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
sdgthy
@optonline.net
 from:
Ugly
| reply to Ugly
Nice find, I was wondering what exactly TRIM was...
I think if you check the 2CPU thread it's mentioned that a later firmware version for the Intel X25-E added TRIM support.
It's starting look like all the good SSD's will only be SATA.  I want a PATA version for my laptop... | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
| reply to Ugly
said by Ugly :It looks like Win7 is gonna be good. -- Perhaps even better than the Hardware? • How does one know if the X25-E Intel SLC drives can handle the TRIM command? I'd Email Intel Support and ask. (If I was keeping my X25-M I'd probably consider doing this myself.) Be sure to request that the question be given to an actual engineer for confirmation.
There's an answer on the Intel forums, but I would take it with a grain of salt.
I've also yet to find any actual specification details of said TRIM command; I can't find anything on t13.org, nor is there anything in Intel's official AHCI 1.3 spec. The only way to be sure to is to get in contact with an actual engineer.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to koitsu
said by koitsu :And do not let anyone tell you that AHCI == RAID; that's false. I use AHCI on all of my ICH7R boards and *do not* use BIOS-level RAID. AHCI is just an interface command specification that's standardised so OSes can speak AHCI to the controller rather than having to speak the classic ATA protocol(s). It's a good protocol when implemented correctly ( Intel has it down pat, AMD/ATI has theirs down pretty good with some quirks, and I have no idea about nVidia, VIA, JMicron, or SiliconImage). I got this from a friend:
»en.wikipedia.org/wiki/TRIM_(SSD_command)
said by Wikipedia :
TRIM has already been implemented in Windows 7 release candidate, but until solid state drives are updated with firmware that can understand the command, it will simply be ignored. It looks like Win7 is gonna be good. -- Perhaps even better than the Hardware?
• How does one know if the X25-E Intel SLC drives can handle the TRIM command?
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
Fishead1
Premium
join:2001-05-08
Bronx, NY
| reply to Martinus
Am I right that all your gaining with a RAID 0 is loading time like booting up and in games when they need to populate a new area say in a game or reloading a saved game?
I went thru the whole RAID thing back in 2005 and thought I was going to have games run faster.
I can see the value in other RAID 1 ,RAID 5,RAID 10 ,etc for back up of important stuff (redundancy). | |
Martinus
Premium
join:2001-08-06
EU | reply to Ugly
Great thread.
So, the consensus is that Windows 7 correctly aligns partition boundaries on install and you don't need to do anything extra "by hand"?
I'm planning on getting a couple of SSDs for my next rig when W7 comes out. | |
Ugly
Fishy Cool Bird
join:2001-12-12
The Meadow
·Comcast
| reply to Cabal
said by Cabal :
Vista and Windows 7 correctly align partition boundaries on install.
So here's the current plan, involving BOTH XP and Win7. (not wasting time w/ Vista)
1. The mobo gets up and running with an ordinary spinniing platter HD and boot from Win XPpro.
2. Next, a SSD or pair of SSD's are added.
3. Boot into Win7 install disc and employ tools of Win7 installer to create SSD partition for OS and Raid-0 (no bios-type Raid!). Bird says, "No need for Raid-driver floppy and F6. This is Win7" -- Right? 4. Complete Win7 installation.
Result = dual boot: XP and Win7.
Is this good?
--
Oh, I love the smell of fish. Guts, rotten, it's all good. | |
Cabal
Premium
join:2007-01-21
Boston, MA
| reply to koitsu
said by koitsu :This proves that you literally cannot "drop in" an SSD to be a HD replacement, at least with XP. That's correct. I'm not sure why you're surprised, though, it was released 8 years ago. Vista and Windows 7 correctly align partition boundaries on install.
At this time, I don't believe any Linux or BSD distributions do so correctly, either, but there are plenty of write-ups about it.
»thunk.org/tytso/blog/2009/02/20/···ck-size/
--
Interested in open source engine management for your Subaru? | |
aurgathor
join:2002-12-01
Lynnwood, WA
| reply to koitsu
said by koitsu :This proves that you literally cannot "drop in" an SSD to be a HD replacement, at least with XP. That actually depends on the type of the SSD. DRAM based, or simpler flash based SSD should have less issue than flash based SSDs with sophisticated firmware.
--
And the winner is: | |
sdgthy
@optonline.net
from:
Ugly
| reply to koitsu
said by koitsu :This proves that you literally cannot "drop in" an SSD to be a HD replacement, at least with XP. Same thing applies for a RAID array, it's nothing new. I do think I've seen something about Vista making this easier. | |
|
