Raid0 and TRIM Support on Intel 11.5 OROM and Latest v11.5.0.1184 RST Drivers ?

[radier]

Z77, Z68, P67, X58 are just few examples of popular chipset that has ICH10R inside.

[Fernando]

Z77, Z68, P67, X58 are just few examples of popular chipset that has ICH10R inside.

Please reread, what I have written: Z68 chipsets are not supported by the Trim+RAID0 feature and I dont think, that P67 or X58 are!

[radier]

Then you are wrong apparently. Z77 is no different than Z68 in terms of SATA controller.

As for now release notes for RST 11.5 WHQL are missing and no official info was given about TRIM in RAID 0.

Your experiments does not prove anything.

BR,

[andressergio]

Then you are wrong apparently. Z77 is no different than Z68 in terms of SATA controller.

As for now release notes for RST 11.5 WHQL are missing and no official info was given about TRIM in RAID 0.

Your experiments does not prove anything.

BR,

Chill mate...we are not fighting here just trying to discover what going on with this new ROMS and drivers, a job that intel and others should published clear and cloudy as they did...

[m.oreilly]

if these as ssd results are what you are going by, check out mine, and i'm not using any drivers or an os that would facilitate trim:

night before last, after some heavy storage benching:


afer reboot the next day (i believe the difference would be because of GC, not raid trim...):

just amazing. my GC/non 'trim' results are way more dramatic than any of the so called trim results in this thread...
this morning, system uptime 15 minutes, cup of coffee, and a couple of benches:





100% incompressible test data too...

[m.oreilly]

you guys should be lobbying intel for their intel here. on one hand we have MS saying 'no win7 trim', and intel saying 'raid trim', but not delineating which os they claim trim to be working under, though just because the drivers are for several os do not mean that win7 is in with win 8, unmap wise. trimmed data should not be zeros, it should be ones or 0xFF. i hope intel put out a clearer message as to what they are claiming...

[Fernando]

Then you are wrong apparently. Z77 is no different than Z68 in terms of SATA controller.

If there is no difference in terms of SATA Controller, why do the SATA AHCI Controllers have different DeviceID's (DEV_3A22 = "Intel(R) ICH10R SATA AHCI Controller", DEV_1C02 = "Intel(R) Desktop/Workstation/Server Express Chipset SATA AHCI Controller")?

As for now release notes for RST 11.5 WHQL are missing and no official info was given about TRIM in RAID 0.

If you run the RST Console Software of the latest official Intel RST driverpacks and hit "Help" > "Introduction" you can see the required "official info" given by Intel about TRIM in RAID0:

TRIM
This feature provides support for all pass-through solid-state drives (SSDs) in your storage system that meets the ATA-8 protocol requirements. Also, support is provided for SSDs that are part of a RAID 0 array.

Everything clear?

Your experiments does not prove anything.

I trust my own experiments more than any info of a vendor, who primarily wants to earn money.

[m.oreilly]

clear? no. no os is mentioned, and it would rely on the unmap commands sent down. why do you think we are seeing 'scsi' even for single drives? the drivers will pass through an unmap command, but there isn't one from win7.

[Fernando]

why do you think we are seeing 'scsi' even for single drives? the drivers will pass through an unmap command, but there isn't one from win7.

Win7 is not able to send the UNMAP command, but the Intel SCSI filter driver iaStorF.sys is able to change the Trim command to an Unmap command. That is the reason why Intel is now using 2 drivers simultaneously (iaStorF+iaStorA.sys), whereas the "normal" Intel MSM and RST drivers always had just 1 single driver named iaStor.sys.

[andressergio]

Win7 is not able to send the UNMAP command, but the Intel SCSI filter driver iaStorF.sys is able to change the Trim command to an Unmap command. That is the reason why Intel is now using 2 drivers simultaneously (iaStorF+iaStorA.sys), whereas the "normal" Intel MSM and RST drivers always had just 1 single driver named iaStor.sys.

+1 for this

[DooRules]

Any issue with loading the 11.5 rom on an x79 bios?

[m.oreilly]

Win7 is not able to send the UNMAP command, but the Intel SCSI filter driver iaStorF.sys is able to change the Trim command to an Unmap command. That is the reason why Intel is now using 2 drivers simultaneously (iaStorF+iaStorA.sys), whereas the "normal" Intel MSM and RST drivers always had just 1 single driver named iaStor.sys.

where do you get this? quite an assumption. you would need two drivers anyways: trim hint and unmap hint passthrough. single ahci+trim/ahci driver, raid would need unmap, hence the scsi. where are you getting documented info that drivers are 'converting' trim to unmap hints, and the os is oblivious to this? i know some are bandying about the idea of a low stack driver, but this is not taking into consideration the os's part, and i have not seen any working examples of this anywhere on earth documented as working. you are making a rather big assumption, and i would like again to know what you are basing your opinion on. i can find ms docs showing that win7 will not and can not pass unmap, and that it would take the os to have that in it's api, but i can't find any bona fide info re drivers creating unmap out of basic trim hints. please share...

[m.oreilly]

Any issue with loading the 11.5 rom on an x79 bios?

unless you have a dual bios option that works, i would not try it.

[m.oreilly]

