Sign in to follow this  
steve8

The Best OCZ Core SATA SSD information

Recommended Posts

So SSD are also extremely vulnerable to filesystem fragmentation? :o

Imagine NTFS trying to fill gaps. 64KB here, 256 there, 512 more. To save 832KB, it has to read-modify-write 30MB!

Edited by Benfica

Share this post


Link to post
Share on other sites
So SSD are also extremely vulnerable to filesystem fragmentation? :o

Imagine NTFS trying to fill gaps. 64KB here, 256 there, 512 more. To save 832KB, it has to read-modify-write 30MB!

well yeah i mean u wouldnt wanna defrag an SSD...

but most stuff thats fragmented wouldnt be re-writtent a lot...

regardless i think SSDs are essentially understood by the effective

random read/write seek times

and the effective sequential throughput

Share this post


Link to post
Share on other sites

A few more comments:

Watch out when using the word cell instead of block.

Your OCZ core SSD is apparently made with MLC flash chips, where according to Wikipedia a cell can typically store 2 bits (contrary to SLC where a cell stores 1 bit).

An erase block consists of multiple cells - lots of them.

BTW where you calculate the random "seek" times for writes the table header says read instead of write.

Share this post


Link to post
Share on other sites
A few more comments:

Watch out when using the word cell instead of block.

Your OCZ core SSD is apparently made with MLC flash chips, where according to Wikipedia a cell can typically store 2 bits (contrary to SLC where a cell stores 1 bit).

An erase block consists of multiple cells - lots of them.

BTW where you calculate the random "seek" times for writes the table header says read instead of write.

thanks ill update my word choice regarding cell/block ,and fix that read/write wrong-word issue.

Share this post


Link to post
Share on other sites

In your article:

For a horribly fragmented drive, where free space is sparse, the penalties for a large write could be as numerous as the number of clusters on the disc! This situation is highly avoidable, and very unlikely.

No, IMHO it's not it! When deleting files, temp, temporary internet files, copies, etc... gaps are created. Then, to create new files NTFS tries to find free space from the beginning of the drive. Therefore fragmentation starts very soon, you don't need to have low disk space.

Another thing, IMHO the OCZ core has got to have both SLC and MLC. High grade and cheapo flash in multi-channel or whatever. And the first 25% of the drive is SLC. The MFT is there, NTFS will soon find small files will fit. And every HDTune benchmark shows the same.

If you wish, create 2 partitions: 1 smaller than 16GB and the 2nd using the rest. The second will hit the lala land, it will not be funny to have the $mft and $logfile there :P

And why the irregular pattern? The HDTune block size. It is configurable on v2.54 and above, go to Options->Benchmark. They recommend HDTach on their paper, because maybe the block size is 8MB, no wonder! Look at the OCZ Specs, Random Write ~= 18MB/s and look at the 8MB value on your "Random Write Performance: Actual vs Predicted"

Share this post


Link to post
Share on other sites

In your article:

For a horribly fragmented drive, where free space is sparse, the penalties for a large write could be as numerous as the number of clusters on the disc! This situation is highly avoidable, and very unlikely.

No, IMHO it's not it! When deleting files, temp, temporary internet files, copies, etc... gaps are created. Then, to create new files NTFS tries to find free space from the beginning of the drive. Therefore fragmentation starts very soon, you don't need to have low disk space.

Another thing, IMHO the OCZ core has got to have both SLC and MLC. High grade and cheapo flash in multi-channel or whatever. And the first 25% of the drive is SLC. The MFT is there, NTFS will soon find small files will fit. And every HDTune benchmark shows the same.

If you wish, create 2 partitions: 1 smaller than 16GB and the 2nd using the rest. The second will hit the lala land, it will not be funny to have the $mft and $logfile there :P

And why the irregular pattern? The HDTune block size. It is configurable on v2.54 and above, go to Options->Benchmark. They recommend HDTach on their paper, because maybe the block size is 8MB, no wonder! Look at the OCZ Specs, Random Write ~= 18MB/s and look at the 8MB value on your "Random Write Performance: Actual vs Predicted"

Share this post


Link to post
Share on other sites
Guest Vantage72
Besides the low random write results, real world performance of these OCZ SSDs is still very, very good.

I'm not too sure about that. Users on dutch forums have reported many freeze ups, even when they were doing something as simple as opening 2 tabs in Opera with youtube...

And they had their pagefiles switched off.

More examples of performance problems:

http://blog.laptopmag.com/in-depth-with-th...es-low-cost-ssd