ok, i'll toss out a bone. yes, there have been manufacturers that have demonstrated trim capable raid controllers, but the required windows api was not going to be changed on ms's side...some time passes, and we see win8 getting all perky and including unmap. intel is a big player, as is MS in the now burgeoning solid state storage/server market. it has to be seamless in execution, and with what we got in the pot as players, it may take some more umpf to get 'magic' drivers in place. when we see lsi and areca touting win7, or really, server 2008 r2 unmap passthrough, i'll be a believer al la that win kernel/magic drivers are here.

[m.oreilly]

ok , another bone toss. you have computurd here. sorry for the tug, but you could ask him if areca or lsi are passing on server 2008 r2 unmap drivers. sorry comp, but intel consumer boards running win7 getting raid trim above server class(?) just doesn't sit right...

[DooRules]

unless you have a dual bios option that works, i would not try it.

Sure do.

[Marc HFR]

trimmed data should not be zeros, it should be ones or 0xFF

So please explain me why on a standard single AHCI SSD it's also 00 00 00 etc. ?

Note that on some SSD like Vertex 4 it's FF FF FF FF etc.

[canthearu]

TRIMmed data is generally whatever the controller chooses it to be. Most SSDs do not have a static LBA to physical address mapping scheme like hard drive do .... so what happens is that the SSD actually creates the mapping between LBAs and physical locations when you perform writes. This avoids the read->erase->rewrite operations that caused so many latency problems with old jmicron drives. This means, that if you haven't written to a particular LBA number, then there is nowhere to read it back from. Thus the controller simply creates a fake sector with whatever data it wants (FF or 00)

When you secure erase a drive, or delete files off it with TRIM, you are also eventually removing the LBA mapping for the sectors you are erasing. This means again, that the drive must create a fake sector if you then attempt to read it.

[radier]

Have you noticed process IAStorDataMgrSvc.exe ?

It is consuming memory step by step.

[m.oreilly]

So please explain me why on a standard single AHCI SSD it's also 00 00 00 etc. ?

Note that on some SSD like Vertex 4 it's FF FF FF FF etc.

i assume 0x00 is a programmed state. which drives under what conditions report 0x00 as clean nand? i'm hoping you guys have really hit on something here, but i'm just not getting enough documentation that points to what you are claiming. i wish intel would be a little more forthcoming. i don't understand why they wouldn't be, but until they do, i really can't drink the coolaid...

[Fernando]

Have you noticed process IAStorDataMgrSvc.exe ?
It is consuming memory step by step.

You are right and we have noticed that already earlier, but this has nothing to do with the topic of this thread, because it is a software issue (since v11.5.1184) and not a driver or RAID ROM one.

[medeirosdez]

Hello everyone!

I have subscribed to this forum and spent one dollar just to inform you there is an updated ROM, version 11.5.0.1582 available!!!

I contacted Biostar requiring an update to the OROM for the motherboard of the server of my gaming center. The mobo is T5XE CFX-SLI, P55 chipset. It was abandoned quite some time ago and left with OROM 9.5.x.xxxx. I asked them to updated BIOS so OROM was brought to the most recent version, and they sent me a new BIOS with the mentioned version.

I sent another email asking if 11.5.0.1582 is the latest stable release and they replied saying soquete 1156 mobos are discontinued and that every update is special and beta only, no support. We'll have to wait until Intel updates their own current mobos so we know which OROM is indeed latest. At least this one I offer is more recent.

Now, I don't know how to extract the OROM from the BIOS file, but I give you the link they provided me with so you can extract yourselves. Whomever manages to do extraction, please provide community with public link so everyone can download! Yes, it's OROM 11.5.0.1582 and proof follows by pictures I took during boot. It even works on P55 (soquete 1156) PCH.

I was shocked, astonished, that I got a positive reply, I mean, I'd never ever expect that they'd update the firmware just for me! OMG! I'm sooooo happy!

Also, there is one thing I noted: they changed recommended strip size for RAID0 arrays. It used to select automatically 128KB, now it chooses per se 16KB. OROM screen below shows 8KB strip, but that's because I used that array with OROM 9.5.x.xxxx before and in my test that's where I achieved maximum performance. I've reformatted the HDD's, now I use 16KB and 16KB NTFS cluster ("unit") size on all partitions.

This is the link:
http://206.108.48.66/temp/Eric/P55DA726.zip

IMG_0017.JPG

[Marc HFR]

i assume 0x00 is a programmed state. which drives under what conditions report 0x00 as clean nand? i'm hoping you guys have really hit on something here, but i'm just not getting enough documentation that points to what you are claiming. i wish intel would be a little more forthcoming. i don't understand why they wouldn't be, but until they do, i really can't drink the coolaid...

Corsair Force 3 or Intel 330 for example

But like canthearu said it's not clean NAND, it's "clean" LBA

[Fernando]

FYI:
I just have tested, if the presence of the new Intel RAID ROM module v11.5.0.1582 does change anything regarding the Trim support of an Intel Z68 chipset RAID0 array.
Result: It doesn't. The sector with the freshly deleted file didn't zeroed out. The original Hex data were still there.

[m.oreilly]

i think you guys are relying on the hex 'results' a little too much, especially with multi drive lun and single/'shared' lba. both drives you mentioned are sandforce based, and with their inherent encryption/lba jiggery pokery, i think you would still be looking at programmed with 00 returned...still not buying it...