Edited by Vantage72

Share this post


Link to post
Share on other sites
Another thing, IMHO the OCZ core has got to have both SLC and MLC. High grade and cheapo flash in multi-channel or whatever. And the first 25% of the drive is SLC. The MFT is there, NTFS will soon find small files will fit. And every HDTune benchmark shows the same.

If you wish, create 2 partitions: 1 smaller than 16GB and the 2nd using the rest. The second will hit the lala land, it will not be funny to have the $mft and $logfile there :P

And why the irregular pattern? The HDTune block size. It is configurable on v2.54 and above, go to Options->Benchmark. They recommend HDTach on their paper, because maybe the block size is 8MB, no wonder! Look at the OCZ Specs, Random Write ~= 18MB/s and look at the 8MB value on your "Random Write Performance: Actual vs Predicted"

I think you are bonkers and I think it's all MLC.

Take a peek at http://www.ocztechnology.com/ssd/OCZ_Core_...es_SSD_SPEC.pdf

Technical/ Performance Notes

• RAID support: Please refer to the original manufacturer’s manual or bundled diskette.

Raid support for Solid State Disks is not mature and may require specific driver

installation, please view our resource guide should you have an issue

• SSD performance may vary slightly based on chipset and OS

• AHCI mode should not be used while installing windows with Intel chipsets due to known

conflicts during installation which may slow or corrupt installation; installation is best

handled in IDE mode and dependent on chipset should often be left disabled, but can be

used after installation.

• Due to sector size and block size variation between hard drives and SSDs, benchmarking

could be effected, recommended benchmarks include HD bench, ATTO, win bench and

IO Meter. Older benchmarks that use HDD optimized sector sizes may show invalid Write

test results that vary highly.

Share this post


Link to post
Share on other sites
I think you are bonkers and I think it's all MLC.

Care to elaborate and prove on what I'm wrong :rolleyes:

Care to prove that you are right?

I mean show me a statement from a reliable source that there is a single SSD on the market that has SLC and MLC mixed just to at least give a baseline for reasonability of your claim.

Wait. I'll do it for you. Apacer makes a combo drive that is 96GB because it has 32 GB SLC and 64 GB MLC. But then they market that information and besides the 96GB gives it away as an odd size for an SSD.

http://usa.apacer.com/us/news/News_05_28_2008_162.htm Notice how the specs mention a different read/write rate per type of flash.

The OCZ Core series comes in expected drive sizes. It doesn't fit the mold for a SLC + MLC product.

So lets revise that request show me a link from a reliable source saying that the OCZ is using multiple flash chip types and what amount of flash is SLC versus MLC in the 32GB product or for 64GB, or even for 128GB.

Share this post


Link to post
Share on other sites
Care to prove that you are right?

No, I don't have to prove it. I'm talking about this possibility as the justification for the irregular writing pattern from the 16GB onwards.

The burden of proof is always on the one that claims that something is impossible

The OCZ Core series comes in expected drive sizes. It doesn't fit the mold for a SLC + MLC product.

This argument is flawed, as manufacturers don't care about what you expect or what is your notion of mold.

Share this post


Link to post
Share on other sites
Care to prove that you are right?

No, I don't have to prove it. I'm talking about this possibility as the justification for the irregular writing pattern from the 16GB onwards.

The burden of proof is always on the one that claims that something is impossible

No, the burden of proof is on the person that makes a claim. In this case we both did so we both have the burden of proof on our shoulders and one of us will be proven wrong. If you don't want to contribute to the process of finding out which one of us that is then stop posting. Eventually the answer will be known and whoever is right can say I told you so and the person that is wrong can admit they were wrong. It's not the most complex process in the world but so far I haven't seen a single URL or bit of evidence to back up your claim.

BTW there was a reason I quoted the paragraph below

Due to sector size and block size variation between hard drives and SSDs, benchmarking

could be effected, recommended benchmarks include HD bench, ATTO, win bench and

IO Meter. Older benchmarks that use HDD optimized sector sizes may show invalid Write

test results that vary highly.

You seem to be paying attention to irregularities in benchmarking and assuming it implies a variation in hardware inside the drive. It is entirely possible that the drive is all one type of flash and there is still variation in benchmark results.

I still haven't seen a specific rebuttal on:

* Apacer showing SLC + MLC in specs but OCZ not.

* The possibility that chipset/OS combinations affect SSD performance

* The possibility that benchmark apps could give misleading results

and to this point I haven't been able to find a single article on the web that supports your supposition that the OCZ Core series uses SLC + MLC. I've read dozens of reviews, news articles, specs, hundreds of comments on other forums. You are the only one I see making this claim.

Prove me wrong and I'll thank you for doing so.

Share this post


Link to post
Share on other sites
Besides the low random write results, real world performance of these OCZ SSDs is still very, very good.

I'm not too sure about that.

I dont have first hand experience but someone i trust says so.

Users on dutch forums have reported many freeze ups, even when they were doing something as simple as opening 2 tabs in Opera with youtube...

And they had their pagefiles switched off.

More examples of performance problems:

http://blog.laptopmag.com/in-depth-with-th...es-low-cost-ssd

I havent read that link yet.

You get all sort of problems in windows vista if you disable pagefile altogether. That's the main source of their problems.

Besides, I know that there are some compatibility problems, so its not that these drives are the solution to all sins.

Edited by Telstar The Sorcerer

Share this post


Link to post
Share on other sites

MLC AND SLC?

well that would certainly complicate the matter of programming.

And probably make at least a 2-Channel Controller necessary.

But anyway.

There's pictures on the net of disassembled / dismantled OCZ Core 128GB.

There's only one type of Chips on the board. Samsung MLC Flash Chips.

Share this post


Link to post
Share on other sites
In your article:
For a horribly fragmented drive, where free space is sparse, the penalties for a large write could be as numerous as the number of clusters on the disc! This situation is highly avoidable, and very unlikely.

No, IMHO it's not it! When deleting files, temp, temporary internet files, copies, etc... gaps are created. Then, to create new files NTFS tries to find free space from the beginning of the drive. Therefore fragmentation starts very soon, you don't need to have low disk space.

Another thing, IMHO the OCZ core has got to have both SLC and MLC. High grade and cheapo flash in multi-channel or whatever. And the first 25% of the drive is SLC. The MFT is there, NTFS will soon find small files will fit. And every HDTune benchmark shows the same.

If you wish, create 2 partitions: 1 smaller than 16GB and the 2nd using the rest. The second will hit the lala land, it will not be funny to have the $mft and $logfile there :P

And why the irregular pattern? The HDTune block size. It is configurable on v2.54 and above, go to Options->Benchmark. They recommend HDTach on their paper, because maybe the block size is 8MB, no wonder! Look at the OCZ Specs, Random Write ~= 18MB/s and look at the 8MB value on your "Random Write Performance: Actual vs Predicted"

There are some HUGE false assumptions in the above discussion.

first, NTFS: It doesn't just write a file in the first available free block (that was FAT). It tries to fit it in the first _contiguous_ block of the size of the write. So yeah, a program that writes a file by a lot of small appends will have a problem. Otherwise, no.

More importantly -- you are assuming that the SSD is like a hard disk. It does NOT have to map its space linearly, and in fact, if it has any wear leveling at all it won't. You think it needs higher reliability flash in one "region" due to the MFT? Or maybe due to the swap drive?

Well the whole wear-leveling part of the device makes that all go away. The first few MB of the disk are not always mapped to the same set of flash cells.

Simple wear leveling works like this: You want to write? Write to a random erase block, preferably a free one. Read the old one, write to the new one. Then, change the map that specifies which erase block corresponds to what 'position' in the drive. If there is no free erase blocks some compaction will have to occur.

Yup -- the actual erase blocks have to be virtualized in order to do this sort of wear leveling -- but it makes all your concerns above go away. You can't make a well designed SSD die by writing a single byte a half million times -- since you won't actually be making the same erase block do the read/write, but instead it would be spread over all the erase blocks.

Now, I don't know which drives are using what sort of wear leveling algorithms, but people have known about the concerns you have above long long ago and are working on solutions.

Some have claimed to have fixed the random write cost (Intel, FusionIO, and others).

My guess on how this can be implemented:

In the wear leveling algorithms, some extra processing and storage is used to better virtualize the blocks and track them, and a pure copy-on-write policy is used at the low level. If the disk gets 1000 4k write requests to various random locations, just put all those in the same block and change the map of disk locations to the erase blocks and their sub-blocks. This mapping metadata can be stored in the header of each block, with a transactin id or timestamp. An internal RAM based representation of this map is used during normal operations and rebuilt from the metadata by 'playing back' the metadata in the order it was written. That order could also be easily tracked in the metadata -- think linked list. All it has to do is know what the next free block for writing is before it commits the prior write.

The hardest part will be random writes with an os sync that forces a flush to disk with small writes. In that case, batching writes together into a block can't be done. Hence, the need for some smaller erase blocks -- a set of smaller ones for use when bigger write transactions are not possible would be handy.

From what I can see -- all these tricks will make SSD drives start to perform worse on writes as the drive fills up. I'd guess that after about 90% full, it would start to get real slow or need regular "compaction" actions. But no disk really works that well when almost full and writing data.

Share this post


Link to post
Share on other sites
For a horribly fragmented drive, where free space is sparse, the penalties for a large write could be as numerous as the number of clusters on the disc! This situation is highly avoidable, and very unlikely.

There are no huge false assumptions there,, I said could , and if there is no contiguous area on the disc large enough to fit the write, it'll be fragmented, and worst case, is: horribly..worst case with bad fragmentation is minutes for a single write, since each partial cluster write costs around 1/4th of a second.

Share this post


Link to post
Share on other sites
There are some HUGE false assumptions in the above discussion.

More importantly -- you are assuming that the SSD is like a hard disk. It does NOT have to map its space linearly, and in fact, if it has any wear leveling at all it won't. You think it needs higher reliability flash in one "region" due to the MFT? Or maybe due to the swap drive?

Well the whole wear-leveling part of the device makes that all go away. The first few MB of the disk are not always mapped to the same set of flash cells.

Simple wear leveling works like this: You want to write? Write to a random erase block, preferably a free one. Read the old one, write to the new one. Then, change the map that specifies which erase block corresponds to what 'position' in the drive. If there is no free erase blocks some compaction will have to occur.

This reminds me of an old story ... in Indian mythology, the Earth is supported on the back of an elephant. "Well, what's the elephant standing on?" "Don't be silly - it's elephants all the way down!"

Where is the map stored? What is the wear life of the mapping cells?

Share this post


Link to post
Share on other sites
This reminds me of an old story ... in Indian mythology, the Earth is supported on the back of an elephant. "Well, what's the elephant standing on?" "Don't be silly - it's elephants all the way down!"

Where is the map stored? What is the wear life of the mapping cells?

Read my post -- this was already explained. The mapping information goes in the cell that is being written. In simple terms, the block being written IS the mapping block -- its self-descriptive. Finding this data can be done many ways -- a timestamp or transaction ID in the metadata allows for order discovery. Or, the order can be implicit: If the next erase block to be used after the current one is known (it should be -- erases are pipelined ahead of requests) then a pointer to the next erase block is written too. So a linear, linked list of the erase block write order is persisted . . . When you power up, scanning all the "map regions" of each block into some RAM can be used to reconstruct the state of the entire thing and produce the "TLB" of sorts. Play the mapping metadata changes back in chronological order, with more recently written blocks map metadata overwriting old ones, and the resulting map is consistent and represents the last known state before power down.

Simply think of the mapping metadata in each block like a mapping transaction. Play them back in order on power-up and the result is a full, current map.

Also note that SSD's can buffer writes into small RAM bits and use a supercapacitor to write that last bit of cache to flash in the event of a power loss.

The random write penalty already has been largely overcome by smart designs, by engineers that can see past the elephants.

Micron/Intel/FusionIO are the ones I know of at the moment. Intel claims 30,000 read IOPS with 3300 write IOPS on 4k blocks. (250MB read 170MB write streaming 4k). No, random write performance won't ever be as good as random read performance. But it will be a lot better than random writes on spinning magnetic disks. A little write buffering (safely) and translation of random writes to sequential batches with address translation, and poof! Its pretty good. The better, the more expensive however because:

1. It takes more processing and RAM and more software and testing.

2. It capacity is reduced because of metadata storage needs.

Also, you could just use a file system that converts random writes to sequential ones, such as ZFS or (in the future) btrfs -- so long as you don't have too high of a requirement on synchronous writes/sec. Fragmentation in such systems will no longer matter.

Now, I will admit to some flaws in my original post -- not all SSD's have great wear-leveling algorithms and many of the first and second generation ones are not very good. But the point is that it is possible to make every one of those concerns, especially those about fragmentation and the MFT or swap file -- go away with good engineering.

Share this post


Link to post
Share on other sites

Where is the map stored? What is the wear life of the mapping cells?

Read my post -- this was already explained. The mapping information goes in the cell that is being written. In simple terms, the block being written IS the mapping block -- its self-descriptive.

Ah right, I must have skimmed past that the first time 'round. I see, sorry, thanks for the explanation.

It begins to remind me of old mainframe disk extents...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this